ONEWEB provides built-in monitoring tools help keep track of the current active process instances in your system. There are 2 types of monitoring tools available with ONEWEB

Process monitoring - Process monitor shows all the active instances of a process and the current status of each instance. Task Monitoring - Using a task monitor you can monitor the progress of an individual process instance across the many activities of a process from start to finish.

What is Process Monitor?

The Process Monitor is the tool to keep track of the deployed processes. Users can view how many active process instances exist currently for each deployed process. It can show the status of the process instances at each activity in the process. For a Human task the status will show how many instances are assigned to users, how many instances are waiting to be assigned to a user and how many instances are claimed by users?

The View All Process Monitoring page will show one box each for each deployed process. Each box has process name and project name. User can click the box to open monitor screen for that process.

In the monitor screen, system will show the flow of process and an icon on the activity to show / hide the status box of the activity.

In status box has ASSIGNED, WAITING and CLAIM for showing.

ASSIGNED shows how many instances of that process are assigned to users at that activity. WAITING shows how many instances are waiting to be assigned to user at that activity. CLAIM shows how many instances are claimed by users at that activity.

The status is shown only for Human Task and Sub Process Task if the Sub Process Task has a Human Task.

You can double click on the activity to show details of all the instances currently active at that activity. Details will show task id, node name, create date and the user who has claimed it. You can click task id to take you to the Task Monitoring.

Process Monitor has been developed to monitor the overall tasks in each process as described in 6.4.7.1 and 6.4.7.2. However, if the user wants to implement custom Monitoring Dashboard by using the various programming languages or the ONEWEB Dashboard utility, he must know the important table relationships between "BPM" schema and "PD" schema in order to retrieve the tasks that are executing.

"BPM" schema is used to store the process runtime configuration. There are 3 important tables which as shown in below figure.

"wf_t1_definition" table is used to keep the process deployment structure. There are 3 important columns:

• "id_" is the primary key.

• "bytes" is used to store the xml structural of process deployment.

• "process_key" is the prorcess name which can be a relation with "project_process_name" of "project_process" table on "PD" schema.

"wf_t2_task" is used to store all activity human tasks that occur in the process. There are 7 important columns:

• "id_" is the primary key of this table.

• "activity_id" is the id of node task which can be a relation with "id" of "node_task_property" table on "PD" schema.

• "assign_status" is a status of task. There are 3 types - ASSIGNED, WAITING, CLAIM.

• "claim_user" is a column to store the user that has claimed the task.

• "distributor_type" is the type of task assignment method used. There are 5 type - "Pull", "Round Robin", "Load Balance", "Routing Policy" and "Custom".

• "instance_id" is the unique id of executed process runtime; whenever the process is executed by process runtime, the instance id is generated automatically.

• "work_party_name" is the work-party name that is assigned on the task.

"wf_t3_activity" is a log table that is used to store all the activities of node tasks that are executed by each "instance_id" of the process. The main columns are:

• "id_" is a primary key of table,

• "instance_id" is the unique id of executed process runtime.

• "activity_id" is the id of node task which can be used to a relation with "node_property_id" column of "node_property" table on "PD" schema.

• "activity_name" is a name of node task.

• "activity_type" is a type of node task.

• "start_time" is the time of node task is start.

• "end_time" is the time of node task is end.

• "duration" is duration time of node task is executed.

"PD" is used to store the design of process. There are 3 important tables:

"project_process" is the table used to store the process data. There are 2 important columns:

• "project_process_id" is the primary key of table.

• "project_process_name" is the name of process. This column can be used to a relation with "process_key" column on "wf_t1_definition" table.

"process_template" is a table that is used to store the JSON process diagram. There are 3 important columns:

• "pd_process_template_id" is a primary key of table.

• "project_process_id" is a foreign key of "project_process" table.

• "pd_pro_tp_json" is a column that is used to keep json diagram.

"node_property" is the table used to store the details of node tasks in the process diagram. There are 5 important columns:

• "node_property_id" is a primary key of table.

• "pd_process_template_id" is a foreign key of process_template table.

• "node_property_name" is a name of node task.

• "node_property_key" is a key of node task.

• "node_category" is a type of node task

What is Task Monitoring?

The Task Monitoring is used to keep track of the progress of process instances from start to finish. It shows the path taken by the process instance, the status and time taken by the instance at each of the activities. When a process instance is created, users can keep track of that instance on where the instance has reached, who is it assigned to and the total time taken in that task using the task monitor.

Monitor has Search Task Monitoring page for searching a particular process instance. Users can search the instance by using the date on which the process instance is created or the activity on which the instance is currently waiting or the user to whom the instance is assigned to or the role to whom the instance is assigned to.

When user clicks Search, the results will be displayed according to the search criteria. In the results panel user can click on a specific Task ID to open the details panel for that process instance.

In the detail panel, system will highlight in blue the flow of the process instance. The activities that are completed are marked with a check mark and the currently active activity is shown by the task highlight. There is an icon at the top of the activity to show / hide the status of that activity.

When the icon is clicked by user, system will show the status box of activity. The status box has HOURS, MINUTES and SECONDS of the time for which the process instance has been waiting at that particular activity. HOURS is the hours since the process instance has reached this task. MINUTES is the minutes for which it has been waiting. SECONDS is seconds.

This status is shown only for Human Task and Sub Process Task if Sub Process Task has Human Task.

When process has Sub Process Task, and user double click on the Sub Process Task, system will open the task monitor for the sub process.

SLA (Service Level Agreement) and OLA (Operational Level Agreement) are the agreements which are often used in the software development industry to measure performance. SLA is used to measure the target performance during the execution of a process. SLA is created in order to ensure the result quality of the process and the agreed turnaround time will be achieved with customer commitment. OLA is used to help the internal teams to work together in order to achieve the service requirement level in the SLA. Moreover, another difference between SLA and OLA is that SLA is responsible for the turnaround time between IT service provider and customer, OLA is responsible for the turnaround time between IT service provider and another department within the company.

Process Designer does not provide an out of the box SLA task. But we can work around to implement an SLA in process designer using the Timer event.

For example, an SLA can be defined as "When the credit application is submitted by the user, the reviewer and approval have to decide whether this credit application should be approved or rejected within 5 days". Therefore, when process is executed, we desire that our process can be operated according to this agreement. The timer event in PD can be used to develop the OLA in order to support SLA as shown in figure below.

This process is initiated when a credit application is submitted by the customer. This application is reviewed by the user in the Review human task. The timer event is used to listen as shown in the figure below. If the credit application is not reviewed within two days, this application is sent to Manager group in order to review. Afterward this application is checked for completion on the exclusive gateway. If this application is complete, it is sent to approve decision which is represented by "Decision to approve" in human task, otherwise the process will end. For the details on how to configure the timer is explained in 6.4.3.3.4 Timer section