Zum Inhalt springen

Best Practices für Jitterbit Design Studio

Einführung

Dieses Dokument dient als Leitfaden zur Verwendung von Harmony mit Design Studio, der desktopbasierten Projektanwendung von Jitterbit. Für Best Practices zur Verwendung von Integration Studio, der webbasierten Version der Projektanwendung von Jitterbit, siehe Harmony Best Practices.

Dieses Dokument ist nicht als umfassend gedacht und deckt nicht alle Integrationsszenarien ab. Vielmehr soll es eine Anleitung für gängige Integrationsszenarien bieten und die besten Entscheidungen bei der Nutzung der vielen Werkzeuge empfehlen, die einem Jitterbit-Nutzer zur Verfügung stehen.

Diese Seite liest sich am besten, nachdem Sie sich mit Jitterbit vertraut gemacht haben: Sie haben die Seite Erste Schritte durchgesehen, die Kurse der Jitterbit University abgeschlossen und möglicherweise ein Integrationsprojekt eigenständig durchgeführt. Zu diesem Zeitpunkt kennen Sie die grundlegenden Konzepte und Begriffe, die in Jitterbit verwendet werden, und verstehen, was Jitterbit mit Projekten, Operationen, Quellen, Zielen, Scripting und Deployment meint.

Dieses Dokument ist eine Zusammenfassung der Funktionen, die über Harmony 9.9 verfügbar sind. Ab Frühling 2019 steht das webbasierte Integration Studio als Ersatz für die desktopbasierte Design Studio Anwendung zur Verfügung.

Siehe den Abschnitt Zusätzliche Ressourcen unten für Links zu Videos und anderen Dokumenten, die die Best Practices mit Jitterbit erweitern.

Support, Customer Success Manager und Dokumentation

Der Zugang zum Jitterbit-Support ist Teil einer Harmony-Kundenlizenz. Wenn Fragen oder technische Probleme auftreten, können Sie fachkundige Unterstützung vom Jitterbit-Support erhalten. Die Seite Jitterbit Support beschreibt spezielle Anweisungen für Produktionsausfälle, um zeitkritische Probleme zu eskalieren.

Sie können auch Ihren Customer Success Manager (CSM) mit Fragen zu Lizenzen oder anderen Themen kontaktieren.

Diese Dokumentationsseite (Jitterbit Documentation) enthält mehr als 3.600 einzigartige URLs mit technischem Material.

Jitterbit-Produktupdates

Harmony-Updates werden häufig veröffentlicht (siehe Release schedule). Selbst ein kleines Update enthält neue Funktionen und Verbesserungen sowie Fehlerbehebungen.

Webanwendungen, die über das Harmony-Portal aufgerufen werden, werden automatisch aktualisiert und laufen immer in der neuesten veröffentlichten Version.

Updates für das Cloud API-Gateway und die Cloud-Agenten-Gruppe werden automatisch angewendet. Für die Cloud-Agenten-Gruppen gibt es zwei Sätze: Produktion und Sandbox. Letzterer Satz wird verwendet, um die Kompatibilität mit Vorabversionen der Agentensoftware zu testen und ist kein Entwicklungsumfeld.

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

Es wird empfohlen, mit den Releases auf dem Laufenden zu bleiben, insbesondere mit den Releases, die Funktionsupgrades enthalten.

Projektorganisation und -design

Wiederverwendbarkeit

Projektwiederverwendbarkeit

Ein typisches Szenario für die Wiederverwendung eines Projekts umfasst die Entwicklung eines "Standard"-Projekts mit umfangreicher Nutzung von globalen Variablen und – insbesondere – Projektvariablen. Konfigurierbare Elemente – wie Endpunktanmeldeinformationen, optionale Feldzuordnungen, E-Mail-Adressen, Dateinamen – können als Projektvariablen bereitgestellt werden. Das "Standard"-Projekt wird in mehreren Umgebungen bereitgestellt, und über die Management-Konsole werden die Projektvariablen für jede Umgebung befüllt.

Quelle/Ziel-Wiederverwendung

