Prozesse

WebSocket-Aktion

In der WebSocket-Aktion gibt es eine neue Checkbox "Nachricht nach dem Transaktions-Commit senden". Wenn die Checkbox aktiviert ist, wird die erstellte Nachricht erst gesendet, wenn die aktuelle Transaktion abgeschlossen ist.

REST-Call-Action

Beschreibung

Zielsetzung

Mit Hilfe von REST-Call-Aktionen innerhalb von Prozessen können Sie REST-API-Calls automatisch bzw. eventgesteuert absetzen.

Je nachdem, welche Endpunkte die entsprechende REST-API zur Verfügung stellt, können umfangreiche "Aufgaben" nahezu automatisch oder "auf Knopfdruck" erledigt werden.

Die Rest-Call Aktion ist im Prozessmanager im Bereich "Aktionen" verfügbar.

REST-CALL Aktion ausführen

Folgende Schritte sind für die Ausführung eines REST-CALLs nötig:

Allgemein

In den allgemeinen Eigenschaften werden Alias, Titel und Beschreibung der Aktion definiert.

 

 

Bei den Verbindungseinstellungen können folgende Aktionen aktiviert werden:

 

Request und Response loggen

Wenn Sie diese Option aktivieren, wird der Request unmittelbar vor dem Versenden und die Response direkt nach dem Empfang geloggt. Die Option dient hauptsächlich dem Debuggen des Requests und sollte im Produktivbetrieb abgeschaltet werden, da die Logdatei sonst extrem umfangreich werden kann.

 

JSON parsen

 

Wenn Sie diese Option aktivieren, wird der Payload der Response generell als JSON geparst.

 

Wenn der Payload erfolgreich als JSON geparst werden kann, wird das geparste JSON-Objekt an den REST-Call angehängt und steht ab dann im Shared State zur Verfügung.

 

Wenn der Payload nicht erfolgreich als JSON geparst werden kann, wird eine Meldung in die Logdatei geschrieben (Property: parseJson). In diesem Fall steht dann kein JSON-Objekt zur Verfügung.

 

Hostnamen verifizieren

Wenn Sie diese Option aktivieren, prüft der REST-API-Client, ob eine Verbindung mit dem korrekten Host hergestellt werden kann. Wenn der Host nicht verifiziert werden kann, wird die Verbindung abgelehnt und der Call scheitert (Property: hostnameVerification).

 

Allen Zertifikaten vertrauen

Wenn Sie diese Option aktivieren, wird eine https-Verbindung aufgebaut. Es findet aber keine Prüfung des Zertifikates statt.

 

Das Aktivieren dieser Option bietet sich für Entwicklungsumgebungen an, so dass Sie mit selbstsignierten Zertifikaten arbeiten können. Generell kann es sich in einer Entwicklungsumgebung anbieten, dass der REST-API-Client allen Zertifikaten vertraut (Property: trustAllCertificates).

 

Timeout (in Sekunden)

Hier können Sie die Zeit in Sekunden angeben, die der REST-API-Client auf den Aufbau einer Response wartet, beziehungsweise die Dauer, bis der REST-API-Client die Verbindung abbricht, wenn eine Response ausbleibt oder abreißt. Der Standard-Wert ist mit 30 Sekunden vorbelegt (Property: timeout).

 

Authentifizierung

In diesem Schritt wird die Authentifizierung festlegen. Für die Authentifizierung stehen die folgenden Möglichkeiten zur Verfügung:

Keine/Benutzerdefiniert

Mit diesem Typ steht die Option "Client für Session-basierte Interaktion wiederverwenden" zur Verfügung.

 

Das Aktivieren dieser Option bietet sich insbesondere im Zusammenhang mit dem Login an einer API an und wenn die API Session-Cookies vergibt. Diese kann der REST-API-Client vorhalten und in späteren REST-Call-Aktionen innerhalb desselben Prozesses wiederverwenden.

 

Hintergrund Intrexx verwendet den "Apache HTTP Client 5" als REST-API-Client. Dieser wird bei jeder REST-Call-Aktion generiert und nach deren Ausführung gelöscht. Das Löschen des REST-API-Clients können Sie mit der Option "Client für session-based Requests wiederverwenden" unterbinden. In diesem Fall wird der Client in einer Intrexx-internen Registry abgelegt. Bei weiteren REST-Call-Aktionen innerhalb desselben Prozesses sucht Intrexx in der Registry, ob ein passend konfigurierter Client bereits vorliegt. Wenn dies der Fall ist, verwendet Intrexx automatisch diesen Client.

 

