Zum Inhalt springen

Verwandeln Sie Ihre Kontakte in Urlaubsgeld mit unserem neuen Kundenempfehlungsprogramm! Erfahren Sie mehr

✕

Bewährte Methoden für Jitterbit iPaaS

Einführung

Dieses Dokument dient als allgemeiner Leitfaden zur Nutzung der Jitterbit Integration Platform-as-a-Service (iPaaS). Es bietet Best Practices für gängige Integrationsszenarien und Empfehlungen zur Verwendung der verfügbaren Tools. Dieses Dokument ist nicht umfassend und deckt nicht alle Szenarien ab.

Dieses Dokument richtet sich an Benutzer von Integration Studio, die webbasierte Version der Projektdesign-Anwendung von Jitterbit. Für Best Practices mit Design Studio, Jitterbits Desktop-basierte Projektdesignanwendung, siehe Best Practices mit Design Studio.

Best Practices für App Builder, Jitterbits Anwendung zum Erstellen von Web- und mobilen Apps, werden separat behandelt.

Sie sollten bereits mit Jitterbit iPaaS und Integration Studio aus den folgenden Ressourcen vertraut sein:

An diesem Punkt sollten Sie die grundlegenden Konzepte und Begriffe von Jitterbit iPaaS kennen und verstehen, was wir unter Projekten, Operationen, Endpunkten, Skripting, Migration und Bereitstellung verstehen.

Siehe Zusätzliche Ressourcen am Ende dieser Seite. Dort finden Sie Links zu Videos und anderen Dokumenten, die diese Best Practices erläutern.

Support, Customer Success Manager und Dokumentation

Der Zugriff auf den Jitterbit-Support ist Teil einer Harmony Kundenlizenz. Bei Fragen oder technischen Problemen erhalten Sie kompetente Unterstützung vom Jitterbit-Support. Der Jitterbit-Support Auf der Seite finden Sie spezielle Anweisungen für Produktionsausfälle, um zeitkritische Probleme zu eskalieren.

Sie können sich auch an Ihren Customer Success Manager (CSM) wenden bei Fragen zur Lizenzierung oder anderen Themen.

Diese Dokumentationsseite (Jitterbit-Dokumentation) und unsere Entwickler (Jitterbit Developer Portal) enthalten mehr als 3.600 eindeutige URLs mit technischem Material.

Um Ihnen die Suche nach relevantem Material zu erleichtern, ist das Suchfeld vorgefiltert und beschränkt die Suchergebnisse auf den aktuell aufgerufenen Abschnitt der Dokumentation. Sie können die gesamte Dokumentation durchsuchen, indem Sie den Suchfilter löschen. Um nach bestimmten Begriffen zu suchen, setzen Sie diese in Anführungszeichen.

Rezepte und Vorlagen

Der Marketplace bietet mehr als 400 vorgefertigte Integration Studio-Rezepte und-Vorlagen, die als Grundlage für Integrationsdesigns verwendet werden können:

  • Ein Integrationsrezept verschiebt Daten in eine Richtung zwischen Objekten über zwei Anwendungen oder Systeme hinweg.

  • Eine Prozessvorlage beschleunigt die Ausführung eines bestimmten Geschäftsprozesses mithilfe zahlreicher Objekte über mehrere Anwendungen oder Systeme hinweg. Prozessvorlagen sollen die Bereitstellungszeit um 50 bis 80 Prozent verkürzen.

Jitterbit-Produktaktualisierungen

Jitterbit-Produktupdates werden regelmäßig veröffentlicht (siehe Release-Zeitplan). Selbst eine Nebenversion enthält neben Fehlerbehebungen auch neue Funktionen und Verbesserungen.

Zugriff auf Webanwendungen über das Harmony-Portal werden automatisch aktualisiert und führen immer die neueste veröffentlichte Version aus.