Obwohl Dateiquellen und -ziele häufig in Operationen verwendet werden, muss nicht unbedingt für jede Operation ein neues Quellen/Ziel-Paar erstellt werden. Da Dateiquellen und -ziele globale Variablen für Pfad und Dateinamen akzeptieren, können Quellen und Ziele für ähnliche Operationen einmal erstellt und über globale Variablen gesteuert werden. Angenommen, "Quelle" und "Ziel"-Objekte werden erstellt, und im Dateinamenfeld steht [filename]. Die $filename-Variable kann an beliebiger Stelle gesetzt werden, bevor das Ziel geschrieben wird, und wird verwendet.

Dies gilt für Datenbank-, File Share-, FTP-Standort-, lokale Datei- und HTTP-Quellen und -ziele.

Skriptwiederverwendbarkeit

Eigenständige Skripte, die eine spezifische Funktion ausführen, wie z. B. eine Datenbankabfrage durchzuführen oder ein Ergebnis aus einer Reihe von Argumenten bereitzustellen, können Kandidaten für die Wiederverwendung sein, insbesondere wenn sie in mehreren Operationen verwendet werden.

Wenn ein Skript beispielsweise die Funktion DBLookup() gegen eine Datenbanktabelle verwendet und diese Funktion in der gesamten Integration verwendet wird, kann ein eigenständiges Skript (getrennt von einer Operation) erstellt werden. Mit der Funktion ArgumentList() oder einfachen globalen Variablen kann es Argumente akzeptieren und ein Ergebnis zurückgeben. Da jede Operationkette einen anderen Geltungsbereich hat, kann dasselbe Skript sicher aus mehreren gleichzeitigen Operationen aufgerufen werden.

Hinweis

Wenn Sie Ihre Projekte auf einem Dateiserver speichern, werden Änderungen, die an einem Projekt vorgenommen werden, die ausschließlich die Benutzeroberfläche betreffen (zum Beispiel, wenn Sie Objekte in einer Ansicht neu anordnen), nicht beibehalten, wenn Sie das Projekt erneut öffnen.

Infolgedessen empfiehlt Jitterbit nicht, Projekte auf einem Dateifreigabe zu speichern, da:

  • Änderungen an der Benutzeroberfläche (Anordnung der Objekte) beim Speichern einer Datei nicht beibehalten werden
  • Die Leistung leidet: Das Laden und Speichern eines Projekts kann aufgrund fehlender Caching-Mechanismen träge sein
  • Andere Benutzer im Netzwerk können Änderungen, die an einem Projekt vorgenommen werden, überschreiben, da es an Dateisperren fehlt

Organisieren Sie die Operationen in einem Projekt

Design Studio bietet Operationsordner und sortiert die Operationen alphabetisch, wenn ein Projekt erneut geöffnet wird. Durch die Verwendung eines Nummerierungsschemas beim Benennen von Operationen und Ordnern wird der Integrationsfluss klarer und die Fehlersuche erleichtert.

Beispiel: Angenommen, es gibt zwei Integrationsflüsse; einen für Kundenstamm und einen zweiten für Artikelstamm, jeweils mit zwei Operationen. In Design Studio können zwei Ordner, "Kundenstamm" und "Artikelstamm", erstellt werden. Im ersten Ordner könnten die Operationen "CM001 Kunde abrufen" und "CM002 Kunde aktualisieren" genannt werden. Im zweiten Ordner könnten die Operationen dann "IM001 Artikel abrufen" und "IM002 Artikel aktualisieren" heißen:

attachment

Das Operationsprotokoll kann dann leicht die Schritte in der Integrationskette anzeigen und ob Schritte fehlen. Durch einen Rechtsklick auf einen Ordner in Design Studio zeigt die Operationsliste nur die Operationen eines Ordners an. Eine konsistente Organisationsstruktur und Benennung erleichtert es jemandem, der neu in einem Projekt ist, den grundlegenden Operationsfluss schnell zu erfassen.

Verwalten von Wettlaufbedingungen bei der Verwendung asynchroner Operationen

Bei der Verwendung der Funktion RunOperation() im asynchronen Modus werden Operationen ausgeführt, ohne die Kontrolle an den Aufrufer zurückzugeben. Die Verwendung asynchroner Operationen kann zu Wettlaufbedingungen führen.

