Reporting and sharing data with other systems [Editor]

Introduction

Many of our customers want data to be made available for reporting. This design guide is about reporting, but in fact it is more general: the design guide is about sharing data with other systems. Since Blueriq itself does not provide reports, but merely makes data available for other systems to create reports based on this data, the title reporting is perhaps a bit expectant.

Intermezzo

Making data available for reporting is not the same as storing or tracing data, nor is it the same as using web services. Furthermore, reporting is not an equivalent of business activity monitoring or process mining. To make a clear distinction between these types of data interaction and data interpretation, see the image below.

In this design guide

Persistency

Persistency is all about storing and preserving data and sharing that data among other operational applications. Persistency is typically done in the operational environment and deals with live/actual/realtime data. This data is usually stored a long time. Typical example are: Wedding insurance request data / Person data / Risk profile data. In Blueriq, persistency is achieved by aggregate definitions in the domain, combined with CRUD/search services and a list container.

For more information, see the Persistency Management guide.

Business activity monitoring (BAM)

Business Activity Monitoring also deals with live/actual/realtime data, but this data does not have to be stored or preserved at all. BAM typically concerns data about the production/operational environment at this very moment, mostly about (the number of) cases/tasks/users etc. Since the data shown in BAM is volatile and constantly changing, the process database is queried at runtime (also the aggregate database since aggregates can be used to mimic cases, as discussed in Designing cases using aggregates). Typical example are: The number of open/closed/rejected cases of type Wedding Insurance Request at this moment. In Blueriq, containers are available that query the process database, the aggregate database and create visualizations of those queries.

For more information, see AQ_Statistic_Aggregate, AQ_Statistic_Process, AQ_Statistics_Visualization.

Audit/Trace

Traceability is mostly about storing who did what when. The main goal is to make sure that after a while it is still possible to find out what happened. While tracing, the entire profile (in process-tracing) or the aggregate profile (in aggregate-tracing) or the entire runtime decision graph (in decision-tracing) is stored. Since the amount of data that is stored might grow rapidly - and also not to unnecessarily burden the production environment - trace data is stored separately from the production environment. Tracing is done automatically for processes and aggregates (and can be switched off) and can be configured for decisions. A typical example is: Aggregate Person is updated by user Frank at 2015-07-01 11:19:35 and the aggregate content is <...>.

For more information, see Traceability.

Web services

Web services are used to communicate with other systems via messages. A typical examples is A social security number is sent to a web service, and the current marital status of that person is retrieved. Web services definitions are available in Blueriq by means of schema sets (XSD) or domain schemas. Web service calls can be created using services and are available in XML and JSON format.

For more information, see Web Services guide.

Process mining

Process mining typically concerns the afterward evaluation of a process and all its instances. In order to do this, the process trace database is interpreted. A typical example is: When viewing all instances of the Wedding insurance request case process, in how many instances was a risk profile needed? Process mining is not (yet) standard Blueriq functionality.

Reporting

Reporting concerns data in the (near) past and is in most cases done using data marts that originate in a datawarehouse. In order to feed the datawarehouse with the proper data, a reporting service can be used. This service is called when necessary and generates an XML file with live/actual/realtime data. The XML is stored in a database, along with some metadata. Since the amount of data that is sent to other systems might grow rapidly - and also not to unnecessarily burden the production environment - reporting data will be stored separately from the production environment. There is a lot of overlap between data that is persisted and data that is sent for reporting, apart from the fact that reporting data also contains system set (derived) data and persisted data mostly does not.

For more information on the reporting service, see AQ_Report [Editor].

Decoupling

Iets over kopieren, mapping genarator, unidirectioneel,

Strategy

Iets over meerdere reporting modules en meerder mappings etc