Integrationsprojektmethodik für Jitterbit Design Studio

Einführung

Lassen Sie uns ehrlich sein: Integrationsprojekte können schwierig sein, mit vielen potenziellen Fallstricken. Wenn Integration "Daten in Bewegung" bedeutet, gibt es Zeiten, in denen die Daten nicht daran interessiert sind, sich zu bewegen. Integrationsprojekte sind stark von Endpunkten abhängig und können daher Risiken beinhalten, die außerhalb der Kontrolle des Integrators liegen.

In der idealen Welt sind Endpunkte stabil, haben gut dokumentierte APIs und klare Fehlermeldungen. Es gibt leicht verfügbare Fachexperten (SMEs), und nicht-produktive Umgebungen stehen sowohl für die Entwicklung als auch für Tests zur Verfügung. Außerdem ist das Projekt gut finanziert, hat höchste Priorität für das Management und es gibt ausreichend Zeit für Tests. Wenn das nach Ihrem Projekt klingt, herzlichen Glückwunsch! Für den Rest von uns, lesen Sie weiter.

Ansatz

Wenn Sie wissen, dass ein Feld voller Fallstricke vorhanden ist, haben Sie zwei Möglichkeiten:

1. Sehr vorsichtig und absichtlich vorgehen, die gesamte Landschaft bis ins kleinste Detail erkunden und nur bauen, wenn alles bekannt ist.

2. So schnell wie möglich loslegen, frühzeitig alle Fallstricke identifizieren und die Detonationen feiern… denn Probleme frühzeitig zu entdecken, ist weit besser, als sie später zu entdecken.

Richtig, also Nummer 2 ist es. Anschnallen, wir werden schnell vorankommen.

Zielgruppe

Die Zielgruppe ist ein Projektmanager (PM) oder technischer Leiter, der über allgemeine IT-Erfahrung verfügt und nun ein Integrationsprojekt mit Jitterbit iPaaS leitet.

Dazu gehören Personen mit Rollen wie einem Jitterbit-Partner, der allgemeine Integrationsarbeiten durchführt, einem Anwendungsanbieter, der ebenfalls die Aufgabe übernimmt, die Integrationen von Ihrem Produkt zu allen Endpunkten des Kunden zu erstellen, oder einem Kunden-PM, der Jitterbit iPaaS allein oder mit Hilfe von Jitterbit Professional Services implementiert.

Fokus

Der Fokus dieses Dokuments liegt nicht darauf, wie man Jitterbit technisch verwendet (sehen Sie sich die andere Dokumentation für die technischen Details an), sondern behandelt die wichtigsten Punkte, die ein PM für ein Integrationsprojekt wissen sollte. Dieser Leitfaden zeigt, wie Sie Ihr Team organisieren, Anforderungen klar und präzise sammeln und validieren und die Stärken von Jitterbit iPaaS nutzen, um ein erfolgreiches Projekt zu liefern.

Scoping

Scoping ist ein zweistufiger Prozess, der das Sammeln von Informationen, das Abstecken der Grenzen des Projekts und das Beschaffen der grundlegenden Informationen zur Umsetzung des Projekts umfasst:

1. Grobe Schätzung: Schätzen Sie eine hochrangige Grobe Schätzung (ROM) für die Arbeit (kann für bestimmte Endpunkte übersprungen werden).
2. Umfang der Arbeiten: Verfeinern Sie die Schätzung, indem Sie einen Umfang der Arbeiten (SOW) zur Durchführung des Projekts detaillieren.

Dieser Prozess ist empfindlich gegenüber dem Konzept von GIGO — Garbage In, Garbage Out — also sparen Sie nicht daran. Die untenstehende Tabelle wird als Ausgangspunkt für den Scoping-Prozess verwendet. Die spezifische Terminologie, die in dieser Tabelle verwendet wird, wird später in den Unterabschnitten Grobe Schätzung und Umfang der Arbeiten definiert.

Grobe Schätzung (ROM)

In diesem Schritt wird davon ausgegangen, dass der Kunde ausreichend Analysen durchgeführt hat, um zu bestimmen, welche Schnittstellen erstellt werden müssen. Auf hoher Ebene sind Schnittstellen erforderlich, wenn ein Geschäftsprozess Anwendungsgrenzen überschreitet. Wenn die Geschäftsprozesse nicht festgelegt sind, ist auch die Integration nicht festgelegt, und es könnte zu früh sein, um eine Schätzung abzugeben.

Die Grobe Schätzung (ROM) ist darauf ausgelegt, hochrangig zu bleiben und eine schnelle Bearbeitung zur Unterstützung der Planung und Entscheidungsfindung des Kunden zu ermöglichen. ROM-Schätzungen basieren auf diesen Elementen:

• Endpunkte: Dies ist das "Ding", mit dem Jitterbit iPaaS interagiert, um Daten zu lesen/schreiben. Dies kann eine Anwendung mit einer Reihe von Remote-Methoden, ein dateibasiertes System wie FTP oder interne Dateisysteme, eine Datenbank oder eine Webanwendung sein, die APIs bereitstellt.
• Integrationsszenario: Dies ist die Beschreibung der Datenbewegung, die erforderlich ist, um das Integrationsziel zu erreichen. "Konten synchronisieren", "Bestellungen erstellen" oder "Versandinformationen abrufen" sind Beispiele.
  • Objekt: Dies kann ein SFDC (Salesforce)-Objekt (wie Konto oder Produkt), eine Datenbanktabelle oder ein virtuelles Geschäftsobjekt, wie Bestellungen in einem EDI-Dokument, sein.
  • Methode: Dies beschreibt, was mit den Daten gemacht wird, wie CRUD (erstellen, lesen, aktualisieren und löschen).
  • Komplexitätsgrad der Transformation: Dies kann eines dieser Niveaus sein:
    • Niedrig: Verwendet Endpunkt-Connectoren, eine geringe Anzahl von Transformationen und ein oder zwei Operationen im Szenario.
    • Mittel: Kann Endpunkt-Connectoren verwenden oder auch nicht, verwendet eine Anzahl von Transformationen und externen Nachschlägen und verwendet mehrere Operationen pro Szenario.
    • Hoch: Keine Endpunkt-Connectoren, zahlreiche Szenariostufen, und der Endpunkt ist bekannt dafür, herausfordernd zu sein.

Heuristiken werden verwendet, um Stunden zu generieren. Formeln basieren auf der Anzahl der Szenarien und der Komplexität, um zu einer Schätzung zu gelangen, die leicht um bis zu 15–20 % abweichen kann. Betrachten Sie dies als eine Budgetzahl, die früh im Prozess verwendet werden soll.

Die ROM-Schätzung geht davon aus, dass ein Jitterbit iPaaS-Experte die Arbeit mit etwas leichtem Projektmanagement erledigt. Sie ist auch end-to-end: von der Initiierung bis nach dem Go-Live. Die Zeit, um eine Integration zu erstellen, entspricht nicht eins zu eins der verstrichenen Zeit. Die tatsächliche Zeit hängt von den Personalressourcen, der Stabilität der Kundenendpunkte, der Verfügbarkeit von Kunden-SME usw. ab. Um auf der sicheren Seite zu sein, nehmen wir ein Verhältnis von 3:1 zwischen Kalenderdauer und geschätzten Stunden an.