Wenn beispielsweise Operation A eine Datenbanktabelle aktualisiert und an Operation B angekettet ist, die dieselbe Tabelle liest (beide sind synchron), treten keine Wettlaufbedingungen auf. Wenn jedoch Operation A asynchron aufgerufen wird, gefolgt von Operation B, kann B ausgeführt werden, bevor A abgeschlossen ist.

Endpoint-Anmeldeinformationen

Verwenden Sie eine System-ID mit Administrationsberechtigungen als Anmeldeinformationen für den Endpunkt, anstelle einer Benutzer-ID. Benutzer-IDs laufen typischerweise ab oder müssen deaktiviert werden, wenn der Benutzer das Unternehmen verlässt.

Durch die Verwendung von Projektvariablen (deren Werte verborgen werden können) für das Management der Anmeldeinformationen muss der Jitterbit-Administrator keine Produktionsanmeldeinformationen eingeben. Dies kann von einem Benutzer über die Management-Konsole durchgeführt werden. Dieser Ansatz kann bei Bedarf auch für E-Mail-Anmeldeinformationen verwendet werden.

API-Verwaltung

Der API-Manager sollte anstelle von HTTP-Endpunkten verwendet werden. HTTP-Endpunkte waren eine Möglichkeit, um eingehende Anrufe mit geringem Datenverkehr zu verwalten, und erforderten, dass bestimmte Netzwerkports geöffnet sind, was viele Unternehmen heute als ernstes Sicherheitsrisiko betrachten.

Der API-Manager und sein API-Gateway sind für eine hohe Leistungsfähigkeit ausgelegt, führen detaillierte Protokollierungen durch, implementieren gängige Sicherheitsmaßnahmen und verfügen über eine benutzerfreundliche Designoberfläche, die Teil der Harmony-Plattform ist. Es müssen keine Netzwerkports konfiguriert werden, um eingehenden Datenverkehr zu verarbeiten.

Ein API-Manager-API sollte für Echtzeit-/ereignisgesteuerte Integrationsmuster verwendet werden. Zum Beispiel: Endpunkt A hat die Fähigkeit, eine API wie Salesforce über ausgehende Nachrichten aufzurufen. Eine API-Manager-API kann schnell implementiert und an eine Kette von Operationen gebunden werden.

Der bevorzugte Ansatz zur Beantwortung eines Anrufs besteht darin, dies so schnell wie möglich zu tun. Wenn das Integrationsdesign so ist, dass die nachfolgenden Operationen erheblich Zeit in Anspruch nehmen, besteht das Risiko eines Timeouts oder das Risiko, dass andere eingehende Anrufe die Fähigkeit des Zielendpunkts, zu antworten, überwältigen.

Wenn der Quellendpunkt viele Anrufe pro Minute tätigt und das Gateway des Zielendpunkts nur eine bestimmte Anzahl von Verbindungen verarbeiten kann, ist es möglich, dass der Zielendpunkt nicht in der Lage ist, die Anfragen zu skalieren. In diesem Fall kann es der bevorzugte Ansatz sein, asynchron zu antworten. Das bedeutet, dass die Antwort sofort erfolgt und der Datensatz vom Zielendpunkt über einen Anruf an die API des Quellendpunkts gesendet wird.

Persisting integration data

Es gibt viele Szenarien, in denen es hilfreich sein kann, Daten "in der Cloud" zu speichern. Jitterbit bietet mehrere Methoden: Projektvariablen, Cloud-Caching-Funktionen und temporäre Speicherung.

Project variables

Projektvariablen sind vorinitialisierte statische Variablen (ähnlich wie Projekt-"Konstanten"), die aus dem Design Studio oder der Management Console bearbeitet werden können.

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

Ein zweites Beispiel ist die Verwendung von Projektvariablen zur Speicherung von Flags, die von Integrationslogik verwendet werden, um das Verhalten der Integration anzupassen. Wenn ein einzelnes Projekt entwickelt, aber für verschiedene Endpunkte verwendet wird, könnte eine boolesche Projektvariable (wie "Send_PO_number") von der Logik der Transformation für das PO-Nummerfeld überprüft werden. Wenn der Wert der Projektvariablen falsch ist, könnte der Befehl UnMap() verwendet werden, um dieses Feld "auszuschalten".

