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 verfügbaren Werkzeuge für einen Jitterbit-Nutzer empfehlen.

Diese Seite liest sich am besten, nachdem Sie sich mit Jitterbit vertraut gemacht haben: Sie haben die Erste Schritte Seite 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 Bereitstellung 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 Jitterbit-Support Seite beschreibt spezielle Anweisungen für Produktionsausfälle, um zeitkritische Probleme zu eskalieren.

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

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

Jitterbit-Produktupdates

Harmony-Updates werden häufig veröffentlicht (siehe Veröffentlichungszeitplan). 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-Agentengruppen werden automatisch angewendet. Für die Cloud-Agentengruppen 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 Veröffentlichungen auf dem neuesten Stand zu bleiben, insbesondere bei Veröffentlichungen, 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, Email-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. Mithilfe der Funktion ArgumentList() oder einfacher globaler Variablen kann es Argumente akzeptieren und ein Ergebnis zurückgeben. Da jede Operationskette 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.

Aus diesem Grund empfiehlt Jitterbit nicht, Projekte auf einem Dateiserver 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

Das 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 einfacher.

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" heißen. 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 im 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 mit Operation B verkettet 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.

Endpunkt-Anmeldeinformationen

Verwenden Sie eine System-ID mit Administrationsberechtigungen als Endpunkt-Anmeldeinformationen, 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 von 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 Email-Anmeldeinformationen verwendet werden.

API-Verwaltung

Der API-Manager sollte anstelle von HTTP-Endpunkten verwendet werden. HTTP-Endpunkte waren eine Möglichkeit, 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 gestaltet ist, dass die nachfolgenden Operationen erheblich Zeit in Anspruch nehmen, besteht das Risiko eines Zeitüberschreitens 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 Anforderungen zu skalieren. In diesem Fall kann es der bevorzugte Ansatz sein, asynchron zu antworten. Das heißt, die Antwort erfolgt sofort, und der Datensatz vom Zielendpunkt wird über einen Anruf an die API des Quellendpunkts gesendet.

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 Endpunktanmeldeinformationen. 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 bei 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.
  • Anmelde-Token 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-sicher" 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 Falle 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 Falle 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 hängen von der Verwendung desselben Dateinamens ab, um Lese- und Schreibvorgänge zu synchronisieren.

  • In einer clusterbasierten Agentenumgebung (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 Operation Kette A in den temporären Speicher "myfile" schreibt und die Operation Kette 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, entscheiden Sie sich für die Standardmethode. Eine "Standardmethode" ist eine Methode, die über die Benutzeroberfläche von Jitterbit Design Studio bereitgestellt wird, um eine Aufgabe zu erledigen.

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 Fehlerschritte 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 vorantreiben (wie die Verwendung von asynchronen oder optionalen Pfaden), wird bevorzugt, 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 ihn 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 sie 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 Operationenkette 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]

wo:

  • 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 beliebigen 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 allgemein 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 Richtlinie Sie auch immer wählen, wir empfehlen, sie 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 Funktion zur "Migration", 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 zum Bereitstellen 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 Multi-Entwickler-Umgebung 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 ermöglicht eine schnelle Entwicklung von Integrationen und Unit-Tests, 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 eine Verbindung zu einer Datenbank herstellen und mit dem Transformationsassistenten die Operation und die Transformation erstellen. Dann eine "Operation ausführen" mit der geöffneten Transformation durchführen. Die Daten werden im Transformationsbildschirm angezeigt und 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 in das Transformationswerkzeug importiert werden, indem die Funktionen "Beispieldatenquelle laden" und "Transformation testen" verwendet werden.

Fehlersuche bei Integrationen aktivieren

Ein zentrales Konzept für eine gesunde Integrationsarchitektur besteht darin, zu erkennen, dass Fragen von der Geschäftswelt zur Genauigkeit der Integrationsarbeit aufgeworfen werden, insbesondere wenn Diskrepanzen in den Endpunktdaten auftreten. Die Integration kann 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, wenn diese Informationen als fester Bestandteil der Integrationsarchitektur verfügbar gemacht werden.

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

Protokollierung

Das Jitterbit-Betriebsprotokoll erfasst standardmäßig wichtige Daten, wie z. B. die Laufzeiten der Operationen sowie Erfolgs-, Fehlermeldungs- oder Stornierungsnachrichten. 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 gesamte Ergebnis einer Transformation erfasst werden soll, kann dies erreicht werden, indem eine Operation erstellt wird, 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-Erfolgsantwortnachricht, 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 Email-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 Tech Talks zu bewährten Praktiken in Harmony
    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.
  • Bewährte Praktiken zur Fehlerbehandlung Tech Talk
    Eine robuste Fehlerbehandlung zu entwickeln, 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.
  • Bewährte Praktiken für private Agenten 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.
  • Bewährte Praktiken zur Projektorganisation 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 beim Integrieren zu und von SAP-Instanzen auftreten können, insbesondere beim Erstellen einer bidirektionalen Integration.
  • Design Studio Anleitungen
    Häufige Integrationsprobleme, die von unseren Kunden festgestellt werden und 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 Cloud-Backup 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