Umfang der Arbeiten (SOW)

Der Umfang der Arbeiten (SOW) ist darauf ausgelegt, mehr Details bereitzustellen, um ein klareres Bild des Projekts zu erhalten und eine Überprüfung oder Neuberechnung der ROM-Schätzung vorzunehmen. Für bestimmte Endpunkte (wie SAP) oder Arten von Projekten (wie Hub-Deals) können Sie den ROM-Prozess überspringen und direkt zum SOW-Schritt übergehen.

Während dieses Schrittes sollten Sie eine Scoping-Sitzung ansetzen, um Details zu finalisieren und offene Fragen zu beantworten. Ideale Teilnehmer sind Geschäftsbenutzer (und alle Prozessverantwortlichen) sowie Endpunkt-SME. Die Einbeziehung letzterer ist entscheidend, da es sonst schwierig sein kann, in die Details einzutauchen.

Dies ist die beste Gelegenheit, das Risikoprofil des Projekts zu klären, also hören Sie aufmerksam zu und stellen Sie Fragen. Decken Sie diese Themen ab:

• Endpunkte

  • Versionen: Zu verwendende oder anzutreffende Versionen.

  • On-/Off-Premises: Wenn On-Premises, stellen Sie sicher, dass die Verwendung von Cloud- versus privaten Agenten behandelt wird. Ein häufiges Anliegen ist die Netzwerksicherheit, wie das Öffnen der Firewall für private Agenten, also versichern Sie dem Kunden und den Stakeholdern, dass dies kein Sicherheitsproblem darstellt. Stellen Sie einen Link zum Jitterbit-Sicherheits- und Architektur-Whitepaper und zu den Host-Systemanforderungen für private Agenten bereit.

  • Support: Wie die Endpunkt(e) unterstützt werden (intern/extern).

  • Lebenszyklusphasen: In Entwicklung/Vorproduktion, Wartung, undergoing upgrades, Auslauf.

• Endpunkt-Expertise

  • Interne vs. externe Expertise: Bei einem komplexen Endpunkt, wie einem ERP oder CRM, gibt es normalerweise entweder interne Expertise in der IT-Abteilung oder einen Implementierungspartner und/oder Helpdesk. Natürlich ist es umso besser, wenn Sie interne Expertise haben.
  • Grenzen/Rollen: Manchmal sind sich die Kunden über die Rolle des Integrators nicht im Klaren und nehmen an, dass die Anpassung des Endpunkts von Jitterbit durchgeführt wird; wenn dieses Thema aufkommt, machen Sie die Grenzen klar.
  • Verfügbarkeit und Qualität der Dokumentation: Mit der Verbreitung von Cloud-Diensten und APIs listen einige Anbieter einfach ihre APIs, aber die Dokumentation kann spärlich sein. Wenn dies Ihre Situation ist, müssen Sie Zeit für Entdeckung, Machbarkeit und Tests einplanen.

• Integrationsszenarien

  • Methoden- und Endpunktobjekte: Definieren Sie diese für jedes Szenario. Beispiele:
    • "Periodisch nach neuen Kunden in Endpunkt X in das Konto in Endpunkt Y auf Batch-Basis abfragen und die neue Kontonummer an den Kunden aktualisieren."
    • "Einen Echtzeitantrag von Endpunkt X erhalten, der Bestellinformationen enthält, um die Bestellmethode in Endpunkt Y zu senden, und mit der neuen Bestellnummer antworten."
    • "Datenbanktabelle X abfragen und 200.000 Bestandswerte an die Endpunkt Y Inventar-API aktualisieren."
  • Potenzielle Blockaden: Die Szenarien werden für die Zeitschätzung verwendet. Erwarten Sie, dass die Entwicklung jedes Szenarios (es sei denn, es ist extrem einfach) auf Blockaden stößt. Diese können von technischen (schlechte Anmeldeinformationen, nicht zugänglicher Endpunkt, undurchsichtige API) bis hin zu prozeduralen (das Unternehmen muss einen neuen Prozess definieren, Anpassungen sind erforderlich, Fachexperten sind nicht verfügbar) reichen.

• Zeitrahmen

  • Wichtige Daten: Typischerweise kennt ein Kunde sein Go-Live, aber es gibt andere wichtige Daten.

• Benutzerakzeptanztests (UAT) Daten: Wann beginnt UAT? (Dies kann eine Erklärung erfordern, wenn der Kunde nicht an phasenweise Entwicklung gewöhnt ist.)

  • Bereitschaft der Endpunkte: Wenn neue Endpunkte verwendet werden, wann werden die Umgebungen für die Integrationentwicklung und -tests bereit sein?

  • Verfügbarkeit von Fachexperten: Gibt es Einschränkungen bei der Verfügbarkeit von Fachexperten?

    Caution

    Seien Sie vorsichtig, wenn Sie versuchen, ein Integrationsprojekt zu beschleunigen. Mehr Entwickler hinzuzufügen, beschleunigt die Entwicklung nicht, es sei denn, es gibt sehr klare und separate Szenarien.

• Ressourcen

  • Ansätze: Kunden haben unterschiedliche Ansätze zu Projektressourcen:

    • Überwiegend auslagern: Der Kunde stellt einen geschäftlichen Ansprechpartner oder Fachexperten zur Verfügung und kümmert sich um Anforderungen, Eskalationen, UAT und die Koordination externer Ressourcen. Alle anderen Ressourcen (hauptsächlich Entwicklung) werden von Jitterbit Professional Services und/oder dem Jitterbit-Partner bereitgestellt.

    • Überwiegend intern: Der Kunde wird lernen, Jitterbit iPaaS zu nutzen und möchte lediglich Zugang zu einem Jitterbit-Fachexperten für Anleitung und Best Practices.

    • In-/Auslagern: Der Kunde möchte, dass Jitterbit Professional Services oder der Jitterbit-Partner eine Reihe von Integrationen erstellt und diese schrittweise an die Ressourcen des Kunden übergibt. Dieser Teil ist schwer zu schätzen. Der empfohlene Ansatz besteht darin, die gesamte Arbeit zu schätzen und dann einen Prozentsatz der Stunden abzuziehen.

      Note

      Der Kunde könnte sich nicht bewusst sein, dass er unabhängig davon viel Zeit in das Projekt investieren wird und dass die Verlagerung der Entwicklung von extern nach intern keinen großen Einfluss haben wird (da der Großteil auf eine einzige Phase beschränkt ist) und möglicherweise den Fortschritt aufgrund des Wissenstransfers (KT) sogar verlangsamen kann.

  • Grad der Beteiligung: Dieses Diagramm veranschaulicht den relativen Grad der Beteiligung des Projektmanagers (PM), der Ressourcen des Kunden und der Entwicklungsressourcen. Beachten Sie, dass die Entwicklungsressourcen während der Entwicklungsphase am stärksten beteiligt sind, wobei ihre Beteiligung danach abnimmt. Die Ressourcen des Kunden (in der Regel Geschäftsanwender) sind während der UAT-Phase (User Acceptance Testing) sehr beteiligt, was häufig übersehen wird.

    