Cloud caching functions

Cloud-Cache-Funktionen (ReadCache() und WriteCache()) sind zuweisbare Datenräume, die über Projekte und Umgebungen hinweg verfügbar sind. Ein zwischengespeicherter Wert ist für alle Operationen, die im selben Geltungsbereich ausgeführt werden, sichtbar, bis er abläuft, unabhängig davon, wie diese Operation gestartet wurde oder auf welchem Agenten sie ausgeführt wird. Durch das Caching von Daten in Harmony, anstatt sich auf lokale oder agentenspezifische Datenspeicher zu verlassen, können Daten zwischen separaten Operationen und über Projekte hinweg geteilt werden.

Zusätzliche Verwendungen des Cloud-Cachings umfassen:

  • Daten können zwischen asynchronen Operationen innerhalb eines Projekts geteilt werden.
  • Fehler, die in verschiedenen Operationen generiert werden, können in einem gemeinsamen Cache gespeichert werden. Durch die Verwendung dieses Caches zur Ansammlung von Operationsergebnissen können umfassendere Warnmeldungen erstellt werden.
  • Anmeldetoken können zwischen Operationen geteilt werden.

Temporären Speicher verwalten

Temporärer Speicher wird häufig in Integrationsoperationen verwendet. Dies unterscheidet sich von lokalen Dateien (Quellen oder Zielen), die nur auf privaten Agenten verwendet werden können. Beachten Sie diese Richtlinien, insbesondere wenn Sie auf eine clusterbasierte Umgebung hinarbeiten:

  • Machen Sie Ihr Projekt "upgrade-fähig" und verwenden Sie temporären Speicher so, dass der Wechsel von einem einzelnen Server zu einer clusterbasierten Umgebung keine Umstrukturierung erfordert.

  • Temporärer Speicher wird im Standard-Temp-Verzeichnis des Betriebssystems auf dem Agenten geschrieben, der die Arbeit ausführt. Im Fall eines einzelnen privaten Agenten ist es das Standard-Temp-Verzeichnis des Servers dieses privaten Agenten. Wenn Sie mehr als einen privaten Agenten verwenden, ist es das Standard-Temp-Verzeichnis des Serverhosts für den Agenten, der die Arbeit ausführt. Wenn Sie einen Cloud-Agenten verwenden (der clusterbasiert ist), ist es das Standard-Temp-Verzeichnis des jeweiligen Cloud-Agenten-Serverhosts.

  • Standardmäßig wird der temporäre Speicher nach 24 Stunden von einem Jitterbit-Reinigungsdienst gelöscht. Im Fall von Cloud-Agenten kann dies sofort geschehen.

  • Ein einfacher Ansatz besteht darin, ein Ziel zu erstellen, ihm einen eindeutigen Namen zu geben und dann "In neue Quelle kopieren" zu verwenden, um eine Quelle mit demselben Dateinamen zu erstellen. Das Ziel und die Quellen sind tatsächlich unabhängig und basieren auf der Verwendung desselben Dateinamens, um Lese- und Schreibvorgänge zu synchronisieren.

  • In einer clusterbasierten Agenten-Umgebung (private oder Cloud-Agenten) werden alle Lese- und Schreibvorgänge im temporären Speicher auf demselben Serverhost durchgeführt, solange die Operationen, die den temporären Speicher verwenden, miteinander verknüpft (verkettet) sind. Wenn jedoch die Operationenkette A in den temporären Speicher "myfile" schreibt und die Operationenkette B den temporären Speicher "myfile" liest, kann die Leseaktion inkonsistent sein, da sie möglicherweise nicht denselben Serverhost wie Kette A liest.

    Hinweis

    Verkettete Operationen werden immer auf demselben Agenten wie die übergeordnete Operation ausgeführt, unabhängig von der Synchronität.

  • Für Ziele ist die Standardeinstellung, die Datei zu überschreiben. Dies kann mit der Option "An Datei anhängen" geändert werden. In der Regel erfordert dies, dass die Datei nach dem Lesen der Quelle gelöscht oder archiviert wird. Eine einfache Möglichkeit, dies zu tun, besteht darin, "Datei löschen" oder "Datei umbenennen" in der Quelle auszuwählen.

  • Dateinamen-Schlüsselwörter sind verfügbar, die beim Erstellen eines Dateinamens verwendet werden können.

  • Eine Datei im temporären Speicher kann schnell gelesen werden, indem ein Skript mit der Funktion ReadFile() erstellt wird, wie zum Beispiel ReadFile("<TAG>Sources/test</TAG>"). Beachten Sie, dass dies nur zuverlässig funktioniert, wenn es einen einzelnen privaten Agenten gibt.

