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

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 a Model in the Process Modeler

To deploy a model version, open this model in the Stardust Process Workbench and proceed as follows:

Deploying a Process Model
Figure: Deploying a Process Model

In case you prefer to use your custom environment to deploy your model(s) to, expand the Advanced section and browse to your CARNOT_HOME and CARNOT_WORK folders. Please refer to the section Environment Variables of the Installation chapter for more information on these variables.

Deploying with Custom Environment Variables
Figure: Deploying with Custom Environment Variables

Quick Deployment Option

Another way to quickly start a model deployment with the default environment settings is to right-click the model in the Outline view and select Deploy Model.

Deploying a Process Model
Figure: Deploy Option in the Outline View

To skip the following dialogs like the login dialog and the version dialog, you can set appropriate preferences in the Process Manager Preferences, like the option to always overwrite model versions and providing the credentials for the deployment authentication. Please refer to the section Deployment of the chapter Setting Process Manager Preferences for detailed information on available deployment preferences.

Adding a deployment toolbar button

To be able to quickly start a model deployment from the perspective toolbar, Stardust provides a deployment button, which can be added to the currently open perspective in the following way:

  1. In the main menu, select Window > Customize Perspective.
  2. In the Customize Perspective, select the Commands tab.
  3. In the Available command groups section, select Stardust.
  4. OK the dialog.

Deploy Icon
Figure: Add an Icon for Model Deployment to the Toolbar.

Now a button to start a model deployment is available in the perspective toolbar:

Deploy Option
Figure: Model Deployment Option in the Toolbar.

Note that the deploy option only starts in case a model editor is currently open. The deployment then starts with the currently open model.

PredefinedModel in Deployment Dialog

Also, note that when you are deploying a model, the Deploy Model dialog also displays the PredefinedModel. This is the technical model which gets deployed automatically at the time of deployment. It gets deployed at the time of first deployment of any other model but it is visible in the Deployment dialog if at least one model version is already deployed. For more information, please refer to the section Predefined Model of the Case - Grouping Processes chapter of the Concepts Handbook.

PredefinedModel
Figure: Model Deployment - PredefinedModel

Login Dialog

In case no default user and password for the deployment login are set in the Process Manager Preferences, a login dialog opens with entry fields for the required credentials. Per default, the administrator account motu (username: motu, password: motu) is required. Please refer to the section Deployment of the chapter Setting Process Manager Preferences for detailed information on the available deployment preferences.

Version Deployment

At the time of deployment Stardust performs a check whether the model to be deployed is a version of the existing model(s).

A model version dialog opens, where you can choose to overwrite a model version or to create a new model version along with other optional settings like validity date or deployment comment.


Figure: Version Deployment to a Runtime Environment with Existing Active Model

You have the option to skip this dialog and use the default option to always deploy a new model version, by setting as preference in your Process Manager Preferences. Please refer to the section Deployment of the chapter Setting Process Manager Preferences for detailed information on how to set this preference.

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.

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, you have the option to override the selection and manually choose which operation to perform.

Note: 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.

Please refer to the chapter Deploying a Workflow Model of the Deployment Guide, which discusses model version deployment in detail.


Figure: Overwriting a Model

In the figure above, the version 3.0 is being redeployed to the audit trail database. Stardust compares the version ID and OID which results in enabling the option Overwrite instead of version deployment.

Deploying Multiple Models from One Audit Trail

Stardust supports deployment of multiple models at a time from one audit trail database. You can deploy models either one by one in order or in parallel. This is possible only when the provider and consumer relationship is established between two models. It can be achieved through file connection. For more information on file connection, please refer to the section Referencing Model Elements of the External Model Resources chapter.

Deploying Multiple Models One by One

You should deploy the models one by one in the following order always. If the sequence is not followed, the references are not resolved and the models don't get deployed. The deployment sequence is as follows:

  1. Deploy Provider Models
  2. Deploy Consumer Models

In case of multiple provider and consumer models, first, all the provider models should be deployed and then the deployment of consumer models should take place.

To deploy multiple models one by one:

Right-click the provider model and select Export


Figure: Deploy Provider Model

Ensure that provider model is selected in the Deploy Process Model Wizard and click Finish. The model gets deployed.


Figure: Deployed Provider Model

Right-click the consumer model and select Export


Figure: Deploy Consumer Model

Ensure that consumer model is selected in the Deploy Process Model Wizard and click Finish. The model gets deployed.


Figure: Deployed Consumer Model

When deploying a process model from modeler that has a reference to already deployed another model, the Model Version Deployment warning is displayed. In that case, first you need to deploy the Provider model.


Figure: Warning - Model Version Deployment

Deploying Multiple Models Parallel

Parallel deployment of multiple models provides the ability to deploy a set of provider and consumer models in one click. A set of multiple models ready for deployment is called a deployment unit. Note that you cannot deploy more than one version of the same model in one deployment unit. To deploy multiple models in parallel:

Select all the models to be deployed from the Package Explorer.


Figure: Select Models

Right-click selected models and select Export

Ensure that provider and consumer models are selected in the Deploy Process Model Wizard and click Finish. All the selected models get deployed.


Figure: Deployed Provider and Consumer Model

Consistency Checks

If the model has consistency deficiencies, the automatic consistency check, which otherwise remains invisible to you, will issue a list of inconsistencies found. There are two categories of inconsistencies:

Consistency checks are implemented for:

Consistency Checks for Scoped Participants

The following rules apply to version deployment consistency checks as well as for overwrite deployment consistency checks:

Unscoped Organization followed by Scoped Organization

If in any model of the audit trail a certain organization exists and is unscoped, it is not possible to deploy a successor model version that contains this organization as a scoped organization. A consistency error occurs, notifying that the organization is scoped, but in the audit trail it is unscoped. The deployment fails.


Figure: Consistency Error for Scoped Organization former Unscoped

Likewise it is also not supported to change from a scoped to an unscoped organization in model version deployment.

Changed Data or Data Path for Department

If in any model of the audit trail a certain organization exists and is scoped, it is not allowed to deploy a successor model version that contains this organization as a scoped organization, but uses a different data or data path to retrieve the scope identified. A consistency error occurs, notifying that the ID of the data or the data path is different from the data ID of the deployed scoped organization in the audit trail. The deployment fails.


Figure: Consistency Error for Changed Data.

Invalid Data Types for Departments

Only primitive or structured data with type java.lang.String are allowed. In case other types are used a consistency error occurs, notifying that the data type used to retrieve the department for the scoped organization is not valid. The deployment fails.


Figure: Consistency Error for Unsupported Data Type.

Changes in the organizational structure

It is not supported to deploy a succeeding version with changes in the department association for existing roles or organizations. That means that for any scoped organization and its entire subtree (all roles and organizations directly or indirectly connected to this organization via "Part Of" or "Works For" or "Manager Of") it is not allowed to:

All operations that will change the number or order of declared departments for any of the participants are not supported.

However, the following changes are allowed:

In case changes in the organizational structures, which are not allowed to be deployed in a succeeding model version, have been performed, a consistency error occurs, notifying that the organization tree is different from the tree in the model that was deployed earlier. The deployment fails.


Figure: Consistency Error for Changed Participant Tree.

Duplicate Participant ID

IDs for participants have to be unique within all model participants like roles, organizations or conditional performer. In case you use the same ID for more than one participant, the deployment fails with the following error:


Figure: Consistency Error for Duplicate Participant ID.

Administrator role has relationsship

The Administrator role is not allowed to have relationships to any organization. In case such a connection exist in the model, the deployment fails with the following consistency error:


Figure: Consistency Error for unsupported Relationship of Administrator.

Multiple Superorganizations

It is not supported that a model participant has multiple superorganizations. Only one or zero relationships to other model participants are allowed, otherwise a consistency error occurs during model deployment and the deployment fails.


Figure: Consistency Error for Multiple Superorganizations.

Consistency Checks for Dependent Models Deployed in One Audit Trail Partition

The following rules apply whenever you want to deploy multiple models dependent on each other by any relationship:

Deploying a referencing model that has references to not yet deployed referenced model

If any referencing model is deployed without deploying its referenced model in that case the references are not resolved. This results in deployment error preventing deployment.

Deploying a model that has more than one implementing process definitions for a process interface

Any model cannot have two process definitions that are implementing same process interface of a referenced model. Whenever such a relationship is established, it causes deployment error. For example, process definition PD1 and PD2 are trying to implement the process interface of model M1. In this case, the deployment error is displayed because either PD1 or PD2 can implement the process interface of Model M1.

Overwriting a model with a version that has an incompatible interface

If any changes are done to the process interface and then the referenced model is overwritten, in this case the referencing model cannot get the changed references. This results in deployment error.

Overwrite of a model which has default implementation for a process interface

Whenever an overwrite takes place at the deployment time, the versions of the model to be overwritten should be taken into consideration. If it has default implementation configured for a process interface and it gets overwritten with a version without process interface then the references that are not resolved causes deployment error.

Deployment of models having references to models that are not part of same deployment unit

If the model set contains the models having references to models that are not part of the same model set and are not being deployed, in that the deployment error occurs. The models that are referenced should be deployed first.

Deploying a model set (deployment unit) that has circular references

Circular references are not allowed in Stardust. If the referenced model is again establishing relationship with the referencing model then the deployment error is displayed. Similarly, the model which references to the referenced model cannot become the referenced model again. For more information on Circular References please refer to the Key Concepts chapter.

Deploying a provider model file having future validFrom timestamp

The validFrom timestamp of all the referenced provider models should always be before or equal to the consumer model to be deployed. For example, the validFrom date of the Provider model is 20/02/2020 and the validFrom date of the consumer model is 11/02/2015. The references to the provider model won't get resolved because in 2020 the Provider model will be available for use.

Deploying a deployment unit or overwriting a model that would violate transitive consistency

If model A is a consumer of models B and C, and model B is itself a consumer of model C, any deployment of A and B must be linked to identical deployments of C. Note that relinking will happen only when you will deploy consumer models. So, when you deploy version one of Model C, you need to deploy version one of model A and B to see the references.

Deploying a model that has participants with identical IDs

IDs of each participant in the provider and consumer model should be unique. If the provider and consumer model contains participants with identical IDs then the validation error is displayed.

Deploying a model that has broken references

The model elements that can be referenced from the provider model should not be deleted. If a deleted model element is already referenced in the consumer model, then at the time of deployment it results into broken references.

Deploying a model that has data with identical IDs

IDs of the data defined in the provider and consumer model should be unique. If the provider and consumer model contains data with identical IDs then the validation error is displayed.