Overview
Parameter entities can be managed in two environments: in the production environment, or in the development environment. It is really important that you consider this classification, so that you best design your Parameter entities in terms of system maintainability.
The criteria to choose one type or the other, depends on how you expect their values to be defined and managed:
They can be defined and managed dynamically by a business administrator in the production environment according to the business needs, or they can be defined and managed during design time (in the development environment).
|
Keep in mind that Replicated entities, due to their nature, are managed remotely. |
1. Manageable in the production environment
For an entity to be manageable in the production environment, it means that the entity’s values will be entered and edited by a business administrator, separately on that particular production environment. Such values will not be deployed from a development environment to a production environment.
Administration of values in a production environment is easily done through options in the Work portal, as described at Include records in Parameter Entities through the Work Portal.
If you wan to transfer values from the development to the production environment, you carry out a data synchronization.
Quick facts of entities manageable in the production environment
Make sure you acknowledge these facts when deciding over where to manage Parameter entities:
•Web administration
When the entity has the Web administration option enabled, in its Advanced properties, it will be displayed for end users to modify its values.
If the Web administration option is not enabled, even if the entity is marked as Manageable in production, it will not be displayed.
•Deployment: values handled separately in each environment
In each deployment, Bizagi only updates the metadata of the entity. That means that it only updates the structure of the entity. For example, attributes' properties or entity's properties. Values, on the other hand, are not synchronized and will need to be handled in an entirely independent manner.
•Switching its definition
You may convert an entity manageable in production so that it is set as manageable in development. We recommend to review if the entity has no forms associated (not being currently used), it is not in use by Bizagi Data Replication, it has no collections, and if it has not been deployed yet to a production environment. Review the deployment considerations.
In addition to the above, you will need to make sure that it is compatible for management in a development environment (e.g, if it does not have in turn a relationship of any type with another Parameter entity which is manageable in production).
For more information about compatibility definitions in this aspect, refer to the Where to manage the Parameter entity section below.
Example of entities manageable in the production environment
Assume we have a Parameter Entity called Documents Requested. This entity contains the list of all documents that are requested to every customer when opening a bank account. Required documents can be certainly added, modified or disabled (according to regulations or specific business needs). Consequently, the list can vary significantly over time, at unpredicted moments and unknown time intervals. Therefore this entity should be manageable directly in the production environment, since this will allow the flexibility to edit values anytime through Bizagi Work portal options.
2. Manageable in the development environment
Parameter entities that are manageable in the development environment are not displayed for edition in the production environment. This means that end users will still be able to use and select data in a case, but that data will not be available for dynamic changes without a deployment.
Entities which are manageable in the development environment are very useful to define a finite list of possible values that affect the process routing.
These can be also used to hold a list of predefined values that you know they will not change over time, such as Gender.
The main advantages when using this type or Parameter entity are: that you avoid administration overhead in the production environment. especially when you identify there will be no need to provide the option to administer such values (nor add, modify or disable), and that you have more control over the process work flow's business parameter values.
Administration of values in a development environment is easily done through options in Bizagi Studio, as described at Include records in Parameter Entities through Bizagi Studio.
Quick facts of entities manageable in the development environment
Make sure you acknowledge these facts when deciding over where to manage Parameter entities:
•Web administration
When the entity has the Web administration option enabled, in its Advanced properties, it will be displayed for end users to modify its values in the Work Portal, even if the entity is set to be managed in the production environment. The difference is that when managed in production, its values are not deployed.
If the Web administration option is not enabled, the entity will not be displayed.
•Deployment: Development values always overwrite those at production.
Values of entities manageable in development will always be deployed to the production environment within a deployment; and these will overwrite any existing records (or new ones will be insert as well if applicable).
•Switching its definition.
You may convert an entity manageable in development so that it is set as manageable in production at any time, though you will need to make sure that it is compatible for management in a production environment (e.g, if it does not have in turn a collection of values from a Parameter entity manageable in development). For more information about compatibility definitions in this aspect, refer to the Deciding where to manage the Parameter entity section below.
Example of entities manageable in the development environment
Assume we have a Parameter Entity called Request status. This entity contains the list of possible states of a request: approved and rejected.
Assume that according to the state set for the request, as evaluated by an approver, the process work flow takes a different routing that fires up a different set of tasks. Given that this is a finite list of values which directly affect the process work flow, this entity should be managed from the development environment.
In the event that a new value is needed (for instance, assume a "needs revision" status), then it is usually expected that you define this new status in the development environment, alongside with any modifications to your process work flow so that it acts accordingly (i.e enables an end user to review the request when marked under this new possibility).
Configuration and default behavior
By default, Parameter entities start off as Manageable in development environment (if you do not carry out any action when creating entities).
As a best practice, you should define this property whenever a new Parameter entity is created and review it before deploying to production.
To configure this, notice the entity creation wizard for Parameter entities only, shows the Manage values in Production environment checkbox located at the bottom of the window. By default, the check box is not selected so it is recommended to review and think over if your need to allow this entity to be manageable in the production environment:
For an existing Parameter entity (if you skipped the initial configuration or to modify it), this property can be reviewed through the Expert View. Once there, select the Entities module, right click the given entity and choose the Advanced Properties option. Under the Instances tab, you can locate checkbox to mark or leave unmarked correspondingly.
In Bizagi Studio, notice that Parameter entities will have an additional mark that makes them look slightly different according to this property's values, as shown below:
Deciding where to manage a Parameter entity
If you have trouble determining whether an entity should be manageable in the production or development environment, consider the following:
Scenario |
Should be Manageable in production |
Should be Manageable in development |
|---|---|---|
The entity's values will be used in any kind of rule like an expression, or assignment rule, or in a form having actions and validations. |
|
X |
The entity's values will be used to define how the process workflow reacts (logic behind the routing). |
|
X |
The entity will need constant administration, because its values are likely to be changing and updated often. |
X |
|
The entity will need a relationship with the WFUser (references this special System entity which is handled in production). |
X |
|
The entity will need a relationship with other System entities such as Area, Role, Location, Skill (these System entities all have their values defined in the development environment). |
|
X |
The entity will need a collection (1-n relationship) of another Parameter entity which is manageable in the development environment. |
|
X |
The entity will need a relation (of any type) with another Parameter entity which is manageable in the production environment. |
X |
|
For a better illustration on how you may create compliant relationships for each of the 4 possible combinations when having the two sub-types of Parameter entities, refer to the image below:
Last Updated 1/23/2023 11:57:08 AM