Kapitel 8 - Bewährte Verfahren (Best Practices) für die Integration

Zweck dieses Kapitels ist es, die bewährten Integrationsverfahren für die WebSphere Product Center-Implementierung zusammenzufassen. Wenn Sie diese "Best Practices" verwenden, werden Sie eine hohe Qualität und verlässliche Integration der Systeme erreichen. Dieses Dokument soll alle unterschiedlichen Aspekte ("Dimensionen") der Integration einbeziehen und die zugehörigen Best Practices darstellen.

Schlüsselelemente der Integration:


Begriffsbestimmungen und Akronyme

Integrationsdimensionen: Die unten aufgelisteten Dimensionen tragen zum Verständnis der verschiedenen Implementierungsarten bei WebSphere Product Center-Implementierungen bei. Das Dokument hebt außerdem hervor, welche Best Practices oder Richtlinien auf welche Dimensionen oder Implementierungsarten anzuwenden sind.

WebSphere Product Center als Quellen- oder Zielsystem

Die naheliegendste Dimension ist die Frage, ob WebSphere Product Center das Quellensystem oder das Zielsystem für die auszutauschenden Informationen ist. Die Beschaffenheit des Quellensystems legt die Vorgaben für die Integration fest. Die wichtigsten Vorgaben sind u.a.: (a) die Fähigkeit, Deltasyndikationen auszuführen, (b) die Möglichkeit, eine Integration einzuleiten, (c) die Möglichkeit, eine Benachrichtigung über Erfolg oder Fehlschlagen der Datenübertragung zu empfangen und die entsprechenden Maßnahmen zu ergreifen und (d) die Art der unterstützten Protokolle und Formate, sowie die Unterstützung einer EAI-Infrastruktur (Enterprise Application Integration - EAI).

Steuersystem

Ein Steuersystem soll für die Zwecke dieses Dokuments als ein System definiert werden, das Maßnahmen gemäß einem internen Auslöser für die Integration ergreift. Ein Beispiel hierfür wäre, dass WebSphere Product Center eine Syndikation auf terminierter Basis als Job ausführt. Ein anderes Beispiel wäre, dass SAP einen WBI-Adapter als Ergebnis der Hinzufügung eines Elements auslöst. Ob WebSphere Product Center das Quellen- oder das Zielsystem bei einer Integration ist, ist vollkommen unabhängig davon, welches System das Steuersystem bei einer Integration ist. Es sind mehrere Fälle möglich. Wenn eine zwischengeschaltete Einheit, wie ein FTP-Server oder ein EAI-Tool, enthalten ist, können sowohl das das Quellen-, als auch das Zielsystem das Steuersystem sein: ein traditionelles System stellt auf terminierter Basis eine Datei auf einen FTP-Server, und WebSphere Product Center ruft diese Datei ebenfalls auf terminierter Basis ab. Ein Beispiel, in dem WebSphere Product Center als gesteuertes Zielsystem fungiert (d.h. auf einen externen Auslöser eines Datenimports wartend), wäre IBM WebSphere Business Integration (IBM WBI), das eine Nachricht an WebSphere Product Center über das aufrufende Programm sendet, bei der der Nachrichteninhalt beispielsweise eine Elementaktualisierung der Einkaufsplattform Transora sein könnte. Ein Beispiel, in dem WebSphere Product Center als gesteuertes Quellensystem fungiert (d.h. auf einen externen Auslöser eines Datenexports wartend), wäre IBM WBI, das eine WebSphere Product Center-Warteschlange regelmäßig danach abfragt, ob eine Datei für den Abruf bereit steht.

Protokoll

Es besteht einige Unklarheit in den WebSphere Product Center-Implementierungsteams und den Kundenressourcen über den Unterschied der protokoll-, format- oder nachrichtenbasierter Integration im Vergleich zu dateibasierter Integration. Daher soll ein Ziel dieses Dokuments sein, sicherzustellen, dass eine einheitliche Terminologie für diese Konzepte verwendet wird. Beispiele für Protokolle sind FTP (File Transfer Protocol), HTTP (Hyper Text Transfer Protocol), SMTP (Simple Message Transfer Protocol), d.h. E-Mail, JMS (Java Messaging Service) und IBM WebSphere MQ (IBM WebSphere Message Queuing). Ein Protokoll legt z. B. Umgebungsvariablen fest, oder die Codierung bestimmter Daten wie z. B. Zahlen, oder erwartete Antworten, hat aber nichts mit dem übertragenen Inhalt zu tun. Bei allen Integrationen muss klar sein, welche Protokolle verwendet werden, da immer mindestens eines vorhanden ist. Außerdem werden möglicherweise in den verschiedenen Stadien einer Integration unterschiedliche Protokolle verwendet: Der WBI-Adapter überträgt in SAP möglicherweise Daten von SAP an WBI ICS (Inter Connection Server - ICS) über HTTP, das wiederum die Daten an einen IBM MQ-Warteschlangenmanager übergibt, damit sie an einen anderen Warteschlangenmanager weitergeleitet werden, mit dem WebSphere Product Center als MQ-Client verbunden ist.

