Der Sammlerdienst

Der Sammlerdienst - eine Kernkomponente der Servicesuche Bund - ist für das Aufnehmen und Validieren von Verwaltungsleistungen aus den Redaktionssystemen verantwortlich.

Was ist der Sammlerdienst?

Der Sammlerdienst ist eine Komponente des Online-Gateways des Portalverbunds. Die Aufgabe des Sammlerdienstes ist das Aufnehmen von Leistungen aus den Redaktionssystemen der Länder und des Bundes. Die Leistungen werden dabei geprüft und an die anderen Komponenten des Online-Gateways verteilt.

Der Sammlerdienst importiert Leistungen im XZuFi Standard (derzeit 2.2.0 und 2.3.1), welcher durch die Firma Teleport i.A. gepflegt wird.

Die Daten durchlaufen im Sammlerdienst eine mehrstufige Verarbeitungspipeline. Hierbei werden die Informationen aufgenommen, validiert, auf Änderungen geprüft und weitergeleitet.

Es werden 6 Stufen durchlaufen

1. XZuFi-Downloader: Übernimmt die Aufgabe des Downloads der XZuFi-Dateien von den Redaktionssystemen.
2. Technischer Validator: Prüft die XZuFi-Dateien gegen ein XML-Schema.
3. Zerteiler: Das XZuFi-Dokument wird in bis zu sechs fachliche Geschäftsobjekte getrennt, welche in einem internen Datenmodell persistiert werden: Leistung, Organisationseinheit, Zuständigkeit, Spezialisierung, Onlinedienst, Formular
4. Fachlicher Validator: Alle Geschäftsobjekte aus einem Redaktionssystem werden einer fachlichen Prüfung unterzogen.
5. Delta Detektor: Vergleicht die Geschäftsobjekte aus einem Redaktionssystem mit bisher bekannten Geschäftsobjekten. Neue oder geänderte Geschäftsobjekte werden weitergeleitet. In einem Datenbestand nicht mehr vorkommende Geschäftsobjekte werden für die Löschung markiert. Bereits vorhandene und unveränderte Geschäftsobjekte werden nicht erneut weitergeleitet.
6. Verteiler: Leitet die ausgewählten Geschäftsobjekte über eine Schnittstelle weiter zum Bereitstelldienst und Suchdienst.

Neben dem hier beschriebenen Pull-Verfahren ist auch der Import über eine Push-Schnittstelle möglich, bei dem die Redaktionssysteme einzelne Änderungen direkt und zu jeder Zeit in den Sammlerdienst übertragen ("pushen") können.

Technologie

Der Sammlerdienst ist eine auf Spring Boot basierende Web-Anwendung, die mit Java realisiert wird. Zur Datenhaltung wird eine relationale Datenbank (PostgreSQL) verwendet.

Kurzüberblick:

• Java Spring Boot Web-Anwendung
• REST API
• Keycloak Authentifizierung Integration
• Relationale Datenbank (PostgreSQL)
• OpenAPI-konforme API-Beschreibung
• Logging mit EFK-Unterstützung

Anbindung - FAQ

Ist es ausreichend, wenn die zu liefernden Daten den Anforderungen des XZuFi-Standards entsprechen?

Nein, neben den Anforderungen des XZuFi-Standards müssen die zu liefernden Daten den Anforderungen des PVOG Sammlerdienst-Konzept entsprechen.

Welche Sprachen werden unterstützt?

Generell unterstützt XZuFi die Beschreibung von Inhalten in mehreren Sprachen. Im PVOG werden grundsätzlich die Sprachen Deutsch und Englisch unterstützt. Folgende Angaben für das Attribut languageCode sind gemäß Sammlerdienst-Konzept erlaubt: de und en.

Sind alle HTML-Tags erlaubt?

Nein, laut Sammlerdienst-Konzept sind die folgenden HTML-Tags/Attribute erlaubt:

  <p>, <br>,
  <h1>, <h2>, <h3>, <h4>, <h5>, <h6>
  <b>, <strong>
  <i>, <em>
  <sup>, <sub>
  <ul>
  <ol>
  <li>
  <a href>