Da der Client Session-Cookies speichert und ausliefert, bleibt so ein Login bis zum Ende des jeweiligen Prozesses gültig.

 

Wenn ein Client wiederverwendet wird, wird dies in der Log-Datei mit "Getting retained Client ..." angezeigt.

 

 

Basic Authentication

Verwenden Sie den Typ "Basic Authentication", wenn die API eine Basic Authentication erwartet.

 

Benutzername

Sie können den Benutzernamen frei eingeben oder aus dem Ressource-Mapping beziehen oder beides kombinieren.

 

Passwort

Sie können das Passwort frei eingeben, aus dem Anmeldeinformationsspeicher (Anmeldeinformationsspeicher) oder über das Ressource-Mapping beziehen.

 

Optional kann ein Header konfiguriert werden.

Im Header können Sie beliebige Einträge (Key/Value-Paare) hinzufügen.

 

API-Key

Verwenden Sie den Typ "API-Key", wenn die API einen API-Key und den dazugehörigen Informationen erwartet.

Token

 

Der Token bzw. API-Key kann frei eingegeben werden, aus dem Ressource-Mapping bezogen werden oder eine Kombination aus beidem sein.

 

Authorization Header

 

Hier können Sie auswählen, welcher Header für den API-Key verwendet werden soll. Die folgenden Optionen stehen zur Verfügung:

 

Authorization: Apikey

 

X-API-Key

Bei den Optionen "Authorization: Apikey" und "X-API-Key" wird die gewählte Option in der Tabelle im Bereich "Header" angezeigt und der Token wird automatisch eingefügt. Der erstellte Eintrag kann nicht manuell aus der Tabelle im Bereich Header gelöscht werden. Beim Absetzen des REST-Calls wird der entsprechende Header generiert.

 

Benutzerdefiniert

Wenn Sie die Option "Benutzerdefiniert" wählen, müssen Sie den Header selbst erstellen.

 

Bearer Token

Verwenden Sie den Typ "Bearer Token", wenn der REST-Call eine Authentifizierung mit einem Bearer Token erfordert.

 

Token

Der Token kann frei eingegeben werden, aus dem Ressource-Mapping bezogen werden oder eine Kombination aus beidem sein.

 

Bei dieser Option wird immer ein Eintrag mit dem Key BEARER_TOKEN in die Header-Tabelle eingetragen. Dieser Eintrag kann nicht manuell aus der Header-Tabelle gelöscht werden. Beim Absetzen des Calls nutzt der REST-API-Client den Header Authorization: Bearer.

Header

Bei allen Typen kann ein Header definiert werden.

Dazu werden in die Header-Tabelle die Header für den Request eingetragen. Im Default-Betrieb werden die Header vom Apache Client selbstständig generiert, sodass in den meisten Fällen keine eigenen Header geschrieben werden müssen. Falls dennoch Header benötigt werden (z.B. für eine selbst angelegte Authentifizierung), müssen Sie die Header-Einträge als Key/Value-Paare eingeben. Werden im Dialog Header gesetzt, überschreiben sie Default-Header mit dem gleichen Key. Das Ressource-Mapping wird sowohl auf die Keys als auch auf die Values der Header angewendet, es sind also dynamische Header möglich. Ein typischer Anwendungsfall wäre, einen dynamisch generierten Token in einen Header zu legen (sofern das nicht mit den Optionen API-Key oder Bearer Token ohnehin schon abgedeckt ist).

 

Request erfassen

In diesem Schritt müssen Sie Angaben zur API-Ressource machen und die Query-Parameter über Key/Value-Paare erfassen.

 

Methode

Wählen Sie hier das HTTP-Verb bzw. die HTTP-Methode, die für den REST-Call verwendet werden soll.

Folgende Methoden können Sie auswählen:

 

• GET

• POST

• PATCH

• PUT

• DELETE

Schema

Legen Sie hier fest, ob der REST-Call eine HTTP oder HTTPS-Verbindung nutzen soll.