Format

Das Format der Daten ist unabhängig vom verwendeten Protokoll. Beispiele für Formate wären durch Kommata getrennte Daten (CSV - Comma Separated Values), Pipe mit Begrenzer, eXtensible Markup Language (XML), oder lediglich einige vordefinierte Felder und Datensatzstrukturen, wie z. B. für EDI-Nachrichten (Electronic Data Interchage). Jedes Format definiert Felder entweder mittels Positions- oder Längenparameter, oder durch Tags. Es ist wichtig, dabei zu berücksichtigen, das für ein bestimmtes Format eventuell eine bestimmte Codierung notwendig sein könnte. So wird z. B. bei Implementierungen oftmals die Tatsache vergessen, dass Zeichen wie spitze Klammern ('<', '>') in XML ein Escapezeichen benötigen, oder dass Inhalt in CSV möglicherweise Kommas enthält.

Größe von Daten

Diese Dimension wird oftmals mit "nachrichtenbasierter" oder "dateibasierter" Übertragung verwechselt, daher soll sie hier noch einmal klar definiert werden. Bei "nachrichtenbasierter" Integration wird normalerweise vorausgesetzt, dass es um einen kleineren Datenaustausch mit den folgenden Charakteristika geht:

Es gibt jedoch keine klare Linie, die zur Unterscheidung einer nachrichtenbasierten, einer dateibasierten oder einer Batch-Integration gezogen werden kann, und es ist wichtig, eine eindeutige Menge an Dimensionen festzulegen und keine Verwechslungen oder Überschneidungen zuzulassen. Aus diesem Grund sollte die Gesamtgröße der Daten die wichtigere zu berücksichtigende Dimension sein, als die Frage, ob man die Integration als "nachrichtenbasiert" oder als "Batchintegration" bezeichnen soll.

Übertragungsarten

Eine weitere zu berücksichtigende Dimension ist die Art der Übertragung bei der Integration. Die synchrone Übertragung gibt dem Benutzer oder System eine sofortige Rückmeldung über das Ergebnis einer Aktion. Wenn Sie beispielsweise HTTP für die Übertragung verwenden, wird automatisch eine Rückmeldung an das System oder den Benutzer gesendet, nachdem eine Aktion gesendet wurde. Die asynchrone Übertragung dagegen setzt eher auf eine Strategie, die man als "fire-and-forget" (absenden und vergessen) bezeichnen kann. Wenn es für die Integration erforderlich ist, eine Datei auf einen FTP-Server zu stellen, die dann von einem System angerufen wird, gibt es beispielsweise keine automatische Rückmeldung an das System, das die Datei auf den Server gestellt hat, um über das Ergebnis der Aktion zu informieren.

Häufigkeit

Zusammen mit der Dimension "Größe von Daten" wird mit der Dimension "Häufigkeit" erfasst, wie groß die gesamte Datenmenge ist, die regelmäßig verarbeitet werden muss.

Integrationsthread

Diese Dimension, die Zwischensysteme und temporäre Infrastrukturen betrifft, legt fest, ob eine EAI-Infrastruktur verwendet wird, oder nicht. Außerdem müssen gelegentlich bei Integrationen mit traditionellen Systemen eventuell Zwischenprogramme geschrieben werden, um Daten in traditionelle Systeme hochzuladen oder aus diesen zu extrahieren. Es wichtig, diese Zwischensysteme oder -programme zu verstehen und zu dokumentieren, da sie häufig die schwächsten Glieder in der Integrationskette sind.

Insbesondere in komplexen Integrationen, die mehrere Hops erfordern (z. B. von WebSphere Product Center an WBI an Zielsystem), von der Norm abweichende Mittel (z. B. direkte Datenbankaktualisierungen), mehrere Protokolle oder andere Herausforderungen bei der Übertragung beinhalten (z. B. durch eine Firewall), sollten Sie frühzeitig einen einzigen, funktionierenden Thread oder kompletten Integrationspfad aufbauen. Dadurch können mögliche Probleme vorab identifiziert und anderen Beteiligten (wie z. B. Netzwerkadministratoren, Teams, die an IBM WBI arbeiten) ausreichend Zeit gegeben werden, solche Konnektivitätsprobleme parallel dazu zu lösen.

Diese aufgeführten Dimensionen einer Integration sollten der Standard für die Beschreibung der Integrationen bei WebSphere Product Center-Implementierungen sein. Für die Dokumentation, die von PS-Teams in der Analyse- und Entwicklungsphase bereitgestellt wird, sollten diese Dimensionen in eindeutiger und konsistenter Weise verwendet werden.

Akronyme

