Gültige Operation und Validierungsfehler

Einführung

Operationen müssen gültig sein, um bereitgestellt werden zu können. Auf dieser Seite erfahren Sie, wie Sie ungültige Operationen identifizieren, die zugehörigen Validierungsfehler anzeigen und Validierungsfehler mithilfe eines gültigen Operation beheben. Außerdem werden Beispiele für gängige Operation bereitgestellt.

Validierungsfehler

Bei neuen Projekten werden ungültige Elemente standardmäßig auf der Design-Canvas hervorgehoben, wobei standardmäßig Ungültige Elemente hervorheben ausgewählt ist. Um diese Option zu deaktivieren, deaktivieren Sie diese Option:

Wenn Ungültige Elemente hervorheben ausgewählt ist, werden ungültige Vorgänge oder Komponenten rot hervorgehoben und mit einem 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 Klicken Sie neben dem Operation auf das Symbol „Ungültig“, um eine Meldung mit den Validierungsfehlern für die Operation anzuzeigen.

Operationen mit einem impliziten Fehler können aus einem der unter Implizite Operation aufgeführten Gründe ungültig sein unten auf dieser Seite.

Die Das Symbol „Ungültig“ wird nicht angezeigt, wenn die Operation ungültig ist, weil 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 eine Operation unterstützen. 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 von einem Script aufgerufen wird.

Die Validierungsregeln hängen vom Typ der Komponente ab und werden zusammenfassend unter Komponentengültigkeit.

Validierungsmuster

Für die Bereitstellung von Vorgängen in der Harmony Cloud und die Ausführung auf Jitterbit-Agenten müssen bestimmte Validierungsmuster befolgt werden. Diese Muster stellen sicher, dass alle Teile eines Projekts vom Agenten unterstützt und erwartet werden:

• Archivmuster
• Script
• Transformation
• Zwei-Ziel-Archivmuster
• Zwei-Ziel-HTTP-Archivmuster
• Zwei-Transformationsmuster
• Salesforce-Massenquellenmuster
• Salesforce-Massenzielmuster

Die folgende Legende zeigt die Definition der in den Validierungsmusterabbildungen dargestellten Flusslinien:

Flusslinie	Definition
	Eine erforderliche Komponente.
	Eine optionale Komponente.
	Null oder mehr Script(e) oder Flow Control tools sind gültig.

Häufig gestellte Fragen (FAQ)

Beim Entwerfen von Vorgängen kann es hilfreich sein, die Antworten auf diese häufig gestellten Fragen zu berücksichtigen:

• Was ist der Unterschied zwischen einer Quelle und einem Ziel?
  Aktivitäten gelten als Quelle, wenn sie Daten innerhalb einer Operation bereitstellen. Aktivitäten gelten als Ziel, wenn sie Daten innerhalb einer Operation empfangen. Weitere Erläuterungen zu Quellen und Zielen sowie zu den Bestandteilen einer Operation finden Sie unter Erstellen und Konfigurieren von Operationen.
• Welche Muster sind für meinen Endpoint gültig?
  Die Muster, die mit den einzelnen Aktivitätstypen 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 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 anschließend mithilfe von Operation.

• Wie kann ich mir diese Muster merken?
  Operationen, die keinem gültigen Muster folgen, werden als ungültig gekennzeichnet und können nicht bereitgestellt werden. Mit zunehmender Vertrautheit mit den Mustern können Verallgemeinerungen wie diese deutlich werden:

  • Dateibasierte generische Konnektoren, wie FTP, HTTP und Temporärer Speicher, können ohne Transformation verwendet 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 ihre Betriebe aufgebaut haben?
  Gängige 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

Das Archivierungsmuster ist für Quell- und Zielaktivitäten vorgesehen, die mit Dateien interagieren. Es ermöglicht die Speicherung inaktiver Daten (im ursprünglichen Dateiformat) von einem Produktionssystem in einem sicheren Speichersystem für den späteren Abruf.

---

Script(e) oder Flusskontrolle Tools + Quellaktivität + Script(e) + Zielaktivität + Script(e)

In diesem Muster können die Quell- und Zielaktivitäten mit einem der folgenden Endpoint verknüpft werden:

• API ^A
• Dateifreigabe
• FTP
• HTTP
• Lokaler Speicher
• NetSuite
• Salesforce ^B
• Salesforce Service Cloud ^B
• ServiceMax ^B
• Zwischenspeicher
• Variable

^A Wenn eine Operation eine API Aktivität enthält, muss diese die einzige API oder API SOAP Anforderungsaktivität in der Operation sein und die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer „bei Erfolg“ oder „bei Fehler“ ausgeführten Operation aufrufen.

^B An diesem Standort können nur Nicht-Bulk-Aktivitäten verwendet werden.

