abas Software AG

You can use Administration Overview to manage abas BPM. You can easily and quickly create new users and groups or edit and delete existing ones. Additionally, you can configure abas ERP triggers to start workflows automatically. Furthermore, access using the API key is configured in Administration Overview.

Administration Overview is available at the path <tenant>.[<region>].<domain>/workflow/administration/ (for Hybrid-Cloud installation) or at the path <hostname>/workflow/administration/ (for On-Premises installation).

1. Structure

Administration Overview consists of the following sections:

To open Administration Overview, go to the URL <your-cloud-url>/workflow/administration/. If you have logged in as administrator, you can see all users, groups and triggers and manage them. Furthermore, you can generate a new API key.

2. Users

The Users tab displays all users that can use abas BPM. You can create new users or edit and delete existing ones. abas BPM has its own user management which does not overlap with abas ERP.

2.1. Creating users automatically

An abas BPM user is automatically created as soon as a person logs on to an abas BPM application (e.g. Task Overview) with a valid login. The process engine uses these data for the creation, e.g., the user email is used as the ID.

Requirement: The user must exist in the user management.

2.2. Creating users manually

To create a BPM user manually, click the + button and fill in the following fields:

  • ID - unique ID (recommendation: use the email address)

  • First Name - first name

  • Last Name - last name

  • Email - email address

Then click the Add button to create the user.

After a user has been created, it can be used in Workflow Designer.

2.3. Editing and deleting users

To edit a selected user, use the adminoverview users icon edit button. You can edit the first name and the last name.

To delete a selected user, use the adminoverview users icon delete button.

3. Groups

The Groups tab displays all groups which can be used in Workflow Designer. You can create new groups, edit and delete existing groups, assign users to groups or remove users from groups.

3.1. Creating groups

To create a new group, click the + button and fill in the following fields:

  • ID - unique ID

  • Name - group name

  • Type - user-defined group type

Then click the Add button to create the group.

After a group has been created, it can be used in Workflow Designer.

3.2. Assigning and deleting users

To assign users to a group, select the group and click the 15 button. In the opened window, you can search for users in the search bar and click the Add button to add them to the group. To remove a user from a group, select the user and click the adminoverview users icon delete button.

3.3. Editing and deleting groups

To edit a selected group, use the adminoverview users icon edit button. You can change the name and type. To delete a selected group, use the adminoverview users icon delete button.

Deleting a group directly affects modeled or running workflows.

4. Triggers

Triggers are required to automatically execute workflows from abas ERP under certain conditions. On the Triggers tab, you can create new triggers or edit and delete existing ones.

4.1. Creating triggers

To create a new trigger, click the + Add Trigger button and fill in the following fields:

  • Name - unique name

  • Description (optional) - user-defined description

  • Process definition - name of the workflow to be started automatically

  • DB Group - table of variables number of the object (e.g. 3:22) for which the workflow is to be started

  • Modes - mode for which the trigger is to become active (multiple modes must be separated by commas)

    • New - creating a new data record

    • Copy - creating a new data record using a template

    • Edit - editing a data record

    • Delete - deleting a data record

    • Release - transfer a data record

  • Clients - clients for which the trigger is to be activated (defined in docker-compose.yml)

  • Active - status of the trigger, activated or deactivated

  • Condition (optional) - conditions under which the trigger is to become active (language: Groovy)

Condition-Variablen
bpmEditor: editor object (access to all variables of the abas ERP object)
bpmCurrentUser: user logged into abas ERP
bpmClient: current client name (value of global environment variable G|client)
Achtung: Only use English field names
se the table of variables number of the shell groups for the shell group triggers, not the table of variables number of the header or table section.
There can only be ONE triggers per database group.

4.2. Editing and deleting triggers

To edit a trigger, use the Edit button on the right. Use the DELETE button to delete the trigger in the opened window.

4.3. Trigger example

The worklfow Sales order release should be started when the following conditions are met:

  • A new sales order (3:22, Mode: New) has been created.

  • The sales order net total (totalNetAmtDom) exceeds the value 10.000 .

  • The current user is called wf1.

4.4. Creating a corresponding workflow

The first task of a workflow which is to be started by a trigger must be a User Task with the abas ERP Workflow Template template. Through this task, you can save screen parameters as variables, such as the ID of the object.

You can now start the workflow in Task Overview using the + button or via a selected screen event which has been defined in the trigger. If the workflow is started via the trigger, the first User Task is executed already when saving the screen and the workflow directly goes to the next step.

4.5. Entering the abas BPM event handler