Wenn als Verbindung ausgewählt wird, muss ein geeignetes Zertifikat im Intrexx-Zertifikatsspeicher hinterlegt sein.

 

Die Option "Hostname verifizieren" auf der Registerkarte "Allgemein" muss deaktiviert sein und die Option "Allen Zertifikaten vertrauen" auf der Registerkarte "Allgemein" muss aktiviert sein. Wenn dies nicht der Fall ist, dann wird der REST-Call abgebrochen.

 

Wenn als Verbindung ausgewählt wurde, wird in der Log-Datei eine Warnung ausgegeben, da Login-Credentials, Keys usw. dann im Klartext bzw. nur unzureichend obfuskiert sind.

Port

Port der API des Host-Systems werden erfasst:

Wird kein Wert eingeben, werden folgende Default-Werte verwendet:

 

Port 443 (bei HTTPS)

Port 80 (bei HTTP)

 

Hostname

Hostnamen der API wird erfasst.

Wird der Hostname ohne die Angabe von "http://" oder "https://" und ohne die Angabe von Pfad- und Query-Parametern hinterlegt.

 

Der Hostname kann direkt eingegeben werden, per Key aus dem Ressource-Mapping bezogen oder aus beidem kombiniert werden. Es sind also Host möglich wie z.B.:

statisch:

dynamisch:

Kombination:

 

Pfad

Der Pfad zur gewünschten API-Ressource wird erfasst.

Der Pfad bezeichnet bei einer REST-API die gewünschte Ressource. Sie könnte in einem fiktiven CSM für die Rechnung für April 2024 eines Kunden mit der Nummer 12345 beispielsweise sein:

/api/customers/12345/bills/2024/4 oder für ein Profilbild:

/user/54321/profila/image usw.

 

Der Pfad kann direkt eingegeben werden, aus dem Mapping bezogen werden oder (was wahrscheinlich der häufigste Fall sein wird) aus beidem kombiniert werden, z.B. als

/api/customers/${customerID}/bills/${year}/${month},

wobei ${customerID}, ${year} und ${month}

dann je nach Kunde zur Ausführungszeit gefüllt werden können. Keys können an allen Stellen auch mehrfach verwendet werden.

Download-Dateiname (optional)

Dateinamen kann hinterlegt werden, falls der REST-Call einen Datei-Download auslöst.

Die Datei wird nach dem Download unter dem hier hinterlegten Namen in einem temporären Verzeichnis abgelegt, das für die Dauer der Prozess-Ausführung besteht und danach wieder gelöscht wird. Das Verzeichnis ist über das Groovy-Objekt erreichbar. Im Verarbeitungskontextobjekt des REST-Calls steht unter der absolute Pfad als String zur Verfügung.

 

Wenn Sie keinen Dateinamen erfassen, durchsucht der REST-Call den Content-Disposition-Header der Response und prüft, ob dort gegebenenfalls ein Dateiname angegeben ist. Wenn kein Dateiname gefunden wird, dann wird der Name "download" als Default verwendet.

 

Query-Parameter

Ein Query-Parameter kann hinzuzufügt werden.

Über das Plus-Symbol können Key und Wert hinterlegt werden.

 

Der Wert kann wie folgt erfasst werden:

Manuell

Ressource-mapping

Manuell + Ressource-mapping

 

Die Query-Parameter werden im generierten REST-Call hinter dem Pfad mit einem "?" getrennt angehängt, wobei Key und Value mit "=" verbunden und die Paare mit "&" getrennt werden.

 

Body erstellen

In diesem Schritt wird der Body (Payload) festgelegt. Die folgenden Auswahlen stehen zur Verfügung.

Keiner

Es wird an den Request keine Payload angefügt.

 

Text

In einem Textfeld wird die Payload als einfacher Text erfassen.

 

Über das Ressource-Mapping-Symbol können Ressourcen hinzugefügt werden.

Folgende Ressourcenkönnen gewählt werden.

 

Statischer Text

Request

Session

Verarbeitungskontext

Datengruppe

Systemdatengruppe

Benutzerwert

Vorgehergehender Request

Anmeldeinformationsspeicher

 

JSON

In einem Textfeld wird die Payload als einfacher Text erfasst. Dabei wird der Text als JSON (application/json) an den Request angehängt.

 

