Gemsstock Sprint 4: New Inscription view for all process elements

Louis Müller

Below you can find the demo content of our Gemsstock Sprint 4 review. In summary, you may expect the following topics:

For those who have access to our Confluence, potential internal discussions and issue references can be found here:
Sprint 4: Demo - Inscription view for all process elements

Alexander Suter

Index tasks in Elasticsearch

Workflow tasks will be indexed into Elasticsearch to provide workflow statistics for now and maybe to serve the task list for the end user later. As soon as a task changes, the index will updated asynchronous.

Reindex
On startup we'll re-index if the format of the index changes on engine upgrade or if the amount of tasks in Elasticsearch does not match the amount of task in the system database. This is exactly the same behavior as for business data.

Engine Cockpit
All task indexes appear in the search engine overview of the engine cockpit. You are able to manually start a reindex. We slightly changed the index names and provide a better splitting for multi-tenancy:

${prefix}-${securitySystem}-${feature}-${additional}

The ${prefix} is configurable in ivy.yaml and is by default ivy. You don't need to change it, just if you run multiple engines for the same Elasticsearch server. Most of you only have the default as ${securitySystem}. Just if you run multi-tenancy, then you will have different security systems.

e.g.

ivy-default-businessdata-com.axonivy.dossier
ivy-default-task
ivy-customer-task

Elasticsearch
Bundled Elasticsearch server will be always started now, we think it becomes a must requirement. At the moment you can disable the indexing of workflow task with the feature flag Workflow.Index.Enabled in ivy.yaml.

Kibana Dashboard
With this change, you are already able to setup Kibana Dashboard based on tasks.

Audience: Business Analyst, Axon Ivy Developers, Axon Ivy Operators
Value: Reliable indexing of tasks to provide workflow statistics
Version: 11.1.0
Discussion: Any concerns?
Next steps: Providing an API (Java OR REST API) to load statistics for workflow

Screenshots / Code
Engine-Cockpit shows also workflow indices and allows manual re-indexing.

Smart little view in Axon Ivy Designer to see all indexed data.

Traffic Graph shows now also traces to traffic graph.

Alexander Suter

Provide an API for workflow statistics

In Portal we want to present aggregations of worklfow data using charts. We are already doing this. However, current query options are limited and we encounter performance problems with large amounts of data. Now we have the data in Elasticsearch, which is designed for such data query.

API
I've started to investigate, how we could provide these data to build charts. There is already a very experimental Java API for it, see usages in: https://github.com/axonivy/workflow-stats-demo

Next to a plain old Java API we could also just provide REST Services. These REST Services can be consumed directly with Javascript in e.g. Portal (no Primefaces!). This is anyway important that each chart will be loaded asynchronous to provide a good user experience on a dashboard with a lot of charts. Wheres we need to define security restriction for accessing these endpoints.

Java API vs REST API

Java APIs are well-known in Ivy
REST API can be used also for monitoring
REST API needs to be protected (permission?)
REST API drives a good user experience on a dashboard with a lot charts
REST API provided by the core should not be designed for specific UIs. You will need to transform the result in Javascript to show the data in the chart

Generic, full featured API vs. small but highly stable API
Elasticsearch provides so many features to query what ever you want. Date histogram, endless sub aggregations. It's much work to model it all out and just miss your specific use case, but we could be highly stable. On the other hand we should could leverage the Elasticsearch API and bring you all the great features of Elasticsearch, but as soon as we change how we index task and when we upgrade to next Elasticsearch, we could break.

Audience: Business Analyst, Axon Ivy Developers, Portal
Value: Provide meaningful charts
Version: 11.1.0
Discussion:

Java or REST API? Or both?
Generic, full featured API vs. small but highly stable API

Next steps: Decide and implement

Screenshots / Code

JLA

Task and Case ModifiedTimestamp

New Task and Case property which shows when the last time a task or case has been modified.
In order to add this feature properly we had to make sure all of our supported databases can support saving milliseconds.

We adjusted some of the types used to generate our database in some DBMS:
MySQL, MariaDB: DATETIME -> DATETIME(3)
OracleDB: DATE -> TIMESTAMP
MsSQL Server: DATETIME -> DATETIME2(3)

Audience

Process Developers

Value

See the timestamp when a case or task was last modified
New public API on task and case
New options for TaskQuery and CaseQuery
More precise timestamp/date fields in the DBs

Version

11.1.0

Next steps

Display ModifiedTimestamp in Dev-Workflow-UI

Code

TaskQuery.create().where().modifiedTimestamp().isLowerOrEqualThan(new Date());
CaseQuery.create().aggregate().minModifiedTimestamp();
Case.getModifiedTimestamp();
Task.getModifiedTimestamp();

JLA

Use business states of task and case in Dev-Workflow-UI

Using the business state as the main Task and Case state display with the technical case as an addition.

Audience

Process developers
Ivy Users

Value
Much simpler to understand Task and Case states.

OPEN - not all sub cases or tasks are DONE or DESTROYED.
DONE - all sub cases and tasks are DONE
DESTROYED - case has been destroyed or last sub case or task has been destroyed

Version

11.1.0

Lukas Lieb

Update from new Inscription Editor Prototype

Currently, there is a lot of pressure on the new Inscription Editor Prototype. So let's have a look at what happened in the last sprint:

Designer integration
We have integrated the current Inscription Editor prototype into our Designer. Open the Inscription Editor view and select an element in the process editor. Documentation

All elements
We now support all process elements in the Inscription Editor prototype. Most of the elements only support the Name Tab, but the element label and icons are updated according to the current selection.

More common tabs
We have added support for the "single" Task Tab (e.g. Request Start, User Task element) and the Code Tab (Script Step element).

Better IvyScript integration
We improved the IvyScript integration for some input fields. Now you will get highlight, writing, validation, and completion support for your scripts.

Audience: Process Developers, Pre-sales
Value: Designer integration, all elements, more tabs, better ivy script integration
Version: 11.1.0
Discussion: Any feedback?

Reto Weiss

Optimize Task Query for canWorkOn and isInvolved

We optimized Task and Case Queries for canWorkOn and isInvolved filter use cases. For this we reused the WorkerId field of the task and now duplicate the ActivatorId in it for tasks in state SUSPENDED, DELAYED, etc.
With this we can simplify the queries and only need to filter with WorkerId and no longer with WorkerId and ActivatorId depending on the task state.

Audience
Portal Developers, End Users

Value
Faster task and case lists

Version

11.1.0

Discussion

Next steps
Nothing planned

Screenshots / Code