Topic overview

A workflow is a defined sequence of coordinated activities to execute a business process or work routine efficiently and repeatedly or to automate the process in whole or in part.

Workflow management is a component of the ERP system that uses the basic properties and functions of the system to map business processes and workflows. With the seamless integration, almost any application is free to access the workflow. Conversely, workflow management itself is also used in many places in the system, e.g., in relationship management or batch processing.

This article provides an introduction to the scope and benefits of workflow management. It contains an overview and brief descriptions of the important elements and functionalities of the Workflow Management framework.

Please refer to the application descriptions for details on the structure and operation of the individual applications. Please also refer to the technical documentation, such as the Workflow engine article.

Description

The basic properties and features of the system are used for the workflow, such as authorizations, the structural organization and document management. Conversely, workflow management itself is also used in many places in the system, e.g., in relationship management or batch processing.

The workflow can be customized via conditions in the system scripting language, but also Java programming. With the seamless integration, almost any application is free to access the workflow without a need for a complex interface programming.

Using the option of generating batch jobs through activities, events and batch applications can be linked flexibly and without adaptations through the workflow.

The following describes the elements and functionalities of the Workflow Management framework, which are required for the application, organization and development of workflows.

Workflow-related applications

This chapter describes the components of workflow management that are relevant for the workflow user.

Components relevant for the user

The following components of workflow management are relevant for workflow users:

Tasks
A task in workflow management represents the assignment of an activity resulting from an action to a user. Each task has a scheduled processing period, which is determined by the parent activity, and a task status. The first time you switch to a new status, the time of the change is documented.  Further information can be found under Tasks.

Activities
An activity describes an action that can be carried out by one or more users. If an activity has several users as editors, a task linked to the activity is created for each user. An activity therefore forms a bracket around the resulting tasks and contains information about the tasks. An activity has an activity status, which describes its status. Further information can be found under Activities.

Processes
A process in workflow management describes the execution of an operational process or sub-process based on the process definition. A process is modeled in the form of a diagram, with its nodes representing the activities and its edges outlining the control flow. The generated activities are used to process the individual process steps. The completion of a process step can trigger the processing of other process steps.
A process has a defined processing period, a start and an end. Further information can be found under Processes.

Workflow box
The dockable Search for tasks window serves as a workflow inbox. All user-related tasks are automatically displayed in this window. You can choose whether you want to view all tasks, the current tasks, the tasks whose processing period has already expired (delayed tasks), or scheduled tasks.

Workflow bar
If you open and accept a task in the dockable Search for tasks window or in one of the cockpits, the workflow bar is displayed and the workflow mode is activated. You can use the actions on the workflow bar to edit your tasks. You can take over, complete, postpone, bring forward and forward tasks.
Further information on the workflow bar can be found in article Operating guidelines in the Workflow management chapter.

Activity information
The Activity information application provides a simple and quick overview of workflow activities in a dockable window. The application opens automatically when a task is opened and the parent activity is linked to an application or a business object. This means that both the business object to be processed and the most important information about the activity always remain visible. Further information can be found in article Activity information.

E-mail notifications
Email notifications can be used to inform workflow users about new tasks or status changes to tasks, activities and processes, for example. Sending e-mails is particularly useful for employees of business partners who do not regularly work with the system.

Tasks

The tasks to be edited by a user are listed under the Search for tasks tab in the navigation pane. The tab serves as a workflow inbox in the ERP system and can be used as a dockable window.

Every user can also set an additional setting to receive a notification when a new task arrives via e-mail. This e-mail will also contain a link to open the concerned activity. If the status of a task changes to Delayed, the user may optionally receive another e-mail. The e-mail is particularly useful for employees of business partners who do not regularly work with the system.

The dockable Search for tasks window is updated in time and offers access to every functionality the user requires to completing the tasks. If a task is edited, the workflow bar becomes active. The workflow bar provides actions and information related to the task being edited.

Further information on the workflow bar can be found in article Operating guidelines under the Workflow management chapter.

Searching for tasks

