...
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 to 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 for 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 a distributed system it is expected that in some cases one could have some de-synchronized events / data. For example one could be processing 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.
...
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 handles information and status about cases.
...
| Note | ||
|---|---|---|
| ||
An implementation for transaction security on notifications has been requested. Meaning This means 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 but steps towards it have been taken. The approach is to remove the SignalR notifications and replace them with messages for RabbitMQ through a secure connection. RabbitMQ ensures transaction security in this context. |
To get notifications about cases you need to connect to caseHub. URLs:
...