Liste der Standard-Parameter der WIM-Requests:
ACTION(ex. "Action"):- Bei EVENT-Requests wird hier die Art des Ereignisses angegeben. Mehr bei "EVENT-Request-Parameter"
EVENTS(optional):Bei der Anforderung von Daten kann bestimmt werden, dass eine Nachricht über aktualisierte Daten gesendet werden soll. Im EVENTS-Parameter wird der in diesen Fällen zu startende Request notiert.
Das Senden von Benachrichtigungen bei aktualisierten Daten muss explizit "abbestellt" werden. Dazu kann ein neuer Request mit der Angabe
EVENTS=""geschickt werden.FOLLOWUP(optional):Hier kann ein Request angegeben werden, der nach regulärer (= "erfolgreicher") Bearbeitung dieses Request gestartet werden soll.
Kann ein Request erst verzögert bearbeitet werden - weil z. B. erst noch Daten beschafft werden müssen - wird der FOLLOWUP-Request erst später und nach regulärer Bearbeitung des Requests gestartet. Zum Auftraggeber wird eine "Zwischeninformation" mit "delayed"-STATUS gemeldet - falls nicht geblockt.
Konnte dieser Request nicht regulär bearbeitet werden und ist kein spezieller Parameter für die "gescheiterte" Bearbeitung angegeben (
OTHERWISE,WHEN_xxx), wird auch der im FOLLOWUP angegebene Request verwendet.Folgende Standard-Parameter werden automatisch zum Folgerequest kopiert: REF, ...tbd .
FROM(meist automatisch):- Requests werden von einem Modul bzw. Server/WIM-App versendet. Hier wird die Absender-Adresse angegeben. Dieses geschieht in der Regel automatisch.
OTHERWISE(optional):- Analog zu "
FOLLOWUP" kann hier ein Request angegeben werden, der bei nicht regulärer Bearbeitung gestartet werden soll. Fehlt der OTHERWISE-Parameter und ist auch kein passender WHEN_xxx -Parameter angegeben, wird nach nicht regulärer Requestbearbeitung der unter FOLLOWUP angegebene Request gestartet. REF(optional):- Manchmal wird zur Bearbeitung eines Folgerequests Zusatzinformation benötigt. Diese wird beim REF-Parameter eingetragen und automatisch in die Folgerequests übernommen, sodass bei der Request-Antwort gezielt agiert werden kann. Der Parameterwert unterliegt im Prinzip keinen Einschränkungen, da ihn "unterwegs" niemand anschaut und er einfach nur weitergereicht wird. Der Effizienz wegen sollte der Wert jedoch nicht zu lang werden.
TO(obligatorisch):WIM-Requests sollen von einem (anderen) Modul bzw. einem (anderen) Server/WIM-App bearbeitet werden. Hier wird die Adresse des Empfängers eingetragen.
ANmerkung: Bei
CALL- undSEND-Aufrufen miss der Empfänger (derzeit) als separater Parameter angegeben werden. Er wird dann automatisch in den Request eingefügt.WHEN_xxx(optional):Für spezifische Fälle der nicht-regulären Bearbeitung von Requests können spezielle zu aktivierende Requests definiert werden. Das "xxx" in WHEN_xxx steht dabei für den Namen des STATUS der Requestbearbeitung.
Das WHEN_xxx kann auch dazu verwendet werden, das Aktivieren von Requests bei speziellen STATUS-Ergebnissen zu unterdrücken. So wird bei der Angabe von
WHEN_delayed=""eine Benachrichtigung im Fall von Verzögerungen unterdrückt.
Bei speziellen Requests:
RE(verwendet bei Requestweiterleitungen an den Server):Bei Requests, die an ein anderes System (einen anderen Namensraum) gehen, wird vom Sender ein RE-Parameterwert gesetzt, der bei eintreffenden Folgerequests die Weiterleitung im System des Senders ermöglicht.
Alle Requests der WIM-Apps werden vom BACKEND-Modul im RE-Parameter mit einer (direkten oder "verschlüsselten") Kennung des anfordernden Moduls versehen. Bei Folgerequests /Antworten wird der RE-Parameter automatisch wieder angegeben und kann zur Adressierung des ursprünglich anfordernden Moduls verwendet werden.
[[Die obige Liste ist noch sehr unvollständig !
... tbd ... ]]
Requesthandling im WIM-System WIM-App-Verfahren (techn.) Cloud-Server-Verfahren Events im WIM-System Robustheit des openWIM-Systems