With the Cockpit: Tasks/OLTP database and Cockpit: Tasks/repository database applications, you can get an overview of future, current and past tasks and their basic information, for example about the task editor, the task status and the business entities linked to the parent activity. Authorizations restrict user access to the data relevant to them.

The Cockpit: Tasks/repository database application is used to query and edit tasks from the central repository database. The repository database is the foundation for Comarch ERP Enterprise system. All development objects are contained in this higher-level database. The development objects describe and define the system. The repository database is the central location for importing, activating and distributing software updates. It also contains the data dictionary, which describes the database schema using an object-relational type system. The repository database also assumes the role of the central database of the system. It contains the system log and the authorization definitions.

The Cockpit: Tasks/OLTP database application is used to query and edit tasks from the OLTP repository database you are currently logged on to. In an Online Transaction Processing (OLTP) database, master data and transaction data for the business applications are managed. Furthermore, instructions regarding “customizing” are stored in it. In a productive system, the OLTP database is exposed to the highest user load. For this reason, it is specially designed to be able to serve a large number of users who process a shared database simultaneously.

More information can be found in article Cockpits: Tasks/OLTP database and Tasks/repository database.

Editing and completing tasks

When the set start time is reached, the scheduled tasks are assigned the status To be processed. Tasks to be edited are displayed in the dockable window Search for tasks.

To open the development task to be edited in the task, either select the option Open entry in the context menu or double-click on the displayed task. At the same time, the workflow bar is displayed and the workflow mode is activated. Further information on the workflow bar can be found in article Operating guidelines under the Workflow management chapter.

When a task is opened and the parent activity is linked to an application or a business object, the corresponding application opens automatically for processing the task. At the same time, the Activity information application opens as a dockable window. The Activity information application provides a simple and quick overview of workflow activities. This means that both the business object to be processed and the most important information about the activity always remain visible. Further information can be found in article Activity information.

If a task is opened and the parent activity is not linked to an application or a business object, the task’s parent activity is opened in the Activities application. Accepting the task changes its status to In process.

If the Single editing edit mode is set for the parent activity, any other tasks in the activity from other editors are assigned the status Blocked. The automatic acceptance of tasks when the task is opened can be set in under the Workflow management function in Customizing.

If you have accepted a task for editing, but would like to return it (so that other colleagues can edit it for instance), then tasks can be put on hold again.  Such task is assigned the To be processed status.

Tasks can also be forwarded to another editor. You can either transfer or copy the task when forwarding it and track the status of the forwarded task with e-mail notifications if required. You can enter a notification text for the new editor of the task.

If required, the continuous edit mode can be activated for editing tasks. With continuous processing, several consecutive tasks can be completed without exiting the workflow edit mode. When a task is completed, the next task is opened automatically.

After you have finished processing your task, change its status to Completed. If you are unable to complete a task, change its status to Completed unprocessed.

Activities

This chapter provides an introduction to activities. Further information on activities can be found in article Activities.

Generating activities

Using an activity definition, an activity can be generated as a reaction to any event. It is visible as task to the concerned editors. The application to be used for editing the task can be specified in the activity definition.

Every user can generate activities manually for themselves and/or other users. These activities generated manually by the user are called manual activities.  Manual activities can be generated very easily using an entry in the context menu for every business entity. Such manual activity is automatically linked with a business object. This covers the important re-submission scenarios in particular.

Activities can also be entered manually in the Activities application, either as a new individual activity or duplicated from an existing activity. The link to one or more business objects can be added in the activity. Furthermore, various applications automatically generate activities through a generally accessible program interface Examples: relationship management, batch processing, supplier quotations (re-submission date).

Querying activities

Existing activities can be queried in the Cockpit: Activities/OLTP database and Cockpit: Activities/repository database applications. If you are looking for the activity for a specific business entity, you can use the context menu to procced to the corresponding cockpit for the search. The search criterion for the link is then already assigned in the cockpit.

Further information regarding cockpits for tasks can be found in article Cockpits: Tasks/OLTP database and Tasks/repository database.

Completing activities

