• Created by Unknown User (m.gulpers), last modified on Aug 17, 2015

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

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

In this design guide

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.

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

Although reporting is all about facilitating accurate data at the right time, it does not mean that the reporting model must reflect the domain model exactly all the time. Some sort of decoupling between the Blueriq domain model and the model intended for reporting is necessary, to avoid dependencies and make agile application development in Blueriq possible. This is illustrated below.

As shown above, the domain module is not the source for reporting. A mapping between a domain module and a reporting module acts as the source. By doing this, the domain module can be adjusted, without bothering the reporting module and thus the external system. This is illustrated by the numbers in the elements in the domain and the reporting module:

  • Initially in iteration 1 (depicted by 1's in the elements), a reporting module was created that contained a subset of the elements of the domain module.
  • A datamapping was created that mapped the domain elements onto corresponding reporting elements.
  • Development of the domain model and the application took place, at iterations 2 and 3.
  • It was decided that a certain element created in iteration 1 should be replaced by a corresponding but different element created in iteration 2.
  • The datamapping was adjusted accordingly, the reporting domain remains unaffected.

This form of decoupling between a domain and an external system, i.e. decoupling domain definition and reporting definition, is very helpful in agile application development as the external system probably does not use the same release cycle as the Blueriq application.

Reporting module type

At a certain moment in the application development process, a reporting module is created, along with a mapping from the domain module onto the reporting module. This moment in time has to be chosen wisely and will probably be late in this process, when most of the domain is defined and created. When creating such a reporting module, beware to adhere to the following rules:

Only the following elements should be present in the reporting module:

  • Entities
  • Attributes
  • Relations
  • Value lists

Other elements are useless in a reporting module, since the reporting service completely ignores these elements.

The datamapping from an interaction module to a reporting module should be uni-directional, meaning only from the domain model to the reporting module.
Mapping the other way around is useless, since the reporting service completely ignores this datamapping.

Strategy

Iets over meerdere reporting modules en meerder mappings etc

See also

For more information on the relation between reporting concepts, see

Reporting

Reporting [Editor]

 

This page will definitely link to

  • No labels

Didn't find the answer you were looking for? Try the advanced search!