Skip to content

Connect a DPF System

A connector establishes the connection between the SEAL Operator server and a backend system. With the DPF connector, SEAL Operator provides DPF-based panels in the user interface, for example for converting documents. SEAL Operator passes the jobs to the DPF system via its REST interface.

Prerequisites

To connect a DPF system as backend system for SEAL Operator, the DPF system has to have the appropriate REST interface. Therefore, the version 2.2.0 of DPF is required.

Configure the Connector

In SEAL Operator, activate the connector and specify the keys for the connection:

  1. Open a command prompt.

  2. Export the complete configuration of SEAL Operator from Consul to a YAML file. This ensures that you edit the current configuration.

    operator config export <filename>.yml --insecure

  3. Edit the exported file <filename>.yml.

  4. In the section of the DPF connector, set cstatus to on. Also activate the Fileupload (scratch) connector.

    operator:
  connectors:
    ...
      dpf:
        cstatus: 'on'
        serviceName: operator-dpf
        url: 'https://localhost:3014'
      scratch:
        cstatus: 'on'
        serviceName: operator-fileupload
        url: 'https://localhost:3009'
    ...

    Caution - do not turn off

    Do not deactivate the Fileupload (scratch) connector. Otherwise, the DPF connector does not work!

  5. In the env section, specify the following keys for the seal-operator-dpf service in the operator-dpf section:

    env:
  service:
  ...
    operator-dpf:
      tag:
        any:
          ACTION_EXECUTOR: DPF
          DPF_URL: 'https://<dpf_server_name>:<port>/rest/dpf'
  ...

    Literature - keys

    For further information about available keys, refer to the Key Reference.

  6. Save the <filename>.yml file.

  7. Re-import the file to Consul.

    operator config import <filename>.yml --insecure

  8. Check the imported value, for example for DPF_URL:

    operator config get DPF_URL --service operator-dpf --insecure

Configure the Panel

The DPF panel is configured on the DPF server in the following file by default:

%DPFSRV%/conf/operator/panel.json

A different file and location can be specified in main.customer.xml.

Hint - template

For the panel configuration file, the panel.json.tpl template is available.

Multiple DPF Panels per Panel Type

For the DPF connector, you can configure multiple panels that use the same panel type, for example convert, pdf, or publish. Each of these panels keeps its own configuration, for example job configuration, parameters, texts, and visibility. SEAL Operator handles each panel independently. Panels of the same type do not overwrite each other. This allows you to provide different DPF-based panels for different business departments or processes, even if they use the same technical panel type towards DPF.

At a minimum, the DPF connector uses the following properties:

  • Capabilities
  • Merge
  • JobConfig
  • ConversionType

These properties also have to be included in the fieldsets array even if they are not visible in the panel.

The panelname parameter in the Capabilities property decides which DPF REST service is to be used and how the parameters are to be passed:

  • panelname is dpf4convert: The dpfconvert REST operation is used for transferring the job.
  • panelname begins with dpf4convert_: The generic process is used and the parameters have to be mapped.

Hint - DPF version for the /panels route

If panelname is set to dpf4convert, the DPF4Convert panel uses the /panels route on the DPF server. This route requires DPF 3.x or DPF 4.3.0 and later.

Example - minimum configuration of the DPF panel

{
    "name": "Signature",
    "type": "convert",
    "pid": "056f46db-c35a-492d-b545-7275765d57bf",
    "json_schema": {
      "$schema": "http://json-schema.org/schema#",
      "type": "object",
      "required": [],
      "properties": {
        "Capabilities": {
          "type": "object",
          "widget": "hidden",
          "properties": {
            "panelname": {
              "type": "string",
              "default": "dpf4convert_check"
            }
          }
        },
        "ConversionType":{
          "type": "string",
          "default": "convert",
          "widget": "hidden"
        },
        "Merge": {
          "type": "boolean",
          "default": true,
          "widget": "hidden"
        },
        "JobConfig":{
          "type": "string",
          "default": "signature",
          "widget": "hidden"
        }
      },
      "fieldsets": [
        {
          "fields": [
            "JobConfig",
            "Merge",
            "ConversionType"
          ]
        },
        {
          "fields": [
            "Capabilities"
          ]
        }
      ]
    }
}

Configuration of Parameters

The configuration of parameters in panel.json follows the JSON schema standard. Additionally, the following features are available:

Multi-Select Widgets

Example - multi-select widget

MyParameter: {
  "type": "array",
  "description": "My Parameter",
  "widget": "select",
  "items": {
    "type": "string",
    "anyOf": [
      {
        "enum": ["option1"],
        "description": "Option 1"
      },
      {
        "enum": ["option2"],
        "description": "Option 2"
      },
      {
        "enum": ["option3"],
        "description": "Option 3"
      }
    ]
  }
}

Dynamically Filling Options of Select Widgets

The options of a select widget are dynamically filled after every parameter change via a request to DPF.

Example - dynamically filled multi-select widget

MyParameter: {
  "type": "array",
  "description": "My Parameter",
  "widget": "select",
  "items": {
    "type": "string",
    "anyOf": []
  },
  "providedBy": "getParamOptions",
  "providedWhen": "changed",
  "providedByWorkflow": "dpf.workflow.to.be.used"
}

Example - dynamically filled single-select widget

MyParameter: {
  "type": "string",
  "description": "My Parameter",
  "widget": "select",
  "oneOf": [],
  "providedBy": "getParamOptions",
  "providedWhen": "changed",
  "providedByWorkflow": "dpf.workflow.to.be.used"
}

The properties for dynamically filled options have the following meaning:

  • providedBy: function of the DPF connector that fills the options, getParamOptions
  • providedByWorkflow: DPF workflow that returns the options. The DPF connector passes the current parameter values and the name of the parameter to fill, OPERATORPARAMTOFILL, to this workflow.
  • providedWhen: with changed, the options are filled again after every parameter change
  • providedOnChangedParams: optional, list of parameter names. If set, the options are filled again only when one of these parameters changes.

Map Parameters for Generic Processes

If the panel uses a generic process, id est if the value in panelname begins with dpf4convert_, the parameters from panel.json have to be mapped to the properties for the DPF process. Therefore, configure the mapping in main.customer.xml on the DPF server:

Example - mapping of jobConfig field

In the example below, it is assumed the fields Role and DummyUser have been configured in the DPF panel.

<DPFRestService.convert>
    <jobConfig name="signature" workflow="<wf_name>">
        <jobParameters>
          <jobParameter name="Role">%Role%</jobParameter>
          <jobParameter name="DummyUser">%DummyUser%</jobParameter>
        </jobParameters>
    </jobConfig>
</DPFRestService.convert>

Hint - file transfer

The files to be processed by DPF are transferred in the FILE<x> DPF property, for example, FILE1.

Back to top