There are three tables that should be actively maintained by the member state. EUCARIS supports this maintenance by various tools, but the member state is free to choose on how it is going to maintain the database.

The following tables have to be maintained:

ServiceLog

The ServiceLog contains the transferred messages for the following purposes: Auditing and statistics collection. Both have their requirement on retention and specific settings. Default and minimal required settings are distributed and configured using the Configuration Update Mechanism.  When installing the latest version of the Configuration Update, EUCARIS will automatically adhere to the minimum required logging set for both the data retention rules and the statistics collection. It is not necessary to enable more logging unless there are specific needs for that.

The ServiceLog table will increasingly grow when using EUCARIS and needs to be purged on a regular basis. This purging is performed by the ServiceLogPurge task of the EUCARIS Task Scheduler. This task will delete all messages which are older than the agreed retention period. EUCARIS will use a default of 12 months retention if no retention period is explicitly agreed upon. Member states need to take additional actions if they require to retain the messages longer than the configured retention period in EUCARIS.

The following Retention periods are explicitly defined per treaty/agreement/service.

  • AVI – 12 months
  • CBE – 24 months
  • DLInfo – 12 months
  • ERRU – 6 months
  • RESPER – 6 months
  • RSI – 36 months
  • Salzburg services – 24 months
  • TACHO – 6 months
  • VH Owner Holder (Prüm) – 24 months

If not mentioned above, EUCARIS will use a default of 12 months retention per service.

Detailed information for the usage of the ServiceLog table and the data retention rules is available in the document EUCARIS – Description of Logging (see  General Functional Documentation)**.

FileTransferUploadQueue

The FileTransferUploadQueue table contains all outgoing asynchronous messages. The stored messages can have 3 processing states (processstatus column):

  • Unprocessed (processstatus = 0): EUCARIS will try to deliver the messages soon as possible
  • Processing (processstatus = 1): EUCARIS is busy to deliver the message
  • Processed (processstatus = 2): EUCARIS has successfully delivered the message

In normal operations it is expected that the number of unprocessed and processing messages is zero, or larger than zero for a short period of time. A message might retain on process state Unprocessed in case of repeated delivery failures. In this case the column ‘LastTry’ will contain a date and time stamp of the last (failed) delivery attempt. The Windows Application Eventlog will contain detailed information regarding the failed delivery.

Messages with state Processed are successfully delivered and can be removed from the queue if there is no need to access the message for functional purposes. The messages are already stored in the ServiceLog for Auditing and statistical purposes (configured in the Logging Configuration as described in paragraph 8.1.2 of the installation and operations manual). EUCARIS supports the automatically purging of the upload queue. Please refer to paragraph 8.1.13 of the installation and operations manual for more information. Please note that the FileTransferUploadQueue is designed for short-term message storage, so it is advised to keep the FileTransferUploadQueue table as empty as possible. The storage of large volumes of messages for a long period of time might effect the performance of EUCARIS in a negative way.

FileTransferDownloadQueue

The FileTransferDownloadQueue table contains all received asynchronous messages. The stored messages can have 2 retrieval states (column retrieved):

  • Not retrieved (retrieved = 0): The message has not been retrieved by a user or process.
  • Retrieved (retrieved = 1): The message has been retrieved by a user or process.

Note: when using asynchronous message forwarding, the processing state will stay Not retrieved, even after successful forwarding the message to a backend system.

Furthermore the stored messages can have 3 processing states which are only relevant if the received file has to be processed by the EUCARIS Batch Processor (processstatus column):

  • Unprocessed (processstatus = 0 or null): EUCARIS Batch Processor did not process the message (not configured).
  • Processing (processstatus = 1): EUCARIS Batch Processor is busy to process the message.
  • Processed (processstatus = 2): EUCARIS Batch Processor has successfully processed the message.
  • Failed (processstatus = 3): Some failure occurred during the batch processing of the message.

Note: when using the EUCARIS Batch Processor for processing specific messages, the retrieved state will be set to retrieved once the Batch Processor has started processing the message.

Messages with state Retrieved are assumed to be successfully retrieved and can be removed from the queue if there is no need to access the message for functional purposes. The messages are already stored in the ServiceLog for Auditing and statistical purposes (configured in the Logging Configuration as described in paragraph 8.1.2 of the installation and operations manual). Messages with state Not retrieved might be eligible to be processed (depending on the functional design of the message exchange) or can be removed from the queue if there is no need to access the message for functional purposes. EUCARIS supports the automatically purging of the download queue. Please refer to paragraph 8.1.13 of the installation and operations manual for more information. Please note that the FileTransferDownloadQueue is designed for short-term message storage, so it is advised to keep the FileTransferDownloadQueue table as empty as possible. The storage of large volumes of messages for a long period of time might effect the performance of EUCARIS in a negative way.

Manage size of File Transfer Upload- and Download Queue

The EUCARIS download- and upload queue were not designed to store and or archive items over a longer period. Both queues must be regarded as temporary storage for further processing of the message. The storage of large volumes of messages for a long period of time might effect the performance of EUCARIS in a negative way. If messages are processed or transferred to other systems (or archives) they must be deleted from the queues. The easiest way to do this is by means of EUCARIS’s Queue Purging mechanism. It is possible to configure the maximum retention period of both retrieved and un-retrieved messages. Please refer to the Installation and Operation manual, paragraph 8.1.13, “Queue Purge Configuration”.

Furthermore it is possible for EUCARIS to store and forward the incoming messages to an external system where the messages are processed and archived properly. Please refer to the Installation and Operation manual, paragraph 8.1.1 “Service Configuration” for this.