Zum Inhalt springen

Best Practices für Jitterbit iPaaS

Einführung

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

Dieses Dokument richtet sich an Benutzer von Studio, der webbasierten Version von Jitterbits Projektdesign-Anwendung. Für Best Practices mit Design Studio, Jitterbits Desktop-basierter Projektdesign-Anwendung, siehe Best Practices mit Design Studio.

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

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

An diesem Punkt sollten Sie die grundlegenden Konzepte und Begriffe in Jitterbit iPaaS kennen und verstehen, was wir mit Projekten, Operationen, Endpoints, Scripting, Transfer und Deployment meinen.

Siehe den Abschnitt Zusätzliche Ressourcen am Ende dieser Seite für Links zu Videos und anderen Dokumenten, die diese Best Practices vertiefen.

Support, Customer Success Manager und Dokumentation

Der Zugang zum Jitterbit-Support ist in einer Harmony-Kundenlizenz enthalten. Bei Fragen oder technischen Problemen können Sie fachkundige Unterstützung vom Jitterbit-Support erhalten. Die Seite Jitterbit-Support beschreibt spezielle Anweisungen für Produktionsausfallsituationen, um zeitkritische Probleme zu eskalieren.

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

Diese Dokumentationswebsite (Jitterbit-Dokumentation) enthält mehr als 3.600 eindeutige URLs mit technischem Material.

Um Ihnen bei der Suche nach relevanten Materialien zu helfen, ist das Suchfeld so vorgefiltert, dass die Suchergebnisse auf den Dokumentationsbereich beschränkt werden, auf den gerade zugegriffen wird. Sie können alle Dokumentationen durchsuchen, indem Sie den Suchfilter löschen. Um nach bestimmten Ausdrücken zu suchen, setzen Sie diese in doppelte Anführungszeichen.

Rezepte und Vorlagen

Der Marketplace bietet mehr als 400 vorgefertigte 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 mit zahlreichen Objekten über mehrere Anwendungen oder Systeme hinweg. Prozessvorlagen sind darauf ausgelegt, die Zeit bis zur Bereitstellung um 50 bis 80 Prozent zu verkürzen.

Jitterbit-Produktaktualisierungen

Jitterbit-Produktaktualisierungen werden häufig veröffentlicht (siehe Veröffentlichungsplan). Selbst ein kleineres Release enthält neue Funktionen und Verbesserungen sowie Fehlerbehebungen.

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

Cloud-API-Gateway- und Cloud-Agent-Gruppen-Aktualisierungen werden automatisch angewendet. Für die Cloud-Agent-Gruppen gibt es zwei Sätze: Production und Sandbox. Letzterer wird verwendet, um die Kompatibilität mit Vorabversionen der Agent-Software zu testen und ist keine Entwicklungsumgebung.

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

Es ist ratsam, mit den Releases aktuell zu bleiben, besonders mit Releases, die Feature-Upgrades enthalten.

Projektdesign-Einfachheit und Feature-Präferenz

Bei der Gestaltung eines Integrationsprojekts können mehrere Implementierungsmethoden auftreten, die zu derselben Funktionalität führen.

Obwohl eine Methode je nach Integrations-Use-Case oft Vor- oder Nachteile gegenüber einer anderen hat (wie dokumentiert), empfehlen wir, immer das übergeordnete Leitprinzip der Einfachheit im Auge zu behalten. Projekte, die so einfach wie möglich gestaltet sind, haben in der Regel eine längere Lebensdauer und sind viel leichter für Außenstehende zu verstehen, wenn eine Änderung vorgenommen werden muss. Andererseits können übermäßig komplexe Projekte schwieriger zu warten und an andere Personen zu übergeben sein, wenn sich die Verantwortung ändert.

Um einfachere Projekte zu gestalten, empfehlen wir die folgende Reihenfolge der Feature-Präferenz:

  1. Nutzen Sie nach Möglichkeit No-Code-Features, wie das visuelle Gestalten von Operationen auf der Design Canvas, das Gruppieren von Komponenten zur besseren Organisation, das Hinzufügen von Tags und Kommentaren beim Bereitstellen und das Veröffentlichen von Operationen als APIs.
  2. Nutzen Sie Low-Code-Features, wie die Verwendung von Variablen in den assistentengestützten Komponentenkonfigurationsbildschirmen oder die Manipulation von Felddaten auf Feldebene in einer Transformationszuordnung mit einer Skriptfunktion.
  3. Implementieren Sie bei Bedarf komplexere Logik mit Skripten in der Sprache Jitterbit Script.
  4. Nur wenn kein Jitterbit Script-Äquivalent verfügbar ist, implementieren Sie Skripte in JavaScript.

