Description

Data Integration Service (called D-I-S on a daily basis) is a case flow coordination service. It handles information about the flow of cases between Origin Systems and Consumer Systems.

Origin Systems

A Origin System is the "owner" of a case. It is where the case is created, but it also holds the responsibility to update, close, or delete (if required). Every change made to the case after creation besides closing and deletion is an update.

Each Origin System has the responsibility to create a data model for the CaseDetails and therefore different Origin Systems can have different data models for CaseDetails. It is the responsibility of the Origin System to expose the endpoint for fetching CaseDetails by Consumer Systems. The endpoint should be secured by an access token from KeyCloak. The URL to the endpoint is set in the caseDetailsUri attribute on the Case object.

When publishing the four commands (CreateCaseCommand, DeleteCaseCommand, UpdateCaseCommand, CloseCaseCommand) these commands are pushed into four different queues. All commands in each queue will be processed sequentially. But the four queues will be processed in parallel.

Consumer Systems

Consumer systems are the subscribers of cases and corresponding data delivered through DIS by the Origin Systems. To authorize a consuming system and make calls to DIS an access bearer token is needed. This token is generated using KeyCloak, with the use of clientId and clientSecret. To add a system to KeyCloak a realm manager (the Cross team) has to set up the client. Once the client has been created the clientId and clientSecret should be provided to the external integrating system. The integrating system should implement the call KeyCloak to obtain the bearer token and place this in the header when sending requests to DIS and the Origin System (for CaseDetails).

The structure of data delivered is dictated by each Origin System depending on the need of available data. Only EGDW.CaseMetadata is static and set by DIS, the content of CaseDetails and how it is mapped is a contract between the Origin System and the Consumer System. This means the Id, Created, and Updated are set by the Origin System. When a case is created and sent to DIS, DIS will save the metadata in a database (DB) and set the Updated attribute to the same value as Created. When the case, later on, is updated by the Origin System, the value in the DIS DB for metadata will be overwritten with the Updated value.

Since this is distributed system it is expected that in some cases one could have some de-synchronized events / data. For example one could be processing CaseCreatedEvent on a case that has already been deleted. If one asks for case details and the response will be HTTP 404 then one should assume that the case has already been deleted and skip processing of that message - that way we'll get eventual consistency.

NemJournalisering (NJ)

When fully implemented, DIS will replace NemJournalisering entirely. They differ in functionality as NJ is considered a Data Warehouse System for cases, where DIS is handling information and status about cases.

Notifications

When a case is created, updated, closed, or deleted by the Origin System each Consumer System is notified with a push notification, by utilizing the SignalR technology.

SignalR is Microsoft's technology which utilizes underlying web technologies like WebSocket's to achieve real-time web functionality without developers worrying about implementation details. You can read more about it here: https://learn.microsoft.com/en-us/aspnet/signalr/overview/getting-started/introduction-to-signalr

You can check out our example app here: https://github.com/EG-A-S/egdw-dis-signalr-example

You need to fill in the proper clientId  and clientSecret for the proper environment that you want to use and change the hub URL. The clientId and clientSecret are provided to you by EG DW. You should reach out to your contact (project manager) in EG DW and they will provide you with the credentials.

A Microsoft general examples can be found here (aside from .NET in Java and JavaScript too): https://learn.microsoft.com/en-us/aspnet/core/signalr/client-features

When a notification is sent out to an external system and the external system is down the notification will not be queued or be sent out again later on. The notification is lost.

To get notifications about cases you need to connect to caseHub. URLs:

To get notifications you'll need to have a proper bearer access token from KeyCloak. When your application is connected you can listen to these three different events:

• CaseCreatedNotificationAsync  - for create notifications.
• CaseUpdatedNotificationAsync  - for update notifications.
• CaseDeletedNotificationAsync  - for delete notificationss.

Each notification will show in a string what event (create, update, or delete) and what case (id on the case) was affected. See below code snippet as an example of when a case is created.

private async Task OnCaseCreatedNotificationReceivedAsync(string caseId)
        {
            Console.WriteLine($"Created: {caseId}");
        }

The consumer system will only get notifications about cases that your client (from the access token) has access to.

Endpoints and schemas

The following is an overview of what endpoints will return which data.

FAQ

• If /api/Cases is requested with the filter set to get cases which have been updated from xx to yy will you then receive cases created in the same set period?
  • Yes, when a case is created the Updated attribute is set to the same value as Created and therefore cases which have been created in the same period will be returned as a part of the response.
• Is there any pagination on /api/Cases
  • No. If the response dies due to too big an amount of data the response will be 404 Not Found.
• If a case is deleted will it then still show up in the list of cases (/api/Cases)
  • No. When the case is deleted in DIS no metadata exists about it and if requested the response will be 404 Not Found.