Beachten Sie, dass der Text nicht als JSON validiert wird. Das JSON wird erst beim Absenden des Requests konstruiert und ist erst dann semantisch gültig.

 

Über das Ressource-Mapping-Symbol können Ressourcen hinzugefügt werden.

Datei

Eine Datei kann hochgeladen und an den Request angehängt werden. Dabei muss der Link zu der entsprechenden Datei über das Plus-Symbol erfasst werden.

 

Intrexx versucht dabei, anhand der Dateiendung den korrekten Content-Type-Header zu setzen. Falls dies nicht möglich ist, wird "Application/octet-stream" benutzt, um einen allgemeinen Upload zu signalisieren.

 

Beim Erfassen der Datei stehen die folgenden Ressourcen zur Verfügung:

 

Statischer Text

Request

Session

Verarbeitungskontext

Datengruppe

Vorheriger Request

Ausnahmebehandlungen

Ausnahmebehandlung können erst nach dem Anlegen der REST-Call-Aktion bearbeitet werden.

Folgende Optionen können gewählt werden:

Transaktion abbrechen (Standard)

Transaktion fortsetzen

 

 

 

Expert-Attribute ansehen oder erfassen

Expert-Attribute können erst nach dem Anlegen der REST-Call-Aktion bearbeitet werden.

Im Reiter "Expert" können alle Properties manuell gesetzt werden. Hierbei können Sie auch Keys aus dem Ressource-Mapping verwenden.

 

Eine Tabelle aller verfügbaren Properties finden Sie in der Online-Hilfe.

 

Praxisübung: Automatisierter Applikationsexport

Aufgabenbeschreibung

Das Verteilen neuer Applikationen in unterschiedliche Portale eines Servers soll vereinfacht werden. Dabei sollen in einem (Test-)Portal Applikationen bereitgestellt werden, die dann in unterschiedliche Produktivportale importiert werden.

Voraussetzung

Für die Umsetzung dieses Procederes benötigen wir:

Eine Konfiguration der Administration API (IAA) des Zielsystems

Eine Administration API-Lizenz

Eine Applikation, in der die Applikationsexporte für den Import in andere Portale hinterlegt werden.

Die Information des IAA-Passworts. Dieses hinterlegen wir im Credential Store.

Ein Prozess mit einem REST-API-Call, der die Applikationen in die hinterlegten Portale importiert.

Konfiguration Administration API

Port, Username und Passwort sowie ein Zertifikat müssen konfiguriert sein.

Import der Applikation

Importieren Sie aus der mitgelieferten Datei "import-applikationen.zip" die Applikation "Import von Applikationen".

Übersicht der Aufgaben

Zunächst wird im Credential-Store einmalig die IAA-Authentifizierung des Zielservers hinterlegt.

Für jede Applikation wird ein Datensatz angelegt, in dem Applikationsexport, Aktion sowie Host, Port und Portalname des Zielsystems.

 

 

Im Prozess müssen wir eine IAA-Authentifizierung durchführen. Die Anmeldedaten dazu werden wir über ein Groovy-Skript in den Verarbeitungskontext schreiben.

Jetzt erfolgt die IAA-Anmeldung über die REST-Call Action. Die Daten werden aus dem Verarbeitungskontext gelesen.

Im nächsten Schritt wird der Applikations-Upload auf dem Zielsystem vorbereitet. Die Daten des Zielsystems schreiben wir über ein Groovy-Skript in den Verarbeitungskontext.

Jetzt wird in einer weiteren REST-Call Aktion der Upload der Applikation im hinterlegten Zielsystem gestartet. Die Daten werden aus dem Verarbeitungskontext gelesen, der Token zur Anmeldung wird aus dem vorhergehenden Request verwendet.

IAA-Passwort im Credential Store speichern

Für die IAA-Authentifizierung muss einmalig das IAA-Passwort im Credential Store gespeichert werden.

 

Wechseln Sie in das Modul „Integration“. In der "Verbindungsdatenverwaltung" befindet sich der Anmeldeinformationsspeicher (Credential Store).

Erzeugen Sie einen neuen Eintrag und hinterlegen folgende Informationen:

 

Anmeldeinformationsname: iaaPassword

Passwort: [tragen Sie Ihr Passwort ein]

Applikation für den Import bereitstellen

