Integrationsprojektmethodik für Jitterbit Integration Studio

Einführung

Seien wir ehrlich: Integrationsprojekte können schwierig sein und bergen viele potenzielle Fallstricke. 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.

Idealerweise sind die Endpoints stabil, verfügen über gut dokumentierte APIs und bieten klare Fehlerreaktionen. Fachexperten sind schnell verfügbar, und für Entwicklung und Tests stehen nicht-produktive Umgebungen zur Verfügung. Das Projekt ist zudem gut finanziert, genießt höchste Priorität für das Management und es steht ausreichend Zeit für Tests zur Verfügung. Wenn das nach Ihrem Projekt klingt, herzlichen Glückwunsch! Für alle anderen: Lesen Sie weiter.

Ansatz

Wenn man weiß, dass ein Feld voller Landminen ist, hat man zwei Möglichkeiten:

1. Sehr vorsichtig und überlegt vorgehen, die gesamte Landschaft bis ins kleinste Detail untersuchen und erst bauen, wenn alles bekannt ist.

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

Also, es ist Nummer 2. Anschnallen, wir machen schnell.

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 etwa 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 zu erstellen, 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 Anwendung von Jitterbit (weitere technische Details finden Sie in der anderen Dokumentation), sondern auf den wichtigsten Punkten, die ein Projektmanager für ein Integrationsprojekt wissen sollte. Dieser Leitfaden zeigt Ihnen, wie Sie Ihr Team organisieren, Anforderungen klar und prägnant erfassen und validieren und die Stärken von Jitterbit iPaaS nutzen, um ein erfolgreiches Projekt umzusetzen.

Umfang

Die Projektumfangsbestimmung ist ein zweistufiger Prozess, der das Sammeln von Informationen, das Festlegen der Projektgrenzen und das Einholen der für die Projektumsetzung erforderlichen Basisinformationen umfasst:

1. Ungefähre Größenordnung: Schätzen Sie eine grobe Größenordnung (ROM) für die Arbeit auf hoher Ebene (kann für bestimmte Endpoints übersprungen werden).
2. Arbeitsumfang: Verfeinern Sie die Schätzung, indem Sie einen detaillierten Leistungsumfang (SOW) für die Projektabwicklung festlegen.

Dieser Prozess berücksichtigt das GIGO-Konzept (Garbage In, Garbage Out) - also lassen Sie sich nicht unterschätzen. Die folgende Tabelle dient als Ausgangspunkt für den Scoping-Prozess. Die in dieser Tabelle verwendete Terminologie wird später im Abschnitt Ungefähre Größenordnung definiert und Arbeitsumfang Unterabschnitte.

Grobe Größenordnung (ROM)

Bei diesem Schritt wird davon ausgegangen, dass der Kunde ausreichend analysiert hat, um zu bestimmen, welche Schnittstellen erstellt werden müssen. Schnittstellen werden grundsätzlich benötigt, wenn ein Geschäftsprozess Anwendungsgrenzen überschreitet. Sind die Geschäftsprozesse nicht festgelegt, ist auch die Integration nicht festgelegt, und es ist möglicherweise noch zu früh für eine Einschätzung.

Die grobe Größenordnung (ROM) ist darauf ausgelegt, ein hohes Niveau zu halten und eine schnelle Bearbeitung zu ermöglichen, um die Planung und Entscheidungsfindung des Kunden zu unterstützen. ROM-Schätzungen basieren auf folgenden Elementen:

• Endpoints: 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 mit APIs sein.
• Integrationsszenario: Dies ist die Beschreibung der Datenbewegung, die zum Erreichen des Integrationsziels erforderlich ist. Beispiele hierfür sind „Konten synchronisieren“, „Bestellungen erstellen“ oder „Versandinformationen abrufen“.
  • Objekt: Dies kann ein SFDC-Objekt (Salesforce) (wie ein Konto oder Produkt), eine Datenbanktabelle oder ein virtuelles Geschäftsobjekt wie beispielsweise 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: Kann Endpoint verwenden oder nicht, verwendet eine Reihe von Transformations und externen Nachschlagevorgängen und verwendet mehrere Vorgänge pro Szenario.
    • Hoch: Keine Endpoint Konnektoren, zahlreiche Szenarioschritte und der Endpoint gilt als anspruchsvoll.