Projektdesign und Wiederverwendbarkeit

Ein typisches Szenario für die Wiederverwendung eines Projekts beinhaltet die Entwicklung eines Basisprojekts mit umfangreicher Verwendung von globalen Variablen und besonders Projektvariablen. Konfigurierbare Elemente – wie Endpoint-Anmeldedaten, optionale Feldzuordnungen, parametrisierte Abfragen, E-Mail-Adressen und Dateinamen – können als Projektvariablen verfügbar gemacht werden. Das Basisprojekt kann auch allgemeine Funktionen wie Fehlerbehandlung oder die Verwendung von umgebungsweiten Caches enthalten. Das Basisprojekt wird exportiert und dann in neue Projekte importiert, um eine konsistente Grundlage für die Entwicklung zu bilden.

Endpoint-Wiederverwendung

Endpoints, die durch die Konfiguration einer Verbindung und zugehöriger Aktivitäten mit Konnektoren erstellt werden, werden häufig in Operationen verwendet. Es ist jedoch nicht unbedingt erforderlich, einen eindeutigen Endpoint für jede Operation zu erstellen. Da Aktivitätskonfigurationen Variablen für Pfade und Dateinamen akzeptieren, können generische Endpoints einmalig erstellt und dann dynamisch mit globalen und Projektvariablen konfiguriert werden.

Nehmen Sie beispielsweise an, dass eine HTTP-Verbindung und eine zugehörige Aktivität erstellt werden, und die Aktivitätskonfiguration gibt einen Pfad an, der durch eine globale Variable definiert ist, z. B. $gv_http_path. Mit einem Controller-Skript lässt sich $gv_http_path nach Bedarf füllen.

Ein weiteres Beispiel ist eine Datenbankaktivität vom Typ Query mit einer Bedingung. Die WHERE-Bedingung kann einer globalen Variable zugewiesen werden, z. B. $gv_database_condition.

Die meisten Endpunkte können mit Variablen konfiguriert werden.

Skriptwiederverwendung

Eigenständige Skripte, die eine bestimmte Funktion ausführen, z. B. eine Datenbankabfrage zurückgeben oder ein Ergebnis aus einer Reihe von Argumenten berechnen, können Kandidaten für die Wiederverwendung sein, besonders wenn sie in mehreren Operationen verwendet werden.

Wenn beispielsweise ein Skript die DBLookup-Funktion für eine Datenbanktabelle verwendet und diese Funktion im gesamten Projekt eingesetzt wird, kann ein eigenständiges Skript (getrennt von einer Operation) erstellt werden. Mit der ArgumentList-Funktion oder einfachen globalen Variablen kann das Skript Argumente akzeptieren und ein Ergebnis zurückgeben. Da jede Operationskette einen anderen Bereich darstellt, kann das gleiche Skript sicher von mehreren gleichzeitigen Operationen aufgerufen werden.

Projektorganisation

Workflows dienen der Projektorganisation. Ein Workflow enthält normalerweise zusammenhängende Operationen, die Daten von Anfang bis Ende verarbeiten: Create Orders, Sync Customer Master, Process Confirmations usw. Prozesse, die über verschiedene Workflows hinweg gemeinsam genutzt werden, z. B. das Abfragen eines Endpunkts oder die Behandlung einer Operationsfehlerbedingung, können in ihrem eigenen Workflow gespeichert und von anderen Workflow-Operationen referenziert werden.

Sie können auch benutzerdefinierte Gruppen erstellen, in denen Projektkomponenten zur einfachen Referenzierung gesammelt werden können.

Die Designer-Einstellungen eines Projekts enthalten die Option Auto-number operations on the design canvas, die Operationen automatisch basierend auf der Anzeigeposition der Operation im Projekt-Designer nummeriert. Diese Nummern werden nicht in den Operationsprotokollen angezeigt. Wenn ein Operationsnummerierungsschema erforderlich ist, kann es durch Einbeziehung der Nummerierung in den Operationsnamen implementiert werden. Sie können die Standardeinstellung für diese Einstellung in Ihren Studio-Kontoeinstellungen für neue Projekte festlegen.

Asynchrone Operationen verwalten

Bei Verwendung des Invoke Operation-Tools oder der RunOperation-Funktion im asynchronen Modus werden Operationen ausgeführt, ohne die Kontrolle an die aufrufende Funktion zurückzugeben. Die Verwendung von asynchronen Operationen kann zu Race Conditions führen.

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

