Workflow Manual / Version 2301
Table Of ContentsUploaded workflow definitions are stored in the database as serialized objects. You can customize workflows by programming own extensions, for example actions, expressions, handlers. So every time, you have made incompatible changes in classes, which are used in already uploaded workflows, you need to convert these workflows. In case of an update of the CoreMedia Workflow Server, the workflows have to be converted, too. Otherwise, object deserialization errors can occur (see Oracle JDK documentation for details).
Active process definitions and inactive process definitions for which there are still running processes can be
converted during every Workflow Server start. This automatic conversion can be enabled by the
workflow.server.enable-workflow-converter flag (see Section 6.1.2, “Configuration of Workflow Server Properties”).
Alternatively, this conversion can be executed manually with the workflowconverter tool before starting the workflow
server: cm workflowconverter -c
The workflowconverter utility has the following syntax:
cm workflowconverter [ -v | -c [processID]* | -f [processID]* | -X [processID]* | -r processID
jar]
The parameters have the following meaning:
| Parameter | Description |
|---|---|
-v
| Checks which workflows can not be deserialized and have to be converted. |
-c [processID]*
|
If you use -c without a process ID parameter, all uploaded workflows
will be converted if necessary. If you enter process IDs, only the workflows with
the given process IDs will be converted if necessary.
|
-f [processID]*
|
Like -c, but the workflows are converted unconditionally.
This is useful, if group IDs used in the serialized workflows have become invalid.
Even though this should be an exceptional case, sometimes it happens that
external groups (like LDAP groups) vanish and reappear, for example by a
temporary misconfiguration of the user provider, and then get a new ID in the CMS.
The workflow converter does not detect this, because it is not a matter of
deserialization, so you have to enforce the conversion.
|
-X [processID]*
|
Similar to -c the workflow converter converts the uploaded workflows if
necessary. If the conversion fails, the workflow process and all corresponding
workflow instances are removed from the workflow server.
|
-r processID jar
| Replace a custom made JAR file for a workflow with a new version (see Section 3.5.4, “Upload” for the upload of a JAR file). |
Table 3.5. Parameters of the workflowconverter utility
To convert the workflows, use the cm workflowconverter utility as follows:
Make sure that the CoreMedia Workflow Server is stopped.
Make sure that the Content Server to which the Workflow Server is attached is running. If necessary, start the Content Server.
Copy the changed classes (if any) into the appropriate directories.
Start the
workflowconverterutility. Note that the conversion only takes place, if the-cor-Xflag is given.Finally, start the workflow server again.
The Content Server must run so that user names and groups names can be resolved while reparsing the workflow definitions.
