Data Loader

Funktion

Der Microservice konsumiert die Zeiträume aus der Work Package Queue und lädt alle relevanten Nachrichten innerhalb des Zeitraums aus der B2B-Datenbank. Dabei werden alle zur Archivierung konfigurierten Informationen der Nachricht geladen. Danach wird der Status (VS) an der Nachricht auf (“In Archivierung”) aktualisiert. Zu jeder Nachricht wird dann ein Eintrag zur Archivierung in die Persistence Queue geschrieben.

Optionaler zweistufiger Workflow (Message Archive Data Loading)

Ab Version 2026-07-xx kann optional ein zweistufiger Verarbeitungsweg aktiviert werden (message-archive-data-loading.enabled: true). Dieser ist standardmäßig deaktiviert; ohne Konfigurationsänderung verhält sich der Service unverändert wie zuvor.

Bei aktiviertem Workflow wird ein Zeitraum aus der Work Package Queue nicht mehr in einem Schritt verarbeitet, sondern in zwei Stufen aufgeteilt:

1. Stufe 1: Der Service ermittelt zum Zeitraum nur die betroffenen Nachrichten ohne deren (teils sehr große) Attribute und schreibt jede Nachricht einzeln in eine Zwischen-Queue (Standardname message_archive_data_loading_queue).
2. Stufe 2: Ein Consumer holt die einzelnen Nachrichten, lädt je Nachricht die Attribute und Zusatzdaten, aktualisiert den Status und schreibt den Archivierungseintrag in die Persistence Queue.

Dadurch befindet sich immer nur eine einzelne Nachricht inklusive Attribute gleichzeitig im Arbeitsspeicher (zusätzlich begrenzt über message-archive-data-loading.prefetch). Der Speicherverbrauch bleibt so auch bei Zeiträumen mit sehr vielen Nachrichten konstant. Schlägt die Verarbeitung einer Einzelnachricht fehl, wird diese in der Queue belassen (Requeue) und später erneut versucht, statt den Service zu beenden.

Beide Stufen werden verlustfrei gedrosselt (Backpressure): Stufe 1 pausiert, solange die Zwischen-Queue mehr als message-archive-data-loading.queue-max-size Nachrichten (Standard 100.000) enthält; Stufe 2 pausiert, solange die Persistence Queue mehr als production-queue-max-size Nachrichten (Standard 1.000) enthält.

Konfiguration

Die Konfiguration des Microservices geschieht über die im “docker-compose”-Datei angegebene “application.yml”. Die Variablen darin werden üblicherweise im globalen docker environment File konfiguriert, siehe Installation.

Das Standard Docker Image enthält die folgenden Konfigurationsmöglichkeiten:

# Name of the service consuming message queue of archiving periods
consumer-queue: work_package_queue
# Name of the service producing message queue of extracted messages for archiving
production-queue: persistence_queue
# Maximum size of the production queue. The data-loader service pauses temporarily if this threshold is exceeded. Default is 1000
production-queue-max-size: 1000

# Optional two-stage "message archive data loading" workflow (default: disabled).
# When enabled, a time period is fanned out into single messages (without attributes) via an
# intermediate queue, which are then enriched and archived one by one. This keeps the memory
# footprint constant even for periods containing a very large number of messages.
#message-archive-data-loading:
#  # activates the two-stage workflow; default is false (legacy single-stage processing)
#  enabled: false
#  # name of the intermediate queue holding single messages (without attributes)
#  queue: message_archive_data_loading_queue
#  # max. unacknowledged single messages kept in memory by the stage-2 consumer; keep low to bound RAM
#  prefetch: 1
#  # max. messages allowed in the message archive data loading queue before stage 1 pauses producing
#  queue-max-size: 100000

# Configuration of the message archive state operations. Use defaults for production.
#message-archive-state:
#  # only set false for development/testing in database 'read-only' mode
#  doUpdateToPending: true
#  # message archive pending state, B2B default: ARP
#  pending: ARP

message:
  # comma separated list of message state. By default the value are successful ("SUC") and manually finished ("MAN")
  states: SUC,MAN
  # control if additional columns will be included in the archiving message. Default is false.
  include-additional-columns: false
attribute:
  # comma separated list of attribute ids to collect for archiving message information
  ids: ${ATTRIBUTE_IDS}
spring:
  # RabbitMQ access data
  rabbitmq:
    host: ${RABBITMQ_HOST}
    port: ${RABBITMQ_PORT}
    user: ${RABBITMQ_USER}
    password: ${RABBITMQ_PASSWORD}
  # B2B database access data
  datasource:
    driver-class-name: ${DATABASE_DRIVER_CLASS_NAME}
    url: ${DATABASE_URL}
    username: ${DATABASE_USER}
    password: ${DATABASE_PASSWORD}

Releases

Der Service wird in den folgenden Versionen als Docker Container über unsere Registry docker-nob-erp.next-level-apps.com/data-loader bereitgestellt.

2026-07-xx

2025-12-17

2024-09-06

2024-02-28

2023-08-09

2023-03-16

2022-11-23

2021-06-28