To use the trigger, you must enter the abas BPM event handler in fop.txt. To do so, enter the screen number, the screen event and the abas BPM event handler.

Example:
The customer object has the database number 0:1. Therefore, the event handler must be entered as follows

fop.txt
# Customer workflow
0  * maskein * * * java:de.abas.workflow.erp.handler.WorkflowEventHandler@wkflw
0  * maskpruef * * * java:de.abas.workflow.erp.handler.WorkflowEventHandler@wkflw
0  * maskende * * * java:de.abas.workflow.erp.handler.WorkflowEventHandler@wkflw
Versions older than the abas BPM Backend Version 1.0.0 require workflow instead wkflw.
For example:
0 * maskein * * * java:de.abas.workflow.erp.handler.WorkflowEventHandler@workflow

5. Notifications

For some processes, it is useful to send notifications after user actions. This section will show you how to define email notifications.

This function is available from Version 1.1.
If a notification is set as the standard, it applies to all User Tasks of this process. This setting can be made in the administration area. Notifications can also be defined in the User Task itself. The global settings in the administration area will then be overridden.

5.1. Supported user actions

If a notification has been defined, notifications are sent for the following events:

  • User Task has been created

  • User Task has been assigned

  • User Task has been completed

  • User Task has been deleted

The default setting in the user settings is that a notification is sent in the first three cases. You can change these user settings via Task Overview.

Mandatory notifications cannot be deactivated in this way.

5.2. Time at which the notification for a task is triggered

The following table shows when a notification is sent. No mandatory notification is configured. The table field Yes means that a notification is sent to everyone involved.

Event of the task Assignment of a user (assignee) Assignment of one/multiple representative(s) (candidateUsers/ candidateGroups) Does the user receive a message? Do the representatives receive a message?

User Task has been created

Yes

Yes

Yes

Yes

Yes

No

Yes

No

No

Yes

No

Yes

No

No

No

No

User Task has been assigned to a user (assignee)

Yes

Yes

Yes

Yes

Yes

No

Yes

No

User Task has been assigned to the group (candidateUsers/ candidateGroups)

No

Yes

No

Yes

User Task has been completed

-

-

No

Yes

User Task has been deleted

-

-

Yes

Yes

5.3. Creating notifications

For the user to receive a notification for the events described above, a new notification must be created in the "Notifications" section of the administration area. To do so, click the + Add Notification button and complete the following fields:

  • Name - Unique name

  • Process definition - Name of the workflow for which the notification is defined

  • Standard - Setting of the notification for all tasks in the workflow. Only one standard notification can be created per workflow.

  • Force notification - Setting of a mandatory notification. In this case, a notification is always sent and the user settings in Task Overview are ignored.
    (Exception: Override of the User Task setting in the Designer.)

  • Subject - Definition of the email’s subject line. Access to task and process objects possible.

  • Body - Definition of the email’s message content. Access to task and process objects possible.

5.4. Editing and deleting notifications

To edit a notification, click the Edit button on the right. In the opened window, click the Delete button to delete the notification.

5.5. Access to objects

Within Subject and Body, you can access all defined task and process variables using FreeMarker.

5.5.1. workflowTask object

In addition to these variables, you can use workflowTask. This object contains the following useful meta information:

Variable name Type Description

event

String

Event triggered by the User Task. Possible values are: create, assignment, complete and delete.

name

String

Name of the User Task.

abasTaskDescription

String

Description of the User Task (for abas tasks).

assignee

String

Assigned user. Contains the assigned user or null.

recipients

String

List of recipients as comma-separated value, e.g., "wf1@abas.com, wf2@abas.com".

processDefinitionId

String

ID of the workflow.

creationDateTime

String

Creation date of the User Task as ISO8601 date (UTC).

dueDateTime

String

Due date of the User Task as ISO8601 date (UTC).

priority

Integer

Priority of the User Task.

abasClient

String

Name of the abas client of the User Task.

created

Boolean

Returns true if the User Task has been created.

assigned

Boolean

Returns true if the User Task has been assigned to someone. It makes no difference whether assignee has a valid value or is null.

claimed

Boolean

Returns true if the User Task has been assigned to a person. In this case, assignee is never null.

unclaimed

Boolean

Returns true if the User Task has been assigned to the group. In this case, assignee is always null.

completed

Boolean

Returns true if the User Task has been completed.

deleted

Boolean

Returns true if the User Task has been deleted.