Siehe Globale Variable versus Temporärer Speicher für einen Vergleich dieser beiden Typen und Empfehlungen, wann jeder geeignet ist.

Scripting

Wann man Scripting verwenden sollte

Obwohl Jitterbit eine robuste Scripting-Funktionalität bietet, sollte Scripting nur verwendet werden, wenn es notwendig ist. Wenn die Wahl zwischen Scripting oder einer Standardmethode besteht, sollte die Standardmethode bevorzugt werden. Eine "Standardmethode" ist eine Methode, die über die Benutzeroberfläche von Jitterbit Design Studio bereitgestellt wird, um eine Aufgabe zu erfüllen.

Ein Beispiel wäre die Organisation von Betriebsabläufen. Die Benutzeroberfläche von Jitterbit Design Studio ermöglicht es Ihnen, "Betriebsketten" zu erstellen, die durch Erfolgs- und Fehlermeldungswege verbunden sind. Alternativ ist es möglich, eigenständige Operationen zu erstellen und diese dann mithilfe von Scripting und der Funktion RunOperation() zu verknüpfen. Es sei denn, es gibt technische Anforderungen, die diesen Ansatz erfordern (wie die Verwendung von asynchronen oder optionalen Pfaden), wird empfohlen, sich auf die Benutzeroberflächenmethode von Jitterbit zu verlassen, um verschiedene Operationen miteinander zu verknüpfen.

Scripting ist im Allgemeinen an zwei Stellen am besten: innerhalb des Formel-Generators in Transformationen und in eigenständigen Skripten. Wenn derselbe Code in mehr als einer Transformation verwendet wird, ziehen Sie in Betracht, diesen Code in ein eigenständiges Skript zu verschieben und es von jeder Transformation aus mit RunScript() aufzurufen.

Benennungsrichtlinie für Variablen

Jitterbit hat vier Arten von Variablen:

  • lokale Variablen
  • globale Variablen
  • Projektvariablen
  • Jitterbit-Variablen

Lokale und globale Variablen werden in Jitterbit-Skripten erstellt; Projektvariablen werden im Jitterbit Design Studio definiert; Jitterbit-Variablen sind im Jitterbit-System vordefiniert.

Da der Geltungsbereich einer lokalen Variablen auf ein einzelnes Skript beschränkt ist, kann eine Benennungsrichtlinie für diese sehr einfach sein, wie zum Beispiel nur Kleinbuchstaben oder ein Anfangswort, wie "return" oder "myVariable".

Globale Variablen, da ihr Geltungsbereich größer ist (eine globale Variable kann in denselben oder nachgelagerten Operationen und Skripten innerhalb einer Operationskette referenziert werden), sollten eine konsistente Benennungsrichtlinie verwenden, um unbeabsichtigte Wiederverwendung zu vermeiden. Zum Beispiel, indem man mehrere Komponenten für einen Variablennamen verwendet, die durch Punkte getrennt sind, könnte man einem Muster folgen wie:

first.second.third[.fourth]

wobei:

  • Erste Komponente: org-Spezifizierer
  • Zweite Komponente: ein Typ, wie id, error, date, file, token, timestamp, timezone, flag, email, guid, user, externalid, val (für einen allgemeinen Wert), arr (für ein Array) oder ein Endpunkttyp wie sfdc
  • Dritte Komponente: Variablenname
  • Vierte Komponente: optionaler Untervariablenname

Durch die Kombination dieser Komponenten und unter der Annahme, dass Ihr Org-Name example ist, könnten Variablennamen sein:

  • $example.arr.names
  • $example.sfdc.success.message