Cloud-API -Gateway und Cloud-Agent-Gruppe Updates werden automatisch angewendet. Für die Cloud-Agentengruppen gibt es zwei Sets: Produktion und Sandbox. Letzteres dient zum Testen der Kompatibilität mit Vorabversionen der Agentensoftware und ist keine Umfeld.

Lokal installierte Anwendungen werden durch Herunterladen und Ausführen eines Installationsprogramms aktualisiert:

Es ist ratsam, sich über aktuelle Versionen auf dem Laufenden zu halten, insbesondere über Versionen mit Funktionsupgrades.

Einfachheit des Projektdesigns und bevorzugte Funktionen

Während des Entwurfsprozesses eines Integrationsprojekts stoßen Sie möglicherweise auf mehrere Implementierungsmethoden, die zur gleichen Funktionalität führen können.

Obwohl je nach Integrationsanwendungsfall (wie dokumentiert) die eine oder andere Methode oft Vor- oder Nachteile gegenüber der anderen hat, empfehlen wir, stets das übergeordnete Leitprinzip der Einfachheit im Auge zu behalten. Möglichst einfach gestaltete Projekte haben in der Regel eine längere Lebensdauer und sind für Außenstehende im Bedarfsfall deutlich einfacher zu verstehen. Andererseits können übermäßig komplexe Projekte bei einem Verantwortungswechsel schwieriger zu pflegen und an andere zu übergeben sein.

Um einfachere Projekte zu entwerfen, empfehlen wir die folgende Reihenfolge der Funktionspräferenz:

  1. Nutzen Sie, wann immer möglich, No-Code-Funktionen, wie z. B. die visuelle Gestaltung von Vorgängen auf der Design-Canvas, Gruppierungskomponenten zusammen, um sie zu organisieren, Hinzufügen von Tags und Kommentaren beim Bereitstellen und Veröffentlichen von Vorgängen als APIs.
  2. Nutzen Sie Low-Code-Funktionen, wie z. B. die Verwendung von Variablen innerhalb der assistentenbasierten Komponentenkonfigurationsbildschirme oder das Bearbeiten von Daten auf Feldebene in einer Transformation mithilfe einer Script.
  3. Implementieren Sie bei Bedarf komplexere Logik mithilfe von Scripts, die in Jitterbit Script geschrieben sind Sprache.
  4. Nur wenn kein Jitterbit Script Äquivalent verfügbar ist, implementieren Sie Scripts in JavaScript.

Projektdesign und Wiederverwendbarkeit

Ein typisches Szenario für die Wiederverwendung eines Projekts ist die Entwicklung eines Starterprojekts unter umfassender Verwendung globaler Variablen und insbesondere Projektvariablen. Konfigurierbare Elemente - wie Endpoint Anmeldeinformationen, optionale Feldzuordnungen, parametrisierte Abfragen, Email-Adressen und Dateinamen - können als Projektvariablen bereitgestellt werden. Das Starterprojekt kann auch allgemeine Funktionen wie Fehlerbehandlung oder die Verwendung umgebungsweiter Caches enthalten. Das Starterprojekt wird exportiert und anschließend in neue Projekte importiert, um eine konsistente Entwicklungsbasis zu schaffen.

Endpoint

Endpoints, erstellt durch Konfigurieren einer Verbindung und zugehöriger Aktivitäten mithilfe von Konnektoren, werden häufig in Operationen verwendet. Es muss jedoch nicht unbedingt für jede Operation ein eindeutiger Endpoint erstellt werden. Da Aktivitätskonfigurationen Variablen für Pfade und Dateinamen akzeptieren, können generische Endpoints einmalig erstellt und anschließend mithilfe globaler und Projektvariablen dynamisch konfiguriert werden.

Nehmen wir zum Beispiel an, ein HTTP-Verbindung und eine zugehörige Aktivität werden erstellt, und die Aktivitätskonfiguration gibt einen Pfad an, der durch eine globale Variable definiert wird, wie z. B. $gv_http_path. Ein Controller Script kann verwendet werden, um die $gv_http_path nach Bedarf.

