Warten auf Rückmeldung

Aus Helper
Version vom 6. September 2023, 14:04 Uhr von Stefan (Diskussion | Beiträge) (3223 - Neue Seite)
Zur Navigation springen Zur Suche springen
Mantiseinträge
 3223
Systemtyp
 70 
Eintrittsinvarianz
NEIN


Beschreibung

HZ Arbeitsschritt, welche aus zwei Teilschritten besteht. Es muss zuerst eine Statusmeldung für ein extern in Bearbeitung befindliches Objekt empfangen werden, bevor dieses Objekt welche sich zu diesem Zeitpunkt genau an diesem Schritt befinden muss, im Prozess weiterläuft.

Bsp.:

An einem ersten Schritt werden Objekte zu einem Dienstleister hochgeladen, welche dort bearbeitet werden. z.B. Metadaten ermitteln. Bevor die Metadaten empfangen werden können, wird ein Bearbeitungsstatus benötigt um die Objekte für das abholen der Daten frei zu geben.


Technische Funktionsweise

Die Gegenstelle muss über eine REST-API einen sogenannten Webhook senden, welcher vom Rest Server im BSB empfangen wird.

In der Nachricht muss das betreffende Objekt eindeutig indentifizerbar angegeben werden. Dies geschieht in der Regel über die ID der Gegenstelle, welche beim Objekt im Helper bereits hinterlegt wurde. Idealerweise verfügt auch die Gegenstelle über die Helper ID des Objektes. Dies wäre in der Regel die Objektnummer (DO_SEQ). Es kann sich aber auch um die DO_SIGNATUR handeln.

Wird nun eine solche Bestätigung empfangen, dann werden die übermittelnden Details der Nachricht in der entsprechenden Quittungstabelle der Datenbank gespeichert.

Der Eigentliche Quittungsjob prüft laufend ob unverarbeitete Quittungen vorliegen und arbeitet diese entsprechend ab. Wird das zugehörige Objekt am richtigen Arbeitsschritt identifiziert, dann wird die Quittung bestätigt und das Objekt zum nächsten konfigurierten Arbeitsschritt gesendet.


Konfiguration

Als erstes muss ein Anbieter ausgewählt werden. Die danach erscheinenden Einstellungen und Optionen können variieren.

Verfügbare Anbieter

Parashift

Konfiguration im Worklow:

Für jede der verfügbaren Statusmeldungen muss ein eigener Arbeitsschritt und ein zugehöriger Webhook bei Parashift erstellt werden. Es darf bei Parashift nur ein Workflowstatus je Webhook ausgewählt werden. Ansonsten laufen mehrere Quittungen zum selben Arbeitsschritt, welcher nicht unterscheiden kann zu welchem Workflowstatus diese nun tatsächlich gehört.

Authorisierungstoken (Eingabefeld) - Das Kennwort welches für die Authorisierung an der REST API verwendet wird. Es sollte am besten eines über den Taster "Token generieren" erstellt werden. Über den darüber liegenden Taster wird das Token in die Zwischenablage kopiert. Das Feld erlaubt die Eingabe eigener Token. Ein Token kann beim selben Anbieter an Unterschiedlichen Arbeitsschritten mehrmals verwendet werden. Das Token muss bei Parashift in der Webhookkonfiguration in ein Header Feld mit dem namen "authorization" eingefügt werden.

WebHook URL (Anzeigefeld) - Die Adresse zu welcher die Meldung gesendet wird, ist Arbeitsschrittspezifisch und muss für jeden Quittungsschritt über den Taster "URL generieren" generiert werden. Die letzten Ziffern lauten immer auf die HZ_SEQ des Schrittes. Über den darüber liegenden Taster wird die URL in die Zwischenablage kopiert. Die URL muss bei Parashift beim Einrichten des Webhooks angegeben werden.