Akronym

Definition

EAI

Enterprise Application Integration

FTP

File Transfer Protocol

HTTP

Hyper Text Transfer Protocol

MQ

Die Middleware für IBMs Nachrichtenwarteschlange. Wird oftmals als IBM Websphere MQ bezeichnet, da mittlerweile alle Konnektivitätslösungen unter der Marke WebSphere zusammengefasst sind.

ICS

Inter Connect Server von IBM WBI

WBI

Die IBM WebSphere Business Integration-Produktsuite, d.h. die EAI-Produktsuite von IBM.


Gestaltungsprinzipien

Wiederverwendbarkeit

Das grundlegende Prinzip für die Vorgehensweise bei der Implementierung einer Integration ist die Wiederverwendbarkeit. In dem Maße, in dem WebSphere Product Center wächst und mehr Clients implementiert werden, ist es notwendig, dass Integrationen sowohl mit zuvor nicht integrierten Systemen, als auch mit Systemen, die bei vorherigen Implementierungen schon integriert wurden, schnell durchgeführt und skaliert werden können. Um dieser Anforderung gerecht zu werden ist es notwendig, die Integration nach dem Prinzip der Wiederverwendbarkeit so zu gestalten, dass bei einer eventuellen Integation desselben Systems für einen anderen Client größtmögliche Effizienz vorherrscht.

Wiederverwendbarkeit können Sie erreichen, indem Sie: (a) EAI-Tools wie IBM WBI und das Modell generischer Business-Objects nutzen, (b) Formate wählen, die unabhängig vom Datenmodell sind, (c) Bibliotheken für WebSphere Product Center-Scripts erstellen (Bestätigung, Abfrage usw.), die unabhängig vom Datenmodell sind und für andere Implementierungen wiederverwendet werden können.

Gemeinsame Informationsnutzung

Kommunikation als ein Mittel der Integration

Die Integration kann vom Konzept her einfach als eine Serie von Ereignissen betrachtet werden, die durch die Kommunikation zwischen dem Steuersystem WebSphere Product Center und dem oder den gesteuerten System(en) ausgelöst wird. Diese Ereignisse können durch Nachrichten ausgelöst werden, die zwischen den Systemen weitergegeben werden, automatisierten Prozessen, die Inhalte oder Dateien abfragen, oder jede sonstige Möglichkeit der rudimentären Kommunikation. Zur Kommunikation gehört beispielsweise die Art der auszuführenden Änderung (Hinzufügen, Aktualisieren, Löschen), eine eindeutige Kommunikations-ID (für Protokollierung, Bestätigung) und der relevanten Inhalt, damit die Änderung entweder in WebSphere Product Center oder in dem bzw. den zu integrierenden System(en) ausgeführt werden kann.

Zuverlässigkeitsmaßnahmen

Zusätzlich zur Weitergabe von Informationen zwischen Systemen, um Änderungen zu kommunizieren, sollte es die Möglichkeit geben, den Erfolg oder das Fehlschlagen einer bestimmten Transaktion zu kommunizieren. Diese Kommunikation nach dem "Handshakeverfahren" kann intuitiv für synchrone Kommunikationsformen implementiert werden und ermöglicht es den integrierten Systemen, zu verfolgen, ob eine bestimmte Transaktion erneut gesendet werden muss, weil der Empfang am anderen Ende fehlgeschlagen ist. Auf diesem Wege wird die Zuverlässigkeit der Integration verbessert bzw. schließlich sichergestellt.

Informationsformate

Das genaue Format dieser Kommunikation sollte so generisch gestaltet werden, dass sowohl das Format, als auch die umgebende Verarbeitungsfunktionalität in Implementierungen wiederverwendet werden kann.

Bei der Erwägung des allgemeinen Formats, das für die Kommunikation zwischen Systemen verwendet wird, sollte unbedingt darauf geachtet werden, dass das Format die Anforderungen unter den folgenden Gesichtspunkten erfüllen kann:

Informationsverarbeitung

Zwar ist es einsehbar, dass das Format der Informationen, die zwischen Systemen hin- und hergesendet werden, möglichst generisch sein sollte, es ist jedoch auch verständlich, dass nicht alle Implementierungen sich nicht in ein vordefiniertes Format pressen lassen, insbesondere dann, wenn die Integration als eine direkte Verknüpfung zwischen WebSphere Product Center und dem oder den zu integrierenden System(en) betrachtet werden soll. Um zu vermeiden, dass Formate und Zuordnungen zwischen Formaten und WebSphere Product Center-Spezifikationen bei jeder Implementierung aufgrund von Unterschieden wie den Datenmodellen neu konzipiert werden müssen, wird empfohlen, wiederverwendbare Zuordnungsfunktionalitäten zwischen XML-Formaten und WebSphere Product Center-Spezifikationen zu verwenden.

EAI-Plattformen verwenden