Darüber hinaus muss die Anzahl der gleichzeitigen asynchronen Aufrufe verwaltet werden, da die Anzahl der gleichzeitigen Operationen, die auf einem Agent ausgeführt werden, begrenzt ist (siehe den Abschnitt [OperationEngine] der Konfigurationsdatei des privaten Agents).

Endpunkt-Anmeldedaten

Wir empfehlen, für Endpunkt-Anmeldedaten eine System-ID mit Administratorberechtigungen zu verwenden, anstatt eine Benutzer-ID zu verwenden. Benutzer-IDs verfallen normalerweise oder müssen deaktiviert werden, wenn ein Benutzer das Unternehmen verlässt.

Durch die Verwendung von Projektvariablen (deren Werte verborgen werden können) für die Verwaltung von Anmeldedaten muss ein Harmony-Organisationsadministrator keine Produktionsanmeldedaten eingeben. Durch die Einrichtung der entsprechenden Benutzerberechtigungen kann ein Benutzer die Produktionsanmeldedaten über die Seite Projekte der Management Console anwenden.

Wenn Sie private Agents verwenden, können Sie globale Variablen als Alternative zur Verwendung der Management Console über den Abschnitt [PredefinedGlobalVariables] der Konfigurationsdatei des privaten Agents verwalten.

Integrationsdaten persistieren

Beim Erstellen von Integrationen in Studio wählen Sie einen Datenspeicheransatz basierend auf Ihrer Datengröße und Ihren Persistenzanforderungen. Sie können Variablen, Speicher-Connectors und Caching-Funktionen verwenden.

Eine detailliertere Erklärung der Ansätze finden Sie unter Speicherüberlegungen.

Variablen

Verwenden Sie Variablen, um Werte, Konfigurationseinstellungen und kleine Datenmengen zwischen Integrationskomponenten zu übergeben. Wählen Sie einen Variablentyp basierend auf dem Gültigkeitsbereich:

  • Lokale Variablen: Verwenden Sie diese für einzelne Skriptberechnungen und temporäre Werte.
  • Globale Variablen: Übergeben Sie Daten zwischen Operationen in einer Kette.
  • Projektvariablen: Speichern Sie Konfiguration und Anmeldedaten über ein gesamtes Projekt hinweg.
  • Jitterbit-Variablen: Greifen Sie auf systemdefinierte Laufzeitinformationen zu.

Speicher-Connectors

Diese Speicher-Connectors sind für die Speicherung und den Abruf von Dateien und großen Datensätzen konzipiert, die über eine einzelne Operationskette hinaus persistieren müssen:

Connector Persistenz Größenlimits Am besten geeignet für
Variable Operationskette 50 MB Kleine Dateien und Tests
Temporärer Speicher Operationskette 50 GB (Cloud) Große Dateien und Verarbeitung
Cloud Datastore Bis zum Löschen TBD Nachschlagetabellen und operationsübergreifende Daten

Beachten Sie bei der Verwendung dieser Connectors folgende Überlegungen:

  • Variable: Funktioniert am besten für kleine Datensätze. Die Leistung verschlechtert sich bei Dateien größer als 4 MB. Es besteht ein Risiko der Datenverstümmelung über 50 MB. Variablen sind nützlich für Unit-Tests und erhöhen die Wiederverwendbarkeit durch die Erstellung eines gemeinsamen Ziels und einer gemeinsamen Quelle für verkettete Operationen.

  • Temporärer Speicher: Diese Dateien werden in das Standard-Verzeichnis für temporäre Dateien des Agents geschrieben. Bei Verwendung einer privaten Agent-Gruppe mit mehreren Agents oder einer Cloud-Agent-Gruppe müssen Operationen, die temporären Speicher verwenden, in derselben Operationskette sein, um sicherzustellen, dass sie auf demselben Agent ausgeführt werden. Bei Cloud-Agents können Dateien sofort gelöscht werden. Bei privaten Agents werden Dateien normalerweise nach 24 Stunden gelöscht.

  • Cloud Datastore: Dieser Connector bietet eine persistente Lösung für Schlüssel-Wert-Paare oder strukturierte Daten. Er eignet sich ideal für die gemeinsame Nutzung von Nachschlagetabellen oder Referenzdaten zwischen Operationen und Projekten.

Cloud-Caching

Verwenden Sie die Funktionen ReadCache und WriteCache, wenn Sie Daten über Projekte, Umgebungen oder asynchrone Operationen hinweg freigeben müssen. Cloud-Caching ist ideal für Login-Token, Fehlerakkumulation und temporäre Daten, auf die mehrere Operationen zugreifen müssen.

