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.

Queues

Legt fest, aus welcher Queue der Service Zeiträume konsumiert und in welche Queue er die aufbereiteten Nachrichten schreibt.

consumer-queue: work_package_queue
production-queue: persistence_queue
production-queue-max-size: 1000

Nachrichtenfilter

Steuert, welche Nachrichten und Attribute für die Archivierung berücksichtigt werden.

message:
  states: SUC,MAN
  include-additional-columns: false
attribute:
  ids: ${ATTRIBUTE_IDS}

RabbitMQ-Anbindung

Verbindungsdaten zum RabbitMQ-Broker.

spring:
  rabbitmq:
    host: ${RABBITMQ_HOST}
    port: ${RABBITMQ_PORT}
    username: ${RABBITMQ_USER}
    password: ${RABBITMQ_PASSWORD}

Datenbankanbindung

Verbindungsdaten zur B2B-Datenbank.

spring:
  datasource:
    driver-class-name: ${DATABASE_DRIVER_CLASS_NAME}
    url: ${DATABASE_URL}
    username: ${DATABASE_USER}
    password: ${DATABASE_PASSWORD}

Optionaler zweistufiger Workflow (Message Archive Data Loading)

Standardmäßig deaktiviert. Wird für Umgebungen mit sehr großen Zeiträumen empfohlen, um den Arbeitsspeicherverbrauch konstant zu halten. Siehe auch Funktionsbeschreibung.

message-archive-data-loading:
  enabled: true
  queue: b2b.archiving.message_archive_data_loading_queue
  queue-type: QUORUM
  prefetch: 1
  queue-max-size: 100000

Nachrichtenarchivstatus (optional, nur für Entwicklung/Test)

Im Normalbetrieb müssen diese Werte nicht gesetzt werden.

message-archive-state:
  doUpdateToPending: true
  pending: ARP

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-08-xx

2025-12-17

2024-09-06

2024-02-28

2023-08-09

2023-03-16

2022-11-23

2021-06-28