Da Projektvariablen über die Management-Konsole sichtbar sind und im Allgemeinen verwendet werden, um das Integrationsverhalten zu konfigurieren, können freundlichere Namen verwendet werden. Da ein Projektvariablenname keine Leerzeichen enthalten kann, können stattdessen Unterstriche verwendet werden. Zum Beispiel: "Start_Date" und "Include_Assemblies".

Welche Konvention Sie auch immer wählen, wir empfehlen, diese zu kodifizieren und zu dokumentieren, damit alle Teammitglieder sie in allen Projekten konsistent verwenden können.

Warnung

Wenn Sie planen, Ihre Jitterbit globalen Variablen in einem JavaScript-Skript zu verwenden, ist es wichtig, Unterstriche anstelle von Punkten zu verwenden:

  • $example_arr_names
  • $example_sfdc_success_message

Umgebungen und Bereitstellungen

Jitterbit ermöglicht Softwareentwicklungslebenszyklus-Methoden durch die Verwendung von Umgebungen und Bereitstellungsoptionen.

Umgebungen

In Harmony kann die Umgebungsfunktion verwendet werden, um Produktions- und Nicht-Produktionsumgebungen einzurichten.

Angenommen, es sind eine "Dev"- und eine "Prod"-Umgebung im Management Console eingerichtet, und beide sind der Agentengruppe A zugewiesen. Projekt 1 wird unter der "Dev"-Umgebung entwickelt. Jitterbit bietet eine "Migration"-Funktion, die dieses Projekt in die "Prod"-Umgebung kopiert, wonach die Endpunktanmeldeinformationen auf die "Prod"-Endpunktanmeldeinformationen geändert werden. Auch andere Quellen und Ziele werden geändert. Danach schließen alle Migrationen von "Dev" nach "Prod" Endpunkte, Quellen und Ziele aus, es sei denn, sie sind neu.

Optionen zur Bereitstellungsverwaltung

Es gibt mehrere Optionen für die Bereitstellung von Projekten.

  • Vollständige Bereitstellung: Die Auswahl von Aktionen > Bereitstellen > Alles nimmt das gesamte Projekt und überschreibt das Projekt in der Cloud.

  • Projekt-Backup: Bei der Auswahl von Aktionen > Bereitstellen > Alles gibt es die Option "Auch ein Backup in der Cloud speichern." Bevor wesentliche Änderungen an einem Projekt vorgenommen werden, wählen Sie diese Option, um einen Wiederherstellungspunkt in Harmony zu speichern.

  • Alle neuen und geänderten Elemente: Diese Option ist unter Aktionen > Bereitstellen > Erweiterte Optionen verfügbar. Da das Design Studio "schmutzige" Elemente verfolgt, werden Änderungen sowie alle Abhängigkeiten bereitgestellt.

  • Eine neue Funktion besteht darin, den Fortschrittsdialog während einer Bereitstellung zu deaktivieren (siehe Einstellungen > Bereitstellen), was es ermöglicht, dass individuelle Elementbereitstellungen im Hintergrund erfolgen.

Versionswarnungen

Beim Bereitstellen von Änderungen an einem Projekt wird eine Warnung angezeigt, wenn eine neuere Version eines Projekts bereitgestellt wurde, die darauf hinweist, dass eine neuere Version existiert und wer sie bereitgestellt hat. Der Jitterbit-Administrator hat die Möglichkeit, das Projekt zu überschreiben. Im Allgemeinen wird in einer Umgebung mit mehreren Entwicklern empfohlen, das aktuelle Projekt aus der Cloud herunterzuladen, bevor Änderungen vorgenommen werden.

Testen, Fehlersuche und Protokollierung

Testfunktionen für die Entwicklung von rAPID-Integrationen nutzen

Jitterbit kann eine schnelle Entwicklung von Integrationen und Unit-Tests ermöglichen, indem die tatsächlichen Integrationsdaten während der Entwurfsphase sichtbar gemacht werden. Der offensichtliche Vorteil besteht darin, einen iterativen Entwicklungsprozess zu ermöglichen, indem die Daten vor und nach den Feldtransformationen angezeigt werden, anstatt die gesamte Operation zu erstellen, sie auszuführen und die Ausgabe zu überprüfen. Dies geschieht hauptsächlich über das Transformationswerkzeug, insbesondere durch die Funktionen "Transformation testen" und "Operation ausführen".