Ein weiteres Beispiel ist eine Datenbankabfrageaktivität mit einer Bedingung. WHERE Bedingung kann einer globalen Variable zugewiesen werden, wie zum Beispiel $gv_database_condition.

Die meisten Endpoints können mithilfe von Variablen konfiguriert werden.

Wiederverwendung von Script

Eigenständige Scripts, die eine bestimmte Funktion ausführen, z. B. das Zurückgeben einer Datenbanksuche oder das Berechnen eines Ergebnisses aus einer Reihe von Argumenten, können Kandidaten für die Wiederverwendung sein, insbesondere wenn sie in mehreren Vorgängen verwendet werden.

Wenn ein Script beispielsweise die DBLookup Funktion für eine Datenbanktabelle und wird diese Funktion im gesamten Projekt verwendet, dann kann ein eigenständiges Script (getrennt von einer Operation) erstellt werden. Mit dem ArgumentList Funktion oder einfache globale Variablen. Das Script kann Argumente akzeptieren und ein Ergebnis zurückgeben. Da jede Operation einen anderen Gültigkeitsbereich hat, kann dasselbe Script problemlos von mehreren gleichzeitigen Operationen aufgerufen werden.

Projektorganisation

Workflows dienen der Projektorganisation. Ein Workflow umfasst typischerweise zusammenhängende Vorgänge, die Daten von Anfang bis Ende verarbeiten: Aufträge erstellen, Kundenstamm synchronisieren, Bestätigungen verarbeiten usw. Prozesse, die in verschiedenen Workflows vorkommen, wie z. B. die Abfrage eines Endpoint oder die Operation eines Fehlerzustands, können in einem eigenen Workflow gespeichert und von anderen Workflow-Vorgängen referenziert werden.

Sie können auch benutzerdefinierte Gruppen erstellen, wo Projektkomponenten zur leichteren Bezugnahme gesammelt werden können.

Die den im Projektdesigner angezeigten Operationen zugewiesenen Nummern werden automatisch vergeben und basieren auf der Anzeigeposition der Operation im Projektdesigner. Diese Nummern werden nicht in den Operation angezeigt. Wenn ein Nummerierungsschema für Operation erforderlich ist, kann dies durch Einbinden der Nummerierung in den Operation implementiert werden.

Verwalten asynchroner Vorgänge

Bei Verwendung des RunOperation Im asynchronen Modus werden Operationen ausgeführt, ohne die Kontrolle an die aufrufende Funktion zurückzugeben. Die Verwendung asynchroner Operationen kann zu Race Conditions führen.

Aktualisiert beispielsweise Operation A eine Datenbanktabelle und ist sie mit Operation B verknüpft, die dieselbe Tabelle liest (beide sind synchron), treten keine Race Conditions auf. Wird Operation A jedoch asynchron aufgerufen, unmittelbar gefolgt von Operation B, kann B ausgeführt werden, bevor A abgeschlossen ist.

Darüber hinaus muss die Anzahl gleichzeitiger asynchroner Aufrufe verwaltet werden, da die Anzahl gleichzeitiger Operationen auf einem Agenten begrenzt ist (siehe [OperationEngine] Abschnitt der privaten Agentenkonfigurationsdatei).

Endpoint

Wir empfehlen die Verwendung einer System-ID mit Administratorberechtigungen für Endpoint-Anmeldeinformationen anstelle einer Benutzer-ID. Benutzer-IDs laufen in der Regel ab oder müssen deaktiviert werden, wenn ein Benutzer ein Unternehmen verlässt.

Durch die Verwendung von Projektvariablen (deren Werte ausgeblendet werden können) zur Verwaltung der Anmeldeinformationen muss ein Harmony Organisationsadministrator keine Produktionsanmeldeinformationen eingeben. Durch Einrichten der entsprechenden Benutzerberechtigungen kann ein Benutzer die Produktionsanmeldeinformationen über die Management Console Projekte anwenden. Seite.

