Skip to content

Deployment Validations

Deployment Validations

Deployment validation occurs when a BPMN diagram is deployed and its process definition key matches at least one Workflow configuration in the database or when a Workflow configuration is added to the database and there is a deployed BPMN diagram with a matching key. Passing validation will result in the deployment proceeding as intended and a deployment successful message will be displayed. When the validation fails, the deployment will be aborted, and an error message will appear with all the specific things that caused validation to fail. Deployment validation happens on both the configuration(s) and the deployed BPMN diagram that have the matching keys. Please note that if a BPMN diagram is deployed with the same key as a previous diagram then the previous diagram will be overwritten.

As the BPMN diagrams deployed are run on our system as the key part of Workflows, the diagrams must be validated to verify that they are correctly structured for our systems to handle. Not all BPMN diagram functionality is available because of how they have been implemented. Validation is also used to verify that specific parameters or delegates are accounted for particular types of Workflows the diagrams will run.

The Workflow Designer provided in IFS Cloud has been tailored to help in creating the BPMN diagrams such that they contain what is expected of them to have. One of the things that will be added behind the scenes is some specific input variables that are used to pass around some important information. These internal input variables all start with the prefix ifsBpa so it is recommended to avoid naming variables with that prefix. If the Workflow Designer is not used to create the BPMN diagram, then this content will have to be manually added.

Below are some different sections that specify exactly what will cause a deployment to fail validation.

Pre-Validation

The BPMN diagram must be passable. No syntax errors, unknown elements, or attributes or missing mandatory fields. The diagram must contain exactly one definition key.

If no matching configuration or BPMN diagram is found, then the validation is skipped, and the deployment will proceed as intended.

Configurations

Configurations with type Validation can only be of timing Before or After. Validating data will require immediate feedback to the user as to whether validation was passed so it cannot be completed in the background.

Configurations of type UI can only be of timing After. Forms are designed to appear after the projection transaction has been completed and forms cannot be run in the background.

Configurations of type Process Augmentation can be matched with any timing and are the only type available for Asynchronous timings.

BPMN diagrams for Synchronous Configurations

Both the Before and After Configurations timings are run purely synchronous. This means a lot of the BPMN diagram elements are not available for Workflows that have Before or After timings as the elements are inherently asynchronous. The following dictates the elements and other asynchronous functionalities that will give you errors if you try to use them with a config of timing Before or After.

A Start or End Event element cannot be marked as Asynchronous Before or Asynchronous After.

The following elements are not supported for synchronous Workflows:
• Send Tasks
• Receive Tasks
• Manual Tasks
• Call Activities
• Event-Based Gateways
• Complex Gateways
• Event Subprocess
• Signal Start Events or End Events
• Message Start Events or End Events
• Timer Start Events
• Conditional Start Events
• Escalation End Events
• Error End Events
• Compensation End Events
• Intermediate End Events of any type

Unsupported Elements and Functionality

These are elements that are not supported by any configuration type and likely will never be supported in the future. For the most part, they are incompatible with how Workflows are designed to run.

Transaction elements and Participant elements are both unsupported. Service Tasks cannot have an external type implementation. Start Events should not have any form fields. Use the User Task to create Form Fields.

Java Class Implementation

A Service Task with a Java Class implementation must point to an existing delegate. The delegate name and path must be correct for it to be found. The delegate must also be a child of the class TransactionalDelegate. More reference related to Java class implementation could be found in Custom Delegates section of Extending Workflow.

Enrichment Task

An IFS Process Enrichment Task must have at least one entry under the registered variables list. Refer for more information on IFS Process Enrichment.

For those not using the Workflow Designer:

To add enrichment to a Service Task it must have the enrichment delegate com.ifsworld.fnd.bpa.process.enrichment.IfsBpaProcessEnrichmentDelegate and an internal input parameter ifsBpaEnrichmentRegisteredVariables. Both must be applied to pass validation as an enrichment element. The internal parameter ifsBpaEnrichmentRegisteredVariables must be of type list and it must have at least one element in it. Validation will also fail if the internal input parameter ifsBpaEnrichmentRegisteredVariables is found on an element that is not a Service Task.

IFS Projection Task

An IFS Projection Task will be checked to make sure that the mandatory fields have values. This includs the Action and Projection Name fields. In the case of a CRUD Action the EntitySet Name and ETag Variable Name fields are also mandatory. In the case of a Call Action the Call Name field is mandatory. Refer for more information on IFS Projection.

For those not using the Workflow Designer:

A Service Task referencing the delegate com.ifsworld.fnd.bpa.IfsProjectionDelegate will be validated as an IFS Projection Task. The internal input parameter names that will be checked for are listed in IFS Projection. If the IFS Projection Task specific variables are found on an element that is not an IFS Projection Task then validation will fail.

IFS REST Call Task

An IFS REST Call Task will be checked to make sure that the fields variables have values. This includes the URL and Method fields. Refer for more information on IFS REST Call.

For those not using the Workflow Designer:

A Service Task referencing the delegate com.ifsworld.fnd.bpa.delegate.IfsHttpConnectionDelegate will be validated as a IFS REST Call Task. The internal input parameter names that will be checked for are listed in IFS REST Call. If the IFS REST Call Task specific variables are found on an element that is not an IFS REST Call Task then validation will fail.

Validation Type Workflows

Only validation Workflows can contain Terminal End Events. Every Validation Workflow must have at least one Terminal End Event element. Each Terminal End event must have at least one locale message pair in its error message map. There also must exist a pair where the locale is the same as the locale of the system at the time of deployment. Both the key and value parts of the map must not be left blank.

For those not using the Workflow Designer:

Each Terminal End Event must have either an ifsBpaValidationErrorMessages or an ifsBpaValidationErrorCode internal input variable, but only one of these internal input variables can be present, not both. Refer Error Handling section for more information. Further, the Terminal End Event must also have the listener com.ifsworld.fnd.bpa.process.validation.IfsBpaFailureEndEventListener. Refer Execution Listener section on configuring the listener. Validation will fail if the internal input parameters mentioned above or the listener are not found on any elements that are not a Terminal End Event.

User Interface Type Workflows

User interfaces Workflows do not need to contain a user task, but they are the only Workflow that can contain User tasks. Each User Task element must have a form key.

Each Form Field in a User Task must have at least one locale-label pair in its label map. There also must exist a pair where the locale is the same as the locale of the system at the time of deployment. Both the key and value parts of the map must not be left blank.

For those not using the Workflow Designer:

Each Form Field must not fill out the label attribute of the form field element. Instead, each form field must have a matching internal variable with the same ID but prefixed with ifsBpaImpl. Each of these internal variables must be of type map.

Each ID for each separate Form Field in a User Task must be unique. The IDs must also not be similar in such a way that capitalization is the only difference between them. This only applies inside the User Task and not across all User Tasks in a diagram. However, do be aware that the Form Field ID becomes the key that is used in the environment variables key-value pairs that the form data is kept in. If an ID used is the same as an existing environment variable’s key, then the value of that environment variable will get over-written.

Each ID for each separate Form Field in a User Task must be unique. The IDs must also not be similar in such a way that capitalization is the only difference between them. This only applies inside the User Task and not across all User Tasks in a diagram. However, do be aware that the Form Field ID becomes the key that is used in the environment variables key-value pairs that the form data is kept in. If an ID used is the same as an existing environment variable’s key, then the value of that environment variable will get over-written.

All default values must match the type specified for their Form Field. A date type default variable must be in the format dd/mm/yyyy. Default values of enumeration type form fields must match a value provided in the enumeration values.

Constraints cannot be added with the Workflow Designer but are still supported if needed. A list of the constraints Camunda provides and their uses can be found here.

Validation will fail if the min and max constraints are applied to any Form Field that is not a long type and if the minlength and maxlength are applied to any form field that is not a string type. Both minimum and maximum type constraints must be integers and the minimum constraint cannot be larger than the maximum constraint. A read-only constraint requires the default field to be non-null. Also, any default values must pass the constraint (unless the default value is an expression).

Process Enrichment Type Workflows

No additional validation is applied to Process Enrichment Type Workflows other than what has been described above.

In the future Workflows that are both type Process Enrichment and timing, Asynchronous will have access to some of the asynchronous BPMN elements but as of now, these elements are not supported.

XML Validation

Every BPMN diagram is a well formatted xml. XML validation helps to ensure the consistency between Camunda deployed diagram and the database saved diagram for given Workflow version. The BPMN diagram being deployed for particular Workflow version should match the BPMN diagram exist for that version in the database. This will pass the XML validation and deployment successful message will be displayed. XML validation failure will result in deployment failure with an error message.

Lock Status Validation

Lock status validation happens to ensure that correct user has been checked out the given workflow version and allowed to deploy that version. Validation ensures that given workflow version is either locked to the logged in user, is not locked to anyone or permanently locked. This validation helps to control the ownership of workflow versions.

Below diagram elaborates the Lock Status flow in Workflows,

LockStatusFlow