Zum Inhalt springen

Bewährte Methoden für Jitterbit iPaaS

Einführung

Dieses Dokument dient als allgemeiner Leitfaden zur Verwendung der Jitterbit-Integrationsplattform als Service (iPaaS). Es bietet Best-Practice-Anleitungen 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 bei der Verwendung von Design Studio, Jitterbits desktopbasierte 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 vertraut sein und Integration Studio aus den folgenden Ressourcen:

An diesem Punkt sollten Sie die grundlegenden Konzepte und Begriffe kennen, die in Jitterbit iPaaS verwendet werden, und wissen, was wir mit Projekten, Operationen, Endpunkten, Skripting, Migration und Bereitstellung meinen.

Siehe die Zusätzlichen Ressourcen am Ende dieser Seite mit Links zu Videos und anderen Dokumenten, die diese Best Practices näher erläutern.

Support, Customer Success Manager und Dokumentation

Der Zugriff auf den Jitterbit-Support ist Teil einer Harmony Kundenlizenz. Wenn Fragen oder technische Probleme auftreten, können Sie vom Jitterbit-Support kompetente Unterstützung erhalten. Der Jitterbit-Support Seite beschreibt 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 das Auffinden relevanter Materialien zu erleichtern, ist das Suchfeld vorgefiltert und beschränkt die Suchergebnisse auf den Abschnitt der Dokumentation, auf den aktuell zugegriffen wird. Sie können die gesamte Dokumentation durchsuchen, indem Sie den Suchfilter löschen. Um nach bestimmten Ausdrücken zu suchen, schließen Sie diese in Anführungszeichen ein.

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 sind darauf ausgelegt, die Bereitstellungszeit um 50 bis 80 Prozent zu verkürzen.

Jitterbit-Produktaktualisierungen

Jitterbit-Produktupdates werden regelmäßig veröffentlicht (siehe Veröffentlichungsplan). 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-Agent-Gruppen gibt es zwei Sets: Produktion und Sandbox. Letzteres Set wird zum Testen der Kompatibilität mit Vorabversionen der Agent-Software verwendet und ist keine Umfeld.

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

Es ist ratsam, sich über aktuelle Versionen zu informieren, insbesondere über Versionen mit Funktionsupgrades.

Einfachheit des Projektdesigns und bevorzugte Funktionen

Beim Entwerfen 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, immer das übergeordnete Leitprinzip der Einfachheit im Hinterkopf zu behalten. Projekte, die so einfach wie möglich gestaltet sind, haben in der Regel eine längere Lebensdauer und sind für Außenstehende viel einfacher zu verstehen, wenn eine Änderung vorgenommen werden muss. Andererseits können übermäßig komplexe Projekte schwieriger zu pflegen und bei einem Übergang der Verantwortung an andere zu übergeben sein.

Für die Gestaltung einfacherer Projekte 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 umfasst die Entwicklung eines Starter-Projekts mit umfassender Verwendung von globalen Variablen und insbesondere Projektvariablen. Konfigurierbare Elemente - wie Endpoint, optionale Feldzuordnungen, parametrisierte Abfragen, Email-Adressen und Dateinamen - können als Projektvariablen verfügbar gemacht werden. Das Starterprojekt kann auch allgemeine Funktionen wie Fehlerbehandlung oder die Verwendung umgebungsweiter Caches enthalten. Das Starterprojekt wird exportiert und dann in neue Projekte importiert, um eine konsistente Grundlage für die Entwicklung zu bilden.

Endpoint

Endpoints, erstellt durch Konfigurieren einer Verbindung und zugehöriger Aktivitäten mithilfe von Konnektoren, werden häufig in Operationen verwendet. Allerdings muss 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 einmal erstellt und dann mithilfe globaler und Projektvariablen dynamisch konfiguriert werden.

Nehmen wir zum Beispiel 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 Datenbank-Abfrage-Aktivitä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

Standalone 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 diese Funktion wird 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 Umfang hat, kann dasselbe Script problemlos von mehreren gleichzeitigen Operationen aufgerufen werden.

Projektorganisation

Workflows werden als Mittel zur Projektorganisation verwendet. Ein Workflow enthält normalerweise verwandte Vorgänge, die Daten von Anfang bis Ende verarbeiten: Aufträge erstellen, Kundenstamm synchronisieren, Bestätigungen verarbeiten usw. Prozesse, die in verschiedenen Workflows üblich sind, wie z. B. das Abfragen eines Endpoint oder das Behandeln eines Operation, können in einem eigenen Workflow enthalten sein 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 zugewiesen 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 die Einbindung der Nummerierung in den Operation implementiert werden.

Verwalten asynchroner Vorgänge

Bei Verwendung der RunOperation Funktion 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.