Wenn die zu integrierenden Objekte bekannt sind, kann ein erfahrener Entwickler eine Integration schnell mit dem Transformationsassistenten und seinem Toolkit entwickeln. Zum Beispiel kann eine Verbindung zu einer Datenbank hergestellt und mit dem Transformationsassistenten die Operation und die Transformation erstellt werden. Führen Sie dann eine "Operation ausführen" durch, während die Transformation geöffnet ist. Die Daten werden im Transformationsbildschirm angezeigt und die Datensätze können durchgeblättert werden. Dies zeigt sofort die genauen Daten, die Jitterbit erhält, wenn die Operation ausgeführt wird.

Wenn ein Feld eine Transformation erfordert, doppelklicken Sie auf das Feld, um den Formel-Builder zu öffnen und das erforderliche Skript zu erstellen. Durch die Verwendung der Funktion "Test" im Formel-Builder wird die Ausgabe die Transformationsdaten verwenden und die genaue Ausgabe anzeigen, die zur Laufzeit generiert wird.

Wenn die Quelle nicht verfügbar ist, aber die Quelldaten in einer Datei (CSV, XML, JSON) vorliegen, kann die Datei mit den Funktionen "Beispieldatenquelle laden" und "Transformation testen" in das Transformationswerkzeug importiert werden.

Fehlersuche bei Integrationen aktivieren

Ein zentrales Konzept für eine gesunde Integrationsarchitektur besteht darin, zu erkennen, dass Fragen von der Geschäftswelt hinsichtlich der Genauigkeit der Integrationsarbeit aufgeworfen werden, insbesondere wenn Diskrepanzen in den Endpunktdaten auftreten. Die Integration könnte schuld sein oder auch nicht. Es liegt in der Verantwortung der Integration, ein hohes Maß an Transparenz zu bieten, um Fragen zur Datenqualität zu klären.

Für den Fall, dass die Daten in einem Zielendpunkt inkorrekt erscheinen, wird typischerweise der Integrationssupport hinzugezogen, um Details zu den Integrationsaktionen bereitzustellen, wie z. B. Zeiten, Quellen, Transformationslogik, Erfolgs- oder Fehlermeldungen usw. Der Troubleshooting-Prozess profitiert davon, diese Informationen als festen Bestandteil der Integrationsarchitektur verfügbar zu machen.

In Jitterbit wird dies durch Protokollierungs- und Alarmierungsfunktionen unterstützt.

Protokollierung

Das Jitterbit-Betriebsprotokoll erfasst standardmäßig wichtige Daten, wie z. B. die Laufzeiten von Operationen sowie Erfolgs-, Fehlermeldungs- oder Abbruchmeldungen. Bei Fehlern und wenn der Endpunkt Fehlermeldungen zurückgibt, wird dies im Protokoll erfasst.

Beim Entwickeln einer Integration verwenden Sie die Funktion WriteToOperationLog() in den Zuordnungen und Skripten, um wichtige Daten und Schritte im Prozess zu erfassen. Dies ist typischerweise so einfach wie: WriteToOperationLog("Die ID ist: "+sourcefieldid).

Wenn das Erfassen der gesamten Ausgabe einer Transformation gewünscht ist, kann dies durch den Aufbau einer Operation erfolgen, die die Quelle liest, die Transformation durchführt und in eine temporäre Datei schreibt. Ein Nachbetriebs-Skript kann die Datei lesen und in das Betriebsprotokoll schreiben: WriteToOperationLog(ReadFile(<tempfile>)). Dann kann die "echte" Operation durchgeführt werden.

Protokolle können entweder im Design Studio oder in der Management Console angezeigt werden. Der Vorteil der Management Console besteht darin, dass Supportmitarbeiter über den Browser darauf zugreifen können, ohne einen Design Studio-Client auf ihrem Desktop zu benötigen.

Daten in den Protokollen sind durchsuchbar, sodass das Szenario ermöglicht wird, in dem der genaue String, der am Troubleshooting beteiligt ist, ein bekannter Wert ist und protokolliert wird.

