Configure process start validation
This article includes updates for Smart ID 23.10.3.
This article describes how to configure when to start processes on core objects in Smart ID Identity Manager. This can, for example, be used if you have made a card request for a person, then you should not be able to make another card request for the same person until the first is done.
Configure the validator 'Dynamic Search'
Before you can configure when to start a process, you must have defined a search configuration. For more information. see Set up search configuration in Identity Manager. You can use fields of the selected dataset via expressions in the search configuration, for example, ${Person_Email}, like during a process from the process map.
If there is a precondition for a process to start that depends on data from inside Identity Manager, and that data can be found via searches, use the 'Dynamic Search' precondition validator. The symbolic name is dynamicSearchProcessStartInterceptor.
The 'Dynamic Search' precondition validator validates the number of results that are found by a configured search. Depending on if the number matches the condition or not, the required action is triggered.
In Identity Manager Admin, go to CoreTemplate (for example, Identities or Cards) > State tabs > Additional Commands > Precondition.
Configure the parameters.
Click Save.
Configure parameters
Parameter | Possible values | Description |
|---|---|---|
SearchConfig | <SearchConfig> | A search configuration, whose result provides the required data needed to verify the wanted precondition. |
ResultCondition | < lower than = equals > greater than | The condition that is used to validate the number of the result of the search configuration. |
ResultCount | <number> | The number of entries that the ResultCondition validates against. |
Visibility* | isDisabled isEnabled isNotVisible isVisible | Action that should be triggered if the condition if fulfilled. |
Visibility: If the condition is not fulfilled, the opposite of the configured event will be executed. See the table below.
Selected condition | Action if condition is fulfilled | Action if condition not fulfilled |
|---|---|---|
isDisabled | Process is disabled (grayed out in Identity Manager Operator) | Process is enabled |
isEnabled | Process is enabled (in Identity Manager Operator) | Process is disabled (grayed out in Identity Manager Operator) |
isNotVisible | Process is not visible (in Identity Manager Operator) | Process is visible |
isVisible | Process is visible (in Identity Manager Operator) | Process is not visible |
Configure the validator 'One Process per CoreObject'
The 'One Process per CoreObject' precondition validator can be used when there are many operators and you want to make sure that if one operator has started a process, for example, a card request for a specific person, that a second operator cannot start a card request for the same person at the same time. You configure in Identity Manager Admin if the process shall be grayed out or not visible at all in Identity Manager Operator.
The symbolic name is oneProcessPerCoreobjectParamStartInterceptor.
In Identity Manager Admin, go to CoreTemplate (for example, Identities or Cards) > State tabs > Additional Commands > Precondition.
Configure the parameter.
Click Save.
Parameter | Possible values |
|---|---|
Visibility | isDisabled (default) isNotVisible |
Action that should be triggered if a process instance is already running:
Selected condition | Action if condition fulfilled | Action if condition not fulfilled |
|---|---|---|
isDisabled | Process is disabled (grayed out in Identity Manager Operator) | Process is enabled |
isNotVisible | Process not visible (in Identity Manager Operator) | Process is visible |
Configure the validator 'Execute Script'
The 'Execute Script' precondition validator can be used for a wide range of preconditions (combined ones, customer-specific ones, etc.).
Prerequisite is a script that does the necessary validation checks and provides two boolean variables representing the results (see the parameters below).
You can use fields of the selected dataset, for example, "Person_Email", like during a process from the process map.
The symbolic name is executeScriptStartInterceptor.
In Identity Manager Admin, go to CoreTemplate (for example, Identities or Cards) > State tabs > Additional Commands > Precondition.
Configure the parameter.
Click Save.
Parameter | Possible values | Action that should be triggered if a process instance is already running |
|---|---|---|
Script | Scriptname | Script name from the combo box that shows all available script names inside the system. |
isVisibleVar | <varname> | Name from the variable in the script that represents if the process should be visible or not. |
isEnabledVar | <varname> | Name from the variable in the script that represents if the process should be enabled or disabled. |
Migrate old StartInterceptors
This section describes how to migrate from the old StartInterceptors to the new configuration.
TypedCoreObjectRelationProcessStartInterceptor & RelatedObjectsInDefinedStateMissingProcessStartInterceptor
Functionality:
Checks if a relation to a core object of the hard coded
CoreTemplateName/CoreTemplateName and Stateexists.To have a working StartInterceptor, creation of a Subclass is necessary to set a core template name
Migration:
Configure a SearchConfig that matches with the Relation-Search and State.
Use 'Dynamic Search' and set the parameters accordingly as described above.
CoreObjectProcessStartInterceptorComposite
Functionality:
Combines several hard coded StartInterceptors.
To have a working StartInterceptor, creation of a Subclass is necessary. List with StartInterceptors to combine needs to be hardcoded inside.
Migration:
Depending on how the combined StartInterceptors are used in combination, a 1 to 1 migration is not possible.
OneProcessPerCoreObjectStartInterceptor
Functionality:
Checks if for that core object, exactly the same process is already running, for example, if a card request for a specific person is already running.
Problem: Sub-processes where not taken into account. That resulted into wrong results if the process is at that moment in one of the sub-processes.
Migration:
Use 'One Process per CoreObject' and keep the default value of the parameter "Visibility": "isDisabled".