Page History
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
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.
The procedure of reporting is fairly simple and boils down to the use of a single service: 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 application model exactly all the time. Some sort of decoupling between the application 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 completely 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:
| UI Text Box | ||
|---|---|---|
| ||
| The reporting module must be an interaction module. |
To create a reporting module, the business engineer must copy the application module (sometimes referred to as domain module). See How to copy modules [Editor] on where and how to make a copy of a module. Most likely, the copied module will be a flattened (or "rolled up") copy, where all elements of base modules is part of the copy.
| UI Text Box | ||
|---|---|---|
| ||
Only the following elements should be present in the reporting module:
Other elements are useless in a reporting module, since the reporting service completely ignores these elements. |
After creating a reporting module, that is a flattened copy of the application module, the business engineer should delete every element from this copy, except all entities, attributes, relations and value lists. After that, entities, attributes, relations and/or value lists that are not part of the reporting domain can be deleted.
| UI Text Box | ||
|---|---|---|
| ||
The datamapping from an interaction module to a reporting module should be uni-directional, meaning only from the domain module to the reporting module. |
After the application module has been copied and stripped of all non-reporting elements, a mapping has to be made from the application module to the reporting module. Toe get a quick start, the mapping generator can be called. This generator maps all attributes and relations between two modules that have the exact same name and type. For more information on the mapping generator, see How to use the mapping generator [Editor].
Strategy
One of the benefits of decoupling the domain model and the reporting model by means of modules and a datamapping is that it is possible to create multiple reporting modules and multiple datamappings, all based on the same domain. Furthermore, it is possible to have a single datamapping be exported to different connections. This is illustrated below.
Default strategy
The default strategy regards a simple export; within an application module, a service is called that exports a datamapping (that maps the application module to a reporting module) and places this export in a single connection.
Based on this strategy, the following exporting strategies can be used.
Strategy A
Within strategy A the application module consists of service calls to two mappings to different reporting modules. Each export is configured on another connection as well.
One use case immediately comes to mind here: the two exports, the two connections, the two reporting modules and the two datamappings split the entire application module in two and are completely disjunctive. For instance, one is about a health insurance and the other about a mortgage application. However, good practice would probably not have allowed to model this in a single application module.
Strategy A fits better in the following use case: Different parties want different parts of the entire domain.
The first export could very well be the entire export, as described in the default strategy, whereas the second export could be a subset with for instance only data about Persons and not their permit requests. It is most likely that another party is interested in this subset (hence the different connection) and because of the fact that it not 100% sure that it will always remain a subset, it is wise to create another reporting module in this particular case.
Strategy B
Within strategy B, a single connection will receive all exports. From the point of view of the receiving party, there are two types of export, therefore there are two reporting modules. This is almost the same as strategy A, with the exception that both exports are picked up by the same external party on the same connection. From the application's point of view, there are two types of exports: one could be containing all Health insurance requests and one could consist of Dental insurance requests. If these domains are very much the same, strategy C should be used.
Strategy C
Within strategy C, a single connection will receive all exports. From the point of view of the receiving party, there is only one export. This is especially true (and not true for strategy B) because there is only one reporting domain, so only one contract. But within this domain, two distinct flavors can be distinguished. From the application's point of view, there are two types of exports: one could be containing all Health insurance requests and one could consist of Dental insurance requests. If these domains differ a lot, strategy B should be used.
Strategy D
Strategy D resembles the default strategy very much. Within an application module, a service is called that exports a datamapping (that maps the application module to a reporting module). Instead of placing it in a single connection, it places the export in multiple connections. however, since the connection can only be configured once, two export services are created, both of them point to the same datamapping but different connections.
See also
For more information on the relation between reporting concepts, see
| Reporting |
Overview
Content Tools