Personalbesetzung

Diese allgemeinen Richtlinien gelten für die Besetzung von Ressourcen mit Jitterbit-Technik- und PM-Fähigkeiten. Sie schließen Ressourcen wie Fachexperten für Geschäftsprozesse des Kunden und Endpunktbesitzer aus. Abhängig von der Größe des Projekts werden folgende Personalstufen empfohlen:

• Kleine Projekte: Projekte mit 2 Endpunkten und weniger als 12 Szenarien können von einer einzelnen Teilzeit-Jitterbit-technischen Ressource und einem Teilzeit-Projektmanager bearbeitet werden.

• Mittlere Projekte: Projekte mit 2-4 Endpunkten und 12-20 Szenarien können die gleiche Personalstufe wie kleine Projekte haben, jedoch mit einem engagierteren Team.

• Große Projekte: Projekte mit 5+ Endpunkten und 20+ Szenarien haben viele Abhängigkeiten bei der Bestimmung der Personalbesetzung.

Die Rolle des Projektmanagers kann während des gesamten Projekts nahezu 100%ige Beteiligung erfordern, wenn eine dieser Aussagen zutrifft:

• Der Kunde benötigt detaillierte Statusberichte (z. B. Berichterstattung an ein Projektmanagementbüro).

• Zahlreiche externe Fachexperten müssen die Endpunkte des Kunden konfigurieren, um die Integration zu ermöglichen.

• Der Kunde hat wahrscheinlich Schwierigkeiten, detaillierte Integrationsanforderungen zu erhalten.

• Der Projektmanager ist unerfahren oder abwesend, und der Kunde erwartet, dass Sie das gesamte Projekt leiten.

Üben Sie in diesen Situationen strenge Scope- und Änderungsmanagement aus! Machen Sie dem Kunden klar, dass der Erfolg des Projekts davon abhängt, dass der Kunde alle Blockaden beseitigt und alle Projektressourcen die Fristen einhalten.

Bei der Verwendung mehrerer Entwicklungsressourcen sollten Sie folgende Überlegungen anstellen:

• Mehr als einen Entwickler in einem einzigen Jitterbit-Projekt zu haben, erfordert ein hohes Maß an Koordination (mehr Arbeit für den Projektmanager), da es einfach ist, Änderungen bereitzustellen und die Arbeit eines anderen zu überschreiben.

• Streben Sie an, die Entwickler verschiedenen Integrationsszenarien zuzuweisen oder die Arbeit in verschiedene Jitterbit-Projekte aufzuteilen.

• Nutzen Sie Design- und Code-Reviews zwischen den Entwicklern.

• Wenn möglich, erhöhen Sie die Ressourcen während der Entwicklungsphase und reduzieren Sie sie während der UAT- und Go-Live-Phasen.

Kickoff-Meeting

Der Zweck des Kickoff-Meetings besteht darin, die wichtigsten Teilnehmer des Projekts zusammenzubringen, typischerweise die wichtigsten Geschäftsbenutzer, Fachexperten, Endpoint-Eigentümer und Integrationsarchitekten. Diese Zeit wird genutzt, damit alle auf denselben Stand kommen und die Rollen und Verantwortlichkeiten klären können. Während des Kickoff-Meetings sollten folgende Aufgaben erledigt werden:

• Wichtige Termine: Überprüfen Sie alle wichtigen Termine (nicht nur das Go-Live-Datum).
• Informationsaustausch: Teilen Sie Kontaktdaten und Dokumente.
• Überprüfung der Integrationsszenarien: Überprüfen Sie die Integrationsszenarien aus der Scoping-Phase.
  • Dies ist ein guter Zeitpunkt, um zu bestätigen, ob sich seit der letzten Scoping-Sitzung etwas geändert hat.
  • Falls erforderlich, richten Sie ein detailliertes Scoping-Überprüfungstreffen ein.
• Rollen und Verantwortlichkeiten: Die Integration mit Jitterbit erfolgt sehr schnell, aber beachten Sie, dass der größte Faktor, der ein Integrationsprojekt verzögert, die nicht-technischen Abhängigkeiten sind. Dies ist ein guter Zeitpunkt, um diesen Punkt zu betonen. Klären Sie die Verantwortlichkeiten für jede Rolle:
  • PM
    • Arbeitet mit dem Kunden und dem technischen Team zusammen, um detaillierte Integrationsanforderungen zu erhalten und zu organisieren, einschließlich der Feldzuordnungen. Feldzuordnungen werden sowohl von den Jitterbit-Entwicklungsressourcen als auch von den Endpoint-Fachexperten benötigt.
    • Organisiert die Verfügbarkeit von Geschäfts- und Endpoint-Fachexperten für das Projekt und kümmert sich um offene Punkte für die Integration, wie z.B. wer wer ist, deren Engagement im Projekt, Kalender usw.
    • Kommuniziert den Fortschritt der Integrationsentwicklung und die offenen Punkte, die gelöst werden müssen, an den Kunden und das technische Team.
  • Jitterbit-Entwickler
    • Erwirbt ein Verständnis der Anforderungen, um die Integrationsarchitektur zu entwerfen, und arbeitet mit dem Kunden an Designüberlegungen (Batch/Echtzeit, APIs, Master-Datenmanagement, Sicherheitsanforderungen usw.). Der Entwickler sollte mit der Jitterbit Design Studio-Anleitung vertraut sein.
    • Nimmt die detaillierten Anforderungen und nutzt das Tool, um die Betriebsszenarien zu entwickeln, gemäß den Jitterbit-Best Practices.
    • Meldet schnell alle Blockaden und ergreift die Initiative, um diese zu lösen.
    • Idealerweise steht der Jitterbit-Entwickler in direkter Kommunikation mit dem Kunden. Den Jitterbit-Entwickler von Fachexperten und Kunden zu isolieren, ist eine schlechte Praxis und führt zu Kommunikationsproblemen und Verzögerungen. Die Projektressourcen müssen ein Team sein und flüssig kommunizieren.
  • Endpoint-Fachexperte
    • Bietet tiefgehende Expertise zu den exponierten Schnittstellen.
    • Versteht die Integrationsanforderungen und warnt proaktiv das Team, wenn es potenzielle Probleme gibt – wie z.B. die Notwendigkeit einer Änderung an einem Endpoint oder wenn eine Anforderung nicht umsetzbar ist.
    • Ist hochverfügbar, um bei der Unit-Tests zu helfen. Dies kann das Bereitstellen von Testdaten, das schnelle Feedback zu den Ergebnissen der Integrationstests und die Interpretation von Fehlermeldungen umfassen.