It is ensured that workflowTask always contains the above information. This means that if a variable with the same name has previously been created on process or task level, it is overwritten.
Variables of the String type can be null. Therefore, you can perform a check for null values in if queries (<#if assignee??>). When using variables, you should ensure that the variable is initialized with a default value (${assignee!'not set'} or ${assignee!}). Otherwise, an error will occur upon text replacement and no notification will be sent.

5.5.2. Example

To send a notification depending on the task event, you can use the following text in the body, for example.

Hello ${workflowTask.assignee}, <#if workflowTask.created>a task was created<#elseif workflowTask.assigned>a task was assigned</#if>

To test this text in advance, you can call FreeMarker Online Tester.There, copy the FreeMarker script into the Template field and enter the following json as the dataModel:

workflowTask = {
  "event": "create",
  "name": "Taskname",
  "description": "standard description",
  "abasTaskDescription":"abas task description",
  "assignee": "wf1@abas.com",
  "recipients": "wf1@abas.com, wf2@abas.com",
  "owner": "owner",
  "priority": 50,
  "taskDefinitionKey": "id",
  "executionId": "id",
  "abasClient":"abas erp",
  "processDefinitionId": "id",
  "creationDateTime": "20080915T155300Z",
  "dueDateTime": "20080915T155300Z",
  "created": true,
  "assigned": false,
  "claimed": false,
  "unclaimed": false,
  "completed": false,
  "deleted": false
}

You can ignore the remaining fields. After clicking the Evaluate button, the correct text should be displayed in the Result section.

6. Color Designer

You can see all colors which can be used in abas BPM Designer on the Color Designer tab. You can create new colors or edit and delete existing ones.

This function is available from Version 1.1.0.

6.1. Erstellen von Farben

To create a color, click the + Add Color button. Complete the following fields:

  • Name - Unique name of the color

  • Fill - Color of the filling

  • Stroke - Color of the filling

Then click the Create button. The color is created.

After the color has been created, it can be used in Workflow Designer.

6.2. Editing and deleting colors

To edit a selected color, click the Edit button. A window opens. In the opened window, you can edit the color or click the DELETE button to delete it.

7. License Terms

On the License Terms tab, you can find the license terms for abas BPM. The license terms are attached and should be read. To use abas BPM, you must agree to the license terms.

8. API Key

Using the API key, the connection between abas ERP and abas BPM is established.

8.1. Creating an API Key

To create a new API key, you have to execute the following steps:

  1. click the Unlock button

  2. click the Generate button

  3. copy the created API key to the clipboard

  4. click the Lock-Button klicken

  5. open abas ERP and select the BPM web user (or create a new one)

  6. enter the engine rest URL: http://<IP>:8088/engine-rest in the Description field

  7. enter the API key stored in the clipboard in the EMAIL-Adresse field

  8. enter any role in the Role list field

All workflow users require the View permission for the web user.
The web user must have "abas-bpm" as the login and only one record must exist (the value is not case sensitive).
A new API key should only be created in the case of a new installation or if connection problems occur between abas ERP and abas BPM.

9. Camunda Dashboard

The Camunda Dashboard consists of three components:

  • Cockpit: monitoring and controlling all running processes

  • Tasklist: processing User Tasks

  • Admin: configuring users, groups and permissions

The Camunda Dashboard is available at the following link: http://<abas bpm host><:port>/camunda.

9.1. Cockpit

Use the Camunda Cockpit to monitor and control running workflows.

9.1.1. Display the process list

Click the Processes tab to display a list of all deployed workflows and the number of running instances.

Click a workflow to see its running instances.

To see the variables of an instance or cancel an instance, click this instance.

9.1.2. Stop a running workflow instance

To abort an instance, you must first open the provided Worfklow in the correct version. Then you have to click on the instance you want to close and then click the X button.

Further information can be found in the Camunda Documentation.

9.2. Tasklist

You can use the Camunda Taskliste to start workflows and execute User Tasks. However, you cannot execute abas ERP tasks.
Further information can be found in the Camunda Documentation.

We recommend using Workflow Task Overview.

9.3. Admin

In the Camunda Admin In the Camunda Admin area, you can manage users, groups and permissions.

We recommend using Administration Overview.

Further information can be found in the Camunda Documentation.

9.3.1. Set permission to start workflows

If not all deployed workflows should be started by all users, you must set this in the permissions under Authorizations. You can create a new permission by clicking the Create new authorization button. Then you have to decide if you want to create a group or a person permission by changing the icon and specifying the group / person. Under Permissions you can set whether the permission applies to all actions (recommendation by us) or whether it applies only to the creation of instances, for example. In the* Resource ID* column, you must enter the ID of the workflow (not the name). Subsequently, only these users / groups can start the workflow (with the specified ID) in the Task Overview.

Further information can be found in the Camunda Documentation - Authorization Management.