Impact of Modified Process Definitions or Chain Definitions on Processes and Chains
When you modify a process definition or chain definition that has existing processes or chains, you will no longer be able to access the process or chain definition that the existing process or chain was based on. This is due to branching, a term used in development. Process definitions and chain definitions behave the same way when it comes to branching, so the current topic will continue mentioning just process definitions, remember that it is applicable to process definition and chain definitions.
In Redwood Server, a branch is a copy of a master at a given point. Every process definition has a master process definition, as long as no processes have been submitted, no branches are made.
When you submit a process definition, a copy of the process definition is made for the process it is called a branch. This was implemented to prevent issues with process definition modifications impacting existing processes in a chain.
Note that only master process definitions are accessible via the Redwood Server ui.
Updating Existing Processes to use Latest process definition
When you edit a process definition for which processes exist in an initial state ( New, Scheduled, Held, or Modified ), the editor dialog will invite you to update all processes that are in the initial state to use the new process definition.
A specific branched process definition that is in an initial state ( New, Scheduled, Held, or Modified ) can be upgraded to use the latest process definition using the Update action from the process's context-menu. On chains this action updates the chain along with all child processes that have been modified.
Note that the above two methods only work if all parameters on the resultant process are valid. If, for example, you add a mandatory In or In/Out parameter to the process definition without default value, the updated processes will not have a valid value for the parameter in question and will remain in status Modified until the missing mandatory parameter is given a valid value.
The submit wizard ( Scheduling > Edit ) allows you to edit the current as well as any other processes in the JobGroup; allowing you to specify any missing parameter values.
When you edit a process definition or chain definition that has top-level processes or chains in an initial state ( New, Scheduled, Held, or Modified ) then a dialog will be displayed as you save allowing you to select an option for each top-level process or chain:
- Use Old Process Definition - do not update the specific process with the new process definition.
- Use New Process Definition - update the specific process with the new process definition.
- Cancel And Restart - cancel current process and restart with new process definition.
- Hold Process - do not update the specific process with the new process definition, set the process to status Held.
- Set To Error - set the process to status Error.
You use the Monitor process resolution action of the process definition to display all processes in statuses Scheduled, Held, Modified, or Never. When the underlying definition has changed, the Update action is available to allow you to update the definition used by the process. A global filter that displays all processes in the previously listed statuses is the All Process Resolutions filter. The monitor allows you to select multiple processes and simultaneously update them.
Model
When you query JobDefinition, however, you will get all process definitions and chain definitions, by default. Process definitions have properties that allow you to see if a given process definition is a master or not. Master process definitions have BranchedLLPVersion set to -1 and UniqueId set to the same value as MasterJobDefinition. Branches have BranchedLLPVersion set to the UniqueId of the master process definition they are based on (the master process definition at branch-time).
note
When you use a report based on a filter, only master process definitions and chain definitions will be displayed. If you want to have branches in your report, you must use Object Definition Queries.
Promotion
When you import a CAR file that contains updated definitions of already scheduled processes, the old definitions are used by default for already scheduled processes. You use the /configuration/Promotion/JobResolutionActionregistry entry to customize this behavior. The registry entry accepts the following values:
UseOldJobDefinition- the old definitions are used (default).UseNewJobDefinition- the new definitions are used.CancelAndRestart- current processes are canceled and restarted with the new process definitions.HoldJob- the process is set to status Held, retaining the old definition.CancelJob- the process or chain is canceled.SetToError- the process is set to status Error.Abort- the import is aborted.
You can also programmatically update the definitions using RedwoodScript.
The default value (use old definitions) allows you greater control over what happens after a CAR file has been imported.
Example
You created the process definition RS_FinReporter:
- You submit the first version of it and a branch is created.
- You inspect the output and decide it is not ready for prime-time. You edit it and save it. As of this point, the link in the process to the process definition does not work anymore; it has been replaced with the name of the process definition followed by the modification-time. At this point, no new branch has been created.
- You forgot something, so you edit it again. At this point, no new branch has been created.
- You restart the process you submitted in step 1, you note that in the second process, the link to the process definition works again, a new branch was created.
- You inspect the output and decide it is not ready for prime-time. You edit it, save it, and submit the process definition again. A new branch is created and the link works.
Modifying Submitted Definitions and Restarting them
When you modify settings at submit time of a process or chain and restart it, changes to 'scheduled start time' and scheduling parameter 'submit on hold' are ignored for the restart, parameter changes as well as changes to other scheduling parameter are retained.
When you remove a lock or event from a process or chain and restart it, the restarted process or chain will not have the lock or event.
When you remove a lock or event from a call in a chain, disable a step or call, and restart the chain, the restarted process will not have the modifications.
When you remove a lock or event from a call in a chain and restart the call, the restarted call will retain the changes.
See Also
JobChain JobDefinition ProcessDefinition