Integrationsprojektmethodik für Jitterbit Integration Studio

Einführung

Seien wir ehrlich: Integrationsprojekte können schwierig sein und viele potenzielle Fallstricke bergen. Wenn Integration „Daten in Bewegung“ bedeutet, gibt es Zeiten, in denen die Daten nicht bewegt werden wollen. Integrationsprojekte sind stark von Endpoints abhängig und können daher Risiken bergen, die außerhalb der Kontrolle des Integrators liegen.

In einer idealen Welt sind die Endpoints stabil, verfügen über gut dokumentierte APIs und haben klare Fehlerreaktionen. Es gibt leicht verfügbare SMEs (Fachexperten) und Nicht-Produktionsumgebungen sind sowohl für die Entwicklung als auch für Tests verfügbar. Außerdem ist das Projekt gut finanziert, hat für das Management absolute Priorität und es gibt ausreichend Zeit für Tests. Wenn das nach Ihrem Projekt klingt, herzlichen Glückwunsch! Für den Rest von uns gilt: Lesen Sie weiter.

Ansatz

Wenn Sie wissen, dass es ein Feld voller Landminen gibt, haben Sie zwei Möglichkeiten:

1. Gehen Sie sehr vorsichtig und überlegt vor, untersuchen Sie die gesamte Landschaft bis ins kleinste Detail und bauen Sie erst, wenn alles bekannt ist.

2. Legen Sie so schnell wie möglich los, identifizieren Sie alle Landminen frühzeitig und feiern Sie die Detonationen … denn es ist viel besser, Probleme frühzeitig zu entdecken, als sie später zu entdecken.

Also gut, es ist Nummer 2. Schnall dich an, wir werden schnell vorankommen.

Publikum

Die Zielgruppe sind Projektmanager (PM) oder technische Leiter mit allgemeiner IT-Erfahrung, die derzeit ein Integrationsprojekt mit Jitterbit iPaaS leiten.

Hierzu gehören Personen in Rollen wie beispielsweise ein Jitterbit-Partner, der allgemeine Integrationsarbeiten durchführt, ein Anwendungsanbieter, der auch die Aufgabe übernimmt, die Integrationen von Ihrem Produkt zu allen Endpoints des Kunden aufzubauen, oder ein Kunden-PM, der Jitterbit iPaaS allein oder mit Hilfe von Jitterbit Professional Services implementiert.

Fokus

Der Schwerpunkt dieses Dokuments liegt nicht auf der technischen Verwendung von Jitterbit (lesen Sie die anderen Dokumentationen für die technischen Details), 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 erfassen und validieren und die Stärken von Jitterbit iPaaS nutzen, um ein erfolgreiches Projekt abzuliefern.

Umfang

Die Festlegung des Umfangs erfolgt in zwei Schritten: Das Sammeln von Informationen, das Festlegen der Projektgrenzen und das Einholen der grundlegenden Informationen, die zur Umsetzung des Projekts erforderlich sind:

1. Ungefähre Größenordnung: Schätzen Sie eine grobe Größenordnung (ROM) auf hoher Ebene für die Arbeit (kann für bestimmte Endpoints übersprungen werden).
2. Arbeitsumfang: Verfeinern Sie die Schätzung, indem Sie einen Arbeitsumfang (SOW) für die Durchführung des Projekts detailliert beschreiben.

Dieser Prozess ist sensibel für das GIGO-Konzept (Garbage In, Garbage Out) - also vernachlässigen Sie ihn nicht. Die folgende Tabelle dient als Ausgangspunkt für den Scope-Prozess. Die in dieser Tabelle verwendete spezifische Terminologie wird später in der groben Größenordnung definiert und Arbeitsumfang Unterabschnitte.

Grobe Größenordnung (ROM)

Bei diesem Schritt wird vorausgesetzt, dass der Kunde ausreichende Analysen durchgeführt hat, um zu bestimmen, welche Schnittstellen erstellt werden müssen. Auf hoher Ebene werden Schnittstellen benötigt, wenn ein Geschäftsprozess Anwendungsgrenzen überschreitet. Wenn die Geschäftsprozesse nicht fest sind, ist auch die Integration nicht fest und es ist möglicherweise zu früh, um dies abzuschätzen.

Die grobe Größenordnung (ROM) ist so konzipiert, dass sie auf hohem Niveau bleibt und eine schnelle Bearbeitung ermöglicht, um die Planung und Entscheidungsfindung des Kunden zu unterstützen. ROM-Schätzungen basieren auf diesen Elementen:

• Endpoints: Dies ist das „Ding“, mit dem Jitterbit iPaaS interagiert, um Daten zu lesen/von ihnen zu 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 zum Erreichen des Integrationsziels erforderlich ist. Beispiele hierfür sind „Konten synchronisieren“, „Bestellungen erstellen“ oder „Lieferinformationen abrufen“.
  • Objekt: Dies kann ein SFDC-Objekt (Salesforce) (wie ein Konto oder Produkt), eine Datenbanktabelle oder ein virtuelles Geschäftsobjekt wie eine Bestellung in einem EDI-Dokument sein.
  • Methode: Dies wird mit den Daten gemacht, z. B. CRUD (Erstellen, Lesen, Aktualisieren und Löschen).
  • Transformation: Dies kann eine der folgenden Stufen sein:
    • Niedrig: Verwendet Endpoint, eine geringe Anzahl von Transformations und ein oder zwei Operationen für das Szenario.
    • Mittel: Verwendet möglicherweise Endpoint, nutzt eine Reihe von Transformations und externen Nachschlagevorgängen und nutzt mehrere Vorgänge pro Szenario.
    • Hoch: Keine Endpoint Konnektoren, zahlreiche Szenarioschritte und der Endpoint gilt als herausfordernd.

Zur Berechnung der Stunden werden Heuristiken verwendet. Basierend auf der Anzahl der Szenarien und der Komplexität werden Formeln verwendet, um eine Schätzung zu erhalten, 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. Es handelt sich auch um End-to-End: von der Initiierung bis zur Post-Go-Live-Phase. Die Zeit zum Erstellen einer Integration entspricht nicht eins zu eins der verstrichenen Zeit. Der tatsächliche Zeitrahmen hängt von der Personalstärke, der Stabilität der Endpoints, der Verfügbarkeit von KMUs des Kunden usw. ab. Aus Vorsicht gehen wir von einem Verhältnis von 3:1 zwischen Kalenderdauer und geschätzten Stunden aus.