Activities can be completed with an action via the Activities application or via the cockpits for activities. If the activity still has open tasks, these are assigned the task status Completed. If an open task is still being processed, it is assigned the status Blocked.

It is also possible to complete activities with an unprocessed action. This assigns the activity the status Completed unprocessed. If the activity still has open tasks, these are assigned the task status Completed unprocessed. If an open task is still being processed, it is assigned the status Blocked.

Processes

This chapter provides an introduction to processes. Further information on processes can be found in article Processes.

Starting processes

There are various ways to start processes in the ERP system. The prerequisite for this is that the corresponding process definition for the process is activated in the respective database.

The settings in the process definition and the event definition of the activity definition associated with the start event determine how the process is started.  Depending on the event type and settings, the following alternatives are possible:

• The activity definition for the start event has neither an event definition nor the process definition linked to a process application.

In this case, you start the process in the Processes application using the Start process dockable window or the button of the same name. The Start process dockable window shows all process definitions by framework, which can be started in the Processes application.

• The activity definition for the start event has no event definition, but the process definition is linked to a process application.

In this case, you start the process via the linked process application.

• The activity definition for the start event has an event definition of the type User action.

In this case, you start the process via the context menu of the business entity stored in the activity definition.

• The activity definition for the start event has an event definition of the type Business entity or Programmed event.

In this case, you start the process by triggering the event stored in the event definition, e.g., by changing a business object.

Querying processes

Existing processes can be queried in the Cockpit: Processes/OLTP database and Cockpit: Processes/repository database applications. If you are looking for processes for a specific business entity, you can use the context menu to proceed to the corresponding cockpit for the search. The search criterion for the link is then already assigned in the cockpit. The link to a process is created via the activity of the start node.

Further information regarding cockpits for processes can be found in article Cockpits: Tasks/OLTP database and Tasks/repository database.

Creating process comments

Comments can be entered for processes. If required, process owners, the process initiator or all process editors involved can be notified of the new process comment by e-mail.

Completing processes unprocessed

Processes can be completed unprocessed with a dedicated action. The process then receives the status Completed unprocessed and the process activities that are still open also receive the status Completed unprocessed.

Time limit

An activity should be processed within the specified processing period. Otherwise, the activity status changes to Delayed or Delayed in process. If the defined processing period is exceeded, a follow-up action defined in the activity definition can be executed automatically and the editor will be notified about it by e-mail. For processes, an e-mail notification can also be sent to the person responsible for the process. If a process timeout occurs, no follow-up actions are possible.

Workflow organization

This chapter explains the applications and functions for workflow organization. The workflow organization is used to determine editors, representatives and persons responsible for workflows.

Workflow roles

Workflow roles are an abstraction level to map the process organization used by the workflow. Owners must be assigned to a workflow role so that it can be used appropriately. Owners can be users, persons, entities or organizations. The assignment of workflow role owners is database-specific because only objects in this database can be used for the assignment. In different databases a role generally has different owners. Workflow roles can be defined using an expression instead of assigned owners, similar to a function. When these roles are resolved, the owners are determined by the expression.

The workflow role owner is part of the workflow. It is a person or a group of people who have been assigned to a workflow role in a database. Owners can be users, persons, organizations or entities, for example.

If no valid user can be determined from among the workflow role owners when creating an activity, the workflow role cis.WorkflowAdminOLTP or cis.WorkflowAdminRepository is used for the determination.

If this role does not have a valid user, the task is assigned to the Administrator user.

Further information can be found in article Workflow roles.

Job titles

A job title is both the assignment of an occupational activity (a function) to one or more employees and a classification in the company structure (the structural organization). In a structural organization, job titles describe the individual functional work places and their relationships to one another. Job titles can be used for the definition of workflow roles and the identification of superiors and deputies for activities can be controlled with them.

Individual and hybrid job titles can be created. Individual job titles can be assigned to one person only and hybrid job titles to any number of persons.  Job title relationships can be used to hierarchically assign work places in superior and representative relationships between job titles. Partner relationships can be used to assign job titles together with one or more persons to a higher-level organization. Or a job title can be assigned to one or more persons without a higher-level organizational assignment.

