MessageId requirements

The header attribute MessageId identifies a message uniquely. This applies to all types of messages (requests, responses, notifications). A client application that starts a new message dialogue, i.e. submits a request or notification, should assign a MessageId, meeting the following requirements:

  1. The MessageId is a Universally Unique Identifier (UUID). See Wikipedia for further information.
  2. The MessageId is newly generated for each new message.

This means that a client application cannot re-use a MessageId. Everytime a message is submitted to EUCARIS, its MessageId must be unique.

The exact same requirement applies to a legacy system that submits a message to EUCARIS (This usually is a response message, constructed after receiving and processing a request message).

Current situation (until start of 2018)

The MessageId requirements as outlined above, has been present in the EUCARIS XML message specifications of the various EUCARIS services, for a number of years.

However, EUCARIS did not actually check if client applications and legacy systems complied to the requirements. So, if an application re-used a MessageId, or if an application submitted a non-UUID MessageId, then the message was accepted instead of rejected. Since there are many client applications in many countries (systems at police organisations as well as systems at registration authorities as well as systems at ‘competent authorities’), there have been problems with MessageId not complying to requirements. The impact of this is twofold:

  1. In services where the network is a co-existence between the EUCARIS system and a EU system (i.e. ERRU, RESPER and TACHOnet), messages with incompliant MessageId are accepted by EUCARIS, but not by the EU Hub (because MessageId is passed through as ‘workflowId’, and the EU Hub systems checks on the requirements given above). So, from the EUCARIS perspective, the messages seem to be processed, but in fact, they are not.
  2. In the EUCARIS logging, duplicate MessageIds may exist, causing various problems:
    • Troubleshooting problems (not being able to find the right message, confusion about what’s going on)
    • Correlation problems between request and response messages
    • Unreliable statistical reports, since duplicate MessageId cause errors in counts.

EUCARIS Operations regards these problems as unwanted, and has decided to solve them.

Solution to check MessageId

In the EUCARIS datamodel, a new entity is created, named MessageIdRepository. Everytime an external application (a client application or legacy system, including the EUCARIS web client) submits a message to EUCARIS, the MessageId of this message is inserted into the MessageIdRepository entity. There are two reasons why this insert may fail:

  1. The MessageId is already present in MessageIdRepository (so, it  is re-used by the client)
  2. Its pattern is not consistent with the UUID pattern.

If the insert fails (MessageId does not meet the requirements), EUCARIS rejects the message, returning a SOAP error to the submitting client application or legacy system. If the insert succeeds (MessageId is OK) then the message is accepted and processed.

The MessageId is kept in the MessageIdRepository for as long as the retention time of messages in the EUCARIS logging. Usually, this maximum retention time is a legal requirement, denoted in the legal basis under a particular service. If logging is purged because the maximum legally allowed retention time expires, then the MessageIdRepository is also purged.

Implementation of the solution

The solution as described above is implemented as a feature in the EUCARIS Core (SU-U26 and onwards), but can be enabled on Extension basis. Currently,  the solution is implemented in the Extensions mentioned below. Other EUCARIS services will follow in due time.

Extensions which implement this feature:

  1. AVI
  2. ERRU
  3. RESPER
  4. TACHOnet
  5. VAT