Häufig haben APIs eine Erfolgs- oder Nicht-Erfolgsantwortmeldung, die informativ ist. Machen Sie den zusätzlichen Schritt, diese Informationen im Protokoll zu erfassen.

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

Alarmierung

Häufig müssen die Ergebnisse der Integration nicht nur protokolliert, sondern auch eskaliert werden. Jitterbit bietet eine E-Mail-Integration, die leicht an Operationen und Erfolgs-/Fehlerpfade angehängt oder aus Skripten aufgerufen werden kann.

Für weitere Informationen siehe Einrichten von Alarmierung, Protokollierung und Fehlerbehandlung.

Zusätzliche Ressourcen

Diese Abschnitte und Seiten in der Dokumentation beziehen sich auf bewährte Praktiken und werden von Interesse sein.

Tech Talks

Jitterbit Tech Talks sind Video-Präsentationen, die Themen von Interesse für Benutzer aller Erfahrungsstufen abdecken:

  • Tipps & Tricks Harmony Best Practices Tech Talks
    Ein Tech Talk, der für Kunden, Testbenutzer und Partner gedacht ist, die nach bewährten Praktiken für die Harmony-Plattform suchen.
  • APIs Tech Talk
    Bewährte Praktiken zur Erstellung und Implementierung von APIs mit dem API-Manager von Jitterbit und deren Dokumentation gemäß den OpenAPI-Standards (ehemals bekannt als Swagger).
  • Umgebungen Tech Talk
    Bewährte Praktiken beim Arbeiten mit Umgebungen in Jitterbit: jeder Prozess von der Erstellung der Umgebung bis zur Projektmigration.
  • Fehlerbehandlung Best Practices Tech Talk
    Die Entwicklung einer robusten Fehlerbehandlung ist ein kritischer Bestandteil Ihres Integrationsprojekts, der bis zu 25 % der Projektgestaltungszeit in Anspruch nehmen kann. Dieser Tech Talk behandelt die fünf wichtigsten bewährten Praktiken zur Fehlerbehandlung.
  • Private Agenten Best Practices Tech Talk
    Ein Tech Talk, der private versus Cloud-Agenten, Empfehlungen zur Hardware privater Agenten, Agentengruppierung, Betriebssystemoptionen und bewährte Praktiken für Agenten behandelt, die Ihnen helfen können, das Beste aus Ihren Jitterbit-Integrationen herauszuholen.
  • Projektorganisation Best Practices Tech Talk
    Bewährte Praktiken zur Organisation Ihrer Projekte.

Dokumentation

Die Jitterbit-Dokumentation enthält bewährte Praktiken, die auf unseren Seiten zur Verwendung von Jitterbit zu finden sind:

Sicherheit

Entwurfsmuster und Beispiele

  • Bewährte Praktiken für SAP
    Probleme und Überlegungen, die bei der Integration zu und von SAP-Instanzen auftreten können, insbesondere bei der Erstellung einer bidirektionalen Integration.
  • Design Studio Anleitungen
    Häufige Integrationsprobleme, die unsere Kunden haben, die durch die Verwendung unserer Software gelöst werden können.
  • Jitterpak-Bibliothek
    Beispielprojekte, die Ihnen den Einstieg erleichtern.

Projekte erstellen

Protokollierung

Projekte verwalten

  • Neue Rezepte erstellen
    Best Practices, die beim Erstellen von Jitterpaks für die Verwendung mit Citizen Integrator-Rezepten für das Design Studio beachtet werden sollten.
  • Methodik für Integrationsprojekte
    Wichtige Punkte, die ein Projektmanager für ein Design Studio-Projekt wissen sollte, einschließlich der Organisation des Teams, der klaren und präzisen Erfassung und Validierung von Anforderungen sowie der Nutzung der Stärken von Harmony zur erfolgreichen Durchführung eines Integrationsprojekts.
  • Aus der Cloud-Sicherung wiederherstellen
    Best Practices für das Sichern und Wiederherstellen von Projekten.
  • Ein Team-Kollaborationsprojekt einrichten
    Best Practices zur Unterstützung mehrerer Entwickler, die an demselben Projekt arbeiten.

Private Agenten

APIs verwenden