Warten auf Rückmeldung: Unterschied zwischen den Versionen
Stefan (Diskussion | Beiträge) K (Stefan verschob die Seite Quittierung nach Warten auf Rückmeldung: Name des systemtyps hat sich geändert) |
Stefan (Diskussion | Beiträge) K (*→Beschreibung) |
||
Zeile 9: | Zeile 9: | ||
HZ Arbeitsschritt, welcher aus zwei Teilschritten besteht. | HZ Arbeitsschritt, welcher aus zwei Teilschritten besteht. | ||
Dieser Schritt lässt Objekte warten, bis ein Dienstleister ein Signal sendet. Dieses Signal muss über eine REST Schnittstelle kommen. | |||
Es muss zuerst eine Statusmeldung für ein extern in Bearbeitung befindliches Objekt empfangen werden, bevor das Objekt, welches sich zu diesem Zeitpunkt genau an diesem Quittierungs-Schritt befinden muss, im Prozess weiterläuft. | Es muss zuerst eine Statusmeldung für ein extern in Bearbeitung befindliches Objekt empfangen werden, bevor das Objekt, welches sich zu diesem Zeitpunkt genau an diesem Quittierungs-Schritt befinden muss, im Prozess weiterläuft. | ||
Bsp.: | Bsp.: | ||
An einem ersten Schritt werden Objekte zu einem Dienstleister hochgeladen, welche dort bearbeitet werden. z.B. Metadaten ermitteln. Bevor die Metadaten empfangen | An einem ersten Schritt werden Objekte zu einem Dienstleister hochgeladen, welche dort bearbeitet werden. z.B. Metadaten ermitteln. Bevor der Helper die Metadaten vom externen Dienstleister empfangen kann, wird ein Bearbeitungsstatus welcher den Fortschritt der Bearbeitung benötigt um die Objekte für das abholen der Daten frei zu geben. | ||
==Technische Funktionsweise== | ==Technische Funktionsweise== |
Version vom 13. September 2023, 09:54 Uhr
- Mantiseinträge
3223
- Systemtyp
70
- Eintrittsinvarianz
- NEIN
Beschreibung
HZ Arbeitsschritt, welcher aus zwei Teilschritten besteht. Dieser Schritt lässt Objekte warten, bis ein Dienstleister ein Signal sendet. Dieses Signal muss über eine REST Schnittstelle kommen. Es muss zuerst eine Statusmeldung für ein extern in Bearbeitung befindliches Objekt empfangen werden, bevor das Objekt, welches sich zu diesem Zeitpunkt genau an diesem Quittierungs-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 der Helper die Metadaten vom externen Dienstleister empfangen kann, wird ein Bearbeitungsstatus welcher den Fortschritt der Bearbeitung 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 Workflow
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.
Webhook Konfiguration bei Parashift
Auf der linken Seite im Menü die Webhooks anwählen um die Liste der eingerichteten Hook anzuzeigen oder um einen neuen zu Erstellen. Für einen neuen Hook oben rechts auf "+ NEW", um einen bestehenden zu editieren auf das Bleistiftsymbol rechts neben einem aufgelisteten Hook klicken.
- Einen eindeutig dem Arbeitschritt zuordbaren "Webhook Name" angeben
- Die "Webhook URL" aus der zuvor erstellen Konfiguration eingeben
- Ein neues Header Feld mit dem "Name"="authorization" erstellen, falls nicht bereits vorgeschlagen
- Das zuvor erstellte Token in das "Value" Feld neben "authorization" einfügen
- Bei den Topics den gewünschten Workflowschritt für die Statusmeldung auswählen