Flow History

During routing, messages are contained in an exchange and these exchanges flow from one processor to another. So messages follow different steps of an Integration Flow. For the purpose of proof of delivery and error tracking, runs of Integration Flows (transactions) and all their corresponding steps are stored in so-called Flow History. Dependent on the type of Integration Flow, (Sensitive) Personal Data might be involved in the data that is exchanged with a Non-Unit4 Application. The minimal dataset that is exchanged is Integration Flow specific and must be documented as such in a brief Information Flow specific description. The description states among other things; - what data is exchanged; - what purpose the exchange of data serves; - what protocol is used; - what security is applied.

A predefined Time-To-Live (TTL) will be applied on Flow History data throughout the system, so the transactional data will be stored with a predefined TTL. The retention time of any data stored in the solution is configurable to make sure that Flow History data at rest is stored no longer than necessary to be in line with GDPR Article 30(1.f). TTL for Flow History data will therefore be set on an Integration Flow level at design time.

Unit4’s Assigned Support Team can access Flow History data (which may contain PII dependent on Integration Flow) for the purpose of sample-wise verification of successful runs, error-tracking in case of exceptions and to provide proof of delivery on customer request. All these actions will be logged on a user level.

List of runs

In Flow History you can see all the runs of Integration Flows with a brief summary telling the tenant it was executed for, the state of the run (depending on the state an icon will be shown), when it started and the time elapsed. The list of runs is agnostic of what Integration Flows are being executed. This means that you immediately have an overview of what Integration Flows have been executed in the past period of time, so basically what happend recently. Flow History overview can be refreshed by clicking the refresh button. You can also filter the list of runs using different filters like: - Trace Id: We want to know the full route a single event or call triggered. In order to trace logs from all microservices that an action in U4IK portal triggered and to trace logs from all microservices that a GMP message triggered. This means that every call to the U4IK system generates such Trace Id; - Period: where you can specify in which moment of time the run you are interested in was executed. You can choose from one of the options "Start time later than", "Start time earlier than", "End time later than", "End time earlier than" - Status: Status of Integration Flow run. Possible values are "Correct", "Error" or "Pending".

image.png

General run information and list of steps

When you click on a specific run in the list, the list of runs will move to the left of the screen and the corresponding run details and list of steps will appear on the right side of the screen. You can see details of the run, a full list of executed steps and the end state of the steps. This way you can easily go through the different runs and see corresponding steps:

image.png

General step information and step details

When you click on a specific step, the list of steps for the run will move to the left of the screen and the corresponding step details will appear on the right side. So you can go through the different steps of a run on the left and immediately see the step details on the right.

An exchange in Camel is the message’s container during routing. An exchange also provides support for the various types of interactions between systems, also known as message exchange patterns (MEPs). MEPs are used to differentiate between one-way and request-response messaging styles. The Camel exchange holds a pattern property that can be either Exchanges – or MEPs (Message Exchange Patterns) – are like frames where we transport our data across the integrations on Camel. A Exchange can have 2 messages inside, one representing the input and another one representing the output of a integration. The output message on Camel is optional, since we could have a integration that doesn’t have a response. Also, an Exchange can have properties, represented as key-value entries, that can be used as data that will be used across the whole route. The Exchange interface provides an abstraction for an exchange of messages, that is, a request message and its corresponding reply or exception message. In Camel terminology, the request, reply and exception messages are called in, out and fault messages. An exchange contains following elements: - Exchange ID: A unique ID that identifies the exchange. Camel will generate a default unique ID, if you don’t explicitly set one. - MEP: A pattern that denotes whether you’re using the InOnly or InOut messaging style. When the pattern is InOnly, the exchange contains an in message. For InOut, an out message also exists that contains the reply message for the caller. - Properties: Similar to message headers, but they last for the duration of the entire exchange. Properties are used to contain global-level information, whereas message headers are specific to a particular message. Camel itself will add various properties to the exchange during routing. You, as a developer, can store and retrieve properties at any point during the lifetime of an exchange. - In message: This is the input message, which is mandatory. The in message contains the request message. - Out message: This is an optional message that only exists if the MEP is InOut. The out message contains the reply message. - Exception: If an error occurs at any time during routing, an Exception will be set in the exception field.

Following tabs are available: - Exchange tab (always presented): As mentioned, an Exchange can have properties represented as key-value entries that can be used as data that will be used across the whole route. These Exchange properties are shown on the Exchange tab:

![image.png](./images/fhr_step_details.png)