Für die Bereitstellung von Applikationen in anderen Portalen erstellen wir in der Applikation "Import von Applikationen" alle nötigen Quelldaten.

In einem Datensatz werden je Applikation folgende Informationen hinterlegt:

 

Titel

Exportdatei der Applikation

Aktion: keine Aktion / Upload erstmalig/ Update

Server Zielsystem

IAA Portal

IAA Port

IAA User

 

Beim Speichern des Datensatzes triggern wir den Prozess. Wir erfassen den Datensatz also noch nicht jetzt, sondern erst nach Fertigstellung unseres Prozesses

Prozess erstellen

Wir werden nun wir den Prozess erstellen, der beim Speichern des Datensatzes startet.

Erstellen Sie einen neuen Prozess mit dem Titel "Import Applikationen".

DG-Ereignisbehandler

Der Prozess startet, wenn ein Datensatz in der Applikation "Import von Applikationen" gespeichert wird.

Fügen Sie im Prozess einen Datengruppen-Ereignisbehandler hinzu und öffnen mit einem Doppelklick den Eigenschaften-Dialog.

Der Ereignisbehandler soll auf das Einfügen neuer und Ändern bestehender Datensätze regieren.

 

Hinterlegen Sie die folgende Konfiguration:

 

Titel: "Import Applikationen"

Applikation: "Import von Applikationen"

Datengruppe: "Applikationen"

 

Der Ereignisbehandler soll beim Einfügen und Ändern von Daten reagieren.

Groovy-Aktion: Verarbeitungskontext schreiben

Im nächsten Schritt stellen wir die Daten für die Anmeldung an der Administration API bereit. Diese werden wir in den Verarbeitungskontext schreiben.

 

Fügen Sie dem Datengruppen-Ereignisbehandler eine Groovy-Aktion mit dem Titel "Werte setzen" hinzu. Wechseln Sie mit einem Doppelklick in die Eigenschaften, benennen die Aktion um in "Werte setzen" und öffnen dort den Skript-Editor.

Wir benötigen für die Anmeldung via Administration API folgende Informationen:

 

remoteHost

iaaPort

iaaPortal

iaaUser

 

Im angezeigten Skript werden alle Informationen aus dem Datensatz gelesen und in den Verarbeitungskontext geschrieben.

 

Das IAA-Passwort ist im Credential Store gespeichert und wird später daraus ermittelt.

Kopieren Sie das Skript in den Skript-Editor. Markieren Sie die Guid und aktualisieren diese über die Applikationsstruktur. Fügen Sie die Guid der entsprechenden Felder über das Plus-Symbol hinter der Guid ein.

// Zugangsdaten in Verarbeitungskontext schreiben

// IAA-Passwort wird aus dem Credential Store geholt ("iaaPassword")

 

g_sharedState["remoteHost"] =  g_record["[GUID]"].value /* datafield Server Zielsystem <string> */

g_sharedState["iaaPort"] = g_record["[GUID]"].].value /* datafield IAA Port <integer> */

g_sharedState["iaaPortal"] = g_record["[GUID]"].value /* datafield IAA Portal <string> */

g_sharedState["iaaUser"] = g_record["[GUID]"].value /* datafield IAA User <string> */

REST-Call-Aktion: login

Jetzt können wir über uns über die REST-Call Aktion an der Administration API anmelden. Als Rückgabe werden wir ein Token erhalten, das wir später benötigen.

Fügen Sie dem Groovy-Skript eine REST-Call-Aktion hinzu.

 

Öffnen Sie die Eigenschaften der REST-Call Aktion mit einem Doppelklick.

Hinterlegen Sie zunächst Allgemeine Informationen:

 

Alias: "login"

Titel: "REST-Call Aktion"

 

Aktivieren Sie die Verbindungseinstellungen

 

Request und Response loggen

JSON parsen

Allen Zertifikaten vertrauen

 

Hinterlegen Sie ein Timeout von 30 Sekunden.

Klicken Sie auf "Weiter".

 

Wählen Sie den Authentifizierungstyp "Keine / Benutzerdefiniert".

 

Klicken Sie auf das Plus-Symbol, um einen neuen Eintrag im Header zu hinterlegen.

Der Header-Eintrag enthält folgende Information:

 

Key: Content-Type

Wert: application/json

 

Übernehmen Sie den Dialog mit "OK" und klicken dann auf "Weiter".

 

