Publishing/Checking-Out Workflows

Workflows start to make an impact on your operations once you have published them. Until you have published a valid workflow whatever you design remains a working draft:

Before ESM allows a workflow to be taken into active operation, it will validate whether the workflow design contains any major errors such as missing condition statements in condition activities. Elements with erroneous configurations will be marked with red borders on the editor canvas until the configuration is valid.

Once a workflow is published into active service, all new incoming issues will trigger the execution of the workflow if the selection criteria are met.

If you notice after publishing a workflow that it doesn’t work as you expected or you want to retire it, you can remove the workflow from active service by checking it out of active service. If you do so, then the working draft will be reset to the workflow definition you checked out. All ongoing issues that have been handled by the checked out workflow will remain active and ESM will try to complete them according to the checked out workflow definition. You need to manually terminate any issues if they will not complete by themselves. Any new issues for the template will not be handled anymore by the checked out workflow but must be processed manually or a replacement workflow.

Workflow Lifecycle

ESM keeps track of several versions of one and the same workflow:

• A working draft which is the last version you have saved.
• The last published workflow with which newly created or updated data cards will be processed if they meet the workflow selection criteria.
• All previously published versions of workflow configurations as long there are still data cards being processed.

When you open a workflow in the workflow editor you are working by default always on the working draft version. If you choose to checkout a workflow from active service (i.e. undo the publishing action), then the working draft version of the workflow will be reset to the workflow version you have just checked out.

Changes to the working draft are not automatically saved to the database. You should save the changes or discard the changes before doing something else in ESM.

You must always publish your changes to activate them for new or updated data cards. When you publish a workflow into active service then that version will be automatically saved as new working draft.

You can delete workflows from ESM by selecting the Delete button. However, you can only delete workflows that have no open issues. To delete a workflow, issues must have either gone through the entire workflow sequence or have been terminated by an ESM user. You cannot manually delete old versions of workflow configurations. They will be removed by the system when the last data card has been processed.

Checking out a workflow is not enough to enable deletion because there might be still issues being actively processed with the workflow. ESM will always validate whether any issues are still in progress before allowing the deletion of the workflow.

Exporting/Importing of Workflows

Any workflow can be exported to your workstation and then imported again for example to a production system. To export and import workflows, select from the Workflow drop-down menu the corresponding action. Remember to export and import the corresponding templates as well.

Exporting will export the last published version of the selected workflow. Only if there is no published version then the working draft will be exported.

Exporting/Importing of Workflow Nodes

It is possible to export a single workflow node and re-use it another workflow of another template. For exporting a workflow node, select first the corresponding workflow node and then choose from the Workflow drop-down menu “Export workflow node”. The workflow node will then be downloaded to your computer.

To import a workflow node, you must select first the workflow to which you want to import the workflow node. Attributes and attribute values which do not have matching items in the target template will be replaced with empty fields after the import. The usual workflow validation will identity potential corrections that must be done in the imported workflow node.

Verifying the Workflow Status of an Issue

The workflow engine will maintain the status of the workflow for each issue. The status of the workflow can be seen in the data card view of the issue itself. The possible states are: Running, Finished, Error, or Cancelled. The workflow status is a system value but can be made visible by assigning the WorkflowStatusHandler to an attribute.

All users can cancel workflow execution manually by clicking on the workflow status indicator.

Auditing Workflow Configurations

ESM will automatically keep track of changes to the workflows in the system-wide configuration log. The creation of new workflows, the deletion, the publishing, any editing and checking out will be logged with time-stamp and user ID. You can audit any changes to the workflows from the configuration log file.

Logging of Workflow Execution

Log entries are generated for each workflow execution to facilitate administration and troubleshooting. These entries are saved in the workflow.log file. To download this log file, go to Administration > Maintenance > Logs > Download logs. Below is a sample of how the execution of a workflow node is recorded in the logs. The sections highlighted in bold represent key aspects of the log. For ease of reference, the log excerpt is sequentially numbered. These numbers correspond to those in the accompanying screenshot of the relevant workflow, provided after the log excerpt.

