Overview
As of versions 9.7.0 (v9) and 10.4.0 (v10), WorkflowGen supports JSON Process Definition Language (JPDL), a JSON format for importing and exporting WorkflowGen process definitions. JPDL preserves the supported process definition content available through XPDL while using a deterministic, readable JSON structure. Existing XPDL workflows remain supported.
JPDL is semantically equivalent to the supported WorkflowGen XPDL process definition, but is not a byte-for-byte XML representation. It deliberately omits XML namespaces, schema locations, CDATA markers, XPDL boilerplate, and other serialization-only details.
Contents
JPDL envelope
Validation rules
Values and data bindings
Boolean and numeric values
String preservation
Optional and empty values
Arrays and extensions
Semantic equivalence with XPDL
JPDL envelope
A JPDL document uses the following top-level structure:
{
"format": "JPDL",
"format_version": "1.0",
"package": {
"id": "WORKFLOWGEN",
"metadata": {
"generator": "WORKFLOWGEN 10.4.0"
},
"processes": [
{
"id": "EXAMPLE_PROCESS"
}
]
}
}
JSON property names use snake_case. Existing WorkflowGen enum and domain codes such as PUBLIC, APPLICATION, and RELDATA retain their current spelling.
The package can contain the supported WorkflowGen process definition information, including:
-
Processes
-
Participants
-
Applications
-
Activities
-
Transitions and conditions
-
Process data
-
Parameters
-
Notifications
-
Graph metadata
-
Comments
-
Extensions
-
Associated files
JPDL uses native process terminology instead of reproducing XPDL container elements. For example, process properties such as description, updated_at, updated_by, publication_status, and version are represented directly on the process object. XPDL containers such as process_header and redefinable_header are not represented.
The updated_at property uses ISO 8601 UTC. WorkflowGen extended attributes are represented using the extensions array.
The XPDL Codepage value is not represented in JPDL because it is derived from the exporting user’s language and ignored during import.
Validation rules
The current WorkflowGen importer accepts exactly JPDL format version 1.0. The format_version property identifies the JPDL format version, not the process version. Support for later versions must not be assumed.
JPDL documents are validated against the JPDL 1.0 schema bundled with WorkflowGen. Unknown or misspelled properties are rejected, except inside the documented extensions[].attributes compatibility bag, where arbitrary property names are accepted but their values must be strings. Property names, required fields, and value types must match the schema.
JPDL files must use the .json extension and UTF-8 encoding. A UTF-8 byte-order mark (BOM) is accepted. UTF-16, UTF-32, and malformed UTF-8 content are rejected.
When an extensions[].file object is present, it must contain file_name, size, content_type, location, and content_base64. Metadata values can be empty where applicable, and content_base64 can be null when associated files were not included.
Values and data bindings
Where necessary, JPDL makes XPDL binding semantics explicit. For example, properties such as value_kind can identify how a value is interpreted:
"value_kind": "TEXT"
or:
"value_kind": "RELDATA"
These values retain the existing WorkflowGen domain-code spelling.
Boolean and numeric values
Known scalar values are represented using native JSON types.
For example:
"is_array": false
Known WorkflowGen extension booleans are also represented as JSON booleans:
{
"name": "Visible",
"value": true
}
Known numeric extension values are represented as JSON numbers when their original value uses canonical invariant spelling:
{
"name": "GRAPH_ZOOM_X",
"value": 88.5
}
Known XPDL boolean literals such as TRUE / FALSE, YES / NO, and Y / N are converted to native JSON booleans only when WorkflowGen defines the corresponding property or extension as boolean. When JPDL is converted back to XPDL, WorkflowGen restores the required legacy literal.
Boolean recognition for extended attributes uses the extension’s WorkflowGen owner section and the exact uppercase XPDL literal. Lowercase legacy values and same-name custom extensions in other sections remain strings.
DataField.is_array is an exception and continues to recognize TRUE and FALSE case-insensitively.
Deprecated ManualBreakPoints, for example, is represented as a boolean for legacy compatibility, while its BreakPointNcoordinate-pair values remain strings.
String preservation
Enum codes, identifiers, and custom extension values remain strings unless WorkflowGen explicitly defines a different type.
For example, an identifier such as:
"ReldataLimit"
remains a string.
Likewise, a custom extension value such as:
{
"name": "CUSTOM_SETTING",
"value": "Y"
}
remains the literal string "Y" unless WorkflowGen defines that extension as boolean.
Numeric conversion also preserves values whose lexical form is significant. A value is emitted as a JSON number only when WorkflowGen can parse it and render it back using exactly the same canonical invariant representation.
Canonical integers and decimals can therefore become JSON numbers, while values such as the following remain strings:
-
"007" -
"+5" -
" 12" -
"1e3" -
".5" -
"1,234"
This preserves their spelling when the JPDL definition is converted back to XPDL.
Optional and empty values
Optional properties are omitted when the corresponding source value is absent.
An explicitly empty string is preserved when an empty value has a different meaning from an absent value. This allows JPDL to distinguish between a property that was not supplied and one whose value was deliberately set to "".
Arrays and extensions
JPDL arrays preserve their defined order so that process elements whose sequence is significant remain deterministic across export and import.
Extension arrays also preserve duplicate entries. WorkflowGen does not collapse extensions simply because they have the same name, since duplicate extended attributes can carry distinct or ordered information in an XPDL definition.
Semantic equivalence with XPDL
JPDL is intended to preserve the supported semantics of a WorkflowGen XPDL process definition, not its exact XML serialization.
A process exported to JPDL and converted back to XPDL can therefore be semantically equivalent without producing byte-for-byte identical XML. XML-specific information such as namespaces, schema locations, CDATA boundaries, formatting, and other serialization details is not part of the JPDL representation.