Zur Berechnung der Stunden wird Heuristik eingesetzt. Formeln werden basierend auf der Anzahl der Szenarien und der Komplexität verwendet, um eine Schätzung zu ermitteln, die leicht um bis zu 15–20 % abweichen kann. Betrachten Sie dies als eine Budgetzahl, die frühzeitig im Prozess verwendet werden sollte.

Die ROM-Schätzung geht davon aus, dass ein Jitterbit iPaaS-Experte die Arbeit mit leichtem Projektmanagement erledigt. Sie ist zudem durchgängig: von der Initiierung bis zur Inbetriebnahme. Die Zeit für den Aufbau einer Integration entspricht nicht eins zu eins der verstrichenen Zeit. Der tatsächliche Zeitaufwand hängt von der Personalstärke, der Stabilität der Endpoints, der Verfügbarkeit der KMU des Kunden usw. ab. Aus Vorsicht gehen wir von einem Verhältnis von 3:1 zwischen Kalenderdauer und geschätztem Zeitaufwand aus.

Arbeitsumfang (SOW)

Der Leistungsumfang (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 (z. B. SAP) oder Projekttypen (z. B. Hub-Deals) können Sie den ROM-Prozess überspringen und direkt zum SOW-Schritt übergehen.

In diesem Schritt sollten Sie eine Scoping-Sitzung vereinbaren, um Details zu finalisieren und offene Fragen zu beantworten. Idealerweise sollten Fachanwender (und alle Prozessverantwortlichen) sowie Endpoint-SMEs teilnehmen. Letztere einzubeziehen 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 folgende Themen:

• Endpoints

  • Versionen: Zu verwendende oder anzutreffende Versionen.

  • On/Off-Premises: Bei On-Premises-Anwendungen sollten Sie unbedingt die Nutzung von Cloud- und privaten Agenten erläutern. Ein häufiges Problem ist die Netzwerksicherheit, beispielsweise die Öffnung der Firewall für private Agenten. Versichern Sie Kunden und Stakeholdern daher, dass dies kein Sicherheitsrisiko darstellt. Geben Sie einen Link zum Whitepaper zu Jitterbit-Sicherheit und-Architektur an 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 in der Regel entweder internes Fachwissen in der IT-Abteilung, einen Implementierungspartner und/oder einen Helpdesk. Je mehr interne Expertise vorhanden ist, desto 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: Mit der zunehmenden Verbreitung von Cloud-Diensten und APIs listen manche Anbieter ihre APIs lediglich auf, die Dokumentation ist jedoch dürftig. In diesem Fall müssen Sie Zeit für die Entdeckung, Machbarkeit und Tests einplanen.

• Integrationsszenarien

  • Methoden- und Endpoint: Definieren Sie diese für jedes Szenario. Beispiele:
    • "Führen Sie regelmäßig stapelweise eine Abfrage nach neuen Kunden in Endpoint X für das Konto in Endpoint Y Batch und aktualisieren Sie die neue Kontonummer auf Kunde."
    • "Empfangen Sie eine Echtzeitanfrage von Endpoint X, die Bestellinformationen enthält, die an Endpoint Y gesendet werden sollen. Erstellen Sie eine Bestellmethode und antworten Sie mit einer neuen Bestellnummer."
    • "Datenbanktabelle X abfragen und 200.000 Lagerbestandswerte in der Inventar-API von Endpoint Y aktualisieren."
  • Potenzielle Hindernisse: Die Szenarien dienen der Zeitschätzung. Es ist zu erwarten, dass die Entwicklung jedes Szenarios (sofern es nicht extrem einfach ist) auf Hindernisse stößt. Diese können technischer Natur (falsche Anmeldeinformationen, unzugänglicher Endpoint, undurchsichtige API) oder verfahrenstechnischer Natur (das Unternehmen muss einen neuen Prozess definieren, Anpassungen sind erforderlich, KMU sind nicht verfügbar) sein.

• Zeitrahmen

  • Wichtige Termine: Normalerweise kennt ein Kunde seinen Go-Live, aber es gibt noch andere wichtige Termine.

• Termine für den User Acceptance Testing (UAT): Wann beginnt der UAT? (Dies kann eine Erklärung erfordern, 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?

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

    Vorsicht

    Seien Sie vorsichtig, wenn Sie ein Integrationsprojekt beschleunigen möchten. Zusätzliche Entwickler beschleunigen die Entwicklung nur, wenn klare und separate Szenarien vorliegen.

• Ressourcen

  • Ansätze: Kunden gehen unterschiedlich mit Projektressourcen um:

    • Überwiegend Outsourcing: Der Kunde stellt einen Ansprechpartner oder ein KMU und kümmert sich um Anforderungen, Eskalation, UAT und die Koordination externer Ressourcen. Alle anderen Ressourcen (vor allem Entwicklung) werden von Jitterbit Professional Services und/oder dem Jitterbit-Partner bereitgestellt.

    • Überwiegend Insourcing: Der Kunde lernt die Nutzung von Jitterbit iPaaS und möchte lediglich Zugang zu einem Jitterbit-KMU für Beratung und Best Practices.

    • In-/Outsourcing: Der Kunde möchte, dass Jitterbit Professional Services oder der Jitterbit-Partner mehrere Integrationen erstellt und diese schrittweise an die Kundenressourcen übergibt. Dieser Teil ist schwer abzuschätzen. Es wird empfohlen, den gesamten Arbeitsaufwand zu schätzen und anschließend einen Prozentsatz der Stunden abzuziehen.

      Hinweis

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

  • Involvierungsgrad: Dieses Diagramm veranschaulicht den relativen Involvierungsgrad von Projektmanager (PM), Kundenressourcen und Entwicklungsressourcen. Beachten Sie, dass Entwicklungsressourcen während der Entwicklungsphase am stärksten involviert sind und danach nachlassen. Kundenressourcen (in der Regel Geschäftsbenutzer) sind während der UAT-Phase (User Acceptance Testing) stark involviert, was häufig übersehen wird.

    

Personal

Diese allgemeinen Richtlinien gelten für die Besetzung von Ressourcen mit technischen Jitterbit- und PM-Kenntnissen. Ausgenommen sind Ressourcen wie KMUs für Kundengeschäftsprozesse und Endpoint. Je nach Projektgröße werden folgende Personalstärken empfohlen:

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

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

• Große Projekte: Projekte mit 5+ Endpoints und 20+ Szenarien weisen bei der Personalbesetzung 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 benötigt eine detaillierte Statusberichterstattung (z. B. Berichterstattung an ein Projektmanagementbüro).

• 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 diesen Situationen ein striktes Scope- und Change-Management durch! Machen Sie dem Kunden klar, dass der Projekterfolg davon abhängt, dass der Kunde alle Hindernisse beseitigt und alle Projektressourcen die Termine einhalten.

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

• Wenn an einem einzigen Jitterbit-Projekt mehr als ein Entwickler 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 verschiedenen Integrationsszenarien zuzuweisen oder die Arbeit in verschiedene Jitterbit-Projekte aufzuteilen.

• Nutzen Sie entwicklerübergreifende Design- und Codeüberprüfungen.

• Erhöhen Sie nach Möglichkeit 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 Projektbeteiligten zusammenzubringen, typischerweise die wichtigsten Geschäftsbenutzer, KMUs, Endpoint und Integrationsarchitekten. Diese Zeit dient dazu, alle auf den gleichen Stand zu bringen und die Rollen und Verantwortlichkeiten zu klären. Während des Kickoff-Meetings sollten folgende Aufgaben erledigt werden:

• Wichtige Termine: Überprüfen Sie alle wichtigen Termine (nicht nur das Datum der Inbetriebnahme).
• Informationsaustausch: Teilen Sie Kontaktinformationen und Dokumente.
• Überprüfung der Integrationsszenarien: Überprüfen Sie die Integrationsszenarien anhand 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. Bedenken Sie jedoch, dass nicht-technische Abhängigkeiten den größten Verzögerungsfaktor darstellen. Dies ist ein guter Zeitpunkt, diesen Punkt hervorzuheben. Klären Sie die Verantwortlichkeiten der einzelnen Rolle:
  • PM
    • Arbeitet mit dem Kunden und dem technischen Team zusammen, um detaillierte Integrationsanforderungen, einschließlich Feldebenenzuordnungen, zu ermitteln und zu organisieren. Feldebenenzuordnungen werden sowohl von den Jitterbit-Entwicklungsressourcen als auch von den Endpoint-SMEs benötigt.
    • Organisiert die Verfügbarkeit von Geschäfts- und Endpoint-SMEs 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.
    • Informiert den Kunden und das technische Team über den Entwicklungsfortschritt der Integration und die zu lösenden offenen Punkte.
  • Jitterbit-Entwickler
    • Erarbeitet ein Verständnis der Anforderungen für den Entwurf der Integrationsarchitektur und arbeitet mit dem Kunden an Entwurfsaspekten (Batch/Echtzeit, APIs, Stammdatenverwaltung, Sicherheitsanforderungen usw.).
    • Nimmt die detaillierten Anforderungen und verwendet das Tool, um die Operation gemäß den Jitterbit-Best Practices zu entwickeln..
    • Deckt Blockaden schnell auf und ergreift die Initiative, um sie zu lösen.
    • Idealerweise steht der Jitterbit Entwickler in direktem Kontakt mit dem Kunden. Die Isolierung des Jitterbit Entwickler von KMU und Kunden ist ungünstig und führt zu Kommunikationsproblemen und Verzögerungen. Die Projektressourcen müssen ein Team bilden 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 hochverfügbar, um bei Unit-Tests zu helfen. Dies kann die Bereitstellung von Testdaten, die Bereitstellung zeitnaher Rückmeldungen zu den Ergebnissen von Integrationstests und die Interpretation von Fehlerantworten umfassen.
• Lizenzierung und Berechtigungen: Überprüfen Sie die Lizenzierung und Berechtigungen von Jitterbit und 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 zu den Endpoints, hauptsächlich für die Entwicklung.
  • Bei der Arbeit mit lokalen Systemen können viele Schritte einige Zeit in Anspruch nehmen, z. B. die Hardwarebeschaffung, die Installation privater Agenten, die Netzwerkkonnektivität, die Integration der Benutzeranmeldeinformationen und der Testzyklus. Da mehrere Gruppen beteiligt sein können, sollten Sie dies so schnell wie möglich für die Umfeld einleiten.
  • Gehen Sie davon aus, dass die beim Einrichten der Umfeld gewonnenen Erkenntnisse die Einrichtung einer 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 eine Testversion verwendet, enthält die Standard URL möglicherweise noch das Wort „Trial“. Wenden Sie sich an die Jitterbit-Lizenzierung, um dieses Wort zu entfernen, bevor Sie neue 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) wünschenswert. 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 verzahnt werden. Beispielsweise muss die Integrationsentwicklung auf die Konfiguration der Endpoint warten.

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, bleiben 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 iterativ durchläuft. Der UAT-Abschnitt (User Acceptance Testing) kann verschoben werden, bis alle Szenarien einsatzbereit sind.

Anforderungserfassung und -entwicklung

Dieser Abschnitt behandelt zunächst den allgemeinen Ansatz zur Anforderungserfassung und -entwicklung und geht anschließend auf die Details von Mapping, Entwicklung, Management des Entwicklungsprozesses, Wiederverwendung sowie Protokollierung und Fehlerbehandlung ein.

Allgemeiner Ansatz

Das Low-Code- und grafische Entwicklungs-Frontend von Jitterbit (Integration Studio) eignet sich für ein iteratives Modell. Dieser Ansatz ist kein Wasserfallmodell, bei dem alle Anforderungen vor Beginn der Entwicklung dokumentiert werden. Die folgenden Schlüsselschritte beschreiben das allgemeine iterative Modell:

Beginnen Sie mit den Stammdatenszenarien. Da der Ansatz darin besteht, schnell einen Definitions-, Erstellungs- und Testzyklus zu durchlaufen, müssen die Endpoints mit Stammdaten gefüllt sein, 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).

  • Die Stammdatenschlüssel des SOR werden üblicherweise im SOE gespeichert, um Aktualisierungen im SOR zu erleichtern. Wenn beispielsweise SAP der SOR und SFDC das 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, bei dem Salesforce als SOE (System of Engagement) und SAP als SOR (System of Record) in einem unidirektionalen Stammdatenfluss mit Rückschreiben verwendet wird.

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