Arbeitsumfang (SOW)

Der Arbeitsumfang (Scope of Work, SOW) soll mehr Details liefern, um ein klareres Bild des Projekts zu erhalten und eine Überprüfung oder Neuberechnung der ROM-Schätzung zu ermöglichen. Für bestimmte Endpoints (wie SAP) oder Projekttypen (wie Hub-Deals) können Sie den ROM-Prozess überspringen und direkt zum SOW-Schritt übergehen.

Während dieses Schritts sollten Sie eine Scoping-Sitzung vereinbaren, um die Details festzulegen und offene Fragen zu beantworten. Zu den idealen Teilnehmern gehören Geschäftsbenutzer (und alle Prozessverantwortlichen) und Endpoint-SMEs. Die Einbeziehung der letzteren ist entscheidend, da es sonst schwierig sein kann, ins Detail zu gehen.

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

• Endpoints

  • Versionen: Zu verwendende oder anzutreffende Versionen.

  • Vor Ort/außerhalb: Wenn Sie vor Ort arbeiten, sollten Sie unbedingt die Verwendung von Cloud- und privaten Agenten behandeln. Ein häufiges Problem ist die Netzwerksicherheit, z. B. das Öffnen der Firewall für private Agenten. Versichern Sie daher dem Kunden und den Beteiligten, dass dies kein Sicherheitsrisiko darstellt. Stellen Sie einen Link zum Whitepaper zu Jitterbit-Sicherheit und-Architektur bereit und die Hostsystemanforderungen für private Agenten.

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

  • Lebenszyklusphasen: In Entwicklung/Vorproduktion, Wartung, wird aktualisiert, Sonnenuntergang.

• Endpoint-Expertise

  • Interne vs. externe Expertise: Bei komplexen Endpoint wie ERP oder CRM gibt es normalerweise entweder interne Expertise in der IT-Abteilung oder bei einem Implementierungspartner und/oder Helpdesk. Wenn Sie über interne Expertise verfügen, ist das natürlich umso besser.
  • Grenzen/Rollen: Manchmal ist den Kunden die Rolle des Integrators nicht klar und sie gehen davon aus, dass die Endpoint von Jitterbit durchgeführt wird. Wenn dieses Thema aufkommt, machen Sie die Grenzen deutlich.
  • Verfügbarkeit und Qualität der Dokumentation: Angesichts der zunehmenden Verbreitung von Cloud-Diensten und APIs listen manche Anbieter ihre APIs einfach auf, die Dokumentation kann jedoch dürftig sein. Wenn dies auf Sie zutrifft, müssen Sie Zeit für die Entdeckung, Machbarkeit und Prüfung einplanen.

• Integrationsszenarien

  • Methoden- und Endpoint: Definieren Sie diese für jedes Szenario. Beispiele:
    • „Führen Sie in regelmäßigen Abständen stapelweise Abfrage für neue Kunden in Endpoint X in das Konto in Endpoint Y Batch und aktualisieren Sie die neue Kontonummer auf Kunde.“
    • "Erhalten Sie eine Echtzeitanfrage von Endpoint X, die Bestellinformationen zum Senden an Endpoint Y enthält. Erstellen Sie eine Bestellmethode und antworten Sie mit einer neuen Bestellnummer."
    • "Datenbanktabelle X abfragen und 200.000 Lagerbestandswerte an Endpoint Y Inventory API aktualisieren."
  • Potenzielle Blocker: Die Szenarien werden für die Zeitschätzung verwendet. Erwarten Sie, dass die Entwicklung jedes Szenarios (sofern es nicht extrem einfach ist) auf Blocker stößt. Diese können von technischen (falsche Anmeldeinformationen, unzugänglicher Endpoint, undurchsichtige API) bis zu verfahrenstechnischen (das Unternehmen muss einen neuen Prozess definieren, Anpassung ist erforderlich, KMU sind nicht verfügbar) reichen.

• Zeitrahmen

  • Wichtige Termine: Normalerweise kennt ein Kunde den Zeitpunkt der Produktivsetzung, aber es gibt noch weitere wichtige Termine.

• Termine für User Acceptance Testing (UAT): Wann beginnt das UAT? (Dies bedarf möglicherweise einer Erklärung, wenn der Kunde nicht an eine stufenweise Entwicklung gewöhnt ist.)

  • Endpoint: Wann sind die Umgebungen bei Verwendung neuer Endpoints für die Integrationsentwicklung und -tests bereit?

  • KMU-Verfügbarkeit: Gibt es Einschränkungen hinsichtlich der KMU-Verfügbarkeit?

    Achtung

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

• Ressourcen

  • Ansätze: Kunden haben unterschiedliche Ansätze in Bezug auf Projektressourcen:

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

    • Meistens Insourcing: Der Kunde lernt die Verwendung von Jitterbit iPaaS und möchte lediglich Zugang zu einem Jitterbit-KMU für Anleitung und Best Practices.

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

      Hinweis

      Dem Kunden ist möglicherweise nicht bewusst, dass er ohnehin sehr viel Zeit mit dem Projekt verbringen wird und dass die Verlagerung der Entwicklung von extern nach intern keine großen Auswirkungen hat (da der Großteil davon auf eine einzige Phase beschränkt ist) und den Fortschritt aufgrund des Wissenstransfers (KT) sogar verlangsamen kann.

  • Involvierungsniveau: Dieses Diagramm veranschaulicht das relative Involvierungsniveau des Projektmanagers (PM), der Kundenressourcen und der Entwicklungsressourcen. Beachten Sie, dass die Entwicklungsressourcen während der Entwicklungsphase am stärksten involviert sind und danach nachlassen. Kundenressourcen (normalerweise Geschäftsbenutzer) sind während der UAT-Phase (User Acceptance Testing) stark involviert, was häufig übersehen wird.

    

Personalbedarf

