Configuration of Rendering Service
This document describes the Rendering Service (also sometimes referred to as the Rendering Worker Service) - an application providing worker threads for handling Camunda tasks that ships with priint:suite 4 - Publishing Server.
You need Java 17 to run the rendering-service.
1. Configuring Application Properties
Your pubserver uses either Adobe InDesign Server® (short: ids) or priint:pdf renderer (short: pdf). Depending on the renderer type the Rendering Service must use either the configuration in 'application-ids.yml' or 'application-pdf-renderer.yml'.
Some settings are the same for both cases.
1.1. Common Settings
The default port for Rendering Service is 8880. Change it to for example 8881 with this setting:
server:
port: 8881
The connection to the pubserver is controlled by the following settings:
priint:
app-name: "renderingservice1"
comet:
bridge:
# Comet-bridge url/user/password are used to make the rendering-server (PDF Renderer or Adobe InDesign Server) connect to the pubserver.
# Please remember that the URL provided here needs to be resolvable by the rendering-server from its machine!
url: http://localhost:40082/CometBridge/Comet3Service
user: admin
password: somePassw0rd
# List of comma-separated project identifiers. Provide all projects you expect this rendering-service to process tasks for.
# This list is used on application startup to connect to comet bridge on pubserver. A connection is created for each project.
# That way you can get instant feedback if the connection fails, the rendering-service does not need to wait for a first task to arrive.
# Warnings are issued to logs if tasks from projects not listed here arrive as the application tries to recover and provide
# additional connections in such cases. It is best however to list the projects here in advance and keep this list up-to-date.
projects: DefaultProject,someOtherProject
planner-engine:
url: http://localhost:40080/PlannerEngine/api
# The user added here needs to be assigned to or have access to projects this rendering-service will process. Make sure you either
# explicitly configure this account to take part in projects or grant it a role that enables it to access any project.
user: admin
password: somePlannerEnginePassw0rd
If your installation uses different settings for host, port, user, password or project, please change them. Use localhost in the urls, if your rendering service is installed on the same host as the pubserver.
The connection to priint-bpm is controlled by the following settings:
priint:
camunda:
externalclient:
base-url: http://localhost:8888/engine-rest/
password: someCamundaPassw0rd
user: admin
backoff-time: 600
# Leave empty to handle all processes. Provide a comma-separated list of process keys to process only those processes.
handled-processes:
If your installation uses different settings for host, port, user or password, please change them.
Rendering settings are controlled using the following settings:
priint:
rendering:
# This determines how opening a document for rendering processes should work.
# If both rendering-service and rendering-server (eg. InDesign Server) have access to the same paths,
# set this to TEMP_COPY to open documents during rendering from a copy or IN_PLACE if no copying is required.
# If a rendering-server works on another machine and paths to the document files differ from what rendering-service perceives,
# use the IN_PLACE_TRANSLATED or TEMP_COPY_TRANSLATED values.
rendered_document_open_mode: IN_PLACE
# This determines how the document template should be accessed for grid element preview generation.
# If both rendering-service and rendering-server (eg. InDesign Server) have access to the same paths, set this to TEMP_COPY.
# If a rendering-server works on another machine and paths to the same files are different from its point of view,
# use the TEMP_COPY_TRANSLATED value.
preview_document_template_open_mode: TEMP_COPY
# This determines how the document template should be accessed for fire and forget script execution and PDF generation.
# If both rendering-service and rendering-server (eg. InDesign Server) have access to the same paths, set this to TEMP_COPY.
# If a rendering-server works on another machine and paths to the same files are different from its point of view,
# use the TEMP_COPY_TRANSLATED value.
fire_and_forget_script_pdf_open_mode: TEMP_COPY
# Unless both rendering-service and planner-engine have access to the document root path,
# this should be set to match the setting in the planner-engine.
# This also needs to be set when using the IN_PLACE_TRANSLATED open mode.
document_root_path:
# Unless both rendering-service and planner-engine have access to the document root path,
# this should be set to how it is perceived by the rendering-service.
# This should also be set if the IN_PLACE_TRANSLATED mode is used.
rendering_worker_document_root_path:
# This should be equal to how it is perceived by the rendering-server (eg. InDesign Server) if only the IN_PLACE_TRANSLATED mode is being used.
rendering_server_document_root_path:
# This should be set to a temp folder path from a rendering-service perspective if the TEMP_COPY or TEMP_COPY_TRANSLATED open modes are being used.
rendering_worker_temp_folder_path: /tmp
# This should be set to a temp folder path from a rendering-server (eg. InDesign Server) perspective if the TEMP_COPY_TRANSLATED mode is being used.
# Note: this prefix should most likely end with a [back]slash due to the way InDesign Server uses this as a prefix to format file paths.
rendering_server_temp_folder_path:
# This determines the resolution of preview files generated along with document metadata during rendering
document_preview_resolution: 120.0
# This is the time it takes for file systems to sync so that Adobe InDesign Server notices a document file has been created by rendering-service
# or for the rendering-service to see that the remote rendering-server altered or created some files
file_system_changes_propagation_delay_millis: 3000
# In scenarios where rendering-service waits for Adobe InDesign Server files to become visible to it via the file system,
# this sets the period between the active checks if the expected file appeared
file_system_changes_probe_period_millis: 500
# Document metadata creation can be done asynchronously - it all depends on the scripts the rendering-server runs.
# This property sets the delay rendering-service should wait for the metadata to be created by the rendering-server.
# Leave this at 0 if the metadata creation script operates synchronously.
# Set it to the maximum time expected between when the metadata creation script returns and when the actual files get created in the file system
# if that script triggers asynchronous metadata file creation.
document_metadata_creation_delay_millis: 0
# This is the time needed for Adobe InDesign Server lock files to disappear once a document gets unlocked
document_closing_timeout_seconds: 10
1.2. Special Settings
Some settings are unique between Adobe InDesign Server® and priint:pdf renderer.
1.2.1. Settings for Adobe InDesign Server®
If your pubserver uses Adobe InDesign Server®, the following setting is needed (and already in application-ids.yml):
spring:
profiles:
active: indesign-server
No further changes in application-ids.yml are needed.
1.2.2. Settings for priint:pdf renderer
If your pubserver uses priint:pdf renderer, the following settings are used:
priint:
pdfrenderer:
pdfr_native_library_path: C:/PubServer440/rendering-worker-service/native/win
pdfr_config_path: C:/PubServer440/rendering-worker-service/config
installation_path: C:/PubServer440/rendering-worker-service/src/lib/lib
spring:
profiles:
active: pdf-renderer
Please adjust the three paths to your installation folder.
Detailed description of external properties overrides available can be found here.
2. Observability
2.1 Logging
You can configure logback to output logs as desired. When defining your own application-....yml, just define a pointer to logback config file like this:
logging:
config: your-logback-file.xml
Then create your-logback-file.xml next to your jar and application....yml. Example configuration you might use as a start:
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="30 seconds">
<include resource="org/springframework/boot/logging/logback/defaults.xml"/>
<include resource="org/springframework/boot/logging/logback/console-appender.xml"/>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>rendering-service.log</file>
<encoder>
<pattern>%d{HH:mm:ss.SSS}|%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
</encoder>
</appender>
<!-- Appenders and loggers below should only be set when working with the PDF renderer -->
<appender name="PDF-RENDERER-INSTANCE-1" class="ch.qos.logback.core.FileAppender">
<file>C:\comet\log\pdf-renderer-1.log</file>
<encoder>
<pattern>%d %p %c{1} [%t] %m%n</pattern>
</encoder>
</appender>
<logger name="com.priint.comet.renderer.pdf.Instance1" level="INFO" additivity="false">
<appender-ref ref="PDF-RENDERER-INSTANCE-1"/>
</logger>
<appender name="PDF-RENDERER-INSTANCE-2" class="ch.qos.logback.core.FileAppender">
<file>C:\comet\log\pdf-renderer-2.log</file>
<encoder>
<pattern>%d %p %c{1} [%t] %m%n</pattern>
</encoder>
</appender>
<logger name="com.priint.comet.renderer.pdf.Instance2" level="INFO" additivity="false">
<appender-ref ref="PDF-RENDERER-INSTANCE-2"/>
</logger>
<appender name="PDF-RENDERER-INSTANCE-3" class="ch.qos.logback.core.FileAppender">
<file>C:\comet\log\pdf-renderer-3.log</file>
<encoder>
<pattern>%d %p %c{1} [%t] %m%n</pattern>
</encoder>
</appender>
<logger name="com.priint.comet.renderer.pdf.Instance3" level="INFO" additivity="false">
<appender-ref ref="PDF-RENDERER-INSTANCE-3"/>
</logger>
<appender name="PDF-RENDERER-INSTANCE-4" class="ch.qos.logback.core.FileAppender">
<file>C:\comet\log\pdf-renderer-4.log</file>
<encoder>
<pattern>%d %p %c{1} [%t] %m%n</pattern>
</encoder>
</appender>
<logger name="com.priint.comet.renderer.pdf.Instance4" level="INFO" additivity="false">
<appender-ref ref="PDF-RENDERER-INSTANCE-4"/>
</logger>
<!-- END of PDF renderer appenders and loggers -->
<root level="INFO">
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
</root>
<logger name="com.priint" level="INFO"/>
</configuration>
2.2 Health checks
Health and separate readiness and liveness endpoints can be activated by adding the following lines to application/yml:
management:
endpoint:
health:
show-details: ALWAYS
probes:
enabled: true
health:
livenessstate:
enabled: true
readinessstate:
enabled: true
endpoints:
web.exposure.include: health
Following endpoints will become accessible by HTTP GET at runtime:
http://your-host:your-port/actuator/healthhttp://your-host:your-port/actuator/health/readinesshttp://your-host:your-port/actuator/health/liveness
3. Configuring worker properties
You are not done yet, the workers are configured in a second file, either workers-config-ids.json or workers-config-pdf.json. These are not YML, but JSON files.
Use workers-config-ids.json for Adobe InDesign Server®:
{
"workerTypes" : [
{
"workerType": "InDesignWorker",
"defaultWorkerConfig": {
"type": "InDesignWorker",
"topic": "priint-rendering",
"lockDuration": 600000,
"maxTasks": 1,
"usePriority": true
}
}
],
"applications" : [
{
"applicationName" : "renderingservice1",
"workersPools" : [
{
"type" : "InDesignWorker",
"workersConfig" : [
{
"type" : "InDesignWorker",
"indesignServer": "http://localhost:4712"
},
{
"type" : "InDesignWorker",
"indesignServer": "http://localhost:4713"
},
{
"type" : "InDesignWorker",
"indesignServer": "http://localhost:4714"
}
]
}
]
}
]
}
Add as many workersConfig as there are Adobe InDesign Server® instances reserved for rendering workers. Please note, that an instance can be used either for a rendering worker or for the old comet server. If the same instance is used from both services, a lot of strange problems will occur. Adjust the URL of the instance to your configuration. The port must be the port set by the instance option -cometport on the instance.
Use workers-config-pdf.json for priint:pdf renderer:
{
"workerTypes" : [
{
"workerType": "PdfRenderingWorker",
"defaultWorkerConfig": {
"type": "PdfRenderingWorker",
"topic": "priint-rendering",
"lockDuration": 600000,
"maxTasks": 1,
"usePriority": true
},
"defaultWorkersCount": 4,
"maxWorkersCount" : 4
}
],
"applications" : [
{
"applicationName" : "renderingservice1",
"workersPools" : [
{
"type" : "PdfRenderingWorker"
}
]
}
]
}
No further changes in workers-config-pdf.json are needed.
3.1 Workers Configuration File Structure
This section describes the fields found in the worker config files in the order of their appearance. A description of the idea behind the format of this config is also provided along with detailed explanations of the config values.
3.1.1 Fields in worker configuration file
Here is a description of the fields in the order they appear in the file
| Field name | Mandatory | Values | Description | ||
| 1st level | 2nd level | 3rd level | |||
| workerTypes | required | list of worker types - for now only 1 is used at once | |||
| workerType | required | PdfRenderingWorker, InDesignRenderingWorker | |||
| defaultWorkerConfig | optional | set | It is a sub-set of properties from worker-specific configuration which should be common for all the worker instances. These values will be pre-set for every worker in every application (but can be potentially overriden on the lower lever) - for the structure refer to section 3.1.3 | ||
| defaultWorkersCount | optional | number | if a worker doesn't require low level config settings (like Adobe InDesign Server® url which has to be different for each worker) you can just specify default number of its instances. This value can be also overriden on lower levels. | ||
| maxWorkersCount | optional | number | maximum number of workers of a given type. | ||
| applications | required | ||||
| applicationName | required | string | it is matched from priint.app-name application property | ||
| workerPools | required | list of worker pools - one for each worker type working on a given machine. When one type is used then would be only 1 entry for every application | |||
| type | required | must be set the same as workerType | the only required field for a worker pool allowing us to link it to a given workerType - must be equal to workerType value | ||
| defaultPoolLevelConfig | optional - not used | allows to define worker specific configuration common for all the workers in the pool. Specified values will potentially override the values from the type level and can be still overriden on the concrete worker level. For the structure refer to section 3.1.3 | |||
| workerConfigs | optional | one of the possibilities to specify concrete worker instances - there will be as many workers as entries of this array. It allows you to define different configuration for every worker. Each config is a sub-set of properties from worker-specific configuration - for the structure refer to section 3.1.3 | |||
3.1.2. Worker types
In the workerTypes field is defined only the type of the worker. No worker will be started if only this field is set. It is just the type definition (like a class without an object instance). Certain worker behavior (rendering through Adobe InDesign Server® or priint:pdf renderer through a pdf library) is associated with a given worker type.
Only 2 types are available in Worker Service: PdfRenderingWorker and InDesignRenderingWorker - each of them requires different configuration properties.
3.1.3. Worker specific configuration
There is a fixed set of configuration properties for every worker type. Each configuration consists of common properties and custom properties.
3.1.3.1 Common properties
Common properties are the same for all the types and for the moment we use the following ones: type, topic, lockDuration, maxTasks, usePriority. These fields are used to configure and initialize the Camunda client. Their meaning is the following:
| Property | Required | Value | Description |
|---|---|---|---|
| type | required | PdfRenderingWorker, InDesignRenderingWorker | workerType is required for every config property definition - it must be the same as workerType field of a given worker |
| topic | required | priint-rendering | the camunda topic name for a given worker type - this field shouldn't be modified |
| lockDuration | required | number in millis | defines for how long the camunda will lock a given camunda task for processing by a given worker. After this time passes the given task may be unlocked and given to another worker |
| maxTasks | required | integer | defines how many tasks should be fetched at once when accessing Camunda. Typically, equal to 1 when tasks should be fetched one by one. It is not recommend changing this value unless there is a big number of tasks which has to be processed in parallel and fetching them one by one would require too many requests and may be too slow. This field is required. |
| usePriority | optional | boolean | true by default - if set to false camunda will ignore task priorities when fetching tasks |
3.1.3.2. Custom properties
Custom fields are exclusive for a given worker type and are typically related to its specialization. For example InDesignRenderingWorker uses obligatory indesignServer property. Here is full set of properties for InDesignRenderingWorker:
{
"type": "PdfRenderingWorker",
"topic": "priint-rendering",
"lockDuration": 600000,
"maxTasks": 1,
"usePriority": true,
"indesignServer" : "http://localhost:4714"
}
3.1.3.3 Configuration levels
The files are named global-xxx-workers-config.json. Reason to use global in name is that the structure is prepared to manage configuration of workers on multiple machines in one central place. Then the worker properties can be defined on various levels:
1. workerType 2. application - machine on which it is working 3. concrete workers on a given machine which live inside workerPools - one for each workerType
On each level you can define a sub-set of all the configuration properties for a given worker type. At the same time when the application starts, it always checks the whole file by for example checking if properties are globally unique and obligatory values are present. To take the advantage of such validation define the same file for all the applications (machines) running Worker Services and map to the proper application level configuration by setting the appropriate priint.app-name.
4. Running the Application
On Windows as user application start a cmd, cd to the rendering-worker-service folder.
If your pubserver uses an Adobe InDesign Server®, execute:
start-rendering-service-ids.bat
If your pubserver uses a priint:pdf renderer, execute:
start-rendering-service-pdf.bat
You can create a Windows Service instead. The file worker-service-4.4.xml controls the features of the service.
<service>
<id>rendering-worker-service-4.4</id>
<name>rendering-worker-service-4.4</name>
<description>Rendering Worker Service for priint:suite 4.4</description>
<executable>C:\PubServer440\java\jdk17\bin\java</executable>
<arguments>-jar "%BASE%\rendering-service-4.4.jar" --spring.config.additional-location=file:"%BASE%\application-pdf.yml" --workers.config="%BASE%\workers-config-pdf.json"</arguments>
<logmode>rotate</logmode>
</service>
Please adjust the path to java according to your installation path. If your pubserver uses an Adobe InDesign Server®, change <arguments>...</arguments> like that:
<arguments>-jar "%BASE%\rendering-service-4.4.jar" --spring.config.additional-location=file:"%BASE%\application-ids.yml" --workers.config="%BASE%\workers-config-ids.json"</arguments>
Then start an administrator cmd, cd to the rendering-worker-service folder and execute:
worker-service-4.4.exe install
When your service was created, do not forget to start it.
4.1. Check Status of Rendering Workers
To check the status of the configured rendering workers (e.g. InDesign Server Instances) open Worker Status Page
http://your-host:your-port/workers/status