Administrator workflow

IMPORTANT: This Kogito wiki is deprecated. For the latest Kogito documentation, see the Kogito documentation page. To contribute to Kogito documentation, see the master-kogito branch of the kie-docs repository in GitHub.

Administrator (or the operator of Kogito project) workflow focuses on day to day management of the running services.

Management

Be aware

Awareness of the state of your project is crucial from the administration standpoint, thus the first and foremost administrators should be approached with is the dashboard like the state of the system. This is to allow them to just with a single look know what they need to focus on and where to move next.

Manage and act

The primary focus of the management aspect is on active instances, that is processes (and maybe decisions) that are currently active. Management will enable operators and admins to

• effectively search across active instances including filtering by business data

• deep dive into individual instances including visualisation of the process instance state

• perform admin operations on

  • individual instances

  • group of instances in batch mode

Deep dive

Deep dive view will provide a complete view of the process instance, including

• process instance visualisation

• process instance variables

• process instance logs (what was executed)

• process instance subprocesses

deep dive view focuses on showing the current state of the instance with options to dig even more based on tracing information or to fetch live data from the service that hosts/owns that instance.

Operate

Administrators will be able to perform certain operators on active instances, either on individual instances or on set of instances using batch mode. Available operations are

• cancel selected process instance

• cancel selected node instance

• retrigger selected node instance

• trigger selected node in a process instance

• add/change/remove process variable

• cancel or reschedule timer in a selected process instance

Watch and explain

Watch and explain is focusing on historical data that allow troubleshooting unexpected situations. That includes but is not limited to

• finding out what nodes were executed and when

• finding out what decisions where executed and when

• finding out who made changes to data - especially applicable to user task tracking

• finding out when data were changed

Monitoring

Monitoring should be based on metrics provided by

• runtime services

• data index service

• timer service

all metrics should be then collected into Prometheus and made available to build dashboards using for instance Grafana.

There should be both standard metrics produced by runtime services such as rule and process execution but also custom defined metrics that are specific to a particular domain that the applications are dealing with.

On top of that, both data index service and timer service provide metrics about their internals so these can also be monitored and managed.

Tracing

Every interaction from within process or a decision that results in calling another service should be tracked by default. That means should be equipped with information based on OpenTracing to allow deep dive analysis on service to service interaction using tools like Jaeger or Kiali.