Diese allgemeinen Richtlinien gelten für die Besetzung von Ressourcen mit technischen und PM-Kenntnissen bei Jitterbit. Sie schließen Ressourcen wie KMUs für Kundengeschäftsverfahren und Endpoint aus. Basierend auf der Größe des Projekts werden diese Personalstärken empfohlen:

• Kleine Projekte: Projekte mit 2 Endpoints und weniger als 12 Szenarien können von einer einzigen technischen Teilzeitressource mit Jitterbit-Kenntnissen und einem Teilzeit-Projektmanager bearbeitet werden.

• Mittelgroße Projekte: Projekte mit 2–4 Endpoints und 12–20 Szenarien können den gleichen Personalbestand wie kleine Projekte haben, allerdings mit mehr eingebundenem Personal.

• Große Projekte: Projekte mit 5+ Endpoints und 20+ Szenarien weisen bei der Personalbestimmung viele Abhängigkeiten auf.

Die PM- Rolle kann im Verlauf des Projekts eine Beteiligung von nahezu 100 % umfassen, wenn eine der folgenden Aussagen zutrifft:

• Der Kunde verlangt ein detailliertes Statusreporting (z.B. Reporting an ein Projektmanagement-Office).

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

• Der Kunde wird wahrscheinlich Schwierigkeiten haben, detaillierte Integrationsanforderungen zu erhalten.

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

Führen Sie in solchen Situationen ein striktes Umfangs- und Änderungsmanagement durch! Machen Sie dem Kunden klar, dass der Erfolg des Projekts davon abhängt, dass der Kunde alle Blockaden beseitigt und alle Projektressourcen die Termine einhalten.

Wenn Sie mehrere Entwicklungsressourcen verwenden, berücksichtigen Sie Folgendes:

• Wenn mehr als ein Entwickler an einem einzigen Jitterbit-Projekt beteiligt ist, ist ein hohes Maß an Koordination erforderlich (mehr Arbeit für den PM), da es leicht passieren kann, dass Änderungen einsetzen und die Arbeit eines anderen überschrieben wird.

• Versuchen Sie, die Entwickler unterschiedlichen Integrationsszenarien zuzuweisen oder die Arbeit auf unterschiedliche Jitterbit-Projekte aufzuteilen.

• Nutzen Sie entwicklerübergreifende Design- und Code-Reviews.

• Erhöhen Sie wenn möglich die Ressourcen während der Entwicklungsphase und reduzieren Sie sie dann während der UAT- und Go-Live-Phasen.

Auftaktbesprechung

Der Zweck des Kickoff-Meetings besteht darin, die wichtigsten Teilnehmer des Projekts zusammenzubringen, in der Regel die wichtigsten Geschäftsbenutzer, KMU, Endpoint und Integrationsarchitekten. Diese Zeit wird genutzt, damit alle auf den gleichen Stand kommen und die Rollen und Verantwortlichkeiten geklärt werden. Während des Kickoff-Meetings sollten diese Aufgaben erledigt werden:

• Wichtige Termine: Überprüfen Sie alle wichtigen Termine (nicht nur das Datum der Inbetriebnahme).
• Informationsaustausch: Geben Sie Kontaktinformationen und Dokumente frei.
• Überprüfung der Integrationsszenarien: Überprüfen Sie die Integrationsszenarien anhand der Festlegung des Umfangs.
  • Dies ist ein guter Zeitpunkt, um zu bestätigen, ob sich seit der letzten Scoping-Sitzung etwas geändert hat.
  • Vereinbaren Sie bei Bedarf ein ausführliches Scoping-Review-Meeting.
• Rollen und Verantwortlichkeiten: Die Integration mit Jitterbit geht sehr schnell, aber bedenken Sie, dass der größte Faktor, der ein Integrationsprojekt verzögert, die nicht-technischen Abhängigkeiten sind. Dies ist ein guter Zeitpunkt, diesen Punkt hervorzuheben. Klären Sie die Verantwortlichkeiten für jede Rolle:
  • Nachmittag
    • Arbeitet mit dem Kunden und dem technischen Team zusammen, um detaillierte Integrationsanforderungen, einschließlich Zuordnungen auf Feldebene, zu erhalten und zu organisieren. Zuordnungen auf Feldebene werden sowohl von den Jitterbit-Entwicklungsressourcen als auch von den Endpoint-SMEs benötigt.
    • Organisiert die Verfügbarkeit von Geschäfts- und Endpoint-KMU für das Projekt und kümmert sich umgehend um offene Punkte für die Integration, wie z. B. „Wer ist wer“, ihr Grad des Projektengagements, Kalender usw.
    • Kommuniziert dem Kunden und dem technischen Team den Entwicklungsfortschritt der Integration und die zu lösenden offenen Punkte.
  • Jitterbit-Entwickler
    • Erlangt ein Verständnis der Anforderungen für den Entwurf der Integrationsarchitektur und arbeitet mit dem Kunden an Entwurfsüberlegungen (Batch/Echtzeit, APIs, Stammdatenverwaltung, Sicherheitsanforderungen usw.).
    • Übernimmt die detaillierten Anforderungen und verwendet das Tool, um die Operation unter Befolgung der Jitterbit-Best Practices zu entwickeln.
    • Erkennt schnell etwaige Hindernisse und ergreift die Initiative, um sie zu beseitigen.
    • Im Idealfall steht der Jitterbit Entwickler in direkter Kommunikation mit dem Kunden. Den Jitterbit Entwickler von KMU und Kunden zu isolieren, ist eine schlechte Praxis und führt zu Kommunikationsstörungen und Verzögerungen. Die Projektressourcen müssen ein Team sein und reibungslos kommunizieren.
  • Endpoint KMU
    • Bietet tiefgreifendes Fachwissen zu den bereitgestellten Schnittstellen.
    • Versteht die Integrationsanforderungen und benachrichtigt das Team proaktiv, wenn potenzielle Probleme auftreten, z. B. wenn eine Änderung an einem Endpoint erforderlich ist oder eine Anforderung nicht durchführbar ist.
    • Ist hoch verfügbar, um bei Unit-Tests zu helfen. Dazu kann das Bereitstellen von Testdaten, das schnelle Geben von Feedback zu den Ergebnissen von Integrationstests und das Interpretieren von Fehlerantworten gehören.