• Lizenzierung und Berechtigungen: Überprüfen Sie die Jitterbit-Lizenzierung und Berechtigungen sowie den Prozess zur Anforderung von Berechtigungen.
• Harmony-Architektur: Berücksichtigen Sie diese Punkte zur Harmony-Architektur:
  • Wenn private Agenten verwendet werden, priorisieren Sie die Installation der technischen Architektur und die Konnektivität zu den Endpunkten, hauptsächlich für die Entwicklung.
  • Wenn mit lokalen Systemen gearbeitet wird, gibt es viele Schritte, die Zeit in Anspruch nehmen können, wie z.B. Hardwarebeschaffung, Installation privater Agenten, Netzwerkverbindung, Integrationsbenutzeranmeldeinformationen und den Testzyklus. Da dies mehrere Gruppen betreffen kann, sollten Sie dies so schnell wie möglich für die Entwicklungsumgebung in Angriff nehmen.
  • Erwarten Sie, dass die in der Einrichtung der Entwicklungsumgebung gewonnenen Erkenntnisse die Einrichtung der Nicht-Entwicklungsumgebung beschleunigen, also sollten Sie diesen Schritt so schnell wie möglich erledigen.
• Harmony-Mitgliedschaften: Stellen Sie sicher, dass die Entwicklungsressourcen mit Administratorberechtigungen zur Harmony-Organisation hinzugefügt werden (siehe Jitterbit-Organisationen).
• API-Manager-APIs: Wenn APIs verwendet werden, überprüfen Sie die Abhängigkeiten. Überprüfen Sie die Standard-URL der Jitterbit-API. Wenn der Kunde mit einer Testversion begonnen hat, ist es wahrscheinlich, dass die Standard-URL noch das Wort "trial" enthält. Eskalieren Sie dies an die Jitterbit-Lizenzierung, um dies vor dem Erstellen von APIs entfernen zu lassen (siehe Jitterbit API Manager).
• Zukünftige Meetings: Legen Sie den zukünftigen Meeting-Rhythmus fest.
  • Wenn die Integration Teil einer Endpoint-Implementierung ist, nehmen Sie an diesen Meetings teil.
  • Andernfalls sind kurze, häufige Meetings (täglich ist nicht ungewöhnlich) bevorzugt. Eine Instant-Messaging-Plattform wie Slack kann ebenfalls eingerichtet werden.

Integrationsprojektplan

Wie bereits erwähnt, hat die Integration viele Abhängigkeiten. Projektpläne kommen in der Regel in zwei Typen vor:

• Teil der Implementierung eines neuen Endpunkts, wie z.B. eines ERP.
• Eigenständig, bei denen die Endpunkte relativ stabil sind.

Im ersten Fall können (und müssen) die Aufgaben des Integrationsprojekts mit dem Gesamtprojekt verzahnt werden. Zum Beispiel muss die Entwicklung der Integration warten, bis die Endpunktobjekte konfiguriert sind.

Im zweiten (eigenständigen) Fall kann ein Projektplan nur für den Aufbau der Integration erstellt werden.

Unabhängig davon, ob die Integrationsaufgaben Teil eines anderen Plans oder eigenständig sind, sind die Aufgaben dieselben. Hier ist ein Beispiel aus einem eigenständigen Projektplan:

Beachten Sie, dass der Projektplan mit den grundlegenden Bausteinen beginnt und dann durch jedes Szenario iteriert. Der Abschnitt UAT (User Acceptance Testing) kann bis nach dem Erreichen eines Bereitschaftsstatus aller Szenarien verschoben werden.

Anforderungserhebung und Entwicklung

Dieser Abschnitt beginnt mit dem allgemeinen Ansatz zur Anforderungserhebung und Entwicklung und geht dann auf die Details der Abbildung, Entwicklung, Verwaltung des Entwicklungsprozesses, Wiederverwendung sowie Protokollierung und Fehlerbehandlung ein.

Allgemeiner Ansatz

Jitterbits Low-Code- und grafische Entwicklungsoberfläche (Design Studio) eignet sich für ein iteratives Modell. Dieser Ansatz ist nicht Wasserfall, bei dem alle Anforderungen dokumentiert werden, bevor die Entwicklung beginnt. Diese Schlüsselschritte beschreiben das allgemeine iterative Modell:

• Beginnen Sie mit den Masterdaten-Szenarien. Da der Ansatz darin besteht, schnell durch einen Define-Build-Test-Zyklus zu iterieren, müssen die Endpunkte mit Masterdaten gefüllt sein, bevor mit Transaktionsdaten gearbeitet wird.

• Verstehen, welche Systeme SOR (Systems of Record) und welche SOE (Systems of Engagement) sind:

  • SOR (Systems of Record): Die autoritative Quelle für Masterdaten, normalerweise ein ERP.
  • SOE (Systems of Engagement): Das kunden- oder verkäuferseitige System, wie z.B. ein System zum Kauf eines Produkts.

• Verstehen Sie die wichtigsten Datenfelder und welche geteilt werden (externe oder Fremdschlüssel).

  • Typischerweise werden die Masterdaten-Schlüssel des SOR im SOE gespeichert, um Aktualisierungen zurück an das SOR zu erleichtern. Wenn beispielsweise SAP das SOR und SFDC das SOE ist, werden die SAP-Kundennummern als externe IDs in SFDC gespeichert.
  • Da geteilte Schlüssel Anpassungen erfordern können (was zu Zeitverzögerungen führen kann), ist es wichtig, diesen Bereich von Anfang an zu klären.

Dieses Diagramm zeigt ein Beispiel, das Salesforce als SOE (System of Engagement) und SAP als SOR (System of Record) in einem unidirektionalen Masterdatenfluss mit einer Rückschreibung verwendet.

Wenn es um bidirektionale Masterdatenaktualisierungen geht, erkennen Sie, dass dies eine komplizierte Integration sein kann:

• Sie können auf Wettlaufbedingungen, Logik zur Ausschluss von Aktualisierungen durch den Integrationsbenutzer, die von Geschäftsanwendern getrennt sind, und gegenseitig geteilte Schlüssel stoßen.
• Häufig sind die Geschäftsregeln für Masterdaten an den Endpunkten nicht identisch, und entweder muss die Integrationsschicht diese berücksichtigen oder die Endpunkte müssen angepasst werden. Dies kann ein Hindernis darstellen, daher sollten Sie die Szenarien im Detail für diese Arten von Integrationen durchgehen.

Mapping

Der PM sollte den Kunden anweisen, mit den detaillierten Feldzuordnungen zu beginnen. Diese werden sowohl von den Jitterbit-Entwicklungsressourcen als auch von den Endpunkt-SME benötigt.

Der Kunde ist möglicherweise daran gewöhnt, die Systeme aus der Sicht der Benutzeroberfläche zu betrachten und kann möglicherweise keine Zuordnungen basierend auf der Sicht der Schemata erstellen. In diesem Fall sollten die Schemata, wenn möglich, in die Zuordnungs-Spreadsheet eingefügt werden. Dies kann die Hilfe des SME, Online-Dokumentation oder die Verwendung von Jitterbit iPaaS erfordern, um sich mit dem Endpunkt zu verbinden und die Schemata herauszuziehen.

