Allgemeines

Ein wirklicher Austausch eines bereits versendeten Druckauftrages im Sinne des Austauschs der physikalischen Datei beim Empfänger ist prinzipiell nicht möglich.

Stattdessen wird eine Job-Kopie mit einer neuen ID und einer zusätzlichen Referenz auf den auszutauschenden Job angelegt.

Der schematische Ablauf stellt sich dann in etwa so dar:

• Erstellung einer Kopie des auszutauschenden Jobs ohne die Drucktunterlagen-PDF.
• In dieser Job-Kopie wird die eindeutige ID des auszutauschenden Jobs als Referenz in dem neuen Feld AustauschFuerJobId gespeichert.
• Der Versender lädt eine neue Druckunterlage hoch und versendet den Job nach erflogreichem Preflight.
• Dem auszutauschenden Job in der Portal-Datenbank wird eine Referenz auf den neu angelegten Job in dem neuen Feld AusgetauschtDurchJobId gespeichert.

Erweiterungen der Model-Klassen

Den bestehenden Klassen:

• AuftragsUebersicht
• DruckAuftrag
• JobTicket

wurden jeweils zwei optionale Felder:

• AustauschFuerJobId: Zeigt an, dass dieser Job denjenigen mit dieser ID ersetzt.
• AusgetauschtDurchJobId: Zeigt an, dass dieser Job durch denjenigen mit dieser ID ersetzt wurde.

hinzugefügt. Diese Änderungen sind auch in der Service-Definition swagger.json aufgeführt:

Grundsätzlich sollte die Einführung einiger neuer optionaler Felder keine Auwirkungen auf eine bestehende Anwendung haben.
Die Deserialisierung aus dem Json-Format in die Klassen / Objekte der jeweiligen Programmiersprache ignoriert diese Felder in der Regel einfach.

Um allerdings den geänderten Workflow abzubilden, müssen die clientseitig generierten Klassen / Objekte aber entsprechend erweitert werden.

Ein Beispiel für zwei über Referenz-IDs verbundene Jobs könnte in etwa so aussehen:

Erweiterungen der API-Endpunkte

Die erweiterten Model-Klassen führen entsprechend zu geänderten Rückgaben der folgenden Endpunkte:

• /Auftraege/{id}
• /Auftraege/{id}/Ticket.xml
• /Auftraege/{id}/Ticket.json
• /Auftraege/Uebersicht
• /Auftraege/EmpfangsUebersicht
• /Auftraege/NachStatus/{status}