• Lizenzierung und Berechtigungen: Überprüfen Sie die Jitterbit-Lizenzierung und-Berechtigungen sowie den Prozess zum Anfordern von Berechtigungen.
• Harmony-Architektur: Beachten Sie diese Punkte bezüglich der Harmony-Architektur:
  • Wenn private Agenten verwendet werden, priorisieren Sie die Installation der technischen Architektur und die Konnektivität mit den Endpoints, in erster Linie für die Entwicklung.
  • Wenn Sie mit lokalen Systemen arbeiten, können viele Schritte einige Zeit in Anspruch nehmen, z. B. Hardwarebeschaffung, Installation privater Agenten, Netzwerkkonnektivität, Integrationsbenutzeranmeldeinformationen und der Testzyklus. Da mehrere Gruppen daran beteiligt sein können, sollten Sie dies so bald wie möglich für die Umfeld beginnen.
  • Gehen Sie davon aus, dass die beim Einrichten der Umfeld gewonnenen Erkenntnisse die Einrichtung der Nicht-Umfeld beschleunigen. Erledigen Sie diesen Schritt daher so schnell wie möglich.
• Harmony Mitgliedschaften: Stellen Sie sicher, dass die Entwicklungsressourcen der Harmony-Organisation mit Administratorberechtigung hinzugefügt werden (siehe Jitterbit-Organisationen).
• API-Manager APIs: Wenn APIs verwendet werden, überprüfen Sie die Abhängigkeiten. Überprüfen Sie die API Standard URL. Wenn der Kunde mit der Nutzung einer Testversion begonnen hat, ist es möglich, dass die Standard URL immer noch das Wort „Testversion“ enthält. Wenden Sie sich an die Jitterbit-Lizenzierung, um das zu entfernen, bevor Sie irgendwelche APIs erstellen.
• Zukünftige Meetings: Legen Sie den Rhythmus zukünftiger Meetings fest.
  • Wenn die Integration Teil einer Endpoint ist, nehmen Sie an diesen Meetings teil.
  • Ansonsten sind kurze, häufige Meetings (täglich ist nicht ungewöhnlich) vorzuziehen. Eine Instant-Messaging-Plattform wie Slack kann ebenfalls eingerichtet werden.

Integrationsprojektplan

Wie bereits erwähnt, gibt es bei der Integration viele Abhängigkeiten. Projektpläne gibt es in der Regel in zwei Typen:

• Teil der Implementierung eines neuen Endpoint, beispielsweise eines ERP.
• Standalone, wo die Endpoints relativ stabil sind.

Im ersten Fall können (und müssen) die Aufgaben des Integrationsprojekts mit dem Gesamtprojekt verflochten werden. Beispielsweise muss die Integrationsentwicklung warten, bis die Endpoint 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 jedes Szenario durchläuft. Der UAT-Abschnitt (User Acceptance Testing) kann verschoben werden, bis alle Szenarien einen gewissen Grad an Bereitschaft erreicht haben.

Anforderungserfassung und Entwicklung

Dieser Abschnitt behandelt zunächst den allgemeinen Ansatz für die Anforderungserfassung und -entwicklung und befasst sich dann mit den Details der Zuordnung, Entwicklung, Verwaltung des Entwicklungsprozesses, Wiederverwendung sowie Protokollierung und Fehlerbehandlung.

Allgemeiner Ansatz

Jitterbits Low-Code- und grafisches Entwicklungs-Frontend (Integration Studio) eignet sich für ein iteratives Modell. Dieser Ansatz ist kein Wasserfall, bei dem alle Anforderungen dokumentiert werden, bevor mit der Entwicklung begonnen wird. Diese wichtigen Schritte beschreiben das allgemeine iterative Modell:

• Beginnen Sie mit den Stammdatenszenarien. Da der Ansatz darin besteht, schnell einen Zyklus aus Definieren, Erstellen und Testen zu durchlaufen, müssen wir die Endpoints mit Stammdaten füllen, bevor wir mit Transaktionsdaten arbeiten.

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

  • SOR (Systems of Record): Die maßgebliche Quelle für Stammdaten, normalerweise ein ERP.
  • SOE (Systems of Engagement): Das kunden- oder verkäuferorientierte System, beispielsweise ein System zum Kauf eines Produkts.

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

  • Normalerweise werden die Stammdatenschlüssel des SOR im SOE gespeichert, um Aktualisierungen des SOR zu erleichtern. Wenn beispielsweise SAP der SOR und SFDC der SOE ist, werden SAP Kundennummern als externe IDs im SFDC gespeichert.
  • Da gemeinsam genutzte Schlüssel möglicherweise angepasst werden müssen (was zeitaufwändig sein kann), ist es wichtig, diesen Bereich gleich zu Beginn zu erledigen.

Dieses Diagramm zeigt ein Beispiel mit Salesforce als SOE (System of Engagement) und SAP als SOR (System of Record) in einem unidirektionalen Stammdatenfluss mit Rückschreiben.

Wenn Sie mit bidirektionalen Stammdatenaktualisierungen arbeiten, müssen Sie sich darüber im Klaren sein, dass die Integration kompliziert sein kann:

• Es können Race Conditions, Logik zum Ausschließen von Updates durch den Integrationsbenutzer, getrennt von den Geschäftsbenutzern, und gegenseitig freigegebene Schlüssel auftreten.
• Häufig sind die Geschäftsregeln für Stammdaten in den Endpoints nicht dieselben, und entweder muss die Integrationsschicht sie berücksichtigen oder die Endpoints müssen angepasst werden. Dies kann ein Hindernis darstellen. Arbeiten Sie daher die Szenarien für diese Art von Integrationen im Detail durch.

Zuordnung

Der PM sollte den Kunden mit der Arbeit an den detaillierten Zuordnungen auf Feldebene beginnen lassen. Diese werden sowohl von den Jitterbit-Entwicklungsressourcen als auch von den Endpoint-SMEs benötigt.

