The multi instance
Why use multi-jurisdiction?
Working on several instances allows to reduce the risks when developing processes on a production instance. Here are some examples of the hazards this method avoids:
- Dropping an instance with a development error
- Infinite loops or other errors no longer paralyze the production instance.
- Updating production data through testing
- An error in a list ID or business ref ID in a script can happen quickly.
- Use developmental artifices:
- Commenting on script blocks to avoid updating production data means that you risk forgetting to uncomment them after testing.
- Having test data on a production instance
- and especially to forget to delete them so as not to distort the KPIs.
What is multi-instance ?
Multi-Instance consists in using 2 or 3 instances instead of one to reduce the above mentioned risks. This requires at least two instances and potentially the interposition of another instance to take advantage of a space for validating developments.
The instances are distributed like this:
- Development
- Recipe
- Production
| Développement | Recette | Production |
|---|---|---|
| New processes AND improvement of old processes | Validation of developments | Current process flow |
| Test data | ISO PRODUCTION except services | manufacturing data |
Development
This instance is a space reserved for the development of new processes and for the evolution of old ones. The data (lists, tables and repositories) are dummy. They’re usually filled with fake lines written arbitrarily or not by the testers.
All processes on this instance are at least as advanced as their production counterparts.
Recipe
The Recipe instance is the place where future users can test new processes with real data, without risking perturber any other tool or user.
It is possible not to have this instance, especially since the new functionality of the Test mode allows you to recreate these conditions.
In this test instance, services must be services showcases to avoid the risk of updating data outside the application or sending test mails. Therefore a reduced number of users is preferable (usually only testers of processes that are currently evolving.
Production
The Production instance is the instance on which authentic users run the real processes, with real data. It is the instance that must not be altered in any way.
It is preferable to use the tab “ Design ” of the production authority only as a last resort. In case of an urgent bug, it will be necessary to perform the patch on the other instances.
Configuration and production start-up
Configuration
In order to facilitate production, it is advisable to respect one of these rules:
- Objects (lists, tables and refs) have the same names and IDs on all instances (difficult to ensure)
- Objects have the same names on all instances and the IDs will be determined using JUEL methods (e.g. getIdByName).
- Objects are stored in a repository: Object name => Id. In this case, all scripts do a getParam to retrieve the object ID on that instance.
In all cases it is preferable to prefer assignments by variables and groups to those by user.
Going into production
Multi-institution dissociates the production and test instances, so it is necessary to prepare a migration protocol and monitorer this same migration.
You need to prepare a migration protocol on the :
- Services
- Groups
- Lists
- Dependency tables
- Business repositories
- Process
- from micro to macro processes
If a process calls itself it must be imported twice to ensure the mapping.
To start production, it is best to :
- Favour API for structures
- Have no warning when importing processes
- Validate the import thanks to the test mode by paying attention to scripts, services and sub-processes.
As a result of the migration, you have to :
- Wait for the process to be launched in real conditions by the users.
- Check that there are no errors.
- Follow up on the first instances in detail.
During migration, there are 2 special cases to which it is important to pay attention :
- In case of a modification of an operation or a change on a service you must :
- Duplicate the operation before modifying it so that it is always accessible in the previous version for the current processes.
- Make the corrections on the duplicate operation.
- Change the mapping so that the imported processes use the new operation.
- Wait until the processes that were started before the production run are completed and then delete the old operation.
- On an evolution in the start of a sub-process or if any parent processes are still in progress you must :
- Put a script just after the start to write a business rule to deduce the modified field from the unmodified field data.