In diesem Dialog wird der Request definiert. Wir werden die benötigten Daten zunächst aus Verarbeitungskontext bzw. Credential Store in das Ressource-Mapping schreiben.

 

Klicken Sie auf das Symbol für Ressource Mapping am rechten Rand.

 

Im Ressource-Mapping klicken Sie auf das Plus-Symbol, um neue Keys hinzuzufügen.

Fügen Sie dem Ressourcen-Mapping folgenden Keys hinzuzufügen:

 

Der Key "host" erhält aus dem "Verarbeitungskontext" den Wert "remoteHost"

Der Key "port" erhält aus dem "Verarbeitungskontext" den Wert "iaaPort"

Der Key "portal" erhält aus dem "Verarbeitungskontext" den Wert "iaaPortal"

Der Key "iaaUser" erhält aus dem "Verarbeitungskontext" den Wert "iaaUser"

Der Key "iaaPassword" erhält aus dem "Anmeldeinformationsspeicher" den Wert "iaaPassword"

 

Übernehmen Sie anschließend das Ressource Mapping mit "OK".

 

Jetzt füllen wir den Request mit Werten:

 

Methode: POST

Schema: https

 

Ob http oder https verwendet werden muss, ist im cfg-file der Administration API hinterlegt.

<Installationsverzeichnis>/admin-api/cfg/admin-api.yaml

 

Wählen Sie die folgenden Werte über das Ressource-Mapping:

Port (optional):

Hostname:

 

Der Endpunkt zum IAA-Login enthält keine variablen Bestandteile, daher kann er direkt fest eingetragen werden.

 

Pfad: auth

 

Beachten Sie bitte, dass auf unseren Schulungsportalen in der Cloud ein NGINX verwendet wird. Durch unsere NGINX-Konfiguration muss dort die Eingabe wie folgt aussehen:

 

Port: bleibt leer

Pfad: iaa/auth

 

Klicken Sie auf "Weiter"

 

Im Body wählen wir zunächst den Body-Typ JSON.

 

Informationen zu "name" und "password" werden benötigt.

 

Klicken Sie auf das das Ressource-Mapping-Symbol und hinterlegen Sie die Keys "iaaUser" und "iaaPassword".

 

{

  "name": "${iaaUser}",

  "password": "${iaaPassword}"

}

 

Die Konfiguration ist damit abgeschlossen. Beenden Sie die REST-Call Aktion mit "OK".

Groovy-Bedingung: Ausgänge definieren

Bevor wir den Import der Applikation starten, müssen wir die Transaktionsart prüfen.

Wir müssen unterscheiden, ob die Applikation importiert werden soll (der entsprechende Endpunkt verwendet de Methode POST) oder ob ein Update einer bestehenden Applikation gemacht werden soll (Methode PATCH).

Fügen Sie der REST-Call Aktion eine Groovy-Bedingung hinzu.

 

Wechseln Sie mit einem Doppelklick in die Eigenschaften der Bedingung und öffnen dort den Skript-Editor.

Hinterlegen Sie im Skript-Editor das nachfolgende Skript.

 

Im Skript wird zunächst die im Datenfeld "Aktion" hinterlegte Aktion ausgelesen und in die Variablen transAktion geschrieben. Das Datenfeld wird über das Kontextmenü gewählt.

 

Folgende Werte werden bei Wahl einer Aktion hinterlegt:

 

Upload (einmalig): 2

Update: 3

Je nach gewählter Transaktion werden unterschiedliche Rückgaben per Return-Wert übergeben.

 

Wert: 1

return: noAction

Wert: 2

return: upload_first und always

Wert: 3:

return: update und always

 

Beachten Sie, dass mehrere Rückgaben in eckigen Klammern und durch Komma getrennt hinterlegt werden müssen.

 

 

def transAktion = g_record[""].value /* datafield Aktion <integer> */

 

switch (transAktion)

{

    case "1":

        return noAction

    case "2":

        return [upload_first,always]

    case "3":

        return [update,always]

    default:

        return noAction

}

Ausgang "upload_first”

Fügen Sie der Groovy-Bedingung eine REST-Call Aktion hinzu. Hinterlegen Sie die Verbindungs-ID "upload_first" und übernehmen den Dialog mit "OK".

 