• Es können Race Conditions, Logik zum Ausschließen von Updates vom Integrationsbenutzer getrennt von Geschäftsbenutzern und gegenseitig freigegebene Schlüssel auftreten.
• Häufig sind die Geschäftsregeln für Stammdaten in den Endpoints nicht identisch. 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.

Kartierung

Der Projektmanager sollte den Kunden mit der Arbeit an den detaillierten Feldebenenzuordnungen beauftragen. Diese werden sowohl von den Jitterbit-Entwicklungsressourcen als auch von den Endpoint-SMEs benötigt.

Der Kunde ist möglicherweise daran gewöhnt, die Systeme aus der Sicht der Benutzeroberfläche zu betrachten und kann keine Zuordnungen aus der Sicht der Schemata erstellen. Tragen Sie in diesem Fall die Schemata nach Möglichkeit in die Zuordnungstabelle ein. Dies erfordert möglicherweise die Unterstützung des SME, die Online-Dokumentation oder die Nutzung von Jitterbit iPaaS, 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 genügend Szenariodefinitionen vorhanden sind, um loszulegen, 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 genau darauf, welche Mappings schwieriger sind. Die Transformation ist der entscheidende Punkt, d. h. hier bilden wir die verfügbaren Integrationsmethoden zwischen Systemen ab. Es ist wichtig herauszufinden, welche Szenarien schwieriger sind als andere, da diese mit einem hohen Zeitaufwand verbunden sind. Einfache Mappings können nur wenige Minuten dauern, während komplexe Mappings Tage in Anspruch nehmen können. Achten Sie daher auf diese Situationen und priorisieren Sie:

• Externe Systemsuche: Bei manchen Systemen müssen Sie Werte möglicherweise durch Abfragen nachschlagen. Die Gefahr liegt hier in Leistungseinbußen: Beachten Sie, dass die Transformation datensatzweise ausgeführt wird. Wenn 200 Datensätze verarbeitet werden und die Transformation für jeden Datensatz eine Suche durchführt, sind das 200 Abfragen. Bei einer Datenbank ist das kein Problem, bei einer API können das jedoch auch 200 An- und 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 Quell- und Zielschema beispielsweise flach sind (wie Kundenname und 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, müssen die untergeordneten Abschnitte möglicherweise bedingt verarbeitet werden:

  

Um bei komplexen Mappings schnell voranzukommen, müssen die Endpoint-KMU häufig zusammenkommen, um die Anforderungen zu erarbeiten. Dies kann auch geschäftlichen Input erfordern und zu einer Anpassung der Endpoint führen, was das Gesamtprojekt verzögern kann. Es ist daher 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:

• 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.
  • Schemata gelten (normalerweise) nur beim Umgang mit Datenbanken und Webdiensten.
  • Dateien können ein hierarchisches Format aufweisen, das manuell in Jitterbit erstellt werden muss. Dies kann mühsam sein, daher sollten Sie frühzeitig damit beginnen.
  • 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.
  • Verwenden Sie beim Arbeiten mit Endpoint-Konnektoren die Jitterbit iPaaS-Assistenten und stellen Sie sicher, dass alle Objekte im Bereich verfügbar sind. So können Sie überprüfen, ob der Integrationsbenutzer über alle erforderlichen Berechtigungen verfügt.
• Der Entwickler sollte die Quell- und Zielschemata überprüfen, um „intelligente“ Mapping-Fragen zu stellen, wie beispielsweise 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?"
• Überprüfen Sie unbedingt das Schema (bei einem Webdienst), insbesondere die Fehlerbehandlung. Manche Schemata zeigen Erfolg oder Misserfolg an, während andere Codes liefern, die ausgewertet werden müssen.

Management des Entwicklungsprozesses

Ein guter Ansatz zur Steuerung des Entwicklungsprozesses besteht darin, die während der Scoping-Phase erfassten Szenarien zu nutzen und die zugehörigen Meilensteine zu verfolgen. Dies ist ein Beispiel für eine Tabelle zur Verfolgung wichtiger Meilensteine in einer Integrationsentwicklung:

Behandeln Sie jedes Szenario als Mini-Entwicklungsiteration, beginnend mit Datenabhängigkeiten (z. B. Stammdaten). Anschließend führen Sie Build-Operationen und Transformations durch, holen Testdaten ab, pushen zu einem Endpoint und verarbeiten die Antwort. Streben Sie nicht nach Perfektion. Zielen Sie darauf ab, einfache Testdaten von Punkt A nach Punkt B zu verschieben und dann zum nächsten Szenario überzugehen. Wiederholen Sie anschließend die Entwicklung des Integrationsszenarios und identifizieren Sie Blockaden, bis das Haupterfolgsszenario sowie Fehlerszenarien entwickelt und Unit-getestet sind.

Die ersten Integrationen werden die meisten Probleme bereiten, z. B. bei der Konnektivität, Berechtigungen, fehlenden Feldern usw. Je schneller wir also an diesen Punkt gelangen und die Hindernisse 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 eine Abfrage verwenden, die auf wenige Datensätze beschränkt ist.

Wenn es ein kleines Hindernis gibt, dokumentieren Sie es, weisen Sie die Lösung der richtigen Person zu und gehen Sie zum nächsten Szenario über. Auch hier geht es darum, die Minen schnell zu finden, damit sie beseitigt werden können. Diese Verantwortung liegt in der Regel beim Kunden und/oder dem KMU.

Hier ist ein Beispiel für eine Problemverfolgungstabelle:

Wiederverwendung

Wie bei jeder anderen Softwareentwicklungsplattform kann die Entwicklung beschleunigt werden, wenn man das Rad nicht neu erfindet. Jitterbit iPaaS bietet hierfür mehrere Möglichkeiten:

• Scripts
  • Komplette benutzerdefinierte Funktionen können aus vielen Operationen erstellt und aufgerufen werden. Als Faustregel gilt: Wenn Sie dasselbe Script zweimal schreiben müssen, erstellen Sie ein aufrufbares 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 vorgangsspezifischen Quellen und Zielen.
• Operationen
  • Einzelne Task-Operationen können einmal erstellt und viele Male verwendet werden, insbesondere solche, die sich mit der Fehlerbehandlung und Protokollierung befassen.
  • 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 Gültigkeitsbereich globaler Variablen jedoch die Operation ist (die von mehreren Projekten 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 Anforderungssatz betrifft Protokollierung und Fehlerbehandlung. Der Kunde hat möglicherweise keine spezifischen Anforderungen, insbesondere wenn es sich um sein erstes Integrationsprojekt handelt. Daher benötigt er Unterstützung bei Best Practices in diesem Bereich. Die wichtigsten Punkte sind:

• Jitterbit iPaaS führt sofort einsatzbereite Operation durch.
• Es ist einfach, zusätzliche Daten zu protokollieren, was für die Fehlerbehebung sehr nützlich ist.
  • Hier wird dem Kunden möglicherweise klar, 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 überprüfen. Je klarer und aussagekräftiger die Protokolle, desto schneller erfolgt die Fehlerbehebung. Es gibt zwei große Alarmklassen: datenbezogene Alarme und technische Fehleralarme, die möglicherweise an dieselbe Gruppe weitergeleitet werden müssen. Technische Fehler lassen sich einfach konfigurieren, die datenbezogene Protokollierung hingegen ist vollständig benutzerdefiniert und lässt sich einfacher während der Integrationsentwicklung als später hinzufügen.
• Integration Studio kann Email ganz einfach verwenden, wobei der Email Dienst wie ein Endpoint für den Email Dienst des Kunden behandelt wird, mithilfe von 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 zunächst: „Ich möchte keine Geschäftsregeln in die Middleware einbinden, ich möchte es einfach halten“, stellen dann aber genau die gegenteiligen Anforderungen!

Die ideale Middleware-Architektur sieht eine möglichst schlanke Integrationsschicht vor, die sich auf ihre Stärken konzentriert: Transformation, Szenarioverarbeitung und -orchestrierung, Endpoint sowie Protokollierung und Alarmierung. Das Hinzufügen umständlicher Geschäftsregeln beeinträchtigt die Perfektion dieser Architektur nur, da die Unterstützung dieser Geschäftsregeln über die Endpoint hinaus verteilt wird. Ändert sich eine Geschäftsregel, ändert sie sich nicht nur in der Anwendung, sondern auch in der Middleware. Da Middleware zudem undurchsichtig, trüb und mystisch ist, ist die Regelpflege äußerst mühsam.

Die Realität bricht unsanft aus, da Jitterbit iPaaS mit dem arbeiten muss, 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 enthält, die Dritte verwenden, verarbeiten Sie diese Zeile als AP-Eintrag, andernfalls aktualisieren Sie sie als Serviceauftrag“).

Ja, all die oben genannten Aufgaben könnten vom Endpoint übernommen 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 dies möglich ist, sollte dies unbedingt umgesetzt werden. In der Regel sind die Endpoints jedoch schwieriger zu ändern und zu warten als das Integrationsprojekt.

Wenn Geschäftsregeln beachtet werden müssen, gelten folgende Best Practices:

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

Agenten und Umgebungen

Der Jitterbit-Agent ist das Arbeitspferd der Integration. Integration Studio führt keine eigentlichen Operation aus. Alles geschieht auf einem Jitterbit-Agenten. Eine wichtige Entscheidung ist die Wahl des Agententyps: privat oder in der Cloud (siehe Jitterbit-Agenten).

Wenn einer der folgenden Punkte 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, so dass keine Daten außerhalb seiner Firewall zulässig sind.

Alternativ sind Cloud-Agenten eine Option. Aus projektzeitlicher Sicht ist dies ideal, da so alle Schritte, die mit der Beschaffung von Serverhardware und der Installation der Jitterbit-Agentensoftware verbunden sind, entfallen. Unabhängig davon, ob Sie Cloud- oder private Agenten verwenden, müssen Sie jedoch weiterhin Mitglieder und Umgebungen einrichten.

Je nach Lizenzstufe verfügt ein Kunde über zwei oder mehr Private-Agent-Lizenzen. Darüber hinaus hat er Anspruch auf verschiedene Umgebungen, die typischerweise nach 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 die folgenden wichtigen Punkte:

Die Bezeichnung einer Umfeld als „Produktionsumgebung“ ist nichts Besonderes. Sie läuft weder schneller noch ist sie robuster. Jede Umfeld ist praktisch wie jede andere.

Eine Harmony Umfeld bietet vielfältige Einsatzmöglichkeiten. Wenn der Kunde Integrationen für Dritte bereitstellt, kann eine Umfeld als Container für dedizierte Unternehmensprojekte genutzt werden.

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

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

Eine Agentengruppe ist ein obligatorischer Bestandteil der Agentenarchitektur. Sie dient nicht nur als virtueller Container für die privaten Agenten, sondern spielt auch eine weitere wichtige Rolle. Im Gegensatz zu herkömmlichen Serververwaltungstools, die zusätzliche Anwendungen wie Load Balancer erfordern, ermöglicht Harmony die einfache Serverstabilität durch Lastausgleich und Failover. Durch einfaches Hinzufügen eines Agenten zu einer Gruppe wird dieser automatisch Teil eines Serverclusters.

Zur Verdeutlichung: 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 der Gruppe ausgeführt. Das Hinzufügen von Agenten zu einer Gruppe beschleunigt die Ausführung der Operationen (normalerweise) nicht. Eine Ausnahme bildet ein Design, bei dem eine Gruppe von Agenten für die Bedienung stark frequentierter eingehender APIs benötigt. In diesem Fall ist es sinnvoll, die Last auf mehrere Agenten zu verteilen.

Für den Beginn der Entwicklung benötigen Sie lediglich einen privaten Agenten und eine Umfeld. Im Laufe des Projekts können weitere Agenten zu Gruppen hinzugefügt und neue Umgebungen hinzugefügt werden (natürlich immer im Rahmen der Lizenzbeschränkungen).

Sollte die Beschaffung eines einzigen Agenten problematisch sein, 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 einen durch ein Ereignis ausgelösten Ansatz, etwa durch eine API.

Aus Sicht eines Integrationsprojekts ist die Implementierung einer ereignisgesteuerten Verarbeitung wesentlich weniger aufwändig als die Batch. Warum ist das so?

Jitterbit unterstützt zwar eine Planungsfunktion, die meisten Batch-Prozesse erfordern jedoch einen Datenabruf basierend auf dem Datum der letzten Änderung. Dies erfordert benutzerdefinierte Skripte, um den letzten Operation abzurufen, den erfolgreichen Operation zu prüfen und anschließend das Zeitstempel-Repository zu aktualisieren. Dabei müssen Sie mit möglicherweise unterschiedlichen Zeitzonen der Endpoint, Sommerzeit und Datumsformaten rechnen. Nicht vergessen: Abfrage nur nach Daten ab, die von allen Benutzern außer dem Integrationsbenutzer geändert wurden. Bei der Migration in andere Umgebungen müssen Sie außerdem die Zeitpläne gemäß dem Projektplan aktivieren und deaktivieren. All dies stellt keine große Herausforderung dar, aber die Integrationsebene trägt eindeutig die Verantwortung für Entwicklung und Management.

Vergleichen Sie Batch mit ereignisgesteuerten Vorgängen: 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 die einzige Option. Außerdem kann es sein, dass der Kunde die Verwendung einer API ablehnt, 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 aber keine API implementieren möchte. Das Gespräch läuft ungefähr so ab:

Jitterbit: Wann sollen die Bestellungen im Bestellszenario 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! Bestellsystem jede Minute abfragen! Fertig!

Jitterbit: Moment mal. Sie wissen doch, dass Sie das Bestellsystem überlasten werden, obwohl die meiste Zeit keine Daten zu verarbeiten sind. Viele Zyklen werden vergeudet, und das Durchforsten der Operation wird mühsam. Wenn Ihr Geschäftsbedarf wirklich darin besteht, Daten schnellstmöglich zu übertragen, benötigen Sie eine API. Darüber hinaus bietet es eine Host weiterer Vorteile…

Und hier handelt der Kunde, ermutigt durch diese Informationen, richtig und stimmt der Verwendung einer API zu. Wenn Sie jedoch nicht überzeugend genug sind, wenden Sie sich an unsere Marketing-Mitarbeiter; 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 Konzept sieht vor, dass die Operation direkt aufgerufen wird und das Ziel dann sofort aktualisiert wird.
  • Was der Kunde Ihnen jedoch nicht gesagt hat (und Sie nicht gefragt haben), 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 Zielsystems. Dies könnte das Zielsystem überlasten.
• Ü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 zu speichern. APIs werden unabhängig von den Umgebungen lizenziert. Wenn also für die Entwicklungs-, Qualitätssicherungs- und Produktionsumgebung jeweils eine API verwendet wird, sind drei API Lizenzen erforderlich, nicht nur eine.

Migration

Je nach 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 dann in eine Umfeld migriert.

• Migrieren Sie nach Möglichkeit erst in die nächsthöhere Umfeld, wenn das Projekt nahezu abgeschlossen ist. Nach der Migration müssen Sie die Migration in andere Umgebungen berücksichtigen.

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

Benutzerakzeptanztests (UAT)

Alle Szenarien sind erstellt, alle Unit-Tests erfolgreich und die Benutzer stehen bereit, um die Integration zu testen. Jetzt können Sie die Benutzer mit der Integration vertraut machen. Jetzt erfahren Sie, was die tatsächlichen Anforderungen sind!

Diese Phase kann reibungslos oder sehr intensiv verlaufen. Es hängt stark von der Qualität der vorherigen Schritte ab. Beachten Sie während der UAT-Phase folgende Tipps:

Seien Sie darauf vorbereitet, schnell zu reagieren, wenn Probleme auftreten. Wenn Sie Ihre Arbeit gut gemacht haben, sind die meisten Probleme datenbezogen und nicht technisch. Stellen Sie daher sicher, dass die Endpoint-SMEs für die Problembehebung verfügbar sind.

• Überlassen Sie nach Möglichkeit dem Benutzer die Fehlerbehebung: Reagieren Sie auf Warnungen, lesen Sie Protokolle und verfolgen Sie die Integrationslogik. Idealerweise übernimmt die Person, die diese Aufgabe in der Produktion übernimmt, diese in dieser Phase.

Behalten Sie die während des UAT auftretenden Probleme und deren Lösung genau im Auge. Häufig kommt es vor, dass Probleme die Endpoint betreffen. Das Integrationsproblem ist zwar behoben, die Daten jedoch nicht, was zu einem wiederkehrenden Testproblem führt.

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

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

• 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 in der Jitterbit Management Console in die Produktion migrieren und 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.