Script

---

Script(e) oder Flusskontrolle Tools + Zielaktivität

In diesem Muster kann die Zielaktivität mit einem dieser Endpoint verknüpft werden:

• API
• Dateifreigabe
• FTP
• HTTP
• Lokaler Speicher
• Zwischenspeicher
• Variable

Transformation

---

Script(e) oder Flusskontrolle Tools + (Gruppe: Quellaktivität + Script[s] oder Flusssteuerung Tools) + Transformation + (Gruppe: Script[s] oder Flusssteuerung tools + Zielaktivität) + Script[s] ^{E, F}

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 allein existieren.

^A Wenn eine Operation eine API Aktivität enthält, muss diese die einzige API oder API SOAP Anforderungsaktivität in der Operation sein und die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer „bei Erfolg“ oder „bei Fehler“ ausgeführten Operation aufrufen.

^B An diesem Standort können nur Nicht-Bulk-Aktivitäten verwendet werden.

^C Mindestens eine Aktivität muss enthalten sein; eine Transformation kann nicht für sich allein existieren.

^D Wenn eine Salesforce, Salesforce Service Cloud oder ServiceMax Abfrage als Quellaktivität verwendet wird, ist eine Zielaktivität erforderlich.

^E Operationen können nicht mehr als eine NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax oder SOAP Aktivität umfassen.

^F Operationen, die eine Salesforce, Salesforce Service Cloud oder ServiceMax-Aktivität enthalten, können keine anderen 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.

Zwei-Ziel-Archivmuster

Das Zwei-Ziel-Archivierungsmuster kann verwendet werden, um inaktive Daten (im Originalformat) von einem Produktionssystem auf einem sicheren Speichersystem für den späteren Abruf zu speichern.

---

Script(e) oder Flusskontrolle Tools + (Gruppe: Quellaktivität 1 + Script[s]) oder Flusskontrolle tools + Transformation + Zielaktivität 1 / Quellaktivität 2 + Script(e) oder Flusssteuerung Tools + Zielaktivität 2 + Script(e) oder Flusskontrolle Tools ^{C, D}

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 Rohdaten der Antwort ohne Transformation an ein zweites Ziel weiter. Dies kann als Archivierung oder als Datenweiterleitung (manchmal auch als Passthrough bezeichnet) betrachtet werden.

Die Quell- und Zielaktivitäten müssen bestimmten Endpoint zugeordnet werden, je nachdem, wo sie im Muster verwendet werden:

• Quellaktivität 1 ^A: Bei Verwendung kann die erste Quellaktivität mit jedem Endpoint verknüpft werden.

• Zielaktivität 1 / Quellaktivität 2: Die erste Zielaktivität (auch als zweite Quellaktivität bezeichnet) kann mit jedem dieser Endpoint verknüpft werden:

  • NetSuite
  • Salesforce ^{B, D}
  • Salesforce Service Cloud ^{B, D}
  • SAP
  • ServiceMax ^{B, D}
  • SOAP

  Hinweis

  Eine Variante dieses Musters mit HTTP als mittlerer Aktivität ist das Zwei-Ziel-HTTP-Archivmuster.

• Zielaktivität 2: Die zweite Zielaktivität kann mit einem dieser Endpoint verknüpft werden:

  • API
  • Dateifreigabe
  • FTP
  • HTTP
  • Lokaler Speicher
  • Zwischenspeicher
  • Variable

^A Wenn eine Operation eine API Aktivität enthält, muss diese die einzige API oder API SOAP Anforderungsaktivität in der Operation sein und die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer „bei Erfolg“ oder „bei Fehler“ ausgeführten Operation aufrufen.

^B An diesem Standort können nur Nicht-Bulk-Aktivitäten verwendet werden.

^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 keine anderen 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.

HTTP-Archivmuster mit zwei Zielen

Das HTTP-Archivierungsmuster mit zwei Zielen ermöglicht die Speicherung inaktiver Daten (im Originalformat) von einem Produktionssystem auf einem sicheren Speichersystem für den späteren Abruf über HTTP-Protokolle und-Dienste.

---

Script(e) oder Flusskontrolle Tools + Quellaktivität 1 + Script(e) oder Flusssteuerung Tools + Transformation + Script(e) oder Flusskontrolle Tools + Zielaktivität 1 / Quellaktivität 2 + Zielaktivität 2 + Script(e) oder Flusssteuerung Tools

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, dass die mittlere Aktivität eine HTTP-Aktivität ist.

Die Antwort der mittleren HTTP-Aktivität leitet die Rohdaten der Antwort ohne Transformation an ein zweites Ziel weiter. Dies kann als Archivierung oder als Datenweiterleitung (manchmal auch als Passthrough bezeichnet) betrachtet werden.