Eine Möglichkeit zur Verwirklichung dessen ist die Verwendung von EAI-Plattformen, wie z. B. die Produktsuiten WBI oder webMethods, mit denen wieder verwendbare Verbindungseinheiten erstellt werden können, so dass WebSphere Product Center z. B. über ein einziges vollständig wieder verwendbares Nachrichtenformat kommunizieren kann (d.h. ein einziges XML-DTD). Abweichungen, die aufgrund der Besonderheiten der jeweiligen Implementierung entstehen können, werden anschließend von WBI konvertiert, anstatt eine Neugestaltung der WebSphere Product Center-Funktionalität für die Verarbeitung von Informationen zu erfordern. Da die Umgestaltung der WebSphere Product Center-Funktionalität nicht erforderlich ist, können dieselben Funktionalitäten für mehrere Implementierungen verwendet werden.

Andere Optionen

Es sollte jedoch auch berücksichtigt werden, dass bestimmte Clients ein Format wiederverwenden müssen, das bereits von anderen System im Unternehmen verwendet wird. Dies würde es WebSphere Product Center erschweren, eine vollständig separate DTD einzuführen, die für andere Systeme im Unternehmen konvertiert werden muss, damit sie verstanden wird, anstatt dass WebSphere Product Center die bereits vorhandene DTD verwendet. In diesem Fall sollte eine wieder verwendbare Funktionalität für die Konvertierung zwischen den Spezifikationen in WebSphere Product Center und der DTD verwendet werden.

Es kann auch sein, dass selbst bei der Verwendung einer EAI-Plattform dieser Ansatz für einen bestimmten Client unter dem Aspekt des Verstehens der Zuordnung von WebSphere Product Center-verwalteten Informationen an die interne DTD zur Kommunikation von Informationen nützlicher und damit der bessere Ansatz ist.

Ereignisgesteuerte Verarbeitung

Idealerweise werden Ereignisse über einen automatisierten Prozess in WebSphere Product Center gehandhabt. So könnte beispielsweise die Warteschlangenfunktionalität, die im WebSphere Product Center-Release eingeführt wurde, verwendet werden, um sowohl das Senden von Nachrichten (Warteschlange für ausgehende Nachrichten) als auch das Empfangen von Antworten und eingehenden Nachrichten (Warteschlange für eingehende Nachrichten) zu handhaben. Danach könnten Scripts für die Warteschlangenverarbeitung verwendet werden, um die tatsächliche Verarbeitung von Nachrichten zu handhaben, und somit im Grunde genommen die Ereignisse auszuführen, die als Ergebnis einer bestimmten Nachricht ausgelöst werden sollen.

Die ereignisgesteuerte Verarbeitung ist jedoch nicht an bestimmte Funktionalitäten oder Versionen von WebSphere Product Center direkt gebunden. Andere Möglichkeiten zur Handhabung von Ereignissen können terminierte Jobs in WebSphere Product Center sein, die einen FTP-Server abfragen, terminierte Jobs, die ein lokales Dateisystem nach einer bestimmten Datei (über den Dokumentspeicher) überprüfen, ein Auslöserscript, das auf einem aufrufenden Programm basiert und Ereignisse auf der Basis gesendeter Informationen versendet, oder sonstige Möglichkeiten. Welche Methode ausgewählt wird, sollte letztlich von der genauen Abwägung der Anforderungen hinsichtlich der Größe der Daten und der Häufigkeit für eine bestimmte Integration abhängen.

Änderungsverfolgung

für die Implementierung einer vollständigen Synchronisation zwischen den Systemen muss die Möglichkeit bestehen, dass in WebSphere Product Center Änderungen an Inhalten und Elementen protokolliert werden können, die daraufhin gekennzeichnet werden können, ob sie an die zu integrierenden Systeme kommuniziert worden sind, oder nicht. Wenn z. B. ein Element in WebSphere Product Center (als Quellensystem) gelöscht wird, soll dadurch nicht nur das Senden einer Nachricht an das Zielsystem ausgelöst werden können, die das Zielsystem darüber benachrichtigt, dass dieses Element gleichfalls gelöscht werden soll, sondern es soll auch möglich sein, Erfolg oder Fehlschlagen dieser bestimmten Kommunikation zu protokollieren, so dass WebSphere Product Center weiß, ob dieses Element tatsächlich auch im Zielsystem gelöscht wurde.

Wieder verwendbare Verbindungseinheiten

Verbindungseinheitenrepository