Wenn die Zuordnung unkompliziert ist, können Sie die Zuordnung "live" durchführen, indem Sie Jitterbit iPaaS verwenden, um die Endpunktschemata während eines Kundengesprächs in eine Transformation zu ziehen.

Diese Tabelle zeigt ein Beispiel für Feldzuordnungen:

Wenn genügend Szenariodefinitionen vorhanden sind, um zu beginnen, zielen Sie darauf ab, die Integration in Jitterbit iPaaS zu erstellen und so schnell wie möglich zu testen, um mögliche Blockaden zu identifizieren.

Während der Kunde das Mapping-Spreadsheet durchgeht, achten Sie genau darauf, welche Mappings schwieriger sein werden. Die Transformation ist der entscheidende Punkt, an dem wir die exponierten Integrationsmethoden zwischen den Systemen abbilden. Es ist wichtig herauszufinden, welche Szenarien schwieriger sein werden als andere, da es dafür einen hohen Zeitmultiplikator gibt. Einfache Mappings können nur Minuten in Anspruch nehmen, während komplexe Mappings Tage dauern können. Achten Sie auf diese Situationen und priorisieren Sie:

• Externe Systemabfragen: Für einige Systeme müssen Sie möglicherweise Werte abfragen, indem Sie Abfragen ausführen. Die Gefahr hier ist die Auswirkung auf die Leistung: Seien Sie sich bewusst, dass die Transformation auf Basis jedes Datensatzes ausgeführt wird. Wenn 200 Datensätze verarbeitet werden und die Transformation für jeden Datensatz eine Abfrage durchführt, sind das 200 Abfragen. Das ist kein großes Problem, wenn das Ziel eine Datenbank ist, aber wenn das Ziel eine API ist, können das auch 200 Anmeldungen/Abmeldungen sein. Erwägen Sie, ein Wörterbuch zu verwenden, um die Daten in einem Pre-Operation-Skript abzufragen, wodurch eine einzige Abfrage durchgeführt wird.

• Komplexe Schemata: Die Transformation ist "iterationsbasiert". Wenn die Quell- und Zielschemata flach sind (wie z.B. ein Kundenname und die Wohnadresse), dann wird die Transformation einmal pro Datensatz iterieren, so:

  

  Im nächsten Beispiel (unten) sind sowohl die Quell- als auch die Zielschemata komplex, und die Transformation muss die Kindabschnitte wiederholt verarbeiten. Um die Sache komplizierter zu machen, muss sie möglicherweise die Kindabschnitte bedingt verarbeiten:

  

Häufig müssen, um schnell Fortschritte bei komplexen Mappings zu erzielen, die Fachexperten der Endpunkte zusammengebracht werden, um die Anforderungen zu klären, was möglicherweise sogar geschäftliche Eingaben erfordert und zu Anpassungen der Endpunkte führen kann, was alles das Gesamtprojekt verzögern kann. Es ist von entscheidender Bedeutung, komplexe Integrationsanforderungen so schnell wie möglich zu identifizieren und Abhängigkeiten schnell zu klären, um das Projekt voranzutreiben.

Entwicklung

Wie bereits erwähnt, kann die Entwicklungsarbeit kurz nach dem Kickoff beginnen:

• Die Endpunkte verbinden.
• Einfache Szenarien identifizieren und umsetzen, insbesondere wenn es sich um Stammdaten handelt.
• Bei komplexen Integrationen, auch wenn sie nicht vollständig abgebildet sind, Schritte unternehmen, um die exponierten Integrationsmethoden in eine Transformation zu integrieren.
  • Schemata gelten (in der Regel) nur im Umgang mit Datenbanken und Webdiensten.
  • Beim Umgang mit Dateien können sie ein hierarchisches Format haben, das manuell in Jitterbit erstellt werden muss. Dies kann mühsam sein, daher sollte man frühzeitig damit beginnen.
  • Bei Datenbankendpunkten ist es effizienter, Sichten zu erstellen, als das Integrationsprojekt Tabellen zu verknüpfen. Eine gespeicherte Prozedur kann ein besserer Ansatz sein als komplexe Aktualisierungen durchzuführen.
  • Beim Arbeiten mit Endpunkt-Connectors die Jitterbit iPaaS-Assistenten verwenden und sicherstellen, dass alle relevanten Objekte verfügbar sind. Dies ist eine gute Möglichkeit, um zu validieren, dass der Integrationsbenutzer alle erforderlichen Berechtigungen hat.
• Der Entwickler sollte die Quell- und Zielschemata überprüfen, um "intelligente" Mapping-Fragen zu stellen, wie zum Beispiel:
  • "Haben wir alle Pflichtfelder?"
  • "Wenn wir eine Datensatz-ID übergeben, wird der Endpunkt automatisch einen Datensatz aktualisieren oder versuchen, ihn zu erstellen?"
  • "Wie viele Datensätze können in einem Aufruf übergeben werden?"
  • "Dieses SAP IDoc-Schema verwendet deutsche Abkürzungen. Sprechen Sie Deutsch?"
• Übersehen Sie nicht, das Antwortschema (wenn es sich um einen Webdienst handelt) zu überprüfen, insbesondere wie Fehler behandelt werden. Einige Schemata zeigen den Gesamterfolg oder -fehler an, während andere Codes bereitstellen, die ausgewertet werden müssen.

Verwaltung des Entwicklungsprozesses

Ein guter Ansatz zur Verwaltung des Entwicklungsprozesses besteht darin, die während der Abgrenzung erfassten Szenarien zu nehmen und Meilensteine in Bezug auf jedes Szenario zu verfolgen. Dies ist eine Beispiel-Tabelle, die verwendet wird, um wichtige Meilensteine in einer Integrationsentwicklung zu verfolgen:

Behandeln Sie jedes Szenario als eine Mini-Entwicklungsiteration, beginnend mit Datenabhängigkeiten (wie Stammdaten). Dann Operationen erstellen, Transformationen aufbauen, einige Testdaten abrufen, an einen Endpunkt senden, die Antwort verarbeiten. Streben Sie nicht nach Perfektion. Ziel ist es, einfache Testdaten von Punkt A nach Punkt B zu bewegen und dann zum nächsten Szenario überzugehen. Iterieren Sie dann die Entwicklung des Integrationsszenarios, indem Sie Blockaden aufdecken, bis das Hauptszenario für den Erfolg sowie die Fehlerszenarien entwickelt und getestet wurden.

Der erste Satz von Integrationen wird die sein, die die meisten Probleme verursachen, wie z.B. Konnektivität, Berechtigungen, fehlende Felder usw. Je schneller wir an diesen Punkt gelangen und die Blockaden beseitigen, desto besser. Wir streben nicht sofort nach Perfektion.

Beginnen Sie mit einem kleinen Satz von Testdaten. Diese können in Skripten fest codiert oder durch eine Abfrage, die auf nur wenige Datensätze beschränkt ist, verwendet werden.

Wenn es eine kleinere Blockade gibt, dokumentieren Sie diese, weisen Sie die Lösung der richtigen Person zu und gehen Sie zu einem anderen Szenario über. Nochmals, das Ziel ist es, schnell die Landminen zu finden, damit sie beseitigt werden können, und diese Verantwortung liegt normalerweise beim Kunden und/oder dem Fachexperten.