Further information can be found in article Job titles.

Absences

An absence is a recorded period of time during which a user cannot process workflow tasks. During an absence, delegable workflow tasks that are assigned to the user can be forwarded to a deputy. You define absences and the representative relationships that are to apply when a user is absent in the Absences application. The workflow tasks delegated during a user’s absence are displayed for the deputy in the workflow inbox.

The prerequisite for forwarding a workflow task to a deputy during an absence is that the processing of tasks as a deputy is permitted in the associated activity definition or the activity during absences.

Further information on absences can be found in article Absences.

Determining the process editor

An editor for an activity can be determined using a declaration in one of the scripting languages. For example, the employee responsible for a sales order can be defined as the editor for an activity. For process-related editor determination, you either enter an expression for the editor in the activity definition or you define the editor in the declarations.

Workflow development

This chapter explains the applications and functions for workflow development.

Activity definitions

An activity definition is the template for activities generated from it. If an activity definition is activated, the workflow engine generates a new activity when the registered event occurs, provided the transition condition is met. Activity definitions are independent of the OLTP database and the system in which they were created, as they contain neither system or OLTP-specific data. Activity definitions are stored in the repository database.

The start time, processing time and priority of activities can be controlled via the activity definition.

This chapter provides an introduction to activity definitions. Further information on activity definitions can be found in article Activity definitions.

Activity types

Activity types can be defined in the activity definition. Depending on the activity type, different settings can be made for the activity definition. The following activity types can be defined:

• Individual activity – a single activity describes a one-off task that is not part of a process.  Individual activities can either be created by a user or generated automatically by the system, e.g., based on an activity definition or via a programming interface.
• Series template – a series template is an activity that generates activities according to a series model within a defined period of time. The activities generated are referred to as series activities and are displayed in the series template. A series template has no tasks.
• E-mail message – an activity definition of the E-mail message activity type sends an e-mail to one or more recipients without generating an activity.
• Function call-up – a function call-up is an activity definition that calculates and returns a result instead of generating activities. Function call-ups are used, for example, to enter once complex calculations or to be able to use expressions in JavaScript in activity definitions that are entered in the system scripting language.
• Process definition node type – if the activity definition represents a node of a process definition, the activity type is defined via the node types in the process definition. Further information can be found in article Process definitions.

Events

Events are the foundation for creating activities from activity definitions in workflow management. Events can be triggered by data changes made by the system, by an application or by a user’s action. Events contain parameters that describe the event.

To generate an activity when an event occurs, an activated activity definition must be registered for this event and the transition condition must be fulfilled. The transition condition can be used to restrict a general event for activity definition.

 Programmed events

The specific events can be programmed. These events are registered in the repository database and are specified during application developments. Here, an easy-to-handle program interface is available to enable the simple creation of new events for the partner, for instance.

The event Status of a sales order changed can be printed as programmed event as well as using the Business entity event. The programmed event requires adaptation programming of the application logic, while the Business entity event can be used without adaptation programming. Since the programmed event is only initiated if the status actually changes, it is more efficient than the utilization of the Business entity event.

Business entity changed event

The system engine initiates the event Business entity while creating, changing or deleting a business object instance. Simple tasks can be initiated using this event provided by the system. The problem with the events of this category is that they have a relatively unspecific initiation. This means that an event is initiated with every change in the business object instance. This event is not originally linked with a specific business-motivated process. In general, however, very specific processes need to be reacted to. This is one of the reasons why an activity definition with a transition condition can be linked with the event.

An activity is only created from the activity definition if the concerned event takes place and the transition condition is met. The old and new status of the changed object are acceptable for the analysis of the event, which means it is also available for the transition condition.

User action event

This event is triggered when a user starts a process via the Start process option in the context menu of a business entity.

The type User action is only available in activity definitions that represent a node of a process definition.

Trigger events batch application