Mit dem Fortschreiten der Implementierung und der Entwicklung von Partnerschaften wird schrittweise ein Repository wieder verwendbarer Verbindungseinheiten für eine Vielzahl von Systemen erstellt. Wann immer möglich sollten alle Anstrengungen unternommen werden, diese Verbindungseinheiten wiederzuverwenden, da die Funktionalitäten für die Verarbeitung der Elemente usw., die über diese Verbindungseinheiten ablaufen, dadurch mit wenig oder keiner Änderung vom Standpunkt einer bestimmten Implementierung wieder verwendet werden können. Dadurch wird natürlich die Ausführungszeit der Implementierung insgesamt beschleunigt und die Gesamtzuverlässigkeit und -stabilität der Verbindungseinheiten und der Implementierungen, die diese Verbindungseinheiten nutzen, verbessert, da mögliche Probleme in diesen Bereichen frühzeitig erkannt und gelöst werden können.

Bei einer Systemintegration, für die noch keine Verbindungseinheiten definiert wurden, sollte ein Integrationsexperte hinzugezogen werden, der rasch eine wieder verwendbare Verbindungseinheit erstellen kann, die sowohl für die Integration in einer bestimmten Implementierung verwendet werden kann, als auch im Verbindungseinheitenrepository für die spätere Verwendung gespeichert werden kann, falls jemals dieses System im Zuge einer anderen Implementierung integriert werden sollte.

Verwendung der Verbindungseinheiten

Verbindungseinheiten sollte so verwendet werden, dass alle Änderungen, die jemals durchgeführt werden müssen, über eine EAI-Ebene gehandhabt werden, die die Konvertierung von Informationen handhabt, die zwischen Systemen übergeben werden. Mit anderen Worten: Vor dem Umschreiben einer der wieder verwendbaren Funktionalitäten in WebSphere Product Center zur Verarbeitung von Informationen, die über EAI übergeben werden, sollten die Vorteile der Funktionalität der EAI-Plattform genutzt werden, sämtliche notwendigen Konvertierungen auszuführen, damit das Umschreiben der WebSphere Product Center-Funktionalitäten vermieden werden kann.


Implementierung

Skalieren der Implementierung

'Mini-Integrationen'

Die umfangreiche Aufgabe einer Gesamtintegration sollte in viele kleinere und dadurch einfacher zu verwaltende Aufgaben eingeteilt werden. Dies können Sie beispielsweise tun, indem Sie eine einzige komplette Integration in viele kleinere Integrationen aufteilen - von "separaten" Integrationen für jeden Elementtyp (Spezifikation) in Integrationen für jeden Container (Katalog), bis herunter zu Integrationen für eine Gruppe von Attributen (falls notwendig). Wenn Sie überzeugt sind, dass diese "Mini-Integrationen" tadellos funktionieren, können sie zu einer einzigen vollständigen Integration kombiniert werden.

Unterteilung von Funktionalitäten

Die Ebenen, auf denen die Integration von Systemen erforderlich ist, müssen mit großer Aufmerksamkeit betrachtet werden. Wenn z. B. Änderungen an ein Zielsystem gesendet werden, möchte man in der Lage sein, entweder alle Änderungen seit einem bestimmten Datum zu senden, oder nur die Änderungen für einen bestimmten Katalog seit dem Senden der letzten Änderungen, nur die Änderungen, die für eine bestimmte Gruppe von Elementen aufgetreten sind, oder etwaige Änderungen, die für ein bestimmtes Attribut für alle Elemente aufgetreten sind. Die genauen Anforderungen hängen von der jeweiligen Implementierung ab, es ist jedoch wichtig, die erforderlich Unterteilung schon frühzeitig im Entwicklungsprozess der Implementierung zu erwägen, so dass sie angemessen berücksichtigt werden kann.

Leistungsoptimierung

Kommentare zum allgemeinen Leistungsverhalten

Schieben Sie mögliche Leistungsprobleme nicht zu lange auf. Es ist relativ einfach, Formate oder andere Integrationsaspekte später noch zu ändern oder zu reparieren, ein Leistungsengpass jedoch kann bedeutende Überarbeitungen und gelegentlich sogar die Entwicklung von Unterstützung erfordern. Setzen Sie im Verlauf der Entwicklung Hooks für die Leistungsmessung in den Scripts.

Leistung messen

Unter der Voraussetzung der "Mini-Integration" (wie im Abschnitt "Implementierung" beschrieben) sollte die Leistung in jeder Phase der Integration gemessen werden, indem die erforderliche Gesamtzeit gemessen wird, die für jede Aufgabe in der Mini-Integration erforderlich ist. So können mögliche schwache Leistungsbereiche auf ausreichend differenzierter Ebene identifiziert und dadurch einfacher für die Leistungsverbesserung gefunden werden.

Verbesserung der Leistung

Wenn Leistungsproblembereiche identifiziert wurden, sollte eine detaillierte Analyse erfolgen, um die eigentliche Ursache für die langsame Verarbeitung zu ermitteln. Eine detaillierte Analyse kann mit Tools wie der Middleware-Profilermittlung von WebSphere Product Center und der Registerkarte für das Leistungsverhalten in der Anzeige für die Jobbeschreibung ausgeführt werden. Sodann kann die Analyse einen bestimmten Bereich eines Scripts oder einer SQL-Abfrage fokussieren, und es können geeignete Maßnahmen ergriffen werden - Ändern oder Umschreiben des Scripts, oder die Einbeziehung der Entwicklung, um eine Datenbankabfrage zu verbessern.

