Workflow in Master Data Management
Workflow in Master Data Management solutions includes events associated with business rules, notifications for human actors to take actions on exceptions such as Data Quality issues, data survivorship (unmerge records, merge/consolidate records, etc.), and notifying the participating systems regarding the actions taken.
Workflow in TIBCO EBX
In EBX, the workflow has two components: Workflow Model and Data Workflow. A Workflow Model is the steps and code consisting of the business rules, conditional events, user actions, while the Data Workflow is an instantiation of the Workflow Model with the data going through different operations defined in the model.
Implementing a Workflow Model in EBX involves creating the workflow with a unique name and implementing different operations the data needs to go through (user task, script task, conditional branching, wait for the task, etc.), configuring the model with different properties, including permissions, activating, and finally publishing the workflow for the authorized users to be able to launch it. EBX provides an intuitive user interface to configure workflow models and data workflows.
Creating Workflow Model
A workflow can be created in the Workflow Models area by selecting “Create a Workflow Model”. Workflow can be created, edited or imported, and published in the workflow area of the user interface.
Configuring Workflow Model
We can perform the following operations in the EBX workflow.
- User Task
- Script Task
- Condition
- Sub-workflow Invocation
- Wait Task
User Task: A user task is a typical workflow task where a human user performs a task with the assistance of a ‘Web Component’. This ensures that interactions with the repository are secure and robust. Since a Web Component is technically a web resource inside a Java web application, the interaction can serve any purpose. For example, we can associate work items under a User Task to different Profiles.
Script Task: Script Tasks are automatic tasks that do not involve human interaction. There are two types of script tasks: Library Script Task and Specific Script Task. It defines a script in a language that the engine can interpret. The list of built-in beans is displayed in ‘library’ mode (these beans are defined in module.xml files). When a bean is selected, the associated parameters are automatically displayed. In the ‘specific’ mode, it is necessary to enter the complete classpath to use. In this case, parameters are not used (data context is used in the class).
Condition Task: A condition is used to determine which route has to be taken during the workflow. This switch is made of two derivations. The result of a condition is a boolean (‘true’ or ‘false’). It is possible to specify which step must be executed according to the result of the condition (‘if true …. then …’, ‘if false …. then …’).
Sub-workflow Invocation: A sub-workflow invocation is an automatic task that invokes one or several workflows. This type of step is useful to reuse an existing workflow model by invoking a single sub-workflow or to execute parallel workflows by invoking several sub-workflows.
Wait Task: A wait task is a task that pauses the current workflow until a specific event is received. When the workflow resumes, the data context can be updated with received parameters. After resuming, the workflow automatically goes to the next step. For example, the wait task is useful to wait for the result of the execution of an external system.
Workflow Model Properties
| Module Name | Name of the workflow module |
| Notification Start | Profiles to receive a notification when the workflow execution starts |
| Notification of Completion | Profiles to receive a notification when the workflow completes |
| Notification of Error | Profiles to receive a notification when the workflow execution fails |
| Priority | This is used to set the priority of the workflow (any of the 6 priorities between “Very Low” to “Urgent”) |
| Activate Quick Launch | Allows skipping the documentation step when launching the new workflow. |
| Automatically Open The First Step | Automatically opens the first work item instead of the user having to select from the inbox if the first step is not a sub-workflow item. |
| Workflow Trigger | Triggers actions based on the events within the workflow. |
| Permissions | Defines the permissions related to the actions associated with the workflow |
| Programmatic Action Permissions | A custom component to manage permissions of the workflow by overriding the permissions defined in the “Permissions” property. |
Launching Data Workflow
We can launch a workflow by clicking the Launch button against the desired Workflow Launchers under the Workflow tab.
Monitoring Data Workflow
Data workflow can be monitored under Active Workflows. Depending on the permissions, one can view the workflow execution, replay the workflow steps, or terminate them.
Deleting a Workflow Model
The workflow model can be deleted by clicking Action->Delete. With this action, only the Workflow Model is deleted but not the associated Publications.
