Gültige Operation und Validierungsfehler
Einführung
Vorgänge müssen gültig sein, um bereitgestellt werden zu können. Auf dieser Seite erfahren Sie, wie Sie ungültige Vorgänge identifizieren und die damit verbundenen Validierungsfehler anzeigen können. Außerdem erfahren Sie, wie Sie Validierungsfehler mithilfe eines gültigen Operation beheben können. Außerdem werden Beispiele für gängige Operation bereitgestellt.
Validierungsfehler
In diesem Abschnitt erfahren Sie, wie Sie ungültige Vorgänge identifizieren und die mit ungültigen Vorgängen verbundenen Validierungsfehler anzeigen.
Bei neuen Projekten werden ungültige Elemente standardmäßig auf der Design-Canvas hervorgehoben, mit der Standardauswahl Ungültige Elemente hervorheben. Um diese Option zu deaktivieren, löschen Sie diese Auswahl:
Wenn Ungültige Elemente hervorheben ausgewählt ist, werden alle ungültigen Vorgänge oder Komponenten rot umrandet und haben ein ungültiges Symbol neben ihrem Namen auf der Design-Canvas:
Im Projektbereich, werden die Namen ungültiger Workflows und Komponenten in roter Kursivschrift aufgeführt und mit einem ungültiges Symbol:
Klicken Sie auf das Ungültig-Symbol neben dem Operation, um eine Meldung mit den Validierungsfehlern für die Operation anzuzeigen.
Vorgänge mit einem impliziten Fehler können aus einem der folgenden Gründe ungültig sein:
Fehler | Weitere Informationen |
---|---|
Operation ist leer. | Die Operation muss mindestens einen Operation Schritt haben. |
Der Vorgang entspricht keinem gültigen Muster. Operationsregeln und Muster finden Sie hier. | Der Operation muss etablierten Operation entsprechen, die sicherstellen, dass der Operation vom Agenten unterstützt und erwartet wird. Diese Muster werden als Nächstes unter Validierungsmuster behandelt. |
Das Transformation [Quelle / Ziel] stimmt nicht mit der Schema überein, die von der Aktivität ["Aktivitätsname"] bereitgestellt wird. Öffnen Sie die Transformation ["Transformation "] in der Operation ["Operationsname"] und aktualisieren Sie das Schema. | In einer Operation, die eine Transformation mit einem von der Aktivität bereitgestellten Schema enthält, muss das von der Aktivität bereitgestellte Schema mit der von einer benachbarten Aktivität bereitgestellten Schema übereinstimmen. |
Transformation ["Transformation "] hat ein Schema, aber keine Quellaktivität. Entfernen Sie das Schema aus der Transformation oder fügen Sie vor der Transformation eine Quellaktivität hinzu. | Wenn die Operation eine Transformation mit einer aktivitätsbereitgestellten enthält oder Transformation bereitgestellt Schema muss der Transformation eine Quellaktivität vorausgehen. |
HTTP-Zielaktivitäten, die ihre Antwort an eine zweite Zielaktivität senden, können im gesamten Projekt nur Antworten an eine Zielaktivität senden. Die HTTP-Aktivität ["Ziel 1 Aktivitätsname"] in dieser Operation sendet ihre Antwort an mehrere Zielaktivitäten im gesamten Projekt. In dieser Operation ist ihr Ziel ["Ziel 2A Aktivitätsname"]. In Operation ["Operation 2"] ist ihr Ziel ["Ziel 2B Aktivitätsname"]. Ersetzen Sie die Aktivität ["Ziel 1 Aktivitätsname"] in einer der Operationen durch eine doppelte Aktivität. Sie können dies tun, indem Sie die Aktivität ["Ziel 1 Aktivitätsname"] auf der Registerkarte "Komponenten" suchen, das Menü öffnen und duplizieren. Ziehen Sie die duplizierte Aktivität in die Operation. | In einer Operation, die das Zwei-Ziel-Archivmuster verwendet und enthält eine HTTP-Zielaktivität, die eine Antwort an eine zweite Zielaktivität schreibt, wobei die HTTP-Zielaktivität auch in einem anderen Zwei-Ziel-Archivmuster verwendet wird Operation muss in dieselbe Zielaktivität schreiben. Hinweis Diese Validierungsregel kann deaktiviert werden, dies wird jedoch nicht empfohlen. Weitere Informationen finden Sie unter Fehler bei HTTP-Validierungsregeln am Ende dieser Seite. |
„Operation [„Operationsname“] kann nicht mehr als einen Listener oder eine ereignisbasierte Aktivität haben: [„Aktivitätsnamen“].“ | Eine Operation kann nur eine Listening-Aktivität enthalten pro Operation. |
„Operation [„Operationsname“] hat [„Aktivitätsname“] als Listener oder ereignisbasierte Aktivität - solche Aktivitäten müssen in der Operation am Anfang stehen. | Die Operation muss etablierte Operation für die Listening-Aktivität erfüllen. Die Operation, mit denen jede Höraktivität verwendet werden kann, sind in der Dokumentation für jede Aktivität aufgeführt. |
„Operation [„Operationsname“] kann nicht das Ergebnis [„Bei Erfolg“ / „Bei Fehler“ / „Bei SOAP Fehler“] für eine Operation [„Operationsname 2“] haben, die einen Listener oder eine ereignisbasierte Aktivität als erste Aktivität hat.“ | Eine Operation kann keine Operation verwenden, um eine andere Operation aufzurufen, die eine Abhöraktivität enthält. |
„Operation [„Operationsname“] beginnt mit einer Listener- oder ereignisbasierten Aktivität [„Aktivitätsname“] und kann nicht mit einem Zeitplan verknüpft werden.“ | Eine Operation, die eine Listening-Aktivität enthält kann nicht nach einem Zeitplan ausgeführt werden. |
Das Script "[" Script Name"] in der Operation ["Operation Name"] kann RunOperation() nicht verwenden, um die Operation ["Operation Name 2"] aufzurufen, die über eine Listener- oder ereignisbasierte Aktivität verfügt. | Eine Operation kann das nicht verwenden RunOperation -Funktion, um eine andere Operation aufzurufen, die eine Abhöraktivität enthält. |
Der Das Symbol „ungültig“ wird nicht angezeigt, wenn der Grund für die Ungültigkeit der Operation darin liegt, dass sie andere Komponenten mit impliziten Fehlern enthält. Projektkomponenten, die als Teil einer Operation verwendet werden, müssen gültig sein, damit die Operation gültig ist. Dies umfasst Komponenten, die als Schritte einer Operation verwendet werden, sowie andere Komponenten, die zur Unterstützung einer Operation verwendet werden. Beispiel:
- Eine Komponente, die direkt als Schritt in der Operation verwendet wird, beispielsweise eine Aktivität, Transformation oder ein Script.
- Ein Endpoint, von dem eine im Operation verwendete Aktivität abhängig ist.
- Eine Komponente, die im Operation durch ein Script aufgerufen wird.
Die Validierungsregeln hängen vom Komponententyp ab und werden gemeinsam unter Komponentengültigkeit behandelt.
Validierungsmuster
Bestimmte Validierungsmuster müssen befolgt werden, damit Vorgänge in der Harmony Cloud bereitgestellt und auf Jitterbit-Agenten ausgeführt werden können. Diese Muster stellen sicher, dass alle Teile eines Projekts vom Agenten unterstützt und erwartet werden:
- Archivmuster
- Script
- Transformation
- Zwei-Ziel-Archivmuster
- HTTP-Archivmuster mit zwei Zielen
- Zwei-Transformationsmuster
- Salesforce Massenquellenmuster
- Salesforce Massenzielmuster
Das folgende Diagramm fasst alle gültigen Operation zusammen. Jedes Muster wird auch einzeln dargestellt und im Text unter dem Diagramm beschrieben, wobei optionale Komponenten fett grau dargestellt werden und erforderliche Komponenten fett rot dargestellt werden.
Fußnoten für Validierungsmuster
A Wenn eine Operation eine API Aktivität enthält, muss es sich um die einzige API oder API SOAP Anforderungsaktivität in der Operation handeln und sie muss die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer Operation „bei Erfolg“ oder „bei Fehler“ aufrufen.
B Wenn eine Salesforce, Salesforce Service Cloud oder ServiceMax Abfrage als Quellaktivität verwendet wird, ist eine Zielaktivität erforderlich.
C Operationen können nicht mehr als eine NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax oder SOAP Aktivität umfassen.
D Operationen, die eine Salesforce -, Salesforce Service Cloud- oder ServiceMax-Aktivität enthalten, können nicht gleichzeitig andere Aktivitäten enthalten, außer denen, die mit der API verknüpft sind, Datenbank, Dateifreigabe, FTP, HTTP, Lokaler Speicher, Temporärer Speicher oder Variable-Anschlüsse.
E An dieser Stelle können nur Nicht-Massenaktivitäten verwendet werden.
F Die HTTP-Aktivität muss einen Anforderungstext empfangen und einen Antworttext erstellen. Eine HTTP-GET-Aktivität gibt eine Erfolgsmeldung zurück {"success": true}
oder Versagen {"success": false}
anstelle der tatsächlichen Antwort.
Häufig gestellte Fragen (FAQ)
Beim Konzipieren von Abläufen kann es hilfreich sein, die Antworten auf die folgenden häufig gestellten Fragen zu berücksichtigen:
- Was ist der Unterschied zwischen einer Quelle und einem Ziel?
Aktivitäten werden als Quelle betrachtet, wenn sie Daten innerhalb einer Operation bereitstellen. Aktivitäten werden als Ziel betrachtet, wenn sie Daten innerhalb einer Operation empfangen. Weitere Erläuterungen zu Quellen im Vergleich zu Zielen und den Teilen der Operation finden Sie unter Erstellen und Konfigurieren von Operationen. - Welche Muster sind für meinen Endpoint gültig?
Die Muster, die mit jedem spezifischen Aktivitätstyp verwendet werden können, sind auf den einzelnen Aktivitätsseiten unter Konnektoren dokumentiert. Auf jeder Aktivitätsseite sind die spezifischen Muster, die verwendet werden können, im Abschnitt „Nächste Schritte“ enthalten, der normalerweise der letzte Abschnitt auf jeder Aktivitätsseite ist. - Was passiert, wenn mein Anwendungsfall keinem gültigen Muster entspricht?
Wenn eine bestimmte gewünschte Operation keinem gültigen Muster folgt, können Sie möglicherweise eine Kombination von Operationen verwenden, die jeweils einem gültigen Muster folgen. Erstellen Sie dazu jede Operation separat und verketten Sie sie dann mithilfe von Operation. -
Wie kann ich mir diese Muster merken?
Vorgänge, die keinem gültigen Muster folgen, werden als ungültig gekennzeichnet und können nicht bereitgestellt werden. Wenn Sie sich mit den Mustern vertraut machen, können Verallgemeinerungen wie diese offensichtlich werden:- Dateibasierte generische Konnektoren, wie FTP, HTTP und Temporary Storage, können ohne Transformation genutzt werden.
- In den meisten Fällen Anwendungskonnektoren für Nicht-Massenaktivitäten, wie etwa für Epicor, ServiceNow und Workday, erfordern eine Transformation.
- Scripts können fast überall hinzugefügt werden.
-
Gibt es Beispiele dafür, wie andere ihren Betrieb aufgebaut haben?
Allgemeine Beispiele für die Verwendung dieser Muster finden Sie unter Beispiele für gängige Operation am Ende dieser Seite oder beziehen Sie sich auf die einzelnen Aktivitätsseiten unter Konnektoren.
Archivmuster
Script(e) + Quellaktivität + Script(e) + Zielaktivität + Script(e)
In diesem Muster können die Quell- und Zielaktivitäten mit einem dieser Endpoint verknüpft werden:
- API A
- Dateifreigabe
- FTP
- HTTP
- Lokaler Speicher
- NetSuite
- Salesforce E
- Salesforce Service Cloud E
- ServiceMax E
- Temporärer Speicher
- Variable
A Wenn eine Operation eine API Aktivität enthält, muss es sich um die einzige API oder API SOAP Anforderungsaktivität in der Operation handeln und sie muss die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer Operation „bei Erfolg“ oder „bei Fehler“ aufrufen.
E An diesem Standort können nur Nicht-Bulk-Aktivitäten verwendet werden.
Script
Script(e) + Zielaktivität
In diesem Muster kann die Zielaktivität mit einem dieser Endpoint verknüpft werden:
Transformation
Script(e) + (Gruppe: Quellaktivität + Script[s]) + Transformation + (Gruppe: Script(e) + Zielaktivität) + Script[s])
In diesem Muster können die Quell- und/oder Zielaktivitäten jedem Endpoint zugeordnet werden, solange mindestens eine Aktivität enthalten ist. Eine Transformation kann in einem Operation ohne Aktivität nicht für sich allein existieren.
A Wenn eine Operation eine API Aktivität enthält, muss es sich um die einzige API oder API SOAP Anforderungsaktivität in der Operation handeln und sie muss die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer Operation „bei Erfolg“ oder „bei Fehler“ aufrufen.
B Wenn eine Salesforce, Salesforce Service Cloud oder ServiceMax Abfrage als Quellaktivität verwendet wird, ist eine Zielaktivität erforderlich.
C Operationen können nicht mehr als eine NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax oder SOAP Aktivität umfassen.
D Operationen, die eine Salesforce -, Salesforce Service Cloud- oder ServiceMax-Aktivität enthalten, können nicht gleichzeitig andere Aktivitäten enthalten, außer denen, die mit der API verknüpft sind, Datenbank, Dateifreigabe, FTP, HTTP, Lokaler Speicher, Temporärer Speicher oder Variable Anschlüsse.
E An diesem Standort können nur Nicht-Massenaktivitäten verwendet werden.
Zwei-Ziel-Archivierungsmuster
Script(e) + (Gruppe: Quellaktivität 1 + Script[s]) + Transformation + Zielaktivität 1 / Quellaktivität 2 + Script(e) + Zielaktivität 2 + Script(e)
In diesem Muster wird die zweite Zielaktivität verwendet, um eine Antwort der mittleren Aktivität zu archivieren, die sowohl als erstes Ziel als auch als zweite Quelle fungiert.
Die Antwort der mittleren Aktivität leitet die Rohantwortdaten ohne Transformation an ein zweites Ziel weiter. Dies kann als Archiv oder als Durchleitung von Daten (manchmal auch als Passthrough bezeichnet) betrachtet werden.
Die Quell- und Zielaktivitäten müssen je nach ihrer Verwendung im Muster bestimmten Endpoint zugeordnet werden:
- Quellaktivität 1 A: Bei Verwendung kann die erste Quellaktivität mit jedem beliebigen Endpoint verknüpft werden.
-
Zielaktivität 1 / Quellaktivität 2: Die erste Zielaktivität (auch als zweite Quellaktivität bezeichnet) kann mit einem dieser Endpoint verknüpft werden:
- NetSuite
- Salesforce D, E
- Salesforce Service Cloud D, E
- SAP
- ServiceMax D, E
- SOAP
Hinweis
Eine Variante dieses Musters, bei der HTTP als mittlere Aktivität verwendet wird, ist das HTTP-Archivmuster mit zwei Zielen.
-
Zielaktivität 2: Die zweite Zielaktivität kann mit einem dieser Endpoint verknüpft werden:
A Wenn eine Operation eine API Aktivität enthält, muss es sich um die einzige API oder API SOAP Anforderungsaktivität in der Operation handeln und sie muss die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer Operation „bei Erfolg“ oder „bei Fehler“ aufrufen.
C Operationen können nicht mehr als eine NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax oder SOAP Aktivität umfassen.
D Operationen, die eine Salesforce -, Salesforce Service Cloud- oder ServiceMax-Aktivität enthalten, können nicht gleichzeitig andere Aktivitäten enthalten, außer denen, die mit der API verknüpft sind, Datenbank, Dateifreigabe, FTP, HTTP, Lokaler Speicher, Temporärer Speicher oder Variable Anschlüsse.
E An diesem Standort können nur Nicht-Massenaktivitäten verwendet werden.
HTTP-Archivierungsmuster mit zwei Zielen
Script(e) + Quellaktivität 1 + Script(e) + Transformation + Script(e) + Zielaktivität 1 / Quellaktivität 2 + Zielaktivität 2 + Script(e)
In diesem Muster wird die zweite Zielaktivität verwendet, um eine Antwort der mittleren Aktivität zu archivieren, die sowohl als erstes Ziel als auch als zweite Quelle fungiert. Dieses Muster unterscheidet sich vom Zwei-Ziel-Archivierungsmuster dadurch, dass die mittlere Aktivität eine HTTP-Aktivität ist.
Die Antwort der mittleren HTTP-Aktivität leitet die Rohantwortdaten ohne Transformation an ein zweites Ziel weiter. Dies kann als Archiv oder als Durchleitung von Daten (manchmal auch als Passthrough bezeichnet) betrachtet werden.
Die Quell- und Zielaktivitäten müssen je nach ihrer Verwendung im Muster bestimmten Endpoint zugeordnet werden:
- Quellaktivität 1 A: Bei Verwendung kann die erste Quellaktivität mit jedem beliebigen Endpoint verknüpft werden.
- Zielaktivität 1 / Quellaktivität 2: Die erste Zielaktivität (auch als zweite Quellaktivität bezeichnet) kann mit einem dieser Endpoint verknüpft werden:
- HTTP F
- Zielaktivität 2: Die zweite Zielaktivität kann mit einem dieser Endpoint verknüpft werden:
A Wenn eine Operation eine API Aktivität enthält, muss es sich um die einzige API oder API SOAP Anforderungsaktivität in der Operation handeln und sie muss die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer Operation „bei Erfolg“ oder „bei Fehler“ aufrufen.
E An diesem Standort können nur Nicht-Bulk-Aktivitäten verwendet werden.
F Die HTTP-Aktivität muss einen Anforderungstext empfangen und einen Antworttext erzeugen. Eine HTTP-GET-Aktivität gibt eine Erfolgsmeldung zurück {"success": true}
oder Versagen {"success": false}
anstelle der tatsächlichen Antwort.
Zwei-Transformations-Muster
Script(e) + (Gruppe: Quellaktivität 1 + Script[s]) + Transformation 1 + Zielaktivität 1 / Quellaktivität 2 + Transformation 2 + Script(e) + Zielaktivität 2 + Script(e)
In diesem Muster wird die zweite Transformation verwendet, um die Antwort von der mittleren Aktivität (die sowohl als erstes Ziel als auch als zweite Quelle fungiert) zu übernehmen, sie zu transformieren und sie dann optional in ein zweites Ziel zu schreiben.
Die Quell- und Zielaktivitäten müssen je nach ihrer Verwendung im Muster bestimmten Endpoint zugeordnet werden:
- Quellaktivität 1 A: Bei Verwendung kann die erste Quellaktivität mit jedem beliebigen Endpoint verknüpft werden.
- Zielaktivität 1 / Quellaktivität 2: Die erste Zielaktivität (auch als zweite Quellaktivität bezeichnet) kann mit jedem Endpoint außer API verknüpft werden, Datenbank, Dateifreigabe, FTP, HTTP, Lokaler Speicher, Temporärer Speicher oder Variable.
- Zielaktivität 2 E: Bei Verwendung kann die zweite Zielaktivität mit jedem beliebigen Endpoint verknüpft werden.
A Wenn eine Operation eine API Aktivität enthält, muss es sich um die einzige API oder API SOAP Anforderungsaktivität in der Operation handeln und sie muss die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer Operation „bei Erfolg“ oder „bei Fehler“ aufrufen.
C Operationen können nicht mehr als eine NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax oder SOAP Aktivität umfassen.
D Operationen, die eine Salesforce -, Salesforce Service Cloud- oder ServiceMax-Aktivität enthalten, können nicht gleichzeitig andere Aktivitäten enthalten, außer denen, die mit der API verknüpft sind, Datenbank, Dateifreigabe, FTP, HTTP, Lokaler Speicher, Temporärer Speicher oder Variable Anschlüsse.
E An diesem Standort können nur Nicht-Massenaktivitäten verwendet werden.
Salesforce Massenquellenmuster
Script(e) + Quellaktivität + Script(e) + Zielaktivität + Script(e)
In diesem Muster muss die Quellaktivität eine Salesforce Bulk Query-Aktivität sein, Salesforce Service Cloud-Massenabfrageaktivität oder ServiceMax Bulk Query-Aktivität. Die Zielaktivität kann mit jedem dieser Endpoint verknüpft werden:
Salesforce Massenzielmuster
Script(e) + Quellaktivität + Script(e) + Zielaktivität + Script(e)
In diesem Muster kann die Quellaktivität einem dieser Endpoint zugeordnet werden:
Die Zielaktivität kann mit jedem dieser Endpoint verknüpft werden:
- Salesforce Masseneinfügung
- Salesforce Massenaktualisierung
- Salesforce Massen-Upsert
- Salesforce Massenlöschung
- Salesforce Massenlöschung
- Salesforce Service Cloud Masseneinfügen, Aktualisieren, Upsert, Löschen oder endgültiges Löschen
- ServiceMax Masseneinfügung
- ServiceMax Massenaktualisierung
- ServiceMax Massen-Upsert
- ServiceMax Massenlöschung
- ServiceMax Massenlöschung
Beispiele gängiger Operation
Dieser Abschnitt enthält mehrere allgemeine Beispiele für Operationen, die mit einem gültigen Operation konfiguriert wurden. Diese Beispiele sind vereinfacht, um die grundlegenden Bausteine häufig erstellter Operationen zu demonstrieren, und decken nicht alle möglichen Kombinationen ab. Siehe Validierungsmuster weiter oben auf dieser Seite für alle möglichen Arrangements.
Script
Eine Operation kann einfach ein einzelnes Script enthalten. In diesem Fall werden alle Aktionen im Operation vom Script ausgeführt.
Dieses Muster wird normalerweise zu Beginn eines Workflow verwendet, um ein „Script“ zu erstellen, das basierend auf einer Systemvariablen oder einem anderen Datenwert eine oder mehrere Verzweigungsoperationen ausführt.
Scripts können auch überall in einem Operation verwendet werden, um komplexe Berechnungen durchzuführen, die eine benutzerdefinierte Logik erfordern.
Archiv
Wenn Sie lediglich Dateien von einer Datenquelle zu einem Ziel verschieben müssen, können Sie einen Operation ohne Transformation verwenden.
Die erste Aktivität wird als Quelle verwendet und stellt innerhalb der Operation Daten bereit. Die zweite Aktivität wird als Ziel verwendet und empfängt innerhalb der Operation Daten.
Beim Archivieren von Daten sind die Quell- und Zielaktivitäten auf solche beschränkt, die mit Dateien interagieren. Anstelle einer Quellaktivität können Sie auch ein Script verwenden.
Transformation
Operationen, die Transformations nutzen dienen einer Vielzahl von Anwendungsfällen. Sie können beispielsweise Vorgänge erstellen, die (1) Daten von einer Quelle in ein Ziel umwandeln, (2) Daten umwandeln und dann die Antwort in ein anderes Ziel schreiben oder (3) Daten aus einem Webdienstaufruf umwandeln, indem Sie die Antwort des Anwendungsaufrufs umwandeln und in ein Ziel schreiben.
Der Vorgang transformiert Daten von der Quelle zum Ziel
In diesem Beispiel werden Daten aus einer Quellaktivität abgerufen, die dann transformiert und in eine Zielaktivität geschrieben werden:
Der Vorgang transformiert Daten und schreibt dann die Antwort in ein anderes Ziel
Wenn in diesem Beispiel eine HTTP-Aktivität wie HTTP PUT oder HTTP POST als Ziel der Transformation verwendet wird, kann eine zusätzliche Zielaktivität direkt dahinter oder nach einer anderen Transformation platziert werden, um die HTTP-Antwort in ein anderes Ziel zu schreiben.
Diese Operation, die zum Abrufen eines REST-Tokens verwendet wird, zeigt, wie die HTTP-Antwort in eine globale Variable geschrieben wird, um sie in der nächsten Operation zu verwenden:
Der Vorgang ruft einen Webdienst auf
Dieses Beispiel dient zum Aktualisieren einer Anwendung wie Salesforce über die API der Anwendung oder durch Aufrufen einer SOAP Webdienstmethode. Der Anwendungsaufruf umfasst normalerweise sowohl eine Anforderungs- als auch eine Antwortdatenstruktur.
Bei dieser Anordnung besteht die Operation aus drei Teilen:
-
Die erste Quellaktivität und Transformation zum Erstellen der Anforderungsdatenstruktur.
-
Der Anwendungsaufruf selbst, der als erste Zielaktivität und zweite Quellaktivität fungiert.
-
Eine zweite Transformation und ein zweites Ziel, um die Antwort des Anwendungsaufrufs zu konvertieren und die Daten oder Datei in ein Ziel zu schreiben.
Bewerbungsaufruf
SOAP Aufruf
Fehler in HTTP-Validierungsregeln
Eine der HTTP-Validierungsregeln gilt für Vorgänge mit dem Zwei-Ziel-Archivmuster, wobei eine HTTP-Aktivität an der Position Ziel 1 eine Antwort an eine zweite Zielaktivität (Ziel 2) schreibt. In diesem Szenario erfordert die Validierungsregel, dass eine HTTP-Aktivität Ziel 1 nicht in einem anderen Zwei-Ziel-Archivmuster verwendet werden darf Operationen, bei denen die HTTP-Aktivität Ziel 1 in eine andere zweite Zielaktivität schreibt.
Operationen, die diese Validierungsregel verletzen, werden mit einer Fehlermeldung ähnlich dieser als ungültig gemeldet:
Beheben von HTTP-Validierungsfehlern
Wir empfehlen, die Anweisungen in der Fehlermeldung zu befolgen, um die Vorgänge zu korrigieren, damit sie gültig sind. Wenn Sie diese Anweisungen befolgen, empfehlen wir die folgenden Schritte:
-
Duplizieren Sie die HTTP-Zielaktivität an der Position Ziel 1 eines der Vorgänge mithilfe des Zwei-Ziel-Archivmusters:
-
Ersetzen Sie die HTTP-Zielaktivität an der Position Ziel 1 der identifizierten Operation(en) durch die doppelte Kopie:
-
Wiederholen Sie den Vorgang für alle weiteren ungültigen Vorgänge. Sobald die Validierungsfehler behoben sind, führen Sie die Vorgänge erneut aus.
Deaktivieren der HTTP-Validierungsregel
In bestimmten Situationen kann es wünschenswert sein, diese HTTP-Validierungsregel wie folgt zu deaktivieren:
-
Öffnen Sie die Projekteinstellungen:
-
Deaktivieren Sie auf der Tab Bereitstellen die HTTP-Validierungsregel:
-
Klicken Sie auf Speichern.
Sobald Sie die Einstellung deaktivieren und speichern, sollten die aufgrund dieses Fehlers gemeldeten Operation behoben sein. Beachten Sie jedoch, dass alle HTTP Ziel 1-Aktivitäten, die in einem Zwei-Ziel-Archivmuster verwendet werden, Operation schreibt in die Ziel 2-Aktivität der letzten bereitgestellten Operation. Dies kann dazu führen, dass ungültige Daten geschrieben werden.
Achtung
Die Verwendung dieser Einstellung zum Deaktivieren der HTTP-Validierungsregel wird nicht empfohlen und kann dazu führen, dass bei Vorgängen mit dem Zwei-Ziel-Archivierungsmuster unbeabsichtigt ungültige Daten in Zielaktivitäten geschrieben werden.
Erneutes Aktivieren der HTTP-Validierungsregel
Wenn Sie die HTTP-Validierungsregel zuvor deaktiviert haben und sie nun wieder aktivieren möchten, führen Sie die folgenden Schritte aus:
-
Öffnen Sie die Projekteinstellungen.
-
Aktivieren Sie auf der Tab Bereitstellen die HTTP-Validierungsregel.
-
Klicken Sie auf Speichern. Beachten Sie, dass dies eine Änderung zur Entwurfszeit ist und dass durch diese Aktion keine Änderungen in der Harmony-Cloud einsetzen werden.
-
Beheben Sie alle HTTP-Validierungsfehler (siehe Beheben von HTTP-Validierungsfehlern oben).
-
Stellen Sie das Projekt erneut bereit (siehe Projektbereitstellung).
Notiz
Vor der erneuten Bereitstellung ist die Ausführung aller jetzt ungültigen Vorgänge zulässig, da Harmony die aktuell bereitgestellten Vorgänge ausführt. Die erneute Bereitstellung der betroffenen Vorgänge ist erforderlich, damit die Änderungen an Harmony weitergegeben werden.