Scripting

Skripte, die in der Sprache Jitterbit Script oder JavaScript geschrieben sind, können fast überall in Operationen und innerhalb von Transformationszuordnungen verwendet werden.

Wann Scripting verwendet werden sollte

Operationen können auf zwei Arten in Operationsketten organisiert werden: (1) durch Verknüpfung von Operationen mit Bei Erfolg- und Bei Fehler-Bedingungen mithilfe von Operationsaktionen oder (2) durch Verwendung eines Controller-Scripts.

Anstatt Operationsaktionen zu verwenden, nutzt ein Controller-Script die Funktion RunOperation, um Operationen mithilfe eines Scripts miteinander zu verknüpfen.

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

Ein Controller-Script kann in folgenden Situationen vorteilhaft sein:

  • Um eine Operation auszuführen, die von externen Faktoren wie Projektvariablen oder Daten abhängt.
  • Um Unteroperationen aus einer Schleife heraus aufzurufen, wobei Daten aus einer Liste an die Operation übergeben werden.
  • Um Operationsketten-Aktivitäten zu verfolgen. Beispiel: (WriteToOperationLog("count of records to process: " + cnt), WriteToOperationLog("Starting update operation at: " + Now()), WriteToOperationLog("Database query: " + sql), usw.)

Weitere Bereiche, in denen Scripting häufig verwendet wird, sind die zugeordneten Felder in Transformationen und in anderen eigenständigen Scripts. Wenn dasselbe Script in mehr als einer Transformation verwendet wird, sollte dieses Script als eigenständiges Script eingerichtet und aus jeder Transformation heraus mit RunScript aufgerufen werden.

Namenskonvention für Variablen

Jitterbit iPaaS hat vier Arten von Variablen:

Da der Geltungsbereich einer lokalen Variablen auf ein einzelnes Script beschränkt ist, kann eine Namenskonvention dafür 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 aufgrund ihres größeren Geltungsbereichs (eine globale Variable kann in derselben oder nachgelagerten Operation und Scripts innerhalb einer Operationskette referenziert werden) eine konsistente Namenskonvention verwenden, um Verwechslungen zu vermeiden. Beispielsweise könnten mehrere Komponenten für einen Variablennamen verwendet werden, getrennt durch Punkte, nach einem Muster wie diesem:

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

Kombiniert man diese Komponenten, ergeben sich folgende 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 werden, hilft eine hierarchische Strukturierung bei der Verwaltung und Verwendung von Variablen.

Unabhängig davon, welche Konvention man wählt, empfehlen wir, diese zu dokumentieren und festzuhalten, damit alle Teammitglieder sie konsistent in allen Projekten verwenden können.

Hinweis

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

  • $example_arr_names
  • $example_sfdc_success_message

Umgebungen

Jitterbit ermöglicht Methodologien des Software-Entwicklungs-Lebenszyklus durch die Verwendung von Umgebungen. Man kann sowohl Produktions- als auch Nicht-Produktionsumgebungen einrichten.

Angenommen, eine Entwicklungs- und eine Produktionsumgebung sind in der Management Console eingerichtet und beide sind derselben Agent-Gruppe zugeordnet. Angenommen, ein Projekt wird zunächst in der Entwicklungsumgebung entwickelt.

Studio verfügt über eine Übertragungsfunktion, die das Projekt in die Produktionsumgebung kopiert. Danach werden die Endpoint-Anmeldedaten mithilfe von Projektvariablen in die Anmeldedaten der Produktionsumgebung geändert. Auch andere Quell- und Ziel-Endpoints werden geändert. Nach der ersten Übertragung schließen weitere Übertragungen desselben Projekts von Entwicklung zu Produktion die Migration von Projektvariablenwerten aus, es sei denn, es handelt sich um neue Projektvariablen.

Testen

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

Nach dem Importieren oder Generieren der Beispielquelldaten zeigt die Transformation die Ausgabe aller Zuordnungen und eingebetteten Skripte an.

Fehlerbehebung

Ein Schlüsselkonzept für eine gesunde Integrationsarchitektur ist die Erkenntnis, dass das Unternehmen Fragen zur Genauigkeit der Integrationsarbeit stellen wird, besonders wenn Abweichungen in den Endpoint-Daten auftreten. Die Integration kann schuld sein oder auch nicht. Es liegt in der Verantwortung des Integrationsprojekts, ein hohes Maß an Transparenz zu bieten, um Fragen zur Datengenauigkeit zu klären.