Die Quell- und Zielaktivitäten müssen bestimmten Endpoint zugeordnet werden, je nachdem, wo sie im Muster verwendet werden:

• Quellaktivität 1 ^A: Bei Verwendung kann die erste Quellaktivität mit jedem Endpoint verknüpft werden.
• Zielaktivität 1 / Quellaktivität 2: Die erste Zielaktivität (auch als zweite Quellaktivität bezeichnet) kann mit jedem dieser Endpoint verknüpft werden:
  • HTTP ^C
• Zielaktivität 2: Die zweite Zielaktivität kann mit einem dieser Endpoint verknüpft werden:
  • API
  • Dateifreigabe
  • FTP
  • HTTP
  • Lokaler Speicher
  • Zwischenspeicher
  • Variable

^A Wenn eine Operation eine API Aktivität enthält, muss diese die einzige API oder API SOAP Anforderungsaktivität in der Operation sein und die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer „bei Erfolg“ oder „bei Fehler“ ausgeführten Operation aufrufen.

^B An diesem Standort können nur Nicht-Bulk-Aktivitäten verwendet werden.

^C 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-Transformationsmuster

400.

Script(e) oder Flusskontrolle Tools + (Gruppe: Quellaktivität 1 + Script[s] oder Flusssteuerung Tools) + Transformation 1 + Zielaktivität 1 / Quellaktivität 2 + Transformation 2 + Script(e) oder Flusssteuerung Tools + Zielaktivität 2 + Script(e) oder Flusskontrolle Tools

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 bestimmten Endpoint zugeordnet werden, je nachdem, wo sie im Muster verwendet werden:

• Quellaktivität 1 ^A: Bei Verwendung kann die erste Quellaktivität mit jedem Endpoint verknüpft werden.
• Zielaktivität 1 / Quellaktivität 2: Die erste Zielaktivität (auch als zweite Quellaktivität bezeichnet) kann mit jedem Endpoint verknüpft werden, außer mit API, Datenbank, Dateifreigabe, FTP, HTTP, Lokaler Speicher, Temporärer Speicher oder Variable.
• Zielaktivität 2 ^B: Bei Verwendung kann die zweite Zielaktivität mit jedem Endpoint verknüpft werden.

^A Wenn eine Operation eine API Aktivität enthält, muss diese die einzige API oder API SOAP Anforderungsaktivität in der Operation sein und die Quelle der ersten Operation sein. Das heißt, keine andere Operation darf diese Operation aus einem Script oder einer „bei Erfolg“ oder „bei Fehler“ ausgeführten Operation aufrufen.

^B An diesem Standort können nur Nicht-Bulk-Aktivitäten verwendet werden.

^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 keine anderen 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.

Salesforce Massenquellenmuster

---

Script(e) oder Flusskontrolle Tools + Quellaktivität + Script(e) oder Flusskontrolle Tools + Zielaktivität + Script(e)oder Flusssteuerung Tools

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:

• Dateifreigabe
• FTP
• HTTP
• Lokaler Speicher
• Zwischenspeicher
• Variable

Salesforce-Massenzielmuster

---

Script(e) oder Flusskontrolle Tools + Quellaktivität + Script(e) oder Flusskontrolle Tools + Zielaktivität + Script(e) oder Flusskontrolle Tools

In diesem Muster kann die Quellaktivität mit einem dieser Endpoint verknüpft werden:

• Dateifreigabe
• FTP
• HTTP
• Lokaler Speicher
• Zwischenspeicher
• Variable

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ügung, -aktualisierung, -upset, -löschung oder endgültige Löschung
• ServiceMax Masseneinfügung
• ServiceMax Massenaktualisierung
• ServiceMax-Massen-Upsert
• ServiceMax Massenlöschung
• ServiceMax Massenlöschung

Beispiele für gängige Operation

Dieser Abschnitt enthält einige gängige 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 veranschaulichen, und decken nicht alle möglichen Kombinationen ab. Siehe Validierungsmuster weiter oben auf dieser Seite finden Sie 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 eine oder mehrere Verzweigungsoperationen basierend auf einer Systemvariablen oder einem anderen Datenwert ausführt.

Scripts können auch überall in einer 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 eine Operation ohne Transformation verwenden.

Die erste Aktivität wird als Quelle verwendet und stellt Daten innerhalb der Operation bereit. Die zweite Aktivität wird als Ziel verwendet und empfängt Daten innerhalb der Operation.

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 eignen sich für verschiedene Anwendungsfälle. Sie können beispielsweise Operationen erstellen, die (1) Daten von einer Quelle in ein Ziel transformieren, (2) Daten transformieren und die Antwort anschließend in ein anderes Ziel schreiben oder (3) Daten aus einem Webdienstaufruf transformieren, indem Sie die Antwort des Anwendungsaufrufs konvertieren 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.