Wechseln Sie mit einem Doppelklick in den Eigenschaftendialog der REST-Call Aktion.

 

Im Reiter "Allgemein" hinterlegen Sie zunächst Allgemeine Informationen:

Alias: uploadFirst

Titel: REST-Call Aktion

 

Aktivieren Sie die folgenden Verbindungseinstellungen:

 

Request und Response loggen

JSON parsen

Allen Zertifikaten vertrauen

 

Ein Timeout von 90 Sekunden wird hinterlegt.

 

Klicken Sie auf "Weiter"

 

Authentifizierung und Header

Wählen Sie den Authentifizierungs-Typ "Bearer Token".

 

Für die Authentifizierung benötigen wir den Token, der uns als Antwort auf den vorhergegangenen Login-Request geschickt wurde.

 

Klicken Sie auf das "Ressource Mapping" aufbauen:

 

 

Fügen Sie dem Ressourcen-Mapping folgenden Keys hinzuzufügen:

 

Der Key "host" erhält aus dem "Verarbeitungskontext" den Wert "remoteHost"

Der Key "port" erhält aus dem "Verarbeitungskontext" den Wert "iaaPort"

Der Key "portal" erhält aus dem "Verarbeitungskontext" den Wert "iaaportal"

Der Key "token" erhält seinen Wert aus dem "Vorherigen Request". Hinterlegen Sie den Alias die REST-Call-Aktion "login". Der Qualifier ist "Text" (der Token wird von der IAA als Plaintext geschickt).

 

Übernehmen Sie anschließend den Dialog mit "OK".

 

Wählen Sie im Feld "Token" den Key "token".

 

Der Header setzt sich aus den vorherigen Einträgen automatisch zusammen.

 

Klicken Sie auf "Weiter".

 

Request

Hinterlegen Sie folgenden Request:

 

Methode: Post

Schema: https

 

Wählen Sie aus dem Ressource-Mapping folgende Informationen:

 

Port:

Hostname:

Pfad:

 

Der Pfad ist im Endpunkt definiert.

Wenn Sie auf unseren Schulungsportalen in der Cloud arbeiten, hinterlegen sie bitte folgende Konfiguration:

 

Port: bleibt leer

Pfad: iaa/

 

Klicken Sie auf "Weiter"

 

Im Body wählen wir zunächst den Body-Typ "Multipart/form-data", da für einen Import neben dem eigentlichen zip der Applikation auch ein JSON mit Einstellungen geschickt werden muss.

 

Erstellen Sie über das Plus-Symbol einen neuen Body:

 

 

Hinterlegen Sie den folgenden Body:

Body-Typ: JSON

Body:

{

  "permissions":false

}

Übernehmen Sie den Dialog mit "OK".

 

 

Erstellen Sie einen zweiten Body.

 

Body-Typ: Datei

Body: Wählen Sie das Datenfeld, in dem die Datei gespeichert ist.

 

Die Konfiguration ist damit abgeschlossen. Beenden Sie die REST-Call Aktion mit "OK".

Ausgang "always"

Wir erstellen nun den Ausgang "always". In diesem Ausgang werden wir eine Datengruppen-Aktion hinterlegten, die jeweils nach den Ausgängen upload_first“ und "update" ausgeführt werden soll.

Ziel hierbei ist es, die in der Applikation hinterlegten Transaktionen auf die Aktion "keine Aktion" zurückzusetzen und so unbeabsichtigte Importe zu vermeiden.

Fügen Sie der Groovy-Bedingung eine Datengruppenaktion hinzu. Hinterlegen Sie die Verbindungs-ID "always".

 

In den Eigenschaften der Datengruppenaktion hinterlegen Sie die folgenden Eigenschaften:

 

Titel: Aktion in App zurücksetzen

Aktion: Datensatz ändern

 

Klicken Sie auf "Weiter".

 

Wählen Sie die Zieldatengruppe.

 

Applikation: Import von Applikationen

Datengruppe: Applikationen

Manipulationsmenge

 

Einfacher Filter:

Ziel-DG:

Gleich

Quell-DG:

Um im Datenfeld "Aktion" den Eintrag "Keine Aktion" zu hinterlegen, muss der Wert "1" im Datenfeld gespeichert werden.

Feldzuordnung

Erzeugen Sie über das Zahnrad-Symbol einen "Benutzerdefinierten Wert".