Hier ist ein Beispiel für eine Tabelle zur Verfolgung von Problemen:

Wiederverwendung

Wie bei jeder anderen Softwareentwicklungsplattform kann die Entwicklung beschleunigt werden, wenn Sie das Rad nicht neu erfinden. Jitterbit iPaaS bietet mehrere Möglichkeiten, dies zu ermöglichen:

• Skripte
  • Ganze benutzerdefinierte Funktionen können erstellt und aus vielen Operationen aufgerufen werden. Die allgemeine Faustregel lautet: Wenn Sie dasselbe Skript zweimal schreiben müssen, machen Sie es zu einem aufrufbaren Skript.
• Quellen und Ziele
  • Übergeben Sie globale und/oder Projektvariablen, anstatt Dinge wie Dateipfade oder FTP-Hosts fest zu codieren.
  • Verwenden Sie eine globale Variable als Zwischenarbeitsbereich anstelle von operation-spezifischen Quellen und Zielen.
• Operationen
  • Einzelaufgabenoperationen können einmal erstellt und viele Male verwendet werden, insbesondere solche, die mit Fehlerbehandlung und Protokollierung zu tun haben.
  • Operationen in einem Projekt können von einem anderen aufgerufen werden. Seien Sie sich bewusst, dass die Protokolle in den nativen (aufgerufenen) Projekten erscheinen. Da der Geltungsbereich globaler Variablen jedoch die Operationenkette ist (die von mehr als einem Projekt aufgerufen werden kann), ist es möglich, die Ergebnisse der entfernten Operation zu erhalten und sie im aufrufenden Projekt zu protokollieren.

Protokollierung und Fehlerbehandlung

Ein häufig übersehener Satz von Anforderungen betrifft die Protokollierung und Fehlerbehandlung. Der Kunde hat möglicherweise keine spezifischen Anforderungen, insbesondere wenn dies sein erstes Integrationsprojekt ist, daher benötigt der Kunde Hilfe bei den besten Praktiken in diesem Bereich. Die wichtigsten Punkte sind:

• Jitterbit iPaaS führt die Betriebsprotokollierung sofort aus.
• Es ist einfach, zusätzliche Daten zu protokollieren, was sehr nützlich für die Fehlersuche ist.
  • Hier könnte dem Kunden klar werden, dass seine Integrationsszenarien interne Unterstützung benötigen.
  • Wenn ein Problem in einem Endpunkt identifiziert wird und eine mögliche Ursache die Integration ist, muss eine Ressource die Protokolle überprüfen. Je klarer und informativer die Protokolle sind, desto schneller verläuft der Fehlersucheprozess.
• Es gibt zwei breite Klassen von Benachrichtigungen: datenbezogene Benachrichtigungen und technische Fehlermeldungen, die möglicherweise nicht an dieselbe Gruppe gehen müssen. Technische Fehler sind einfach zu konfigurieren, aber die datenbezogene Protokollierung ist vollständig benutzerdefiniert und lässt sich leichter während der Integrationsentwicklung einfügen, anstatt später hinzugefügt zu werden.
• Das Design Studio kann Emails recht einfach verwenden, wobei der Email-Dienst wie ein Endpunkt zum Email-Dienst des Kunden behandelt wird, unter Verwendung eines Design Studio Email-Ziels. Obwohl dies im Allgemeinen einfach einzurichten ist, sollte dieser Schritt nicht bis zum Schluss aufgeschoben werden.
• Die Jitterbit Management Console kann verwendet werden, um zusätzliche organisationsbezogene Benachrichtigungen zu konfigurieren.

Für detaillierte Informationen siehe Benachrichtigungen, Protokollierung und Fehlerbehandlung einrichten und die Benachrichtigungen Seite.

Verarbeitung von Geschäftsregeln

Die große Debatte: Geschäftsregeln einbeziehen – oder nicht einbeziehen.

Viele Kunden beginnen mit dem Gedanken: "Ich möchte keine Geschäftsregeln in der Middleware einbeziehen; ich möchte die Dinge einfach halten", geben dann jedoch genau das Gegenteil an Anforderungen an!

Die ideale Middleware-Architektur sieht vor, dass die Integrationsschicht so schlank wie möglich sein sollte, wobei der Fokus auf ihren Stärken liegt: Datenumwandlung, Szenarienverarbeitung und Orchestrierung, Endpunktverbindung sowie Protokollierung und Benachrichtigung. Umständliche Geschäftsregeln werden nur die Perfektion dieser Architektur beeinträchtigen, indem sie die Unterstützung für Geschäftsregeln über die Endpunktgrenzen hinweg verteilen. Das heißt, wenn sich eine Geschäftsregel ändert, ändert sie sich nicht nur in der Anwendung; sie ändert sich auch in der Middleware. Darüber hinaus ist die Regelwartung, da Middleware unklar, trübe und mystisch ist, äußerst mühsam.

Realität dringt unhöflich ein, da Jitterbit iPaaS mit dem arbeiten muss, was Anwendungen bereitstellen:

• Die Daten werden schlecht präsentiert, und die einzige Möglichkeit, sie zu verarbeiten, besteht darin, Geschäftsregeln anzuwenden ("wenn Wert = a, Abteilung = Vertrieb, wenn b, Abteilung = Betrieb, wenn c, Abteilung = Support").
• Die Quelldaten sind unvollständig ("wenn Land = USA, Geschäftsjahr ist Kalenderjahr, wenn Land = UK, Geschäftsjahr ist April - März")
• Das Integrationsszenario ist datengesteuert ("wenn Arbeitsauftrag Zeilen mit Dritten enthält, verarbeite diese Zeile als AP-Eintrag, andernfalls aktualisiere sie als Serviceauftrag")

Ja, all das könnte vom Endpunkt behandelt werden. Aber das setzt voraus, dass der Kunde die Ressourcen und die Zeit hat, den Endpunkt anzupassen oder eine API zu ändern. Wenn all das verfügbar ist, dann tun Sie das auf jeden Fall. Allerdings ist der übliche Fall, dass die Endpunkte schwieriger zu ändern und zu warten sind als das Integrationsprojekt.

Wenn Geschäftsregeln behandelt werden müssen, sind die besten Praktiken diese:

• Externalisieren, wo möglich. Zum Beispiel Daten in einer Tabelle haben, die von einem Benutzer gepflegt werden kann.
• Projektvariablen verwenden. Diese sind in der Jitterbit Management Console zusammen mit spezifischer Dokumentation verfügbar. Der Hauptanwendungsfall sind umgebungsspezifische Endpunktanmeldeinformationen, aber diese können auch verwendet werden, um Orchestrierungslogik und Abfragebedingungen zu steuern.
• Detaillierte benutzerdefinierte Protokollierung und Datenfehlerbehandlung hinzufügen, damit, wenn und wann sich die Geschäftsregeln ändern, die Auswirkungen auf die Integration offensichtlich sind.