Der Kunde ist es möglicherweise gewohnt, die Systeme aus der Sicht der Benutzeroberfläche zu betrachten, und ist möglicherweise nicht in der Lage, Zuordnungen aus der Sicht der Schemata zu erstellen. Tragen Sie in diesem Fall die Schemata, wenn möglich, in die Zuordnungstabelle ein. Dies kann die Hilfe des KMU, Online-Dokumentation oder die Verwendung von Jitterbit iPaaS erfordern, um eine Verbindung zum Endpoint herzustellen und die Schemata abzurufen.

Wenn die Zuordnung unkompliziert ist, können Sie sie „live“ durchführen, indem Sie Jitterbit iPaaS verwenden, um die Endpoint während eines Kundenmeetings in eine Transformation einzubinden.

Diese Tabelle zeigt ein Beispiel für Zuordnungen auf Feldebene:

Wenn für den Einstieg genügend Szenariodefinitionen vorliegen, sollten Sie die Integration in Jitterbit iPaaS erstellen und so schnell wie möglich testen, um etwaige Blockierer zu identifizieren.

Achten Sie beim Durcharbeiten der Mapping-Tabelle durch den Kunden genau darauf, welche Mappings schwieriger sein werden. Bei der Transformation wird die Realität konkret, d. h. hier bilden wir die offengelegten Integrationsmethoden zwischen Systemen ab. Es ist wichtig herauszufinden, welche Szenarien schwieriger sind als andere, da diese mit einem hohen Zeitmultiplikator verbunden sind. Einfache Mappings können nur wenige Minuten dauern, während komplexe Mappings Tage dauern können. Achten Sie also auf diese Situationen und priorisieren Sie:

• Nachschlagevorgänge in externen Systemen: Bei manchen Systemen müssen Sie möglicherweise Werte nachschlagen, indem Sie Abfragen ausführen. Die Gefahr besteht hier in Leistungseinbußen: Beachten Sie, dass die Transformation auf Datensatzbasis ausgeführt wird. Wenn 200 Datensätze verarbeitet werden und die Transformation für jeden Datensatz eine Nachschlageoperation durchführt, sind das 200 Abfragen. Das ist keine große Sache, wenn das Ziel eine Datenbank ist, aber wenn das Ziel eine API ist, können das auch 200 Anmeldungen/Abmeldungen sein. Erwägen Sie die Verwendung eines Wörterbuchs, um die Daten in einem Script Abfrage und so eine einzelne Abfrage auszuführen.

• Komplexe Schemata: Die Transformation ist „iterationsbasiert“. Wenn beispielsweise die Quell- und Zielschemata flach sind (wie ein Kundenname und eine Privatadresse), wird die Transformation einmal pro Datensatz iteriert, wie folgt:

  

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

  

Um bei komplexen Mappings schnell voranzukommen, müssen die Endpoint-SMEs häufig zusammengebracht werden, um die Anforderungen auszuarbeiten. Dies kann sogar geschäftlichen Input erfordern und zu Endpoint-Anpassungen führen, was 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, damit das Projekt vorankommt.

Entwicklung

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

• Verbinden Sie die Endpoints.
• Einfache Szenarien, insbesondere bei Stammdaten, erkennen und umsetzen.
• Ergreifen Sie bei komplexen Integrationen, auch wenn sie nicht vollständig zugeordnet sind, Maßnahmen, um die freigegebenen Integrationsmethoden in eine Transformation zu integrieren.
  • Schemas gelten (normalerweise) nur beim Umgang mit Datenbanken und Webdiensten.
  • Beim Umgang mit Dateien können diese ein hierarchisches Format haben, das manuell in Jitterbit erstellt werden muss. Dies kann mühsam sein, also fangen Sie frühzeitig damit an.
  • Für Endpoints ist es effizienter, Ansichten zu erstellen, als das Integrationsprojekt Tabellen verknüpfen zu lassen. Eine gespeicherte Prozedur kann ein besserer Ansatz sein als die Durchführung komplexer Aktualisierungen.
  • Wenn Sie mit Endpoint-Konnektoren arbeiten, verwenden Sie die Jitterbit iPaaS-Assistenten und stellen Sie sicher, dass alle Objekte im Bereich verfügbar sind. Auf diese Weise können Sie gut überprüfen, ob der Integrationsbenutzer über alle zum Arbeiten erforderlichen Berechtigungen verfügt.
• Der Entwickler sollte die Quell- und Zielschemata überprüfen, um „intelligente“ Mapping-Fragen zu stellen, wie zum Beispiel diese:
  • „Haben wir alle Pflichtfelder?“
  • „Wenn wir eine Datensatz-ID übergeben, aktualisiert der Endpoint dann automatisch einen Datensatz oder versucht er, ihn zu erstellen?“
  • "Wie viele Datensätze können in einem Aufruf übergeben werden?"
  • "Dieses SAP IDoc-Schema verwendet deutsche Abkürzungen. Jemand spricht Sie Deutsch?"
• Vergessen Sie nicht, das Schema (bei einem Webdienst) zu überprüfen, insbesondere im Hinblick auf die Fehlerbehandlung. Einige Schemata zeigen insgesamt Erfolg oder Misserfolg an, während andere Codes bereitstellen, die ausgewertet werden müssen.

Management des Entwicklungsprozesses

Ein guter Ansatz zur Verwaltung des Entwicklungsprozesses besteht darin, die während der Festlegung des Umfangs erfassten Szenarien zu verwenden und die Meilensteine zu verfolgen, die mit jedem Szenario in Zusammenhang stehen. Dies ist ein Beispiel für eine Tabelle, die zur Verfolgung wichtiger Meilensteine in einer Integrationsentwicklung verwendet wird:

Behandeln Sie jedes Szenario als Mini-Entwicklungsiteration, beginnend mit Datenabhängigkeiten (wie Stammdaten). Dann erstellen Sie Operationen, erstellen Transformations, holen einige Testdaten, übertragen sie zu einem Endpoint und verarbeiten die Antwort. Streben Sie nicht nach Perfektion. Versuchen Sie, einfache Testdaten von Punkt A nach Punkt B zu verschieben und dann mit dem nächsten Szenario fortzufahren. Wiederholen Sie dann die Entwicklung des Integrationsszenarios und decken Sie Blockierer auf, bis das Haupterfolgsszenario sowie Fehlerszenarien entwickelt und einheitlich getestet wurden.

