This page addresses the following FAQs:

  • Where is the ERRU message queue located?
  • How does the message storage process work?
  • What does late response mean?
  • How do I retrieve a late response?
  • How do I retrieve a message from the ERRU message queue?
  • If a message is uploaded, is it deleted from the queue?
  • How are messages deleted from the queue?
  • What is the EUCARIS time-out value for Check Good Repute and what is the Central Hub time-out value?
  • When sending a Notification Infringement using the web client, how is the ACK handled?
  • Is the ACK marked as retrieved after the web client has processed it?
  • When using the Async Forwarding of the ACK, are the retrieved messages filtered out?

Q: Where is the ERRU message queue located?

EUCARIS uses a generic message queue (FileTransferDownloadQueue) to store ERRU messages. The message queue contains all ERRU responses (i.e. all acknowledgements and all check good repute responses, both in time and late) and all ERRU notifications (notification infringement, notification infringement response).

Q: How does the message storage process work?

EUCARIS stores any ERRU response it receives (i.e. any check good repute response, in time or late, any notification infringement and any notification infringement response, into its message queue. For check good repute, there might be two response messages, i.e. a time out response after EUCARIS time out elapses, and a late response that comes after that. If a message is put in a queue, while for the particular service, another message with the same BusinessCaseId and country is already present, the new message overwrites the old message, i.e. per service, country, BusinessCaseId there is always only one message.

Q: What does “late response” mean?

The time out for completing transactions, especially Check Good Repute, is shorter on the EUCARIS side than on the ERRU Central Hub side (20 seconds vs. 60 seconds). Therefore, it is possible that ERRU Central Hub provides a response after the EUCARIS time out has elapsed (and the synchronous EUCARIS session is closed). EUCARIS broker will pick up such response and store it in the ERRU message queue.

A late response might be received until 60 seconds after firing the request. If the time out on the ERRU Central Hub side elapses, it will ignore any response that comes after that, so EUCARIS broker will not receive it.

Q: How do I retrieve a Late Response?

See: How Do I retrieve a message from the ERRU message queue.

Q: How do I retrieve a message from the ERRU message queue?

EUCARIS recommends using the Generic Asynchronous Service, that is described in the Custom Development Manual, section 3.1.15.

To retrieve Check Good Repute late responses, it is advised to use the ReceiveAggregated method, since this method will give you a full, consolidated response of all responses available in the queue for the particular BusinessCaseId, including a calculated overall result status. If this query is carried out  60 seconds after firing the request, the result obtained will be the final result (ERRU central hub time out has elapsed, no new late responses will be coming).

To retrieve a notification, first use the Index method to check if something is available. If so, use the Receive method to retrieve the notification.

Q: If a message is uploaded, is it deleted from the queue?

No it isn’t (but there is one catch though, see the item “How are messages deleted from the queue?). EUCARIS does record a status change in the queue table, it sets the flag “retrieved” to “true”. However, a notification or late response that has been retrieved already, can be retrieved again.

Q: How are messages deleted from the queue?

It is possible to set an auto purge on the queue, to be configured by each Member State for its own (ERRU) message queue.

Per service, a Member State can choose either to set a purge time (in days), or to disable auto purge. It is possible to distinguish between “retrieved” messages and “not retrieved”. Note that is possible to set a purge time of 0 days, e.g. for retrieved messages. This means that a message will be deleted from the queue as soon as it has been retrieved.

Note that a system administrator can manually delete messages from the queue, using a Management Client option. If auto purge is disabled, then this is the only way to get rid of messages.

Q: What is the EUCARIS time-out value for Check Good Repute and what is the Central Hub time-out value?

EUCARIS: 20 seconds.

Central Hub: 60 seconds.

Q: When sending a Notification Infringement using the web client, how is the ACK handled?

The web client does not handle the ACK at all. What the web client does, is submit the notification to EUCARIS by saving it into the upload queue. If this is successful, the web client process is finished. This is because EUCARIS operates on the principle of guaranteed delivery. If the sending of the ACK fails, EUCARIS will re-attempt until it succeeds. So the handling of the ACK is limited to EUCARIS, i.e. the sending EUCARIS instance and the recipient. The recipient sends the ACK as soon as it receives the IN in the download queue. The sending EUCARIS then considers the delivery to be OK (it will retry sending if it does not receive an ACK)

Q: Is the ACK marked as retrieved after the web client has processed it?

Not applicable, because the web client does not process ACKs. It arrives as “not retrieved” in the download queue.

Q: When using the Async Forwarding of the ACK, are the retrieved messages filtered out?

No. Pushing is done if a message arrives in the download queue, and the push option is set. The correct order of events is.

  1. Message is received in the download queue, and saved as “not retrieved”.
  2. If “push”  is set, the message will be forwarded, but it will remain in the download queue as “not retrieved”.

Something to keep in mind to set the purge times. If you choose to push, and you have no desire to keep the message after pushing has succeeded, you should set auto purge for ‘not retrieved’  Notification Infringements ACK messages.