The batch application Trigger events triggers the event com.cisag.pgm.workflow.InstanceEvent (event triggered by batch application Trigger events) for all business object instances selected by an OQL statement. The batch application can be executed once or regularly using a batch job. Activities can be created using activity definitions that were registered for the triggered event. Further information can be found in article Triggering events.

Editing

Activities can be edited by users, batch jobs or the system. The potential editor of an activity can be determined through various options. A user can simply enter a user or a person. In addition, the elements of the structural organization, specific offices and organizations can also be used. With workflow roles, the procedural organization is mapped on the structural organization, where the two organizations need not be congruent.

If workflow roles are used specifically, procedural and structural organizations can be changed independent of each other. Furthermore, the workflow roles are one of the basic principles based on which the activity definitions can be delivered as templates.

Depending on which assignment option is being used, there is exactly one potential editor or a number of potential editors for one activity. Regardless of that, it can be determined whether the editing will be carried out by exactly one or by many editors. This way, Comarch ERP Enterprise can also map the relevant sections of the structural organization of the relevant business partner besides the internal structural organization.

Basically, anyone who has a browser and a network connection to the source system (via Internet, Intranet or other networks) can be an editor of a task. This way, employees of business partners can also be used easily.

The structural organization in Comarch ERP Enterprise provides the facility to define superior and representative relationships between job titles. Naturally, job titles can also be related in the same way to own company as well as the business partner.

The activities generated from an activity definition can generate and initiate batch jobs and execute batch applications. Batch applications are called up without user interaction. To do this, the parameters must be described in the development object of the batch application. Not all applications fulfill these requirements. The batch application Call up batch applications in the workflow can be used to execute a batch application, even if not all parameters are described for it. Further information can be found in article Call up batch applications in the workflow.

Preconditions

The precondition is checked with every status change of the activity. If it is not met, the activity receives the status Completed unprocessed. This also means that all tasks of the activity that have not yet reached a final status are completed unprocessed. The precondition is not checked for activities that are processed by the system or by a batch job and for status changes to one of the two final statuses Completed and Completed unprocessed.

An activity can only be completed if the postcondition is fulfilled. The postcondition can be used, for example, to prevent an activity from being completed before the editors have carried out the activity described in the activity. A postcondition can also prevent the creator of an order from approving the order themselves.

Series activities are generated from the series template as long as the series condition is fulfilled and the series duration has not been exceeded. If a series activity is to be created and the series condition is not fulfilled at this time, the entire series is canceled. If the precondition of the series template is not fulfilled, no series activity is generated, but the series is not canceled.

Texts

A subject and a description can be entered for activity definitions. Placeholders can also be used, which are defined in the declarations. Multilingual texts can also be entered for the subject and description, which are displayed to the editor according to their language settings.

Application

You can store an application for editing the activities created from the activity definition. If the editor of the activity is a user, you can define a dialog application that is automatically opened when the user starts editing the created task. If the editing of an activity results from a batch job, the batch application can be remembered as the application used for editing.

Results

Each activity has a general result, which is set with the script function setActivityResult. This general result can be displayed in the corresponding cockpits for activities, for example. In addition, further results can be defined in the activity definition that the editors enter when completing the task. The results in the start node of a process can also be used to control the process steps.

Declarations

For activity definitions, declarations can be entered in own system scripting language or in JavaScript. The declarations provide functions that are called when activities are created, when the status changes and when certain parameter values are entered. The properties of processes and activities can be flexibly defined by customizing the declarations.

Links

Every activity can be linked with any number of business entities in the same database. This way, for instance, an activity can be linked with a customer and/or an item. This has the advantage that you can search for and find all activities linked with a customer.

Naturally, any number of Document Management documents or notes can also be linked with activities using the script function.

Process definitions

A process definition is a comprehensive technical description of an operational process or a sub-process. It consists of process steps that describe the business process in terms of time and organization. A process definition is modeled in the form of a diagram with its nodes representing the activities and its edges outlining the control flow. With the help of the process definition and activity definitions, the properties of the processes and process steps are determined. Process definitions are independent of the OLTP database and the system in which they were created, as they contain neither system nor OLTP-specific data. Process definitions are stored in the repository database.

