Warten auf Rückmeldung: Unterschied zwischen den Versionen

Aus Helper
Zur Navigation springen Zur Suche springen
KKeine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
Work in progress..
;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.
 
 




[[Kategorie:Workflowschritt]]
[[Kategorie:Workflowschritt]]

Version vom 6. September 2023, 13:43 Uhr

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.