Deploying a Workflow Model

Model deployment makes the process definitions available to the runtime environment, so that all processes can be executed according to the definitions of this model. To support model version deployment, the Stardust Process Workbench provides a Deploy Model option, which

You can deploy a model via console command or directly in the Stardust Process modeler. Please refer to the according chapters for detailed information:

At the time you are deploying a model, all Stardust daemons must not be running. This will apply the first time to deployments subsequent to the first model version.

Deploying to Runtime with Multiple Versions

Since you can deploy multiple models to the runtime environment but the versions of these models can be updated, the Stardust Process Platform performs a check whether the model to be deployed is a version of the existing model(s).

Since the check is based on the model ID, it is your responsibility to ensure that you deploy a successor version of the model already deployed and you do not deploy an entirely different model with the same model ID. The ID and the OID of the model version are the criteria, which Stardust analyzes to determine whether you should perform version deployment or overwriting.

Stardust allows hot deployment of the model versions so that no restart of the application server is necessary after a new deployment. In Spring local mode, execution clients (swing -, Web - or embedded clients) have to be restarted. Please refer to the section Configuring the Stardust deployment of the Runtime Setup chapter in the Spring Integration Guide for information on how to set up the Spring environment accordingly.

Version Deployment versus Overwriting

When deploying a version to a runtime environment with already deployed versions, Stardust automatically chooses between two possible operations: version deployment or overwriting.

Regardless of the selection performed automatically by the deployment dialog, the deployer has the option to override the selection and manually choose which operation to perform.

In production mode, overwriting should be performed with extreme caution. If the model to be overwritten contains elements that were deleted in the model to be deployed and those model elements have corresponding runtime audit trail objects, overwriting can introduce serious inconsistencies in the audit trail database.

Criteria for Model Changes that Justify Redeployment with Overwrite

This section provides a list of allowed and forbidden model modifications in order to determine whether the deployment of a modified model with overwrite is supported in a productive scenario. All modifications not explicitly listed as allowed in this document should be regarded as potentially dangerous. IN THESE CASES NEVER DEPLOY THE MODIFIED MODEL WITHOUT PRIOR INSPECTION AND AUTHORIZATION BY THE Stardust SUPPORT AS CORRUPTION OF THE AUDIT TRAIL DATABASE AND SUBSEQUENT MALFUNCTION OF THE Stardust ENGINE MIGHT OCCUR.

Preconditions

This document is valid for all Stardust releases 3.x or later. If any recommendations should rely on specific micro-releases, this is explicitly stated in the text. All statements in this document are valid for all supported platforms and not further restricted to any special database, application server or Java runtime environment version.

Following the recommendations stated in this document does ensure the correct operation of the Stardust Process engine after model redeployment. However, if you intend to use the Stardust Process warehouse for subsequent analysis of the audit trail, additional restrictions might apply in order to prevent unexpected results.

List of Allowed Modifications

The following changes are allowed without further restrictions. However, note that modifications to client code might be necessary if the underlying assumptions of this code are no longer valid as a consequence of the modifications (for example if data paths are deleted or their IDs are changed).

Adding activities and transitions at the end of terminal linear work flow branches

It is always possible to add one or more additional activities (and linking transitions) after any terminating activity of the process definition. Terminating activities are activities that do not have any following activity.

Adding activities and transitions before the root activity of the process definition

It is always possible to add one or more additional activities (and linking transitions) before the start activity of the process definition. The first of the newly added activities then becomes the new start activity.

Changing name and description of model elements

The name (not necessarily the ID) and description of all model elements can always be modified.

Adding new model elements

The following elements can always be added to the model:

Modifying attributes of existing model elements

The following modifications to existing model elements are always allowed:

List of problematic changes

All changes listed in this category are allowed only if additional conditions are fulfilled. Please check the conditions carefully, because otherwise unexpected or erratic behavior of the engine might occur after deployment.

Changing the Participant assignment

It is possible to re-assign a different Participant to interactive activities. However, note that the worklist assignment of existing activity instances that were created based on the original assignment will not be modified, which might result is somewhat unexpected results. Furthermore, check your client code for necessary modifications.

Adding additional workflow threads between in an and-split-join construct

If you have a split of type AND that is followed by linear chains of activities which are then joined in an AND join, it is possible to add additional concurrent branches between the split and the join activity. However, note that for any process instances that have already reached the AND split activity at the time of model redeployment, the JOIN condition will never be fulfilled, and the process therefore will never be completed which is generally undesired.

List of forbidden changes

The changes listed below are to be regarded as dangerous and might corrupt the integrity of your audit trail after model redeployment. Please consult the Stardust support if you have the high-priority wish to perform any of these modifications in a production environment. In some cases it may be possible to achieve this aim but special actions using internal mechanisms and interfaces might be required.

Modifying IDs of process definitions, activities, transitions, data, participants, triggers or event handlers already having associated instances in the audit trail.

Instances or these types are associated with their defining model elements by ID, thus overwriting a model with a version not containing all referenced IDs would corrupt the audit trail. If for some reason any such ID must be changed, please contact Stardust support for safe practices.

Deleting transitions or activities in existing process definitions

Deleting any transitions or activities in existing process definitions may result in a corrupted audit trail if running process instances exist for the process definition modified.

Changing the type of existing workflow data

Type conversion errors might occur if the data is used by running instances of the process definition.

Deleting participants

Deleting participants (roles or organizations) will prevent any worklist items already exiting for these participants from being correctly processed. Problems with the participant assignment of existing users might also occur.