In process definitions, a processing time and a storage period are defined for processes, during which the processes cannot be reorganized. No priorities are set for processes in process definitions; they can be set for each process step individually in its activity definition.

To start processes, the process definition can be assigned to a framework and a process application can be defined for a process definition template.

A person responsible is defined for process definitions. This can be a user or a workflow role. Authorizations can be assigned in the process definition for the person responsible for the process and for the process initiator, for process participants and non-participants, and for users consulted in the process. In case of errors or exceeded processing time of a process started from the process definition, notification emails can be sent to the person responsible for the process or to the workflow administrator.

This chapter provides an introduction to process definitions. Further information on activity definitions can be found in article Process definitions.

Process model

Processes are modeled in the process definition editor as a sequence of process steps that are represented as nodes and connected via edges. The process model in the ERP system is based on the Business Process Model and Notation (BPMN), but also differs from BPMN in detail. The following elements are available:

• Action nodes – an action node is a process step that represents a task for one or more editors. Some action nodes support certain tasks, such as making a decision or sending an e-mail message. Depending on the type, an action node is processed by users, by the system or by a batch job. Action nodes are displayed as rectangles in the editor.

• Event nodes – an event node is a process step that represents a process-relevant event instead of a task. Event nodes include a start event, an end event, an error event and intermediate events. Activities generated by the event node are processed by the system. Event nodes are displayed as circles in the editor.

• Gateways – gateways are used in process definitions to split a control flow from one node and forward it to several nodes (branching) or to merge control flows from several nodes and forward them to a single node (merging).  Gateways are displayed as diamonds in the editor.

• Edges (connections) – edges connect the individual nodes and gateways with each other and forward the process flow. Gateways are displayed as lines in the editor.

There is exactly one activity definition for each node. The behavior of the node is determined by this activity definition. When the control flow reaches a node in a process, the workflow engine generates an activity from the activity definition. When the activity is completed, the workflow engine forwards the control flow to the next node via the outgoing edge. If the control flow reaches a branch, the transition conditions for the branch from the activity definition are evaluated before the branch and the control flow continues depending on the evaluation.

The process ends when the activity associated with the end event is completed. Activities and tasks that do not yet have a final status are assigned the status Completed unprocessed. If the process no longer has a control flow or an error occurs in a process step, then the process ends via the error node.

Process variables

Process variables can be declared for processes in the process definition. Process variables extend processes with additional information that can be displayed in the process. Activities can use the declarations to evaluate process variables and assign values to them.

In the activity definitions of the nodes, general attributes can also be used for processes to save texts, numbers or times as process results.

Declarations

In the declarations, you can declare constants, variables and functions that apply to all activity definitions belonging to the process definition.

Workflow engine

Together with the event notification service, the workflow engine coordinates and monitors the execution of workflows. The workflow engine is executed on the message server in every system. The workflow engine is part of the system and can be configured when the system is set up.

All automatic status changes of activities and tasks are performed by the central workflow engine. The workflow engine is executed on the message server in every system. Only events are supported on any other ERP system application server (SAS) in the system.

Detailed information on the workflow engine can be found in the Workflow engine article.

Scripting languages

The workflow engine supports its own system scripting language and

JavaScript to express complex relationships and to define declarations for activities and processes.

Terms, conditions, commands and declarations are used to express complex relationships. All these expressions are part of a common scripting language called system scripting language. The syntax of the system scripting language is based on SQL, Pascal and Java. The system scripting language is used in workflow management, e.g., to formulate a precondition or transition condition or to specify editors that are not included in the workflow role. The system scripting language is verified in the ERP system and any errors in the script are communicated in the form of warnings.

In addition to the system scripting language, the workflow engine supports JavaScript. JavaScript provides access to the Java classes of the ERP system.

Further information on the system scripting language can be found in article Introduction: System scripting language. Functions of the system scripting language can be found in articles System scripting language: General functions, System scripting language: OLTP functions and System scripting language: Workflow functions.