Wählen Sie die Option "Statischer Wert" und klicken auf das Stift-Symbol.

 

Hinterlegen Sie den Datentyp Zeichen und den Wert "1". Übernehmen Sie beide Dialoge mit "OK".

Weisen Sie den festen Wert "1" auf der rechten Seite dem Datenfeld "Aktion" auf der linken Seite zu.

 

Übernehmen Sie den Dialog mit "OK".

Ausgang "update”

Im Ausgang update werden wir ebenfalls eine REST-Call Aktion erstellen. Da diese großen Überschneidungen mit dem uplod_first-Ausgang hat, erstellen wir eine Kopie unseres ersten Ausgangs und bearbeiten diese.

Fügen Sie der Groovy-Bedingung die kopierte REST-Call Aktion aus dem upload_fist-Ausgang hinzu.

 

Hinterlegen Sie die Verbindungs-ID "update" und übernehmen den Dialog mit "OK".

 

Wechseln Sie mit einem Doppelklick in den Eigenschaftendialog der REST-Call Aktion.

 

Zunächst werden Allgemeine Informationen hinterlegt:

 

Alias: update

Titel: REST-Call Aktion

 

Aktivieren Sie die folgenden Verbindungseinstellungen:

 

Request und Response loggen

JSON parsen

Allen Zertifikaten vertrauen

 

Ein Timeout von 90 Sekunden wird hinterlegt.

 

Im Reiter "Authentifizierung und Header" übernehmen die kopierten Werte:

 

Typ: Bearer Token

Token: ${token}

 

Header

Key: Authorization

Wert: Bearer ${token}

 

Im Reiter "Request" ändern wir zunächst die Methode:

 

Methode: Patch

 

Die verbleibenden hinterlegen Requestwerte bestätigen wir:

 

Schema: https

Port:

Hostname: ${host}

Pfad:

 

Wenn Sie auf unseren Schulungsportalen in der Cloud arbeiten, hinterlegen sie bitte folgende Konfiguration:

 

Port: bleibt leer

Pfad: iaa/

 

Im Body übernehmen wir den Body-Typ "Multipart/form-data".

 

Der definierte Body JSON sowie die Auswahl der Datei aus der Datengruppe bleiben an dieser Stelle unverändert.

Die Konfiguration ist damit abgeschlossen. Beenden Sie die REST-Call Aktion mit "OK".

Ausgang "noAction"

Für den letzten Ausgang “noAction“ fügen wir der Groovy-Bedingung die Aktion "Prozess beenden" an.

Hinterlegen Sie die Verbindungs-ID "noAction" und bestätigen mit "OK".

 

 

In den Eigenschaften der Aktion hinterlegen wir, dass alle Zweige der Ereignisbehandlung beendet werden.

 

Übernehmen Sie die Einstellung mit "OK".

Speichern Sie den Prozess. Öffnen Sie anschließend ihre Applikation im Browser. Erstellen Sie einen neuen Datensatz und hinterlegen dort die Daten des Zielsystems sowie die Applikationsdatei. Beim Speichern des Datensatzes triggern Sie den Prozess und die Applikation wird im Zielsystem erfasst.

Neue Javaklasse in Prozessen

In der "Generischen Bedingung" kann eine neue Javaklasse angeboten, die clusterweit einen Lock über den Lock-Service setzt und gibt ihn am Ende der Transaktion wieder frei gibt.

Es handelt sich um die Klasse .

TransactedAcquireLockWorkflowCondition.

Bedingung mit dieser Klasse können verwendet werden, um in Prozessen Application-API-Requests von anderen zu unterscheiden.

 

Drei mögliche Ausgänge können definiert werden:

 

transitionAlways

transitionFalse

transitionTrue

 

Sie hat drei mögliche Ausgänge, die standardmäßig mit "true", "false" und "always" benannt sind. Die Namen können im Dialog geändert werden. Mindestens ein Ausgang muss definiert werden. Maximal drei Ausgänge dürfen bei der Bedingung definiert werden.

Liegt ein Application-API-Request vor, wird zuerst der True-Ausgang und dann der Always-Ausgang abgearbeitet.

 

Liegt kein Application-API-Request vor, wird zuerst der False-Ausgang und dann der Always-Ausgang abgearbeitet