Bei der ersten Integrationsgruppe treten die meisten Probleme auf, z. B. bei der Konnektivität, Berechtigungen, fehlenden Feldern usw. Je schneller wir also an diesen Punkt gelangen und die Blockaden beseitigen, desto besser. Wir streben nicht von Anfang an nach Perfektion.

Beginnen Sie mit einem kleinen Satz Testdaten. Dieser kann in Scripts fest codiert sein oder Sie verwenden eine Abfrage, die auf nur wenige Datensätze beschränkt ist.

Wenn es ein kleineres Hindernis gibt, dokumentieren Sie es, weisen Sie die Lösung der richtigen Person zu und gehen Sie zu einem anderen Szenario über. Auch hier geht es darum, die Landminen schnell zu finden, damit sie geräumt werden können, und diese Verantwortung liegt normalerweise beim Kunden und/oder dem KMU.

Hier ist ein Beispiel für eine Problemverfolgungstabelle:

Wiederverwenden

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

• Scripts
  • Ganze benutzerdefinierte Funktionen können aus vielen Operationen erstellt und aufgerufen werden. Die allgemeine Faustregel lautet: Wenn Sie dasselbe Script zweimal schreiben müssen, machen Sie es zu einem aufrufbaren Script.
• Quelle 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 betriebsspezifischen Quellen und Zielen.
• Operationen
  • Einzelne Task-Operationen können einmal erstellt und viele Male verwendet werden, insbesondere solche zur Fehlerbehandlung und Protokollierung.
  • Operationen in einem Projekt können von einem anderen aufgerufen werden. Beachten Sie, dass die Protokolle in den nativen (aufgerufenen) Projekten angezeigt werden. Da der Umfang globaler Variablen jedoch die Operation ist (die von mehr als einem Projekt aufgerufen werden kann), ist es möglich, die Ergebnisse der Remote Operation abzurufen und im aufrufenden Projekt zu protokollieren.

Protokollierung und Fehlerbehandlung

Ein häufig übersehener Satz von Anforderungen betrifft 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 Best Practices in diesem Bereich. Die wichtigsten Punkte sind diese:

• Jitterbit iPaaS führt sofort einsatzbereite Operation durch.
• Es ist einfach, zusätzliche Daten zu protokollieren, was bei der Fehlerbehebung sehr nützlich ist.
  • Hier kann dem Kunden klar werden, dass seine Integrationsszenarien interne Unterstützung erfordern.
  • Wenn ein Problem an einem Endpoint festgestellt wird und die Integration eine mögliche Ursache ist, muss eine Ressource die Protokolle prüfen. Je klarer und informativer die Protokolle sind, desto schneller ist der Fehlerbehebungsprozess.
• Es gibt zwei große Alarmklassen: datenbezogene Alarme und technische Fehleralarme, die möglicherweise an dieselbe Gruppe gesendet werden müssen, aber nicht müssen. Technische Fehler lassen sich leicht konfigurieren, aber datenbezogene Protokollierung ist vollständig benutzerdefiniert und kann während der Integrationsentwicklung einfacher integriert werden als später.
• Integration Studio können Email ganz einfach nutzen, wobei der Email-Dienst wie ein Endpoint für den Email Dienst des Kunden behandelt wird, mit Integration Studio Email Benachrichtigungen. Obwohl die Einrichtung im Allgemeinen einfach ist, sollte dieser Schritt nicht bis zum Schluss aufgeschoben werden.
• Über die Jitterbit Management Console können zusätzliche organisationsbezogene Benachrichtigungen konfiguriert werden.

Ausführliche Informationen finden Sie im Tech Talk zu Best Practices zur Fehlerbehandlung und die Benachrichtigungen Seite.

Handhabung von Geschäftsregeln

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

Viele Kunden denken anfangs: „Ich möchte keine Geschäftsregeln in die Middleware einbinden, ich möchte es einfach halten“, stellen dann aber genau gegenteilige Anforderungen!

Die ideale Middleware-Architektur sieht vor, dass die Integrationsschicht so schlank wie möglich ist und sich auf ihre Stärken konzentriert: Transformation, Szenarioverarbeitung und -orchestrierung, Endpoint sowie Protokollierung und Warnmeldungen. Das Hinzufügen umständlicher Geschäftsregeln würde die Perfektion dieser Architektur nur beeinträchtigen, da die Unterstützung für Geschäftsregeln über die Endpoint hinaus ausgeweitet wird. Das heißt, wenn sich eine Geschäftsregel ändert, ändert sie sich nicht nur in der Anwendung, sondern auch in der Middleware. Und da Middleware undurchsichtig, trübe und mystisch ist, ist die Regelpflege zudem stumpfsinnig.

Die Realität bricht unsanft aus, denn Jitterbit iPaaS muss mit dem arbeiten, was Anwendungen offenlegen:

• Die Daten werden schlecht dargestellt und die einzige Möglichkeit, sie zu verarbeiten, besteht in der Anwendung von Geschäftsregeln („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 = Großbritannien, Geschäftsjahr ist April - März“_)
• Das Integrationsszenario ist datengesteuert („wenn der Arbeitsauftrag Zeilen mit Drittanbietern enthält, diese Zeile als AP-Eintrag verarbeiten, andernfalls als Serviceauftrag aktualisieren“)

Ja, all das oben Genannte könnte vom Endpoint erledigt werden. Dies setzt jedoch voraus, dass der Kunde über die Ressourcen und die Zeit verfügt, den Endpoint anzupassen oder eine API zu ändern. Wenn all das verfügbar ist, dann tun Sie das auf jeden Fall. Im Normalfall sind die Endpoints jedoch schwieriger zu ändern und zu warten als das Integrationsprojekt.

Bei der Handhabung von Geschäftsregeln gelten folgende Best Practices:

