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

Compare with Current View Page History

« Previous Version 17 Next »

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.

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.

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 infromation 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.

Request for transaction security

An implementation for transaction security on notifications has been requested. Meaning that if a system is down it will not get any notifications, but when it comes back up it will receive the notifications it missed during the offline time period. This feature has not yet been implemented.

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.

OnCaseCreatedNotificationReceivedAsync
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.

Request typeEndpointResponseMedia typeRequires authorizationNote
GET/canarystringtext/plainNo

Used to validate that the application is running.

GET/api/Cases/{id}{
  "id": "Guid",
  "name": "string",
  "kle": "string",
  "entityCode": int,
  "organisationId": "string",
  "originSystemCode": "string",
  "caseDetailsUri": "string",
  "created": "DateTime",
  "updated": "DateTime",
  "caseDetails": "string"
}
text/plainYes

The response is a specific case and as an attribute on the object is caseDetailsUri which is a URI to the Origin System for CaseDetails. The same CaseDetails are provided in the caseDetails attribute.

The id in the parameter is the id of the case and is required in the request. The id is set by the Origin System.

An example of the Guid could look like this: 3fa85f64-5717-4562-b3fc-2c963f66afa6

An example of the DateTime would look like this: 2023-05-15T11:40:47.067Z

GET/api/Cases[
  {
    "id": "Guid",
    "name": "string",
    "kle": "string",
    "entityCode": int,
    "organisationId": "string",
    "originSystemCode": "string",
    "caseDetailsUri": "string",
    "created": "DateTime",
    "updated": "DateTime"
  }
]
text/plainYes

The response is a list of cases that the client has access to. A URI to the CaseDetails is provided in the object of each case in the list.

As a query parameter the following parameters are optional:

  • createdStartDate: string($date-time)
  • createdEndDate: string($date-time)
  • updatedStartDate: string($date-time)
  • updatedEndDate: string($date-time)
  • kle: string

The parameters are optional and can be used as a filter when fetching cases.

An example of the Guid could look like this: 3fa85f64-5717-4562-b3fc-2c963f66afa6

An example of the DateTime would look like this: 2023-05-15T11:40:47.067Z

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.
  • No labels