Connect a DPF System¶
Prerequisites¶
For connecting 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.
For connecting a DPF system as backend system for SEAL Operator, execute the following steps:
Activate the Connector and Specify the Keys for the Connection¶
In SEAL Operator, activate the connector and specify the keys for the connection:
-
Export the complete configuration of SEAL Operator from Consul to a YAML file in order to ensure that the current configuration settings are used.
operator config export <filename>.yml --insecure
-
In the section of the DPF connector, set
cstatus
toon
. The Fileupload (scratch
) connector has to be activated as well.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 due to the DPF connector will not work otherwise! -
In the
env
section, specify the following keys for theoperator-dpf
service:-
ACTION_EXECUTOR
: Backend system, hereDPF
-
DPF_URL
: URL for the REST calls
env: service: ... operator-dpf: tag: any: ACTION_EXECUTOR: DPF DPF_URL: 'https://<dpf_server_name>:<port>/rest/dpf' ...
Literature - keys
For further information about the available keys, refer to the description of the Keys.
-
-
Save the
<filename>.yml
file and re-import it to Consul.operator config import <filename>.yml --insecure
Configure the DPF 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.
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"
]
}
]
}
}
fieldsets
¶
At least, the DPF connector uses the Capabilities
, Merge
, JobConfig
and ConversionType
parameters. These have to be included in the fieldsets
array even if they are not visible in the panel.
Capabilities
- panelname
¶
The panelname
parameter in the Capabilities
property decides which DPF Rest service is to be used and how the parameters are to be passed. With dpf4convert
in panelname
, the dpfconvert
REST operation is used for transferring the job. If panelname
begins with dpfconvert_
, the generic process is used and the parameters have to be mapped.
Map Parameters for Generic Processes¶
If the panel uses a generic process, i. e. 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 that the Role
and the DummyUser
fields 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
.