Workflows

The workflows are the core feature of GWE. They are business processes drawn up in a graphical interface that is both easy to understand and easy to modify. GWE comes with a few sample workflows inspired from real world scenarios to help you get started.

Defining Workflows

To define a new message or edit existing ones you must go to the Define Workflows view.

You should see the following view.

As you can notice you have a few possible actions:

• Add - adding a new workflow
• Select - view or edit the workflow
• Refresh - regenerate the actors’ pending actions much like the refresh action from the roles view
• Delete - tick the checkbox of the desired workflow and use this button to delete it

Adding / Editing involves 3 steps (views):

1. Define - in this step you define the basic information of the workflow
2. Setup - in this step GWE ensures that the workflow table you selected in the previous step meets the requirements
3. Design - in this step you graphically design the workflow

In the following sections we’ll go through each step in depth so as to provide you with a better undestanding of the whole process.

Define

To define a new workflow or edit an existing one there are a couple of fields that are required by GWE:

• Workflow Type: This is the unique code that identifies your workflow and distinguishes it from the other workflows. We usually choose something short and descriptive like “CONTRACT APPROVAL”.

• Activity: The activity decides which application your workflow belongs to and subsequently which directory of /schema/ab-products it should store the views of your workflows in.

• Main Table: The database table in which you want to store your workflow requests in. In the sample workflows we use the wf_requests table but you are free to choose whatever table you need.

• Workflow Icon (Optional): An icon to be displayed in the request creation view.

• Folder Path (Optional): The directory in which the views belonging to this workflow will be stored on the server. While optional, it is recommended to use a separate directory for each workflow to keep things organized. This field relies on the selected activity to determine the base path.

e.g. Choosing WorkflowEngine as your activity will use %webAppDirectory%\schema\ab-products\workflowengine\gweviews as the base path. In this scenario if we now set the Folder Path field to a value like “my-workflow”, all the axvw views of our workflow will be saved in %webAppDirectory%\schema\ab-products\workflowengine\gweviews\my-workflow.

• Description (Optional): A short description of the workflow. It will show up in the request creation view under the Workflow Type.

Setup

In the setup step GWE makes sure that the Main Table selected in the previous step meets the requirements.
The requirements are a few columns necessary for GWE to work properly:

• wf_type - the workflow type
• block_id - the id of the workflow block that the request is currently at (the progress)
• status - the status of the request (must be an enumerated field)
• color - a hex code representing the color (used with SLA escalation)
• comments - comments that the users might make with each action on the workflow (some actions can be made to require a comment from the user; e.g. a rejection that needs to be justified)

To define statuses for your workflow click on the Define Status button.
You should see a popup like this:

Click on the Update Schema button to generate any missing fields that are required by GWE.
If a required field exists both in the database and in the archibus schema you should see a by its side.
Otherwise you will see a Required label.

Additionally, you can add, edit or delete fields from your main table with the Additional Workflow Table Fields panel but don’t forget to click the Update Schema button again once you have finished the modifications.

With all the mandatory fields present and the statuses defined, the Design >> button should become enabled.
Click it to go to the next step: designing the actual workflow.

Design

In this step we can use the feature rich graphical designer to create our business process.
e.g.

The first thing you will notice is that we have a palette of draggable blocks.
Hovering the mouse over them will open a tooltip with their names.
On canvas you can right click blocks and a context menu with actions will appear if the blocks are configurable.
Such a menu will appear also for the connections between the blocks in your workflow when you left click them.

You have the posibility to undo actions with the button and redo them with the button.

Pressing the gear button will open a context menu with a few options:

• Save to Local Storage: This will save the workflow as you see it on the canvas in the browser’s local storage under a key named workflow. You can inspect this key with the developer tools (F12) and copy the value in the clipboard. This way you can share it with someone else who can load it in their local stoarge and then use the next option to load it in their canvas.
• Load from Local Storage: Loading from local storage will check to see if a key named workflow exists in your local storage and if it does it will attempt to recreate the workflow based on the value stored for that key. This is the old way of doing things but it has been kept for compatiblity reasons. It is recommended to use the newer functionality: Export Workflow and Import Workflow.
• Export Workflow: This will export your workflow as a json file which can be shared with others.
• Import Workflow: Will accept a json file containing all the details of a workflow in order to reconstruct it on the canvas.
• Show: This has two checkboxes: Details and Block Id. When details are included, the canvas will display extra information about the blocks (like the description of each block and the status of the reaquest in each step). When the block ids are included GWE will show the id of each block on the canvas as they are saved in the database. This may prove helpful when debugging a workflow.
• Reset: Will set the focus to the start event of the workflow.