Agenten und Umgebungen

Der Jitterbit-Agent ist das Integrationsarbeitstier. Design Studio führt tatsächlich keine Betriebsprozesse aus. Alles geschieht auf einem Jitterbit-Agenten. Eine wichtige frühe Entscheidung ist, welche Art von Agent verwendet werden soll: entweder privat oder Cloud (siehe Jitterbit-Agenten).

Wenn eines dieser Dinge zutrifft, muss das Projekt auf einem privaten Agenten ausgeführt werden:

• Ein Endpunkt befindet sich hinter der Firewall des Kunden. Dies kann eine Anwendung oder ein Netzwerkfreigabe sein.
• Ein Connector oder Treiber wird benötigt, der in den Cloud-Agenten nicht verfügbar ist. Zum Beispiel ist der Excel-Treiber nur auf privaten Agenten verfügbar.
• Die Sicherheitsanforderungen des Kunden sind so, dass keine Daten außerhalb ihrer Firewall erlaubt sind.

Andernfalls sind Cloud-Agenten eine Option. Aus der Perspektive des Projektzeitplans ist dies ideal, da alle Schritte vermieden werden, die damit verbunden sind, dass ein Kunde Serverhardware beschaffen und die Jitterbit-Agentensoftware installieren muss. Unabhängig davon, ob Sie Cloud- oder private Agenten verwenden, müssen Sie dennoch Mitglieder und Umgebungen einrichten.

Je nach Lizenzstufe hat ein Kunde zwei oder mehr Lizenzen für private Agenten. Außerdem hat der Kunde Anspruch auf eine Anzahl von Umgebungen, die typischerweise gemäß den Kategorien des standardmäßigen Softwareentwicklungszyklus eingerichtet werden (Entwicklung, Qualität, Staging, Produktion, Support usw.). Das Übertragungswerkzeug von Jitterbit funktioniert mit Umgebungen, um die Förderung von Integrationsprojekten zu ermöglichen.

Bezüglich Agenten und Umgebungen beachten Sie diese wichtigen Punkte:

• Die Identifizierung einer Umgebung als "Produktion" verleiht nichts Besonderes. Sie läuft nicht schneller oder ist widerstandsfähiger. Eine Umgebung ist ziemlich ähnlich wie jede andere.

• Eine Harmony-Umgebung kann auf viele Arten verwendet werden. Wenn der Kunde Integrationen für Dritte bereitstellt, kann eine Umgebung als Container für dedizierte Unternehmensprojekte verwendet werden.

• Ein einzelner privater Agent kann mehr als eine Umgebung ausführen.

• Eine häufige Frage ist, ob Netzwerkfirewallregeln geändert werden müssen. In der Regel ist die Antwort "nein", es sei denn, der Kunde schränkt den ausgehenden HTTP-Verkehr von Servern und/oder Ports ein. Die Kommunikation von Harmony zu Agenten erfolgt vollständig ausgehend vom Agenten zu Harmony.

Eine Agentengruppe ist ein obligatorischer Teil der Agentenarchitektur. Abgesehen davon, dass sie der virtuelle Container ist, der die privaten Agenten hält, spielt sie eine weitere wichtige Rolle. Im Gegensatz zu traditionellen Serververwaltungswerkzeugen, die zusätzliche Anwendungen wie Lastenausgleicher erfordern, erleichtert Harmony die Erreichung der Serverresilienz durch Lastenausgleich und Failover. Indem einfach ein Agent zu einer Gruppe hinzugefügt wird, wird der Agent automatisch Teil eines Serverclusters.

Um klarzustellen: Wenn eine Operation in einer Agentengruppe mit mehreren Agenten ausgeführt wird, führt nur ein Agent diese Operation aus. Die Operation wird nicht aufgeteilt und über alle Agenten in der Gruppe ausgeführt. Das Hinzufügen von Agenten zu einer Gruppe wird die Operationen normalerweise nicht schneller machen. Die Ausnahme ist ein Design, das eine Gruppe von Agenten vorsieht, um stark frequentierte eingehende APIs zu bedienen, in diesem Fall ist es eine gute Idee, die Last auf mehrere Agenten zu verteilen.

Um mit der Entwicklung zu beginnen, wird lediglich ein einzelner privater Agent und eine einzelne Umgebung benötigt. Zusätzliche Agenten können Gruppen hinzugefügt werden, und neue Umgebungen können im Verlauf des Projekts hinzugefügt werden (alles innerhalb der Lizenzgrenzen, versteht sich).

Falls es problematisch ist, auch nur einen einzigen Agenten zu beschaffen, kann ein Jitterbit privater Agent auf einem Arbeitsplatzrechner ausgeführt werden. Der beste Weg, dies zu tun, ist die Verwendung des Docker-Agenten, um Konflikte mit dem Desktop zu vermeiden.

Batch- und ereignisgesteuerte (Echtzeit-)Verarbeitung

Für jedes Integrationsszenario gibt es eine große Entscheidung: Wie wird die Integration ausgelöst?

Es gibt grundsätzlich zwei Möglichkeiten: einen Batch-Ansatz, wie zum Beispiel durch einen Zeitplan, oder ausgelöst durch ein Ereignis, wie durch eine API.

Aus der Perspektive eines Integrationsprojekts ist die Implementierung der ereignisgesteuerten Verarbeitung wesentlich weniger aufwendig als bei Batch. Warum ist das so?

• Während Jitterbit eine Planungsfunktion unterstützt, erfordern die meisten Batch-Prozesse einen Prozess zum Abrufen von Daten basierend auf einem "letzten Änderungsdatum", was benutzerdefinierte Skripte erfordert, um die letzte Ausführungszeit der Operation abzurufen, zu entscheiden, ob die Operation erfolgreich war, und dann das Zeitstempel-Repository zu aktualisieren. Unterwegs muss man mit potenziell unterschiedlichen Zeitzonen der Endpunkte, der Sommerzeit und Datumsformaten umgehen. Vergessen Sie nicht: Abfragen Sie nur Daten, die von allen Benutzern außer dem Integrationsbenutzer geändert wurden. Und beim Migrieren zu anderen Umgebungen müssen Sie die Zeitpläne gemäß dem Projektplan ein- und ausschalten. Keine dieser Herausforderungen ist riesig, aber eindeutig wird eine Last an Entwicklungs- und Verwaltungsverantwortung auf die Integrationsschicht gelegt.

• Vergleichen Sie Batch mit ereignisgesteuert: Die Operation wird nur aufgerufen, wenn sie vom Endpunkt aufgerufen wird. Keine Zeitpläne, keine Zeitstempel, keine Zeitzonen. Die Verantwortung liegt eindeutig beim Endpunkt.

• Der Hauptmechanismus für die ereignisgesteuerte Verarbeitung von Jitterbit iPaaS erfolgt über die APIs des API-Managers. Obwohl die Lizenzkosten höher sind, ist es das auf jeden Fall wert.

• Offensichtlich ist Batch Ihre einzige Option, wenn der Endpunkt das Aufrufen einer API nicht unterstützt. Außerdem könnte der Kunde zögern, eine API zu verwenden, wenn Batch eine Option ist.