Wenn Sie private Agenten verwenden, können Sie globale Variablen alternativ zur Verwendung der Management Console mithilfe von verwalten [PredefinedGlobalVariables] Abschnitt der privaten Agentenkonfigurationsdatei.

Persistente Integrationsdaten

Es gibt mehrere Methoden zum Speichern von Daten in der Harmony-Cloud, darunter die Verwendung von Projektvariablen, Cloud-Caching-Funktionen oder temporärer Speicherung.

Projektvariablen

Projektvariablen sind vorinitialisierte statische Variablen, die als Projektkonstanten betrachtet werden können. Sie können im Integration Studio bearbeitet werden (siehe Projektvariablen) oder die Management Console (siehe Projekte).

Ein Beispiel für die Verwendung von Projektvariablen sind Endpoint Anmeldeinformationen. Durch die Verwendung von Projektvariablen können verschiedene Endpoint (die in der Regel unterschiedliche Anmeldeinformationen haben) auf verschiedene Harmony-Umgebungen angewendet werden und über die Management Console bearbeitet werden. Dies ermöglicht einen Geschäftsprozess, bei dem ein Benutzer mit Management Console Rechten Anmeldeinformationen ändern kann, ohne Zugriff auf Integration Studio und den Projekt-Designer zu benötigen.

Ein zweites Beispiel ist die Verwendung von Projektvariablen, um Flags zu speichern, die von der Integrationslogik verwendet werden, um das Verhalten der Integration anzupassen. Wenn ein einzelnes Projekt entwickelt, aber für verschiedene Endpoints verwendet wird, kann eine boolesche Projektvariable (z. B. Send_PO_Number) von der Transformationslogik für das Feld PO Number überprüft werden. Wenn der Wert der Projektvariablen „false“ ist, dann UnMap Die Funktion könnte verwendet werden, um dieses Feld „auszuschalten“ und es nicht in eine relevante Transformation einzubeziehen.

Cloud-Caching-Funktionen

Die Cloud-Caching-Funktionen ReadCache Und WriteCache werden verwendet, um Datenräume zuzuweisen, die projekt- und umgebungsübergreifend verfügbar sind. Ein zwischengespeicherter Wert ist für alle Vorgänge im gleichen Bereich bis zu seinem Ablauf sichtbar, unabhängig davon, wie der Operation gestartet wurde oder auf welchem Agenten er ausgeführt wird. Durch das Zwischenspeichern von Daten in Harmony, anstatt auf lokale oder agentenspezifische Datenspeicher wie Temporary Storage zurückzugreifen, können Daten zwischen einzelnen Vorgängen und über Projekte hinweg gemeinsam genutzt werden.

Dies sind weitere Verwendungsmöglichkeiten von Cloud-Caching:

  • Daten können zwischen asynchronen Vorgängen innerhalb eines Projekts geteilt werden. Fehler, die bei verschiedenen Vorgängen auftreten, können in einem gemeinsamen Cache gespeichert werden. Durch die Akkumulation der Operation können umfassendere Warnmeldungen erstellt werden.
  • Anmeldetoken können betriebsübergreifend gemeinsam genutzt werden.