Wenn beispielsweise Daten in einem Ziel-Endpoint fehlerhaft zu sein scheinen, wird typischerweise der Integrationssupport aufgefordert, Details zu Integrationsaktionen wie Zeiten, Quellen, Transformationslogik, Erfolgs- oder Fehlermeldungen usw. bereitzustellen. Der Fehlerbehebungsprozess profitiert davon, diese Informationen als Standardteil der Integrationsarchitektur verfügbar zu machen. In Jitterbit iPaaS wird dies durch Protokollierung und Benachrichtigungen unterstützt.

Protokollierung

Operationsprotokolle erfassen standardmäßig wichtige Daten wie Operationslaufzeiten und Erfolgs-, Fehler- oder Abbruchmeldungen. Wenn Fehler auftreten und der Endpoint Fehlerinformationen zurückgibt, werden diese im Protokoll erfasst.

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

Bei der Entwicklung eines Integrationsprojekts verwendet man die Funktion WriteToOperationLog in Mappings und Scripts, um wichtige Daten und Schritte im Prozess zu erfassen. Dies ist normalerweise so einfach wie: WriteToOperationLog("The id is: "+sourcefieldid).

Wenn man die gesamte Ausgabe einer Transformation erfassen möchte, kann man ein Vorgehen erstellen, das die Quelle liest, die Transformation durchführt und die Ausgabe in einen Variable- oder Temporary Storage-Endpunkt statt in den Zielendpunkt schreibt. Ein Post-Operation-Script kann die Ausgabe lesen und protokollieren. Anschließend kann das „echte" Vorgehen ausgeführt werden.

Protokolle können entweder im Studio-Operationsprotokoll-Bildschirm oder auf der Seite Runtime der Management Console angezeigt werden. Auf die Seite Runtime der Management Console können Support-Mitarbeiter zugreifen, ohne zum Projekt navigieren zu müssen.

Daten in den Protokollen sind durchsuchbar. Um nur die benötigten Protokolle zu filtern, kann man die Suchsyntax message=%\<your text>% in den Operationsprotokollen von Studio und Management Console verwenden.

APIs haben häufig eine aussagekräftige Erfolgs- oder Fehlermeldung. Wenn das Debug-Logging für die API aktiviert ist, wird der Request-Body in den API-Protokollen erfasst (die sich von den Operationsprotokollen unterscheiden).

Operationsprotokolle, einschließlich detaillierter Protokollmeldungen von Cloud Agents und Private Agents, werden von Harmony 30 Tage lang aufbewahrt.

Benachrichtigungen

Integrationsergebnisse müssen häufig nicht nur protokolliert, sondern auch eskaliert werden. E-Mail-Benachrichtigungen können einfach an Vorgänge und Erfolgs-/Fehlerpfade angehängt oder aus Scripts aufgerufen werden. Alternativ kann man den Email-Connector verwenden, um eine Send email-Aktivität als Ziel eines Vorgangs zu konfigurieren.

Weitere Informationen finden Sie unter Set up alerting, logging, and error handling.

Zusätzliche Ressourcen

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

Tech Talks

Jitterbit Tech Talks sind Videopräsentationen, die Themen von Interesse für Benutzer aller Ebenen abdecken:

Tech Talk Dauer Veröffentlichungsdatum
API proxy 39:53 2019.01.09
APIs 49:22 2018.08.07
Studio 43:53 2019.05.14
Complex project orchestration best practices 50:46 2018.10.16
Connector Builder 50:19 2019.07.16
Environments 1:04:22 2018.04.04
External credentials storage and management 46:58 2020.10.09
Error handling best practices 27:22 2018.03.13
Jitterbit best practices 1:04:38 2020.03.16
Logging best practices 1:03:02 2019.02.12
Open API Portal Manager 57:21 2019.11.05
Pass-through sources and global variables best practices 42:44 2018.12.05
Private agents best practices 42:43 2018.07.05
Process templates 43:27 2020.07.08
Project organization best practices 1:08:39 2018.06.08

Dokumentation

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

Sicherheit

Integrationsprojekt-Methodik

  • Integrationsprojekt-Methodik
    Wichtige Punkte, die ein Projektmanager für ein Studio-Projekt kennen sollte, einschließlich der Organisation des Teams, der klaren und prägnanten Erfassung und Validierung von Anforderungen sowie der Nutzung der Stärken der Jitterbit iPaaS zur Durchführung eines erfolgreichen Integrationsprojekts.

Anleitungen

Protokollierung

Agenten