• Externalisieren Sie, wo immer möglich. Speichern Sie die Daten beispielsweise in einer Tabelle, wo sie von einem Benutzer verwaltet werden können.
• Verwenden Sie Projektvariablen. Diese werden zusammen mit spezifischer Dokumentation in der Jitterbit Management Console angezeigt. Der Hauptanwendungsfall sind umgebungsspezifische Endpoint, diese können jedoch auch verwendet werden, um Orchestrierungslogik und Abfrage zu steuern.
• Fügen Sie detaillierte benutzerdefinierte Protokollierung und Datenfehlerbehandlung hinzu, sodass die Auswirkungen auf die Integration offensichtlich sind, falls und wenn sich die Geschäftsregeln ändern.

Agenten und Umgebungen

Der Jitterbit-Agent ist das Arbeitspferd der Integration. Integration Studio führt eigentlich keine Operation aus. Alles geschieht auf einem Jitterbit-Agenten. Eine wichtige Entscheidung ist, welche Art von Agent verwendet werden soll: entweder privat oder in der Cloud (siehe Jitterbit-Agenten).

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

• Ein Endpoint befindet sich hinter der Firewall des Kunden. Dies kann eine Anwendung oder eine Netzwerkfreigabe sein.
• Es ist ein Connector oder Driver erforderlich, der in den Cloud-Agenten nicht verfügbar ist. Beispielsweise ist der Excel Driver nur auf privaten Agenten verfügbar.
• Die Sicherheitsanforderungen des Kunden bestehen darin, dass keine Daten außerhalb seiner Firewall zulässig sind.

Andernfalls sind Cloud-Agenten eine Option. Aus Sicht der Projektzeitleiste ist dies ideal, da so 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 jedoch dennoch Mitglieder und Umgebungen einrichten.

Je nach Lizenzstufe verfügt ein Kunde über zwei oder mehr private Agentenlizenzen. Außerdem hat der Kunde Anspruch auf eine Reihe von Umgebungen, die normalerweise gemäß den Standardkategorien des Softwareentwicklungslebenszyklus (Entwicklung, Qualität, Staging, Produktion, Support usw.) eingerichtet sind. Das Migrationstool von Jitterbit arbeitet mit Umgebungen, um die Förderung von Integrationsprojekten zu ermöglichen.

Beachten Sie hinsichtlich Agenten und Umgebungen diese wichtigen Punkte:

• Eine Umfeld als „Produktionsumgebung“ zu bezeichnen, ist nichts Besonderes. Sie läuft nicht schneller und ist auch nicht robuster. Eine Umfeld ist praktisch wie jede andere.

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

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

• Eine häufige Frage ist, ob irgendwelche Firewall Regeln im Netzwerk geändert werden müssen. Normalerweise lautet die Antwort „nein“, es sei denn, der Kunde schränkt ausgehenden HTTP-Verkehr von Servern und/oder Ports ein. Die Kommunikation zwischen Harmony und Agent erfolgt ausschließlich ausgehend vom Agenten zu Harmony.

Eine Agentengruppe ist ein obligatorischer Bestandteil der Agentenarchitektur. Sie ist nicht nur der virtuelle Container, der die privaten Agenten enthält, sondern spielt auch eine weitere wichtige Rolle. Im Gegensatz zu herkömmlichen Serververwaltungstools, die zusätzliche Anwendungen wie Lastenausgleichsmodule erfordern, ist es mit Harmony ganz einfach, Serverausfallsicherheit durch Lastenausgleich und Failover zu erreichen. Durch einfaches Hinzufügen eines Agenten zu einer Gruppe wird der Agent automatisch Teil eines Serverclusters.

Um es klarzustellen: Wenn ein Operation auf einer Agentengruppe mit mehreren Agenten ausgeführt wird, führt nur ein Agent diesen Operation aus. Der Operation wird nicht aufgeteilt und auf allen Agenten in der Gruppe ausgeführt. Das Hinzufügen von Agenten zu einer Gruppe führt (normalerweise) nicht dazu, dass die Vorgänge schneller ausgeführt werden. Die Ausnahme ist ein Entwurf, der eine Gruppe von Agenten erfordert, um eingehende APIs mit hohem Datenverkehr zu bedienen. In diesem Fall ist es eine gute Idee, die Last auf mehrere Agenten zu verteilen.

Um mit der Entwicklung zu beginnen, sind lediglich ein einziger privater Agent und eine einzige Umfeld erforderlich. Im Verlauf des Projekts können weitere Agenten zu Gruppen hinzugefügt und neue Umgebungen hinzugefügt werden (natürlich alles im Rahmen der Lizenzbeschränkungen).

Wenn die Beschaffung auch nur eines einzigen Agenten problematisch ist, kann ein privater Jitterbit-Agent auf einer Workstation ausgeführt werden. Am besten verwenden Sie hierfür den Docker-Agenten, um Desktop-Konflikte zu vermeiden.

Stapel- und ereignisgesteuerte (Echtzeit-)Verarbeitung

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

Grundsätzlich gibt es zwei Möglichkeiten: einen Batch-Ansatz, etwa durch einen Zeitplan, oder ausgelöst durch ein Ereignis, etwa durch eine API.

Aus Sicht eines Integrationsprojekts ist die Implementierung ereignisgesteuerter Verarbeitung wesentlich weniger aufwändig als die 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 „Datum der letzten Änderung“, was benutzerdefinierte Skripts erfordert, um den letzten Zeitpunkt der Ausführung des Operation abzurufen, zu entscheiden, ob der Operation erfolgreich ausgeführt wurde, und dann das Zeitstempel-Repository zu aktualisieren. Dabei müssen Sie mit möglicherweise unterschiedlichen Endpoint-Zeitzonen, Sommerzeit und Datumsformaten umgehen. Vergessen Sie nicht: Abfrage nur nach Daten ab, die von allen Benutzern außer dem Integrationsbenutzer geändert wurden. Und wenn Sie in andere Umgebungen migrieren, müssen Sie das Ein- und Ausschalten von Zeitplänen gemäß dem Projektplan handhaben. Keines davon ist eine große Herausforderung, aber die Last der Entwicklungs- und Verwaltungsverantwortung wird eindeutig auf die Integrationsebene übertragen.

• Vergleichen Sie Batch mit ereignisgesteuerter Verarbeitung: Der Operation wird nur ausgeführt, wenn er vom Endpoint aufgerufen wird. Keine Zeitpläne, keine Zeitstempel, keine Zeitzonen. Die Verantwortung liegt eindeutig beim Endpoint.