Prüfung

Stabilität

Vorteile von Mini-Integrationen

Die Implementierung von Mini-Integrationen (wie im Abschnitt "Implementierung" beschrieben) bietet einen höheren Grad der Gewissheit, dass die Integration erfolgreich war, indem eine detaillierte Auflistung aller Bereiche zur Verfügung gestellt wird, in denen die Integration sich als funktionierend erwiesen hat. Ohne die Transparenz von Mini-integrationen ist es nicht nur ungleich schwieriger, eine funktionierende Integration zu beweisen, sondern die Integration insgesamt wird mit größerer Wahrscheinlichkeit unter Problemen leiden, die schwierig zu identifizieren, zu diagnostizieren und zu beheben sind. Daher führt das Umsetzen von Mini-Integrationen die Gesamtstabilität der Integration.

Skalierbare Tests

Vorteile von Mini-Integrationen

Die Implementierung von Mini-Integrationen (wie im Abschnitt "Implementierung" beschrieben) ermöglicht es, Integrationstest in weitaus höherem Detaillierungsgrad durchzuführen, so dass etwaige Fehler oder Probleme, die auftreten können, nicht durch zu hohe und möglicherweise irrelevante Komplexität überschattet werden. Daher sollten die Prozesse zum Diagnostizieren, zur Fehlerbehebung und zur Lösung erkannter Probleme, wie oben schon erwähnt, durch diesen Ansatz stark beschleunigt werden.

Repräsentative Umgebungen versus vollständige Umgebungen

Die Integrationstests sollten an repräsentativen Umgebungen mit derselben Konfiguration wie die endgültige Umgebung (dieselben Spezifikationen, Prüfungsregeln, Wertregeln, Ansichten), aber mit so wenig wie möglich repräsentativen Entitäten (Locales, Katalogen, Kategoriebäumen, Organisationen, Benutzern, Aufgabenbereichen) ausgeführt werden. Dies sollte die benötigte Zeit zum Ausführen der Tests und Laden der Anzeigen reduzieren, und insgesamt die Testzeit im Vergleich zu einer Umgebung beschleunigen, die vollständig gefüllt ist. Sämtliche Tests und Debugs sollten in dieser Umgebung ausgeführt werden.

Erst wenn der Test in der repräsentativen Umgebung abgeschlossen ist und alles funktioniert hat, sollte die Integration sodann in einer vollständigen und gefüllten Umgebung bestätigt werden. Dieser Schritt sollte außerdem ausgeführt werden, um sicherzustellen, dass keine Randszenarien versehentlich in der repräsentativen Umgebung ignoriert wurden, und um die Leistung der Umgebung im Produktionsbetrieb zu testen.

Skalierbare Prozesstests

Jeder terminierbare Job wie Importe und Exporte sollte zunächst nur mit einer sehr kleinen Anzahl repräsentativer Elemente ausgeführt werden - 10 oder weniger. Diese Zahl sollte proportional mit dem Grad der Verlässlichkeit des Scripts steigen, das diese Elemente tatsächlich verarbeitet. Dieser Ansatz stellt sicher, dass ein umfangreicher Job nicht über Stunden ausgeführt, nur damit der Ausführende anschließend feststellen muss, dass ein Fehler aufgetreten ist, der jedoch nicht den gesamten Prozess bereits in den ersten Minuten der Ausführung fehlschlagen lassen hat.

Erst wenn vollständige Übereinstimmung im dem Job zugehörigen Script besteht, sollte ein Job mit einem kompletten Datensatz ausgeführt werden. Wie bei den Empfehlungen zur vollständigen Umgebung sollte dieser Schritt außerdem ausgeführt werden, um sicherzustellen, dass keine Randszenarien versehentlich bei der Ausführung kleinerer Jobs ignoriert wurden, und um die Leistung des Jobs im Produktionsbetrieb zu testen.

Transparenz

Berichte

Vorteile von Mini-Integrationen

Die Implementierung von Mini-Integrationen (wie im Abschnitt "Implementierung" beschrieben) ermöglicht eine detaillierter Berichterstellung aufgrund kompakter und schneller implementierbarer Integrationsblöcke. Im Vergleich zur Berichterstellung über den Verarbeitungsfortschritt der Implementierung auf Gesamtintegrationsebene ermöglicht diese abgestuftere Berichterstellung das eine konkretere und quantitativere Protokollierung der Implementierung.