In dieser Anordnung besteht der 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

Implizite Operation

Operationen mit einem impliziten Fehler können aus folgenden Gründen ungültig sein:

Fehler	Weitere Informationen
Operation ist leer.	Die Operation muss mindestens einen Operation Schritt haben.
Der Vorgang entspricht keinem gültigen Muster. Die Regeln und Muster für den Vorgang finden Sie hier.	Die Operation muss etablierten Operation entsprechen, die sicherstellen, dass die Operation vom Agenten unterstützt und erwartet wird. Diese Muster werden als Nächstes unter Validierungsmuster behandelt.
Das Transformation [Quelle / Ziel] entspricht nicht der Schema der Schema ["Aktivitätsname"]. Ö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.
Die Transformation ["Transformation "] verfügt über 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ät bereitgestellt 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 an eine Zielaktivität Antworten senden. Die HTTP-Aktivität ["Target 1 Activity Name"] in dieser Operation sendet ihre Antwort an mehrere Zielaktivitäten im gesamten Projekt. In dieser Operation ist ihr Ziel ["Target 2A Activity Name"]. In Operation ["Operation 2"] ist ihr Ziel ["Target 2B Activity Name"]. Ersetzen Sie die Aktivität ["Target 1 Activity Name"] in einer der Operationen durch eine doppelte Aktivität. Suchen Sie dazu die Aktivität ["Target 1 Activity Name"] auf der Registerkarte „Komponenten“, öffnen Sie das Menü und duplizieren Sie sie. Ziehen Sie die duplizierte Aktivität in die Operation.	In einer Operation, die das Zwei-Ziel-Archivmuster verwendet#operationvalidity-two-target-archive-pattern) 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>
„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 die ersten in der Operation sein.	Die Operation muss etablierte Operation für die Listening-Aktivität erfüllen. Die Operation, mit denen jede Abhö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 die Operation ["Operationsname 2"] haben, die einen Listener oder eine ereignisbasierte erste Aktivität hat.“	Eine Operation kann nicht Operation verwenden, um eine andere Operation aufzurufen, die eine Listening-Aktivität enthält.
„Operation ["Operationsname"] beginnt mit einem Listener oder einer 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 einen Listener oder eine ereignisbasierte Aktivität verfügt.	Eine Operation kann das RunOperation Funktion, um eine andere Operation aufzurufen, die eine Listening-Aktivität enthält.

Fehler in der HTTP-Validierungsregel

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 gegen diese Validierungsregel verstoßen, werden mit einer Fehlermeldung ähnlich der folgenden als ungültig gemeldet:

Beheben von HTTP-Validierungsfehlern

Wir empfehlen, die Anweisungen in der Fehlermeldung zu befolgen, um die Vorgänge zu korrigieren und ihre Gültigkeit wiederherzustellen. Folgen Sie diesen Anweisungen wie folgt:

1. Duplikat die HTTP-Zielaktivität an der Position Ziel 1 einer der Operationen, die das Zwei-Ziel-HTTP-Archivmuster.

2. Ersetzen Sie die HTTP-Zielaktivität an der Position Ziel 1 der identifizierten Operation(en) durch die doppelte Kopie:

3. 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 sinnvoll sein, diese HTTP-Validierungsregel wie folgt zu deaktivieren:

1. Öffnen Sie die Projekteinstellungen:

   

2. Deaktivieren Sie auf der Tab Bereitstellen die HTTP-Validierungsregel:

   

3. Klicken Sie auf Speichern.

Nach dem Deaktivieren und Speichern der Einstellung 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 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. Dies kann dazu führen, dass bei Vorgängen mit dem Zwei-Ziel-Archivierungsmuster unbeabsichtigt ungültige Daten in Zielaktivitäten geschrieben werden.

Aktivieren Sie die HTTP-Validierungsregel erneut

Wenn Sie die HTTP-Validierungsregel zuvor deaktiviert haben und sie nun wieder aktivieren möchten, gehen Sie wie folgt vor:

1. Öffnen Sie die Projekteinstellungen.

2. Aktivieren Sie auf der Tab Bereitstellen die HTTP-Validierungsregel.

3. Klicken Sie auf Speichern. Beachten Sie, dass es sich hierbei um eine Design-Time-Änderung handelt und dass diese Aktion keine Änderungen in der Harmony-Cloud einsetzen.

4. Beheben Sie alle HTTP-Validierungsfehler (siehe Beheben von HTTP-Validierungsfehlern oben).

5. Stellen Sie das Projekt erneut bereit (siehe Projektbereitstellung).

   Notiz

   Vor der erneuten Bereitstellung ist die Ausführung ungültiger 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.