• Der wichtigste ereignisgesteuerte Verarbeitungsmechanismus von Jitterbit iPaaS erfolgt über API-Manager APIs. Zwar sind die Lizenzkosten höher, aber es lohnt sich.

• Wenn der Endpoint den Aufruf einer API nicht unterstützt, ist Batch natürlich Ihre einzige Option. Außerdem kann es sein, dass der Kunde sich gegen die Verwendung einer API sträubt, wenn Batch eine Option ist.

Dann gibt es noch diese seltsame Chimäre, die „Fast-Batch“-Option, bei der die Geschäftsanforderung darin besteht, Daten so schnell wie möglich in ein Ziel zu bringen, der Kunde jedoch keine API implementieren möchte. Das Gespräch läuft ungefähr so ab:

Jitterbit: Wann sollen im Bestellszenario 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. Können wir nicht eine ganz schnelle Batch herstellen?

Jitterbit: Du meinst, alle 10 Minuten prüfen, ob neue Bestellungen vorliegen?

Kunde: Nein, schneller. Was ist die Mindestzeit für einen Zeitplan?

Jitterbit: Ähm... eine Minute.

Kunde: Super! Jede Minute das Bestellsystem abfragen! Fertig!

Jitterbit: Moment mal. Sie wissen, dass Sie das Bestellsystem überlasten werden, wo es die meiste Zeit keine Daten zu verarbeiten gibt. Sie werden viele vergeudete Zyklen haben und das Durchforsten der Operation wird mühsam sein. Wenn Ihre Geschäftsanforderung wirklich darin besteht, Daten so schnell wie möglich zu verschieben, müssen Sie eine API verwenden. Darüber hinaus gibt es eine Host weiterer Vorteile …

Und hier tut der Kunde, der durch diese Informationen ermutigt wurde, das Richtige und stimmt der Verwendung einer API zu. Wenn Sie jedoch nicht überzeugend genug sind, wenden Sie sich an unsere Marketingmitarbeiter. Sie kümmern sich darum.

Beachten Sie die folgenden Hinweise 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. Ganz einfach! Das Design sieht vor, dass der Operation direkt aufgerufen wird und dann sofort das Ziel aktualisiert.
  • Aber was der Kunde vergessen hat, Ihnen zu sagen (und Sie vergessen haben, danach zu fragen), ist, dass Sie bei einer Massenaktualisierung von Datensätzen nicht alle 10 Minuten einen Datensatz erhalten, sondern 10.000. Jitterbit erledigt seine Aufgabe und startet so viele Threads, wie der Server verarbeiten kann, stellt den restlichen eingehenden Datenverkehr in die Warteschlange und beginnt mit der Aktualisierung des Ziels. Dies könnte das Zielsystem überfordern.
• Überprüfen Sie die maximale Ausgabe und erwägen Sie das Hinzufügen einer JMS Warteschlange, einer Datenbank oder sogar einer temporären Datei, um die eingehenden API Daten vor der Verarbeitung im Ziel aufzubewahren.
• APIs werden unabhängig von den Umgebungen lizenziert. Wenn also für jede der Entwicklungs-, QA- und Produktionsumgebungen eine API verwendet wird, sind das drei API -Lizenzen, nicht eine.

Migration

Abhängig vom Prozess des Kunden muss das Projekt vor dem UAT in eine QA- Umfeld migriert werden, oder die Tests werden in einer Umfeld durchgeführt und das Projekt wird dann in eine Umfeld migriert.

• Migrieren Sie, wenn möglich, erst in die nächsthöhere Umfeld, wenn das Projekt fast abgeschlossen ist. Sobald eine Migration erfolgt ist, müssen Sie daran denken, sie in andere Umgebungen zu migrieren.

• Vermeiden Sie es, Änderungen in einer „höheren“ Umfeld vorzunehmen, um ein Problem schnell zu lösen, in der Annahme, dass Sie die Umgebungen später synchronisieren werden. Nehmen Sie die Korrektur stattdessen in der „niedrigeren“ Umfeld vor und migrieren Sie sie. Es gibt keine narrensichere Methode, um granulare Unterschiede zwischen Projekten zu identifizieren, daher kann man leicht den Überblick über Änderungen verlieren.

Benutzerakzeptanztests (UAT)

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

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

• Seien Sie darauf vorbereitet, 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-SMEs zur Problembehebung verfügbar sind.

• Wenn möglich, sollte der Benutzer die Fehlerbehebung leiten: auf Warnungen reagieren, Protokolle lesen, die Integrationslogik verfolgen. Idealerweise erledigt die Person, die diese Aufgabe in der Produktion übernimmt, diese Aufgabe in dieser Phase.

• Behalten Sie die Probleme, die während des UAT auftreten, und deren Lösung genau im Auge. Häufig kommt es vor, dass Probleme Endpoint betreffen, und während das Integrationsproblem behoben ist, sind die Daten nicht behoben und werden zu einem wiederkehrenden Problem beim Testen.

• Planen Sie regelmäßige Treffen mit allen Beteiligten ein, um etwaige Hindernisse zu beseitigen.

• Beginnen Sie mit der Dokumentation, wenn es die Zeit erlaubt.

• Entwickeln Sie Ihren Umstellungsplan.

• Führen Sie in der Umfeld Verbindungstests und alle anderen Tests durch, die Sie durchführen können oder die zulässig sind.

Postproduktion und Monitoring

UAT abgeschlossen! Benutzerabmeldung abgeschlossen! Es ist Zeit, diese Rakete zu zünden!

In dieser Phase sollte die endgültige Migration zur Produktion abgeschlossen sein. Wenn Sie Zeitpläne verwenden, beachten Sie, dass Sie diese zur Produktion migrieren und in der Jitterbit Management Console deaktivieren können. Anschließend kann der Kunde die Zeitpläne aktivieren.

Rechnen Sie damit, sich regelmäßig mit dem Kunden zu treffen, um sicherzustellen, dass alles reibungslos läuft, und rechnen Sie mit ein paar Fragen.

Planen Sie ein Abschlussmeeting ein, um die Projektdokumentation zu übergeben und einen abschließenden Wissenstransfer durchzuführen.