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 Infinity Process Workbench provides a Deploy Model option, which
At the time you are deploying a model, all Infinity daemons must not be running. This will apply the first time to deployments subsequent to the first model version.
To deploy a model version, open this model in the Infinity Process Workbench and proceed as follows:
Figure: Deploying an Infinity 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 in the Developers Handbook for more information on these variables.
Figure: Deploying with Custom Environment Variables
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.
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 Infinity 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 Infinity Preferences for detailed information on available deployment preferences.
To be able to quickly start a model deployment from the perspective toolbar, Infinity provides a deployment button, which can be added to the currently open perspective in the following way:
Figure: Add an Icon for Model Deployment to the Toolbar.
Now a button to start a model deployment is available in the perspective toolbar:
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.
For more information on the deployment of multiple models in one audit trail database, please refer to Deploying Multiple Models from One Audit Trail section of the Deploying a Workflow Model chapter of the Developer Handbook.
In case no default user and password for the deployment login are set in the Infinity 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 Infinity Preferences for detailed information on the available deployment preferences.
At the time of deployment the Infinity Process Platform 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 Infinity Preferences. Please refer to the section Deployment of the chapter Setting Infinity 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 Infinity analyzes to determine whether you should perform version deployment or overwriting.
When deploying a version to a runtime environment with already deployed versions, Infinity 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. Infinity compares the version ID and OID which results in enabling the option Overwrite instead of version deployment.
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:
For cosistency checks of dependent models, please refer to Consistency Checks for Dependent Models Deployed in One Audit Trail Partition section of the chapter Deploying a Workflow Model of the Developer Handbook.
The following rules apply to version deployment consistency checks as well as for overwrite deployment consistency checks:
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.
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.
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.
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.
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.
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.
Since release 5.2., 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.