Temporären Speicher verwalten {: #manage-temporary-storage }Zwischenspeicher Endpoints werden häufig in Operationen sowohl auf Cloud- als auch auf privaten Agenten verwendet. Diese unterscheiden sich von Lokalem Speicher Endpoints, die nur auf privaten Agenten verwendet werden können.

Bei Verwendung eines Endpoint für den temporären Speicher werden temporäre Dateien in das temporäre Verzeichnis des Standardbetriebssystems auf dem Agenten geschrieben und von dort gelesen, der die Arbeit ausführt:

  • Im Fall eines einzelnen privaten Agenten ist das temporäre Speicherverzeichnis das temporäre Standardverzeichnis dieses privaten Agentenservers.
  • Wenn Sie mehr als einen privaten Agenten verwenden, der in einer privaten Agentengruppe gruppiert ist, ist das temporäre Speicherverzeichnis das temporäre Standardverzeichnis des spezifischen privaten Agentenservers, der die Arbeit ausführt.
  • Da Cloud-Agenten in einer Cloud-Agentengruppe gruppiert sind, ist das temporäre Speicherverzeichnis das temporäre Standardverzeichnis des spezifischen Cloud-Agentenservers, der die Arbeit ausführt.

In einer geclusterten Agentengruppe (private oder Cloud-Agenten) erfolgen alle Lese- und Schreibvorgänge des temporären Speichers auf demselben Agentenserver, solange die Vorgänge, die den temporären Speicher verwenden, miteinander verknüpft (verkettet) sind. Schreibt jedoch Kette A in ihren temporären Speicher, myfile und Chain B liest aus seinem temporären Speicher myfile und die beiden Ketten selbst nicht miteinander verkettet sind, kann der temporäre Speicherlesevorgang in Kette B nicht vom selben Agenten wie Kette A gelesen werden.

Notiz

Verkettete Vorgänge werden unabhängig von der Synchronizität immer auf demselben Agenten wie der übergeordnete Operation ausgeführt.

Beachten Sie bei der Verwendung von temporärem Speicher die folgenden Richtlinien:

  • Um Ihr Projekt aktualisierungssicher zu machen, sollten Sie bei der Verwendung privater Agenten den temporären Speicher so nutzen, dass für die Umstellung von einem einzelnen privaten Agenten auf eine Agentengruppe mit mehreren Agenten kein Refactoring erforderlich ist.

  • Wenn Sie eine geclusterte Agentengruppe (private oder Cloud-Agenten) verwenden, stellen Sie sicher, dass der Agentenserver, auf dem der temporäre Speicher geschrieben wird, derselbe Server ist, von dem der temporäre Speicher gelesen wird. Achten Sie darauf, dass sich alle Verweise auf die Lese- und Schreibaktivitäten des temporären Speichers in derselben Operation befinden.

  • Temporärer Speicher auf privaten Agenten wird standardmäßig nach 24 Stunden durch den Jitterbit-Dateibereinigungsdienst gelöscht. Die Häufigkeit des Bereinigungsdienstes kann über die private Agent-Konfigurationsdatei konfiguriert werden unter dem [FileCleanup] Abschnitt. Auf Cloud-Agenten können temporäre Dateien jedoch sofort gelöscht werden.

  • Cloud-Agenten haben eine Dateigrößenbeschränkung für den temporären Speicher von 50 GB pro Datei. Temporäre Dateien über 50 GB sind nur bei Verwendung privater Agenten möglich.

  • Beim Schreiben in den temporären Speicher werden Dateien standardmäßig überschrieben. Dies kann mit dem Kontrollkästchen An Datei anhängen in einer Aktivität Schreiben in den temporären Speicher geändert werden. Normalerweise erfordert dies, dass die Datei nach dem Lesen der Quelle gelöscht oder archiviert wird. Eine einfache Möglichkeit hierfür ist die Verwendung der Nachbearbeitungsoptionen Datei löschen oder Datei umbenennen in einer Aktivität zum Lesen des temporären Speichers.

  • Dateinamen-Schlüsselwörter stehen zur Verfügung, die beim Erstellen eines Dateinamens verwendet werden können.

  • Eine Datei im temporären Speicher kann gelesen werden, indem man ein Script mit dem ReadFile Funktion. Zum Beispiel: ReadFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_read/Read</TAG>") Beachten Sie, dass dies nur dann zuverlässig funktioniert, wenn ein einzelner privater Agent vorhanden ist.

In manchen Fällen kann die Verwendung einer Variable vorteilhaft sein Endpoint anstelle eines Endpoint für den temporären Speicher. Siehe Überlegungen zum temporären Speicher (bei Verwendung von Integration Studio) oder Globale Variable versus temporärer Speicher (bei Verwendung von Design Studio) für einen Vergleich dieser beiden unterschiedlichen Typen und für Empfehlungen, wann welcher geeignet ist.

Skripting

In Jitterbit Script geschriebene Scripts Sprache oder JavaScript kann fast überall in Operationen und innerhalb von Transformation verwendet werden.

Wann wird Skripting verwendet?

Operationen können auf zwei Arten in Operation organisiert werden: (1) durch Verknüpfen von Operationen mit den Bedingungen Bei Erfolg und Bei Fehler mithilfe von Operation, oder (2) durch die Verwendung eines Controller Script.

Anstatt Operation zu verwenden, verwendet ein Controller-Script die RunOperation Funktion, um Vorgänge mithilfe eines Script miteinander zu verknüpfen.

Um eine fehlgeschlagene Operation zu erfassen, If Funktion kann in Verbindung mit verwendet werden RunOperation. Zum Beispiel: If(!RunOperation(<operation tag>),<condition>), wobei die Bedingung verwendet werden kann GetLastError um den Fehler zu erfassen und kann den gesamten Prozess stoppen, indem RaiseError, und/oder führen Sie einen anderen Prozess aus, um den Fehlertext zu sammeln.

Ein Controller Script kann in Situationen wie diesen hilfreich sein:

  • Zum eine Operation Durchführen, der von externen Faktoren wie Projektvariablen oder Daten abhängig ist.
  • Zum Aufrufen von Unteroperationen innerhalb einer Schleife, wobei Daten aus einer Liste an die Operation übergeben werden.
  • Zur Verfolgung von Aktivitäten in der Operation. Zum Beispiel: (WriteToOperationLog("count of records to process: " + cnt), WriteToOperationLog("Starting update operation at: " + Now()), WriteToOperationLog("Database query: " + sql), usw.)

Weitere Bereiche, in denen Skripting häufig verwendet wird, sind die zugeordneten Felder in Transformations und andere eigenständige Scripts. Wenn dasselbe Script in mehreren Transformation verwendet wird, empfiehlt es sich, es als eigenständiges Script einzurichten und es innerhalb jeder Transformation mit RunScript.

Namenskonvention für Variablen

Jitterbit iPaaS verfügt über vier Variablentypen:

Da der Umfang einer lokalen Variable auf ein einzelnes Script beschränkt ist, kann die Namenskonvention für sie sehr einfach sein, z. B. nur Kleinbuchstaben oder ein Wort am Anfang, wie z. B. return oder myVariable. Punkte sind in lokalen Variablen nicht zulässig.

Globale Variablen sollten aufgrund ihres größeren Umfangs (eine globale Variable kann in denselben oder nachlegende Operationen und Scripts innerhalb einer Operation referenziert werden) eine einheitliche Namenskonvention verwenden, um Verwirrung zu vermeiden. Wenn Sie beispielsweise mehrere durch Punkte getrennte Komponenten für einen Variablennamen verwenden, könnten Sie einem Muster wie diesem folgen:

type.category.subcategory
Komponente Beschreibung
type Eine kurze Abkürzung, die den Variablentyp identifiziert, z. B. pv(Projektvariable), gv(globale Variable), io (Endpoint-Quell-/Zielname), dict(Wörterbuch) usw.
category Eine logische Kategorie für die Variable, wie zum Beispiel sfdc, shipearly, confirm, order, usw.
subcategory Eine logische Unterkategorie für die Variable, wie zum Beispiel purchase_orders, categories, ids, usw.

Die Kombination dieser Komponenten ergibt folgende Variablennamen:

  • $pv_shopify_base_url- $dict_staples_po_line_items- $io_request- $gv_sfdc_workorder_idDa Variablen an verschiedenen Stellen der Benutzeroberfläche alphabetisch sortiert sind, erleichtert eine hierarchische Anordnung die Verwaltung und Verwendung von Variablen.

Für welche Konvention Sie sich auch entscheiden, wir empfehlen Ihnen, diese zu kodifizieren und zu dokumentieren, damit alle Teammitglieder sie in allen Projekten einheitlich verwenden können.

Notiz

Wenn Sie planen, Jitterbit Script zu verwenden globale Variablen in einem JavaScript Script ist es wichtig, Unterstriche anstelle von Punkten zu verwenden:

  • $example_arr_names
  • $example_sfdc_success_message

Umgebungen

Jitterbit ermöglicht Methoden für den Softwareentwicklungslebenszyklus durch die Nutzung von Umgebungen. Sie können sowohl Produktions- als auch Nicht-Produktionsumgebungen einrichten.

Nehmen wir beispielsweise an, dass in der Management Console eine Entwicklungsumgebung und eine Umfeld eingerichtet sind und beide derselben Agentengruppe zugeordnet sind. Nehmen wir an, dass ein Projekt zunächst in der Umfeld entwickelt wird.

Integration Studio verfügt über eine Migrationsfunktion, wodurch das Projekt in die Umfeld kopiert wird. Anschließend werden die Endpoint mithilfe von Projektvariablen in die Endpoint von Produktion geändert. Andere Quell- und Endpoints werden ebenfalls geändert. Nach der ersten Migration werden bei allen weiteren Migrationen desselben Projekts von Entwicklung nach Produktion keine Projektvariablenwerte mehr migriert, es sei denn, es handelt sich um neue Projektvariablen.

Testen

Jitterbit ermöglicht eine schnelle Integrationsentwicklung und Unit-Tests, indem es die tatsächlichen Integrationsdaten während der Designphase sichtbar macht. Der offensichtliche Vorteil besteht darin, einen iterativen Entwicklungsprozess zu ermöglichen, indem die Daten vor und nach Transformations angezeigt werden, anstatt die gesamte Operation zu erstellen, auszuführen und die Ausgabe zu prüfen. Die Daten werden mithilfe der Vorschaufunktion sichtbar gemacht in einer Transformation.

Nachdem die Beispielquelldaten importiert oder generiert wurden, zeigt die Transformation die Ausgabe aller Zuordnungen und eingebetteten Scripts an.

Fehlerbehebung

Ein Schlüsselkonzept für eine erfolgreiche Integrationsarchitektur besteht darin, zu erkennen, dass das Unternehmen Fragen zur Genauigkeit der Integrationsarbeit stellen wird, insbesondere wenn Abweichungen in den Endpoint auftreten. Die Integration kann fehlerhaft sein, muss aber nicht. Das Integrationsprojekt muss ein hohes Maß an Transparenz gewährleisten, um Fragen zur Datengenauigkeit zu klären.

Wenn beispielsweise Daten in einem Endpoint fehlerhaft erscheinen, wird typischerweise der Integrationssupport hinzugezogen, um Details zu allen Integrationsaktionen bereitzustellen, wie z. B. Zeiten, Quellen, Transformation, Erfolgs- oder Fehlermeldungen usw. Die Bereitstellung dieser Informationen als Standardbestandteil der Integrationsarchitektur trägt zur Fehlerbehebung bei. In Jitterbit iPaaS wird dies durch Logging unterstützt und Alarmierung Merkmale.

Protokollierung {: #jitterbitharmonybestpractices-logging }Betriebsprotokolle erfassen standardmäßig wichtige Daten wie die Laufzeit von Operation sowie Erfolgs-, Fehler- und Abbruchmeldungen. Wenn Fehler auftreten und der Endpoint Fehlerinformationen zurückgibt, werden diese Informationen im Protokoll erfasst.

Bei Fehlern wird die Antwort zur Statusbestimmung verwendet. Wenn beispielsweise in einer Antwort ein HTTP-Statuscode von 400 oder höher empfangen wird, gilt dies als Fehler. Wenn die Anfrage den Status 200 hat, die Antwort jedoch Datenfehler enthält, gilt dies als Erfolg.

Verwenden Sie bei der Entwicklung eines Integrationsprojekts die WriteToOperationLog Funktion in den Mappings und Scripts, um wichtige Daten und Schritte im Prozess zu erfassen. Dies ist in der Regel so einfach wie: WriteToOperationLog("The id is: "+sourcefieldid).

Wenn die Erfassung der gesamten Ausgabe einer Transformation gewünscht ist, kann dies durch die Erstellung einer Operation erfolgen, die die Quelle liest, die Transformation durchführt und die Ausgabe in eine Variable schreibt oder Temporärer Speicher Endpoint anstelle des Endpoint. Ein Post-Operation Script kann die Ausgabe lesen und protokollieren. Anschließend kann die eigentliche Operation ausgeführt werden.

Protokolle können entweder im Integration Studio Operation-Bildschirm oder die Management Console Runtime Operations Seite. Die Management Console Runtime Operations-Seite kann vom Supportpersonal aufgerufen werden, ohne zum Projekt navigieren zu müssen.

Die Protokolldaten sind durchsuchbar. Um nur die benötigten Protokolle herauszufiltern, können Sie die Suchsyntax message=%\<Ihr Text>% sowohl in den Operation von Integration Studio als auch der Management Console verwenden.

APIs verfügen häufig über eine informative Erfolgs- oder Nichterfolgsmeldung. Wenn die debuggen-Protokollierung für die API aktiviert ist, wird der Anforderungstext in den API Protokollen erfasst (die sich von den Operation unterscheiden).

Betriebsprotokolle, einschließlich detaillierter Protokollnachrichten von Cloud-Agenten und privaten Agenten, werden von Harmony 30 Tage lang aufbewahrt.

Alarmierung

Häufig müssen Integrationsergebnisse nicht nur protokolliert, sondern auch eskaliert werden. Email-Benachrichtigungen können einfach an Operationen und Erfolgs-/Fehlerpfade angehängt oder von Scripts aus aufgerufen werden. Alternativ können Sie die Email Connector zum Konfigurieren einer Email senden-Aktivität als Ziel einer Operation.

Weitere Informationen finden Sie unter Alarme, Protokollierung und Fehlerbehandlung einrichten.

Zusätzliche Ressourcen

Diese Abschnitte und Seiten der Dokumentation bieten zusätzliche Best Practices.

Tech-Gespräche {: #tech-talks }Jitterbit-Tech-Talks sind Videopräsentationen, die für Nutzer aller Erfahrungsstufen interessante Bereiche abdecken:

Tech Talk Dauer Veröffentlichungsdatum
API -Proxy 39:53 09.01.2019
APIs 49:22 07.08.2018
Integration Studio 43:53 14.05.2019
Best Practices für die Orchestrierung komplexer Projekte 50:46 16.10.2018
Konnektor-Generator 50:19 16.07.2019
Umgebungen 1:04:22 04.04.2018
Externe Speicherung und Verwaltung von Anmeldeinformationen 46:58 09.10.2020
Best Practices zur Fehlerbehandlung 27:22 13.03.2018
Jitterbit-Best Practices 1:04:38 16.03.2020
Bewährte Vorgehensweisen zur Protokollierung 1:03:02 2019.02.12
API Portal-Manager öffnen 57:21 05.11.2019
Best Practices für Pass-Through-Quellen und globale Variablen 42:44 05.12.2018
Best Practices für private Agenten 42:43 05.07.2018
Prozessvorlagen 43:27 08.07.2020
Best Practices für die Projektorganisation 1:08:39 08.06.2018

Dokumentation

Die Jitterbit-Dokumentation enthält Best Practices auf unseren Seiten zur Verwendung von Jitterbit-Produkten:

Sicherheit

Methodik für Integrationsprojekte

  • Methodik des Integrationsprojekts
    Wichtige Punkte, die ein Projektmanager für an Integration Studio Projektleiter sollten wissen, wie sie ihr Team organisieren, Anforderungen klar und prägnant erfassen und validieren und die Stärken von Jitterbit iPaaS nutzen, um ein erfolgreiches Integrationsprojekt durchzuführen.

Projekte erstellen

Protokollierung

Private Agenten