1.    WorkflowLogger|INFO|2023-03-22 10:12:12,123|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} run workflow {id: 371441422, name: Checklist approval workflow NEW, templateId: 119733870, wrapperId: 366102831}
2.    WorkflowLogger|INFO|2023-03-22 10:12:12,123|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running StartpointNode {id: 371440955, name: Begin}
3.    WorkflowLogger|INFO|2023-03-22 10:12:12,273|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ConditionNode {id: 371441271, name: LOB SMB escalation or risk amount 1,5m}
4.    WorkflowLogger|INFO|2023-03-22 10:12:12,275|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} run then path:Then
5.    WorkflowLogger|INFO|2023-03-22 10:12:12,430|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ApprovalNode {id: 371441119, name: LOB SMB Approval}
WorkflowLogger|INFO|2023-03-29 13:46:25,469|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ApprovalNode {id: 371441119, name: LOB SMB Approval}
WorkflowLogger|INFO|2023-03-29 13:49:40,790|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ApprovalNode {id: 371441119, name: LOB SMB Approval}
6.    WorkflowLogger|INFO|2023-03-29 13:49:41,748|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ApprovalNode {id: 371441165, name: Credit Committee Approval}’
WorkflowLogger|INFO|2023-03-31 06:47:55,392|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ApprovalNode {id: 371441165, name: Credit Committee Approval}
7.    WorkflowLogger|INFO|2023-03-31 06:47:56,496|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running EmailNode {id: 371441190, name: Notify onboarding team}
8.    WorkflowLogger|INFO|2023-03-31 06:47:56,748|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ConditionNode {id: 371440832, name: Check risk amount}
9.    WorkflowLogger|INFO|2023-03-31 06:47:56,748|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} run then path:Then
10.    WorkflowLogger|INFO|2023-03-31 06:47:56,892|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running WaitConditionNode {id: 371440854, name: Waiting for initial approval}
WorkflowLogger|INFO|2023-03-31 06:47:56,892|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} Conditions were not met. NodeId: WaitConditionNode{id='371440854', name='Waiting for initial approval', criteria=ConditionCollection[booleanOperator=AND,conditions=[SimpleCondition[operator=EQUAL_TO,leftOperand=AttributeOperand[groupAttributeId=119738157,ids=[371440842]],rightOperand=StaticValueOperand[value=StaticValueDTO[value=Initial approval,code=initial_approval,staticValueId=133859530],isOpen=false,id=371440844],id=371440847]],id=371440851]}. Workflow is pending for conditions of this node to be met before continuing.
11.    WorkflowLogger|INFO|2023-03-31 08:53:03,606|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running WaitConditionNode {id: 371440854, name: Waiting for initial approval}
WorkflowLogger|INFO|2023-03-31 08:53:03,606|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} Conditions were met. NodeId: WaitConditionNode{id='371440854', name='Waiting for initial approval', criteria=ConditionCollection[booleanOperator=AND,conditions=[SimpleCondition[operator=EQUAL_TO,leftOperand=AttributeOperand[groupAttributeId=119738157,ids=[371440842]],rightOperand=StaticValueOperand[value=StaticValueDTO[value=Initial approval,code=initial_approval,staticValueId=133859530],isOpen=false,id=371440844],id=371440847]],id=371440851]}. Workflow proceeds.
12.    WorkflowLogger|INFO|2023-03-31 08:53:03,883|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running SetValueNode {id: 371441300, name: Set decision to approved}
13.    WorkflowLogger|INFO|2023-03-31 08:53:04,060|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running EndpointNode {id: 371440960, name: Closed}

Example of a workflow with numbered references to the workflow log snippet':

Logging of Workflow Execution and Failed Data Card Saves

When a listener or handler prevents the workflow from saving a data card, the event is documented in the itsm.log file instead of the workflow log. Failures of this nature are captured in log entries that typically appear as follows:

ErrorLogger|ERROR|2023-05-25 13:43:14,116|QuartzScheduler_Worker-3||Job (workflow.7548098#7546966#7546920#0 threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: com.bitmount.boas.exception.PersistenceException: com.efecte.datamodel.entity.action.FatalDataCardActionException: Data card save failed due to fail_card attribute having a value.]
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)
Caused by: com.bitmount.boas.exception.PersistenceException: com.efecte.datamodel.entity.action.FatalDataCardActionException: Data card save failed due to fail_card attribute having a value.

The final ID in the first line indicates the specific workflow node where the process halts.

In the workflow log, this appears as if the card halts at the node where the failed save occurs. However, in the User Interface (UI), the workflow step (displayed in the top right of the card view) indicates that it's at a previous node. This discrepancy occurs because the card actually reverts to the first preceding 'timer' or 'wait condition' node before the save failure occurred.