Darf das Attribut languageCode 5-stellig sein (bspw. de-DE)?

Nein, seit dem 01.05.2021 müssen in XZuFi 2-stellige languageCodes geliefert werden.

In welchem Zeichensatz müssen die XZuFi-Daten zur Verfügung gestellt werden?

Der zu verwendende Zeichensatz hängt vom konkreten Datentyp ab. Bitte entnehmen Sie diese Angabe der entsprechenden Spezifikation im xRepository.

Wie geht der Sammlerdienst mit leeren oder unvollständigen Indexdateien um?

Es werden konsistente und dem Sammlerdienst-Konzept genügende XZuFi-Daten erwartet. Bei leeren Indexdateien wird die Verarbeitung abgebrochen. Bei unvollständigen Indexdateien werden die nicht referenzierten XZuFi-Dokumente nicht importiert. Dadurch kann es zu einer unbeabsichtigten Löschung von Geschäftsobjekten kommen.

Wie geht der Sammlerdienst mit Fehlern in der Validierung um?

Fehler bei technischer Validierung: Wenn eine Datei nicht Schema-konform (technisch nicht valide) ist, wird der Import komplett abgebrochen.

Fehler bei fachlicher Validierung: Wenn die Datei den fachlichen Validierungsregeln nicht entspricht, wird lediglich diese eine Datei vom Validator erfasst. Abhängig von der Validierungsregel wird dann ein Hinweis, eine Warnung oder ein Fehler aufgezeichnet. Nur im Falle eines Fehlers wird die Datei abgewiesen.

Die fachliche Validierung eines Dokuments wird nur nach einer erfolgreichen technischen Validierung durchgeführt.

Was ist die häufigste Ursache für einen String.Latin-Fehler beim Validator?

Für XZuFi-Version 2.2:

Bei in Word (oder anderen Textverarbeitungsprogrammen) geschriebenen oder formatierten Inhalten kann es vorkommen, dass bestimmte Zeichen automatisch ersetzt werden, die beim Validieren zu einem String.Latin-Fehler führen können.

Jegliche Inhalte, insbesondere mit Word erstellte, müssen auf String.Latin-Konformität geprüft und ggf. angepasst werden.

Für XZuFi-Version 2.3.1:

In Version 2.3.1 gelten die Zeichenvorgaben gemäß DIN 91379. Je nach Feld kommen unterschiedliche Datentypen (datatypeA - datatypeD) zur Anwendung, die jeweils verschiedene Zeichen erlauben. Prüfen Sie daher für jedes Feld, welcher Datentyp laut Spezifikation gefordert ist, und stellen Sie sicher, dass die Inhalte ausschließlich die für diesen Datentyp erlaubten Zeichen enthalten. Eine Übersicht der erlaubten Zeichen finden Sie in der DIN 91379 sowie in der XZuFi-Spezifikation.

Auch in Version 2.3.1 können automatisch ersetzte Sonderzeichen (z. B. aus Textverarbeitungsprogrammen) zu Validierungsfehlern führen, wenn sie nicht im erlaubten Zeichenvorrat enthalten sind.

Was geschieht im Falle eines ConnectionTimeout?

Der Sammlerdienst wiederholt im Falle eines ConnectionTimeout den Verbindungsaufbau 7-mal, bevor der Import abgebrochen wird.

Die Pausen werden dabei zwischen den Versuchen immer länger. Die anfängliche Wartezeit zwischen den Versuchen beträgt 200ms. Danach verfünffacht sich die Wartezeit nach jedem Versuch (200ms, 1.000ms, 5.000ms, 25.000ms, 125.000ms, 300.000ms, 300.000ms).

Die maximale Wartezeit ist jedoch auf 300.000ms, sprich 5 Minuten begrenzt.

Beim Push-Verfahren werden die oben stehenden Pausen nicht durch das PVOG, sondern durch das pushende System durchgeführt.

Benötigen Sie Hilfe?

Bei Fragen und Anregungen zu unseren Diensten und Services wenden Sie sich gerne an unsere Support-Mitarbeiter im Helpdesk.