Start Event

All workflow must have a exactly one Start Event.
Drag it from the palette to the canvas and a popup form will appear.

In this form you can configure 3 things:

• Description (Optional): A short description of the action that starts the process (e.g. “Create Request”).
• Init Next Actions: Displays the next activity actions which became active after main action is triggered.
• View Name: The name of the axvw view associated with this block (what the user will see when they want to create a request).

Along with the fields you will notice a couple of actions:

• Define View: When you need to create a new view.
• Select View: When you need to select the view from pre-existing ones if you have already defined some.
• Code Editor: Allows the you to directly modify the code of the view and its javascript controller from the interface. However, it only works when you have selected a valid view in this field.

End Event

All workflows must have at least one End Event. It marks the end of the request.
Drag it from the palette to the canvas and a popup form will appear.

There are a couple of things you can configure for an End Event:

• Description (Optional): A short description of the closed state. Typically we use the status of the request in past tense (e.g. “Closed” or “Rejected”).
• Show Log: Whether to show the Action Log button on the view. When clicked this button opens a popup with the request’s history: who made which action when and who is supposed to do the next action if the request is not already finished.
• Show Diagram: Whether to show the Diagram button on the view. When clicked this button opens a popup with the request’s graphical history. It shows the actual block on the graphical design where the request is currently at.
• Role (Optional): The role that can see the request in this closed state. By default all the actors that have made an action during the request’s lifetime can see it.
• Expected Duration (Optional): The duration in minutes that the action is expected to be completed in. This will help with the heatmap analysis where you can check which steps of the workflow take the longest and if the time is in the expected range or not.
• View Name: The name of the axvw view associated with this block (what the user will see when they want open the request to do this task).

Along with the fields you will notice a couple of actions:

• Define View: When you need to create a new view.
• Select View: When you need to select the view from pre-existing ones if you have already defined some.
• Code Editor: Allows the you to directly modify the code of the view and its javascript controller from the interface. However, it only works when you have selected a valid view in this field.

Timer Event

Timer Events are events that are triggered independently from the workflow in a scheduled manner.
Based on their type there are 3 predefined rules: SLA Escalation, Archive or Run Rule Chain.

Exclusive Gateway

The Exclusive Gateway evaluates the user’s action and routes the request to the next action.

A typical use case of the exclusive gateway:

Parallel Gateway

The Parallel Gateway is used to represent two or more concurrent tasks in a business flow.
The flow will not progress to the next step until all the parallel actions have been performed.

A typical use case of the parallel gateway:

User Task

The User Task indicates an activity that is being performed by a person with a corresponding role.

There are a couple of things you can configure for a User Task:

• Description (Optional): A short description of what the user is supposed to do in this step (e.g. “Approve”, “Return” etc).
• Show Log: Whether to show the Action Log button on the view. When clicked this button opens a popup with the request’s history: who made which action when and who is supposed to do the next action if the request is not already finished.
• Show Diagram: Whether to show the Diagram button on the view. When clicked this button opens a popup with the request’s graphicalhistory. It shows the actual block on the graphical design where the request is currently at.
• All users must perform the task: When set to yes the workflow will require all the users of the role to perform this task beforecontinuing. By default the workflow will continue to the next step when the task is performed by one user.
• Custom Actions (Optional): These are actions that you can implement by customizing the javascript controller of view. GWE alwaysdisplays these custom actions if they are defined here. For multiple actions use the ; character as separator. To get started, generate anew view and open its javascript controller in your favourite editor. Over there you will see some commented methods that help you get started.
• Role: The role that must do complete this task.
• Expected Duration (Optional): The duration in minutes that the action is expected to be completed in. This will help with the heatmap analysis where you can check which steps of the workflow take the longest and if the time is in the expected range or not.
• View Name: The name of the axvw view associated with this block (what the user will see when they want to create a request).

Along with the fields you will notice a couple of actions:

• Define View: When you need to create a new view.
• Select View: When you need to select the view from pre-existing ones if you have already defined some.
• Code Editor: Allows the you to directly modify the code of the view and its javascript controller from the interface. However, it onlyworks when you have selected a valid view in this field.

A typical use case of the user task:

Service Task

The Service Task indicates an automated evaluation of an expression or Java method.
The automated expression evaluation and the Java methods are defined in the Service Connector forms.

Connectors

There are 2 types of connectors between blocks.
They link the blocks together and dictate the flow of the request.
To connect the blocks you have to click on one of the small circles protruding from the side of a block and drag a connection to another block.

Status Connector