Die Mini-Integrationen können aufgelistet und ihr Zusammenhang mit dem größeren Bild der kompletten Integration kann in einer Grafik dargestellt werden, so dass anhand der Berichterstellung über den Verarbeitungsfortschritt der Mini-Integrationstasks ein genaues Bild des gesamten Verarbeitungsfortschrittes der Implementierung gezeichnet werden kann.

Eignerrechte

Auch wenn Sie mit mehreren Teams arbeiten, sollte eine Einzelperson der Eigner für die gesamte Integration sein. Aufgabe dieser Person ist es, sicherzustellen, dass der Einzelthread frühzeitig erstellt wird, dass die Teams gemäß den Richtlinien in diesem Dokument arbeiten, und dass der Zyklus des schrittweisen Erstellens und Testens anhand von (a) Mini-Integrationen, (b) skalierbaren Prozesstests und (c) repräsentativen versus vollständigen Umgebungen in den verschiedenen Teams synchron stattfindet.

Dokumentation

Formate und Ansatz eindeutig angeben

Entscheiden Sie sich für eine eindeutige Vorgehensweise bei der Ausführung und dokumentieren Sie klar alle Formate, die benutzt werden sollen, wenn mehrere Teams an der Integration mitarbeiten. Das häufigste Beispiel hierfür ist ein WebSphere Product Center-Team, das gerade Daten aus WebSphere Product Center exportiert, und gleichzeitig ein Kunden- oder SI-Team, das diese Daten in ein Zielsystem hochlädt. Beginnen Sie nicht ohne die Spezifikationen für das gemeinsame Format mit der Arbeit, und aktualisieren Sie die Dokumentation täglich. Dies ist eine absolute Anforderung, die der Projektleiter umzusetzen hat.

Dieser Ansatz ist dennoch konsistent mit dem Verwenden von repräsentativen Umgebungen und dem Ausführen von Mini-Integrationen. Beide Teams sollten inkrementell aufbauen und testen, um stetigen, transparenten Verarbeitungsfortschritt sicherzustellen.


Die Top-Ten-Richtlinien für WebSphere Product Center-Integrationen

Verwendung einer klaren und allgemein gebräuchlichen Terminologie zur Beschreibung der Integration

Alle Implementierungen sollten die angegebenen Dimensionen einbeziehen, die im Abschnitt "Dimensionen der Integration" beschrieben wurden.

Wiederverwendbarkeit

Der Schlüssel zur Skalierung liegt darin, aus vorherigen Integrationen zu lernen, und die Integrationen zu konfektionieren, wobei die Prinzipien der Wiederverwendbarkeit berücksichtigt werden müssen, wie im Abschnitt "Wiederverwendbarkeit" beschrieben.

Transparenz

Bauen Sie eine Gesamtmessgröße für den Fortschritt bei der Berichterstellung auf und stellen Sie dem Projektleiter spätestens alle paar Tage eine klare Statusaktualisierung zur Verfügung.

'Mini-Integrationen'

Unterteilen Sie die Komplexität einer großen Integration anhand verschiedener Dimensionen (Kataloge, Attribute), so dass es für die Integration Sinn ergibt. Konzentrieren Sie sich zunächst auf eine Mini-Integration zur Zeit und binden Sie sie direkt in die Messwerte für Transparenz ein.

Repräsentative Umgebungen versus vollständige Umgebungen

Pflegen Sie eine repräsentative Umgebung, für die Fehlerbehebung und Tests leicht durchzuführen sind. Gehen Sie erst zur vollständigen Umgebung über, wenn die Gültigkeit von Scripts und Spezifikationen zutrifft. Binden Sie dies in die Messwerte für Transparenz ein.

Skalierbare Prozesstests

Testen Sie alle Jobs mit kleinen Datensätzen, um die Richtigkeit zu überprüfen, bevor Sie mit den kompletten Datensätzen beginnen. Binden Sie dies in die Messwerte für Transparenz ein.

Leistung

Führen Sie einige Leistungstests in einem frühen Stadium des Entwicklungszyklus aus, ohne sich um logische Richtigkeit oder die Formatierung zu kümmern, und führen Sie diese Tests auch anschließend regelmäßig durch, um mögliche Probleme zu erkennen.

Aufbau eines Einzelthreads in einem frühen Stadium

Insbesondere bei komplexeren Integrationen, die möglicherweise mehrere Hops erfordern, mehrere Protokolle oder vom Standard abweichende Mittel, sollten Sie einen einzigen funktionierenden Integrationsthread frühzeitig errichten.

Gestaltungsspezifikationen und Dokumentation

Legen Sie eine eindeutige Vorgehensweise bei der Ausführung fest und dokumentieren Sie diese, ebenso wie alle Formate, die benutzt werden sollen, insbesondere, wenn mehrere Teams an der Integration mitarbeiten.

Ein einziger Eigner

Auch wenn Sie mit mehreren Teams arbeiten, sollte eine Einzelperson der Eigner für den Gesamtverlauf der Integration sein.


EAI-Plattformintegration