Dann gibt es diese seltsame Chimäre, die "Fast-Batch"-Option, bei der die geschäftliche Anforderung darin besteht, Daten so schnell wie möglich in ein Ziel zu bringen, der Kunde jedoch keine API implementieren möchte. Das Gespräch verläuft ungefähr so:

Jitterbit: Für das Bestellszenario, wann möchten Sie, dass die Bestellungen im ERP angezeigt werden?

Kunde: So schnell wie möglich.

Jitterbit: Dann wollen wir Echtzeit und verwenden APIs.

Kunde: Nein, das möchte ich nicht tun. Können wir nicht einen wirklich schnellen Batch machen?

Jitterbit: Sie meinen, alle 10 Minuten zu überprüfen, ob es neue Bestellungen gibt?

Kunde: Nein, schneller als das. Was ist die minimale Zeit für einen Zeitplan?

Jitterbit: Ähm… eine Minute.

Kunde: Großartig! Abfragen des Bestellsystems jede Minute! Fertig!

Jitterbit: Moment mal. Ihnen ist bewusst, dass Sie das Bestellsystem stark belasten werden, wo die meiste Zeit keine Daten zu verarbeiten sind. Sie werden viele verschwendete Zyklen haben, und das Durchsehen der Betriebsprotokolle wird mühsam sein. Wenn Ihre geschäftliche Anforderung wirklich darin besteht, Daten so schnell wie möglich zu bewegen, dann müssen Sie eine API verwenden. Darüber hinaus gibt es eine Reihe anderer Vorteile…

Und hier tut der Kunde, ermutigt durch diese Informationen, das Richtige und genehmigt die Verwendung einer API. Aber wenn Sie nicht überzeugend genug sind, kontaktieren Sie unser Marketing-Team; die haben das im Griff.

Beachten Sie diese Überlegungen zur Verwendung von APIs:

• Stellen Sie sicher, dass Sie die maximalen API-Verarbeitungsanforderungen verstehen.
  • Sie verstehen, dass die API aufgerufen wird, wenn ein Benutzer einen Datensatz ändert. Einfach! Das Design sieht vor, dass die Operation direkt aufgerufen wird und dann sofort das Ziel aktualisiert wird.
  • Aber was der Kunde vergessen hat zu sagen (und was Sie vergessen haben zu fragen), ist, dass bei einer Massenaktualisierung von Datensätzen, anstatt alle 10 Minuten einen Datensatz zu erhalten, Sie 10.000 erhalten. Jitterbit wird seine Arbeit tun und so viele Threads hochfahren, wie der Server bewältigen kann, und den Rest des eingehenden Verkehrs in die Warteschlange stellen und mit der Aktualisierung des Ziels beginnen. Dies könnte das Zielsystem überwältigen.
• Überprüfen Sie die maximale Ausgabe und ziehen Sie in Betracht, eine JMS-Warteschlange, eine Datenbank oder sogar eine temporäre Datei hinzuzufügen, um die eingehenden API-Daten vor der Verarbeitung in das Ziel zu halten.
• APIs sind unabhängig von den Umgebungen lizenziert. Wenn also eine API für jede der Entwicklungs-, QA- und Produktionsumgebungen verwendet wird, sind das drei API-Lizenzen, nicht eine.

Transfer

Je nach Prozess des Kunden muss das Projekt möglicherweise vor dem UAT in eine QA-Umgebung übertragen werden, oder die Tests erfolgen in einer Entwicklungsumgebung, und das Projekt wird dann in eine Produktionsumgebung übertragen.

• Wenn möglich, übertragen Sie nicht in die nächsthöhere Umgebung, bis das Projekt nahezu abgeschlossen ist. Sobald eine Übertragung erfolgt, müssen Sie sich daran erinnern, es auch in andere Umgebungen zu übertragen.

• Vermeiden Sie es, Änderungen in einer "höheren" Umgebung vorzunehmen, um ein Problem schnell zu lösen, in der Annahme, dass Sie die Umgebungen später synchronisieren werden. Machen Sie stattdessen die Korrektur in der "niedrigeren" Umgebung und übertragen Sie sie. Es gibt keinen narrensicheren Weg, um granulare Unterschiede zwischen Projekten zu identifizieren, sodass es leicht ist, den Überblick über Änderungen zu verlieren.

User Acceptance Testing (UAT)

Alle Szenarien sind erstellt, alle Unit-Tests sind erfolgreich, und die Benutzer stehen bereit, um die Integration zu testen. Es ist Zeit, die Benutzer auf die Integration loszulassen, und jetzt werden Sie herausfinden, was die wirklichen Anforderungen sind!

Diese Phase kann ein reibungsloser Prozess oder sehr intensiv sein. Es hängt wirklich von der Qualität der vorherigen Schritte ab. Behalten Sie diese Tipps während der UAT-Phase im Hinterkopf:

• Seien Sie bereit, schnell zu reagieren, wenn Probleme auftreten. Wenn Sie Ihre Arbeit gut gemacht haben, werden die meisten Probleme datenbezogen und nicht technisch sein. Stellen Sie also sicher, dass die Endpoint-SME verfügbar sind, um Probleme zu triagieren.

• Wo möglich, lassen Sie den Benutzer die Führung bei der Fehlersuche übernehmen: auf Warnungen reagieren, Protokolle lesen, die Integrationslogik nachverfolgen. Idealerweise wird die Person, die diesen Job in der Produktion ausführen wird, dies während dieser Phase tun.

• Behalten Sie genau im Auge, welche Probleme während des UAT auftreten und wie sie gelöst werden. Eine häufige Situation ist, dass Probleme die Endpunktdaten betreffen, und während das Integrationsproblem behoben wird, sind die Daten es nicht und werden zu einem wiederkehrenden Problem beim Testen.

• Planen Sie häufige Meetings mit allen Beteiligten ein, um etwaige Blockaden zu lösen.

• Sofern die Zeit es erlaubt, beginnen Sie mit der Dokumentation.

• Entwickeln Sie Ihren Cut-Over-Plan.

• Führen Sie in der Produktionsumgebung Verbindungstests und alle anderen Tests durch, die Sie durchführen können oder die erlaubt sind.

Nachproduktion und Überwachung

UAT abgeschlossen! Benutzerfreigabe erfolgt! Es ist Zeit, diese Rakete zu starten!

In dieser Phase sollte der endgültige Transfer in die Produktion abgeschlossen sein. Wenn Sie Zeitpläne verwenden, beachten Sie, dass Sie diese in die Produktion übertragen und im Jitterbit Management Console deaktivieren können. Es liegt dann am Kunden, die Zeitpläne zu aktivieren.

Erwarten Sie, sich regelmäßig mit dem Kunden zu treffen, um sicherzustellen, dass alles reibungslos verläuft, und rechnen Sie mit einigen Fragen.

Planen Sie ein "Abschluss"-Meeting ein, um die Projektdokumentation zu übergeben und einen letzten Wissensaustausch durchzuführen.