The Status Connector is used to link an Exclusive Gateway to an End Event, a User Task or a Parallel Gateway.
It is also used to connect a Start Event to a User Task.
GWE will create an action for each status connector.

To edit an action left click on it and select Define Action.

The editable fields are:

• Action Name: The name of the action which also represents the text on the button the user will see when they open the request to do the action. This text can also be localized in the following view:

• Status: The status the request will be in after this action is done.
• Action Type: Can be one of 3 types: Regular, Main or External.
  When there is only one possible action, that will always be locked to Main.
  When the user has multiple choices, one of them should be the main action and the others Regular ones.
  The main action will be highlighted with a different color in the UI compared to the regular ones.
  External actions will not appear in the UI when the user opens the request. Instead, those actions are meant to be executed from an external source, like the REST API.
• Show in action bar: If set to Yes it will display the action in the the request management view so you do not have to open the request to do the action. Instead you can just select the request by ticking its checkbox and then clicking on the action.
• Validate Fields: If set to Yes it will ensure that all forms in the view can be saved before carrying out the action.
• Use Confirmation Message: If set to Yes it will require the user to add a comment before being able to do the action. This comes in handy in situations where you want to know more details about why the user is doing the action (e.g. rejecting a request for a particular reason that must be specified).
• Confirmation Message (Optional): If the Use Confirmation Message is set to No, ignore this. Otherwise, fill out a title for the popup that will force the user to enter a confirmation message (e.g. when a user rejects the request you may ask them to “Specify the reason” - this could be used as a confimration message).
• Use Comments: If set to Yes it will add a text area containing the contents of the comments field of your request. It’s a read only field that gets automatically updated as users do actions and/or provide confirmation messages.
• Append Comments: If set to Yes, the auto generated comments and the user’s confirmation messages will be appended to the end of the existing comments value. Otherwise the value will be overwritten each time with the latest entry.
• After Action Message (Optional): By default, after an action has been performed the user will see a message with the current request status.

The default message looks like this:

You can change this default message to another one by selecting it with the "" button of the After Action Message field. Click on the card below to learn more about how you can define messages.

Service Connector

The Service Connector is used to link an Exclusive Gateway to a User Task or to a Parallel Gateway.
For a given instance of the process, only one of the paths can be taken.
GWE will create a service connector only if the exclusive gateway is preceded by a service task.

Left clicking on the service connector will expose the context menu where you have 3 options:

The Define Events and Remove Connection work the same as in the Status Connector.
The Validation Status option will open a new popup where you can configure the conditions.

There are several things you can configure here:

• Action Name (Read Only): Defaults to AUTOMATIC since it represents an action done by GWE and not a user.
• Status: The status the request will have after the condition is evaluated to true.
• Condition Type: Can be one of 3 types: Default Flow, Java Method or Evaluate Expression.
  The Java Method option allows you to define a custom implementation in Java that should return a boolean.
  The Evaluate Expression will allow you to use one or more SQL clauses to build the condition.
  The Default Flow path will be the last evaluated because it will always return true.
  GWE will evaluate each condition defined in the service connector form and if any of them returns true, the remaining conditions will be ignored (GWE will follow first path which returns true).
• Condition (Optional): The Default Flow type will not require a condition as by default it always returns true.
  For the Evaluate Expression type you need to provide the SQL clause(s) using the fields of the main table of your workflow.
  e.g. If our workflow is based on the wf_requests table we have access to all its fields when building a condition:

(status = 'Approved' OR status = 'Issued') AND cost_estimated >= 250000

For the Java Method type you need to create a java class, write a method that takes two arguments: the event handler context and the request id and then you need to provide the full class name and method name in the condition field.
e.g. Suppose you just created the following class:

package com.archibus.gwe.util;
 
import com.archibus.datasource.DataSource;
import com.archibus.datasource.DataSourceFactory;
import com.archibus.datasource.data.DataRecord;
import com.archibus.datasource.restriction.Restrictions;
 
public class GweTestUtil {
 
	public boolean isWithinBudgetLimit(String pkeyValue) {
		final Integer requestId = Integer.parseInt(pkeyValue);
		final DataSource ds = DataSourceFactory.createDataSourceForTable("wf_requests");
		ds.addRestriction(Restrictions.eq("wf_requests", "request_id", requestId));
		final DataRecord request = ds.getRecord();
 
    // More business logic here...
 
		return false;
	}
}

you can use it for GWE conditions like this:

com.archibus.gwe.util.GweTestUtil|isWithinBudgetLimit

• After Action Message (Optional): By default, after an action has been performed the user will see a message with the current request status. Works similarly to the Status Connector’s after action message.