Methode

Generische Kommunikationsformate

Wann immer möglich sollte ein generisches Kommunikationsformat entwickelt oder aus einem früheren Projekt wiederverwendet werden. Je allgemeiner das Format, desto mehr Systeme können in die Integration einbezogen werden, ohne dass eine besondere Formatüberarbeitung notwendig wäre, damit alle Systeme miteinander kommunizieren können. Natürlich können Kompromisse bei der Leistung notwendig sein, je allgemeiner ein Format gestaltet ist, und daher ist das für ein Projekt richtige Format nicht unbedingt die ideale Wahl für ein anderes Projekt. Die Integrationsdimensionen sollten immer berücksichtigt werden, wenn die Verwendung eines bestimmten Formats festgelegt wird.

Inhaltszuordnungen

Zuordnungen zwischen dem WebSphere Product Center-Inhaltsmodell und dem Modell sollten aus der Perspektive des Kommunikationsformates so weit wie möglich über dynamisch aktualisierbare Mittel erfolgen. Auf der Grundlage einer Untersuchung der Integrationsdimensionen kann es sich, wie bereits erwähnt, herausstellen, dass es für bestimmte Projekte nicht möglich ist, diese Zuordnungen vollständig dynamisch aktualisierbar zu erstellen - beispielsweise aufgrund der hohen Priorität, die dem absoluten Maximumdurchsatz bei der Verarbeitung eingeräumt wird. Eine Möglichkeit hierbei ist das Einbeziehen von Kategoriebäumen (die z. B. eine XML-Struktur darstellen) mit einer einzigen zugehörigen Knotenspezifikation, die den Pfad des Spezifikationsknotens eines Attributs angeben kann, für das ein bestimmter Knoten des Kategoriebaums im WebSphere Product Center-Inhaltsmodell zugeordnet werden kann. Anschließend kann ein rekursives Verarbeitungsscript verwendet werden, um die Zuordnung eines Elements in eine XML-Datei auf der Basis des Kategoriebaums und der definierten Zuordnungen zu verarbeiten, und kann sogar verschachtelte Mehrfachvorkommen ohne großen Aufwand berücksichtigen.


Weitere Vorteile

Konvertierung und Umsetzung von Informationen

Für die in eine Integration einbezogenen Systeme sollte nicht die Notwendigkeit bestehen, selbst die Informationen oder Inhaltseinschränkungen und Anforderungen anderer Systeme innerhalb der Integration zu handhaben. EAI-Plattformen eignen sich hervorragend zur Handhabung der Konvertierung und Transformation von Inhalten. Während z. B. WebSphere Product Center einen FLAG-Wert als "TRUE" (wahr) oder "FALSE" (falsch) speichert, könnte ein System in der Integration diese Werte vielleicht als "Y" (Ja) oder "N" (Nein) speichern. Mit EAI-Plattformen können diese Konvertierungen so erfolgen, dass WebSphere Product Center immer die Werte TRUE/FALSE sendet und auch voraussetzt, TRUE/FALSE zu empfangen, und gleichzeitig können integrierte Systeme immer die Werte Y/N senden bzw. empfangen. Dadurch wird sichergestellt, dass bei der Einbeziehung einer zunehmenden Zahl von Systemen in die Integration keine Änderungen am Programmcode aufgrund der zusätzlichen Systeme erforderlich ist.

Nachvollziehbarkeit für den Client

Da eine Plattform wiederverwendet werden kann, mit der der Client wahrscheinlich bereits vertraut ist, gewinnt der Client die zusätzliche Sicherheit, dass für die Integration eine ihm bekannte Funktionalität eingesetzt wird - die EAI-Plattform. Außerdem müssen clientseitige Entwickler, wenn ein Client-spezifisches Kommunikationsformat bereits vorhanden ist und für die WebSphere Product Center-Integration wiederverwendet wird, nur wenig oder keine zusätzlichen Schulungen, um das Kommunikationsformat zu verstehen, dem WebSphere Product Center zugeordnet wird.

Flexibilität und Zuverlässigkeit der Kommunikation

Die meisten EAI-Plattformen verfügen über umgebungsspezifische Funktionalitäten, damit die Kommunikation über verschiedene Protokolle möglich ist und um sicherzustellen, dass die Kommunikation über Brokering sichergestellt wird. Dadurch kann WebSphere Product Center einfach das notwendige Dokument für die Kommunikation generieren, ohne dass die Unterstützung möglicher unterschiedlicher Formen der Übertragung dieses Dokuments an verschiedene Systeme zu berücksichtigen wäre oder die verfolgt werden müsste, ob das Dokument auch von allen Systemen empfangen wurde. Um diese Dinge kümmert sich die EAI-Ebene und die Plattform, so dass WebSphere Product Center sie lediglich aus der Perspektive des gesamten Integrationsthreads berücksichtigen muss.