Specifications
Specifications about EUCARIS message handling, as well as other general EUCARIS v8 specifications, can be downloaded here (credentials required).
The MessageService described on this page, is specified in detail in EUCARIS 8.0 Core UC-01 Send Message to EUCARIS.
Scope
The MessageService is part of the EUCARIS v8 architecture, so it is not used in services implemented in the v7 architecture.
All enveloped messages, submitted to EUCARIS from the outside world, are received by the EUCARIS MessageService, i.e., messages submitted by client applications, such as the EUCARIS Web Client or a customised client built by a Member State, messages submitted by legacy services, as well as messages sent by EUCARIS BatchProcessor, or messages from the EUCARIS broker (which are messages sent by EU Hub, converted to EUCARIS envelope format).
For further information about the EUCARIS Envelope, visit this page.
Processing
Message processing involves the following main steps:
- Validation
- Processing
- Send to destination
Validation
Everytime an envelope is offered to EUCARIS, the envelope and its contents are validated. Validations are described in UC-11.
If an envelope does not pass validation, it will not be processed. If the envelope contains a workflow initiating message, no workflow will be started, and the sender of the envelope receives an error notification without workflow reference (also referred to as a negative acknowledgement or NACK). The error observed is specified in as much detail as possible (refer to UC-11 for a list of error situations).
If the envelope refers to a known workflow, the sender of the envelope receives an error notification, with a detailed error. Since the workflow cannot be completed successfully, the initiator of the workflow also receives an error notification. This error notification contains a more general error.
Processing
The processing steps carried out by MessageService, depend on the MessageService that is executed in the workflow, e.g. Toll-EETS or IssuedCPC. The configuration of this MessageService in the EUCARIS datamodel, together with the information provided in the envelope of the workflow initiating message, dictate what steps to take.
When executing workflows, the EUCARIS MessageService uses a number of capabilities.
Logging: All activities performeId by the EUCARIS system, are logged, together with an acceptance result, which is OK if the activity succeeds, and something else if it doesn’t. Details of logging are described in UC-13. Successful logging is a precondition to continue processing. If a logging step fails, execution of the workflow is aborted.
Broadcast, or Multi Country Inquiry (MCI): The request (or workflow initiating message) is sent to a number of recipients, and the combined result of this inquiry (a number of response messages) is consolidated, and returned to the requester in one response envelope. Various broadcast variants are supported, such as a broadcast to all participants of a particular service, a broadcast to a subset of participants (where the client application specifies the recipients) or a so-called ‘outsourced’ broadcast where the actual broadcast is done outside EUCARIS, e.g. the EU Hub.
Synchronous exchange: At the workflow initiating Member State, record the workflow, send the request envelope to one or more destinations, and wait until the response envelope arrives or until time-out occurs. Create a response envelope and send it to the client application that initiated the workflow.
At the reacting Member State, receive the request envelope, record the workflow, send the request envelope to a local data service (legacy system), and wait until the response envelope arrives or until time-out occurs. Send the response envelope to the workflow initiating Member State.
Asynchronous exchange: In asynchronous exchange, various patterns are possible, such as exchanging a request and response asynchronously (e.g. a Toll-EETS ‘batch’), or exchanging a notification, with or without a response. Every message in an async workflow is exchanged separately.
At the workflow initiating Member State, record the workflow, send the envelope to one or more destinations, and record acceptance result OK if delivery was acknowledged. Re-try delivery if the acceptance result is different from OK.
At the receiving Member State, receive the envelope, record the workflow, and make the envelope contents retrievable. The content can be retrieved using the MessageRetrievalService (for further info, visit this page). If the receiving Member State is also the workflow initiating Member State, forward the response to the async forwarding url, if async forwarding is required.
Enrich a request message: Add content to the request message (derived from the content already present), required for the reacting participant to process. Example: Add NYSIIS keys.
Enrich a response message: Add content to the response message (derived from the content already present), required for the requester. Example: Add a matching percentage (RESPER).
Enrich envelope content or info: Assign identification to workflow and message(s), add the workflow initiating message to a response envelope, add workflow info to an envelope.
Error handling: If a workflow cannot be completed because somewhere in the processing an error occurs, create an error notification to notify the initiator of the workflow of the error.
Specials: Various specific requirements, such as handling ‘InProgress’ acknowledgements and subsequent async response (applies to RESPER), or handle a secure message exchange where two parties exchange an undefined number of messages within one workflow.
Send to destination
For determining the destination of an envelope, the MessageService uses the existing service configuration in the v7 datamodel. For this reason, every v8 MessageService contains a reference to a v7 ServiceId, that is used to retrieve the v7 service configuration.
At some point, a service configuration for the v8 datamodel will be implemented, which will be used then. The new service configuration is in the design phase.