Wenn beispielsweise Operation A eine Datenbanktabelle aktualisiert und an Operation B gekettet ist, die dieselbe Tabelle liest (beide sind synchron), treten keine Race Conditions auf. Wenn jedoch Operation A asynchron aufgerufen wird und unmittelbar darauf Operation B folgt, 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, die auf einem Agenten ausgeführt werden, begrenzt ist (siehe [OperationEngine] Abschnitt der privaten Agentenkonfigurationsdatei).

Endpoint

Wir empfehlen, für Endpoint eine System-ID mit Administratorberechtigungen anstelle einer ID auf Benutzerebene zu verwenden. Benutzer-IDs laufen normalerweise ab oder müssen deaktiviert werden, wenn ein Benutzer ein Unternehmen verlässt.

Durch die Verwendung von Projektvariablen (deren Werte ausgeblendet werden können) für die 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 Management Console auch mit dem [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 bearbeitet werden von Integration Studio(siehe Projektvariablen) oder die Management Console (siehe Projekte).

Ein Beispiel für die Verwendung von Projektvariablen sind Endpoint. Durch die Verwendung von Projektvariablen können verschiedene Endpoint (die normalerweise 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 der Projektdesigner.

Ein zweites Beispiel ist die Verwendung von Projektvariablen, um Flags zu speichern, die von der Integrationslogik verwendet werden, die das Verhalten der Integration anpassen können. Wenn ein einzelnes Projekt entwickelt wird, aber für verschiedene Endpoints verwendet wird, könnte eine boolesche Projektvariable (wie Send_PO_Number) von der Logik der Transformation für das Feld PO Number überprüft werden. Wenn der Wert der Projektvariablen falsch ist, dann UnMap 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 sichtbar, die im selben Bereich ausgeführt werden, bis er abläuft, unabhängig davon, wie dieser Operation gestartet wurde oder auf welchem Agenten er ausgeführt wird. Durch das Zwischenspeichern von Daten in Harmony, anstatt sich auf lokale oder agentenspezifische Datenspeicher wie Temporary Storage zu verlassen können Daten zwischen einzelnen Vorgängen und über Projekte hinweg gemeinsam genutzt werden.

Dies sind weitere Einsatzmö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 Ansammlung von Operation auf diese Weise können umfassendere Warnungen erstellt werden.
  • Anmeldetoken können betriebsübergreifend genutzt werden.

Temporären Speicher verwalten

Temporärer Speicher Endpoints werden häufig in Operationen sowohl auf Cloud- als auch auf privaten Agenten verwendet. Diese unterscheiden sich von Local Storage 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 Standard-Temp-Verzeichnis dieses privaten Agent-Servers.
  • Wenn Sie mehr als einen privaten Agenten verwenden, die in einer privaten Agentengruppe zusammengefasst sind, ist das temporäre Speicherverzeichnis das temporäre Standardverzeichnis des spezifischen privaten Agentenservers, der die Arbeit ausführt.
  • Da Cloud-Agenten in einer Cloud-Agenten-Gruppe gruppiert sind, ist das temporäre Speicherverzeichnis das temporäre Standardverzeichnis des spezifischen Cloud-Agenten-Servers, der die Arbeit ausführt.

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

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

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

  • Um bei Verwendung einer geclusterten Agentengruppe (private oder Cloud-Agenten) sicherzustellen, dass der Agentenserver, auf den 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 Schreib-Aktivitä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]/agent/cleanuprules/ gelöscht. Die Häufigkeit des Bereinigungsdienstes kann über die Konfigurationsdatei des privaten Agenten 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 größer als 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 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. Beispiel: ReadFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_read/Read</TAG>"). Bedenken Sie, dass dies nur zuverlässig funktioniert, wenn es einen einzigen privaten Agenten gibt.

In einigen Fällen kann es vorteilhaft sein, eine Variable zu verwenden Endpoint anstelle eines Endpoint für temporären Speicher. Siehe Variabler versus temporärer Speicher in Globale Variable versus Temporärer Speicher für einen Vergleich dieser beiden unterschiedlichen Typen und für Empfehlungen, wann welcher geeignet ist.

Skripterstellung

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 unter Verwendung der Bedingungen Bei Erfolg und Bei Fehler mithilfe von Operation oder (2) durch 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 verwendet werden in Verbindung mit RunOperation. Zum Beispiel: If(!RunOperation(<operation tag>),<condition>), wobei die Bedingung verwendet werden kann GetLastError um den Fehler zu erfassen, und können den gesamten Prozess stoppen mit RaiseError, und/oder führen Sie einen anderen Prozess aus, um den Fehlertext zu sammeln.

In Situationen wie diesen kann ein Controller-Script 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.)

Andere Bereiche, in denen Skripte häufig verwendet werden, sind die zugeordneten Felder in Transformations und andere eigenständige Scripts. Wenn dasselbe Script in mehreren Transformation verwendet wird, sollten Sie es als eigenständiges Script einrichten und es aus jeder Transformation heraus aufrufen, indem Sie RunScript.

Namenskonvention für Variablen

Jitterbit iPaaS hat vier Variablentypen:

Da der Gültigkeitsbereich 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 Anfangswort wie return oder myVariable. Punkte sind in lokalen Variablen nicht zulässig.

Globale Variablen sollten, da ihr Umfang größer ist (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 Komponenten für einen Variablennamen verwenden, die durch Punkte getrennt sind, könnten Sie einem Muster wie diesem folgen:

type.category.subcategory
Komponente Beschreibung
type Eine kurze Abkürzung, die den Variablentyp identifiziert, beispielsweise 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 z. B. purchase_orders, categories, ids, usw.

Wenn man diese Komponenten kombiniert, sind dies mögliche Variablennamen:

  • $pv_shopify_base_url- $dict_staples_po_line_items- $io_request- $gv_sfdc_workorder_id

Da Variablen an verschiedenen Stellen in der Benutzeroberfläche alphabetisch sortiert sind, erleichtert die hierarchische Organisation die Verwaltung und Verwendung von Variablen.

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

Notiz

Wenn Sie Jitterbit Script verwenden möchten globale Variablen in einem JavaScript Script ist es wichtig, Unterstriche statt Punkte zu verwenden:

  • $example_arr_names
  • $example_sfdc_success_message

Umgebungen

Jitterbit ermöglicht Methoden für den Softwareentwicklungslebenszyklus durch die Verwendung von Umgebungen. Sie können sowohl Produktionsumgebungen 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 schließen alle weiteren Migrationen desselben Projekts von Entwicklung nach Produktion die Migration von Projektvariablenwerten aus, es sei denn, es handelt sich um neue Projektvariablen.

Testen

Jitterbit ermöglicht eine schnelle Integrationsentwicklung und Unittests, indem es die tatsächlichen Integrationsdaten während der Designzeit sichtbar macht. Der offensichtliche Vorteil besteht darin, dass ein iterativer Entwicklungsprozess ermöglicht wird, indem die Daten vor und nach Transformations angezeigt werden, anstatt die gesamte Operation zu erstellen, auszuführen und die Ausgabe zu prüfen. 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 gesunde Integrationsarchitektur besteht darin, zu erkennen, dass das Unternehmen Fragen zur Genauigkeit der Integrationsarbeit stellen wird, insbesondere wenn Unstimmigkeiten in den Endpoint auftreten. Der Fehler kann bei der Integration liegen, muss es aber nicht. Das Integrationsprojekt muss ein hohes Maß an Transparenz bieten, um Fragen zur Datengenauigkeit zu klären.

Wenn beispielsweise Daten in einem Endpoint falsch zu sein scheinen, wird normalerweise der Integrationssupport herangezogen, um Einzelheiten zu allen Integrationsaktionen bereitzustellen, wie etwa Zeiten, Quellen, Transformation, Erfolgs- oder Fehlermeldungen usw. Der Fehlerbehebungsprozess profitiert davon, wenn diese Informationen als Standardteil der Integrationsarchitektur verfügbar gemacht werden. In Jitterbit iPaaS wird dies durch Protokollierung unterstützt und Alarmierung Merkmale.

Protokollierung

Betriebsprotokolle erfassen standardmäßig wichtige Daten, wie etwa Laufzeiten von Operation sowie Erfolgs-, Fehler- oder 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 400 oder höher empfangen wird, wird dies als Fehler gewertet. Wenn die Anfrage einen Status von 200 hat, die Antwort jedoch Datenfehler enthält, wird dies als Erfolg gewertet.

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

Wenn die gesamte Ausgabe einer Transformation erfasst werden soll, 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. Dann kann die „eigentliche“ Operation ausgeführt werden.

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

Die Daten in den Protokollen sind durchsuchbar. Um nur die Protokolle herauszufiltern, die Sie benötigen, können Sie die Suchsyntax message=%\<Ihr Text>% sowohl in der Integration Studio und Operation der Management Console.

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

Betriebsprotokolle, einschließlich detaillierter Protokollmeldungen 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 aus Scripts aufgerufen werden. Alternativ können Sie auch die Email-Connector zum Konfigurieren einer Email senden-Aktivität als Ziel einer Operation.

Weitere Informationen finden Sie unter Einrichten von Warnmeldungen, Protokollierung und Fehlerbehandlung.

Zusätzliche Ressourcen

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

Technische Gespräche

Technische Gespräche zu Jitterbit sind Videopräsentationen, die Bereiche abdecken, die für Benutzer aller Erfahrungsstufen von Interesse sind:

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
Bewährte Vorgehensweisen zur Fehlerbehandlung 27:22 13.03.2018
Best Practices für Jitterbit 1:04:38 16.03.2020
Bewährte Vorgehensweisen bei der 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
Bewährte Vorgehensweisen 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 Projekt wissen sollte, einschließlich der Organisation Ihres Teams, der klaren und präzisen Erfassung und Validierung von Anforderungen und der Nutzung der Stärken von Jitterbit iPaaS, um ein erfolgreiches Integrationsprojekt abzuliefern.

Projekte erstellen

Protokollierung

Private Agenten