Skip to main content

Configuration of Rendering Service

Overview

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 works with the publishing server.

Prerequisites

  • Rendering Service installed on Linux or Windows
  • Java 21 or later to run the rendering-service
  • priint:suite Publishing Server and priint:bpm configured

About This Guide

This page covers common configuration settings that apply to all rendering service deployments, regardless of which rendering server you use.

Configuration Files

The Rendering Service uses Spring Boot's external configuration mechanism (see Spring Boot documentation).

We suggest configuration provided through YAML files with standardized naming convention:

  • application-ids.yml - For Adobe InDesign Server deployments
  • application-pdf-renderer.yml - For PDF Renderer deployments (both embedded and containerized)

The PDF Renderer configuration uses Spring profiles to differentiate between deployment types:

  • indesign-server - For working with Adobe InDesign Server
  • pdf-renderer - For containerized PDF Renderer deployments
  • pdf-renderer-embedded - For embedded PDF Renderer deployments

The sections below document common settings that apply to all configurations. After configuring the common settings, continue with the engine-specific configuration guide:

1. Application Configuration

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
# how often will the rendering-service report to pubserver
heartbeat-idle-millis: 60000
heartbeat-busy-millis: 5000
# Settings below control the HTTP client used to connect to the planner-engine. Default timeouts are 30s each.
connect-timeout-millis: 30000
read-timeout-millis: 30000
write-timeout-millis: 30000

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:

For object storage, the settings need to be configured:

priint:
objectstore:
minio:
# s3 server adress and port
# for GCS: https://storage.googleapis.com
# for AWS: https://s3.amazonaws.com
endpoint: http://127.0.0.1:9000
# minio server user
access-key: minioadmin
# minio server password
secret-key: someMinioPassw0rd
# region to use for configuring the S3-compatible-service client
region: us-east-1
# By default, our s3 client makes sure bucket naming rules (https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)
# are strictly followed. You can switch that validation off if you plan on using an object storage solution that is more permissive.
# This should come in handy if your GCS buckets use underscores ('_') in their names.
skipBucketNameValidation: false

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 the resolution of preview files generated along with document metadata during rendering
document_preview_resolution: 120.0
# This is the time needed for Adobe InDesign Server lock files to disappear once a document gets unlocked
document_closing_timeout_seconds: 10
# The auto-conversion flags can be either true or false (and are treated as true if they are not provided).
# If false, no conversion will take place when trying to open a document.
# This is used for regular document opening:
rendered_document_auto_conversion: true
# Another auto-conversion flag. This determines, if auto-conversion should be turned on for grid element preview document openings.
preview_document_template_auto_conversion: true

Graceful shutdown settings, which we recommend setting, are:

server:
shutdown: graceful

spring:
lifecycle:
timeout-per-shutdown-phase: 30s

1.2. Engine-Specific Settings

Some settings are unique to each rendering server. After configuring the common settings above, continue with the appropriate guide for your rendering-server:

2. Configuring Worker Properties

The sections below describe worker configuration that applies to all rendering servers. Engine-specific worker configurations are covered in the respective engine configuration guides linked above.

2.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.

2.1.1 Fields in worker configuration file

Here is a description of the fields in the order they appear in the file

Field nameMandatoryValuesDescription
1st level2nd level3rd level
workerTypesrequiredlist of worker types - for now only 1 is used at once
workerTyperequiredPdfRendererWorker, PdfRenderingWorker, InDesignRenderingWorker
defaultWorkerConfigoptionalsetIt 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
defaultWorkersCountoptionalnumberthis is only needed for embedded priint:pdf renderer workers. Set to 1.
maxWorkersCountoptionalnumberthis is only needed for embedded priint:pdf renderer workers. Set to 1.
applicationsrequired
applicationNamerequiredstringit is matched from priint.app-name application property
workerPoolsrequiredlist 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
typerequiredmust be set the same as workerTypethe only required field for a worker pool allowing us to link it to a given workerType - must be equal to workerType value
defaultPoolLevelConfigoptional - not usedallows 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
workerConfigsoptionalone 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

2.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.

2.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.

2.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:

PropertyRequiredValueDescription
typerequiredPdfRenderingWorker, InDesignRenderingWorkerworkerType is required for every config property definition - it must be the same as workerType field of a given worker
topicrequiredpriint-renderingthe camunda topic name for a given worker type - this field shouldn't be modified
lockDurationoptionalintegerdefines (in millis) 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. If 80% of the lock duration passed and the task is still being processed, a watchdog thread will attempt to prolong the lock. We therefore recommend to either leave this property out (for a default of 60000 ms to be used) or set it to at least 10000 ms. A warning will be printed in the logs if you specify a smaller value.
maxTasksoptionalintegerdefines how many tasks should be fetched at once when accessing Camunda. Typically, equal to 1 when tasks should be fetched one by one. We don't recommend changing this value unless you need to process big amount of short-living tasks and fetching them one by one would require too many requests and would be too slow.
usePriorityoptionalbooleantrue by default - if set to false camunda will ignore task priorities when fetching tasks

2.1.3.3 Configuration levels

As you may have noticed the files are named global-xxx-workers-config.json. Why do we use global in name? Because the structure is prepared to manage configuration of workers on multiple machines in one central place. Thanks to that you can define the worker properties 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.

3. 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

To learn more about specific configuration for logging and monitoring please check the dedicated section of the documentation.

Next Steps

After configuring the common settings above, continue with the appropriate engine-specific configuration guide:

For additional information, see: