Die Richtlinien in diesem Thema sollen Ihnen bei der Entwicklung von Integrationsartefakten für WebSphere InterChange Server helfen. Wenn Sie anhand dieser Richtlinien vorgehen, können Sie die Migration von Artefakten aus WebSphere InterChange Server zu WebSphere Process Server vereinfachen.
Auch wenn dieser Hinweis möglicherweise überflüssig ist: Die Integrationslösungen müssen sich unbedingt an das Programmiermodell und die Architektur halten, die durch WebSphere InterChange Server bereitgestellt werden, denn diese sind für echtzeitorientierte, automatisierte Prozessintegrationslösungen optimal geeignet. Auch die einzelnen Integrationskomponenten in WebSphere InterChange Server haben in der Architektur klar strukturierte Aufgaben. Deutliche Abweichungen von diesem Modell erschweren die Migration von Inhalt in die entsprechenden Artefakte unter WebSphere Process Server.
Ein weiteres bewährtes Verfahren, das den Erfolg künftiger Migrationsprojekte erheblich vergrößert, ist die Dokumentierung des Systementwurfs. Achten Sie darauf, Integrationsarchitektur und -entwurf zu erfassen, einschließlich des funktionalen Entwurfs und der Anforderungen an die Servicequalität (Quality of Service), der gegenseitigen Abhängigkeiten von projektübergreifend genutzten Artefakten und auch der Entwurfsentscheidungen, die während der Implementierung getroffen wurden. Dies vereinfacht die Systemanalyse während der Migration und reduziert ggfs. erforderliche Nacharbeiten.
Bei der Erstellung, Konfiguration und Änderung von Artefaktdefinitionen dürfen nur die bereitgestellten Entwicklungstools verwendet werden. Vermeiden Sie eine manuelle Bearbeitung von Artefaktmetadaten (z. B. die direkte Bearbeitung von XML-Dateien), denn dies kann das Artefakt für die Migration beschädigen.
Verwenden Sie für die Artefakte nur die in der Produktdokumentation veröffentlichten APIs. Diese APIs sind in den Entwicklungshandbüchern zu WebSphere InterChange Server ausführlich beschrieben. In vielen Fällen werden zwar Kompatibilitäts-APIs in WebSphere Process Server bereitgestellt, aber nur die veröffentlichten APIs sind enthalten. Auch wenn WebSphere InterChange Server viele interne Schnittstellen enthält, deren Verwendung für einen Anwendungsentwickler wünschenswert wäre, kann die künftige Unterstützung dieser Schnittstellen nicht garantiert werden.
Achten Sie bei Analyse/Entwurf von Geschäftslogik und Konvertierungsregeln in Zuordnungen und Collaboration-Schablonen darauf, weitestgehend mit dem Aktivätseditor zu arbeiten. Dies stellt sicher, dass die Logik durch Metadaten beschrieben wird, die einfacher in die neuen Artefakte migriert werden können. Für Operationen, die Sie in den Tools wiederverwenden wollen, sollten Sie möglichst immer die Funktion für die eigenen Objektgruppen verwenden. Vermeiden Sie nach Möglichkeit über Felder entwickelte Dienstprogrammbibliotheken für allgemeinen Code, die als JAR-Datei (Java Archive) in den Klassenpfad von WebSphere InterChange Server aufgenommen werden, da diese manuell migriert werden müssen.
In jedem Java-Code-Snippet, dessen Entwicklung erforderlich ist, sollte der Code so einfach und atomar wie möglich sein. Die Qualität des Java-Codes sollte in der Scripterstellung, der Einbeziehung von Basisauswertungen, Operationen und Berechnungen, der Datenformatierung, der Typkonvertierung u. a. zum Ausdruck kommen. Wenn eine erweiterte und komplexere Anwendungslogik benötigt wird, sollte die Kapselung der Logik in EJBs erwogen werden, deren Ausführung in WebSphere Application Server erfolgt, und der Aufruf der Logik sollte aus WebSphere InterChange Server heraus über Web-Service-Aufrufe vorgenommen werden. Verwenden Sie JDK-Standardbibliotheken anstelle von Fremdanbieter- oder externen Bibliotheken, die möglicherweise separat migriert werden müssen. Fassen Sie außerdem zusammengehörige Logik in einem einzigen Code-Snippet zusammen, und vermeiden Sie die Verwendung von Logik, wenn sich Verbindungs- und Transaktionskontexte über mehrere Code-Snippets hinweg erstrecken können. Beispielsweise sollte sich bei Datenbankoperationen der Code, der mit dem Anfordern einer Verbindung, dem Starten und Beenden einer Transaktion und dem Freigeben der Verbindung zusammenhängt, in einem einzigen Snippet befinden.
Allgemein muss gewährleistet sein, dass Code, der eine Schnittstelle mit einem unternehmensweiten Informationssystem (Enterprise Information System - EIS) bilden soll, in Adapter und nicht in Zuordnungen oder Collaboration-Schablonen gestellt wird. Dies ist generell ein bewährtes Verfahren für den Architekturentwurf. Außerdem werden so Voraussetzungen für Fremdanbieterbibliotheken und zugehörige Überlegungen im Code verringert, beispielsweise die Verbindungsverwaltung und mögliche JNI-Implementierungen (Java Native Interface).
Machen Sie den Code durch Verwendung der passenden Ausnahmebedingungsbehandlung so sicher wie möglich. Achten Sie auch darauf, dass der Code für die Ausführung in einer J2EE-Anwendungsserverumgebung kompatibel ist, auch wenn er gegenwärtig in einer J2SE-Umgebung ausgeführt wird. Halten Sie sich an die J2EE-Entwicklungsverfahren wie beispielsweise die Vermeidung von statischen Variablen, des Startens von Threads und der Platten-E/A. Diese Verfahren sind nicht nur generell ausgezeichnet geeignet, sondern insbesondere für die Portierbarkeit unabdingbar.
Um eine künftige Portierbarkeit zu maximieren, sollten Datenbanktransaktionen über Java-Snippet-Knoten hinweg in einer Collaboration-Schablone oder Zuordnung nicht aktiv bleiben. Beispielsweise sollte sich der Code, der mit dem Anfordern einer Verbindung, dem Starten und Beenden einer Transaktion und dem Freigeben der Verbindung zusammenhängt, in einem einzigen Snippet befinden.
Primär ist bei der Entwicklung von Geschäftsobjekten wichtig, dass nur die bereitgestellten Tools für die Konfiguration von Artefakten verwendet werden, dass für Datenattribute explizite Datentypen und Längen eingesetzt werden und dass ausschließlich dokumentierte APIs zum Einsatz kommen.
Geschäftsobjekte in WebSphere Process Server basieren auf SDOs (Service Data Object - Servicedatenobjekt), die stark typisierte Datenattribute verwenden. Bei Geschäftsobjekten in WebSphere InterChange Server und Adaptern sind die Datenattribute nicht stark typisiert, und Benutzer geben manchmal Zeichenfolgedatentypen für Datenattribute an, die nicht aus Zeichenfolgen bestehen. Um Probleme bei WebSphere Process Server zu vermeiden, müssen Sie in der Spezifikation der Datentypen explizit sein.
Da Geschäftsobjekte in WebSphere Process Server möglicherweise in der Laufzeit serialisiert werden, wenn sie zwischen Komponenten übergeben werden, ist es von erheblicher Bedeutung, die erforderlichen Längen für Datenattribute explizit anzugeben, um die Auslastung der Systemressourcen so gering wie möglich zu halten. Aus diesem Grund sollte beispielsweise für ein Zeichenfolgenattribut nicht die maximale Länge von 255 Zeichen verwendet werden. Auch die Angabe von Attributen ohne Länge, was derzeit einem Standardwert von 255 Zeichen entspricht, ist zu vermeiden. Geben Sie stattdessen die erforderliche Länge für Attribute präzise an.
Für die Namen von Geschäftsobjektattributen gelten in WebSphere Process Server die XSD-NCName-Regeln. Verwenden Sie daher in Namen von Geschäftsobjektattributen keine Leerzeichen oder Doppelpunkte ":". Namen von Geschäftsobjektattributen, die Leerzeichen oder Doppelpunkte ":" enthalten, sind in WebSphere Process Server ungültig. Benennen Sie Geschäftsobjektattribute vor der Migration um.
Wenn Sie in einem Geschäftsobjekt eine Feldgruppe verwenden, können Sie sich bei der Indexierung der Feldgruppe in Zuordnungen und/oder Beziehungen nicht auf die Reihenfolge der Feldgruppe verlassen. Die Anweisung, die Feldgruppen in WebSphere Process Server migriert, kann die Indexreihenfolge - insbesondere bei gelöschten Einträgen - nicht garantieren.
Wie bereits an früherer Stelle erwähnt, ist es wichtig, Geschäftsobjektdefinitionen ausschließlich mit dem Entwurfstool für Geschäftsobjekte zu bearbeiten und nur die veröffentlichten APIs für Geschäftsobjekte in Integrationsartefakten zu verwenden.
Viele der zuvor beschriebenen Richtlinien gelten auch für die Entwicklung von Collaboration-Schablonen.
Um sicherzustellen, dass Prozesse korrekt mit Metadaten beschrieben werden, verwenden Sie zur Erstellung und Änderung von Collaboration-Schablonen immer das Tool 'Process Designer', und vermeiden Sie es, die Metadatendateien manuell zu bearbeiten. Verwenden Sie nach Möglichkeit immer den Aktivitätseditor, um den Einsatz von Metadaten bei der Beschreibung der erforderlichen Logik zu maximieren.
Verwenden Sie in den Collaboration-Schablonen nur die dokumentierten APIs, denn dies hält die bei der Migration möglicherweise erforderliche manuelle Nacharbeit gering. Verwenden Sie keine statischen Variablen. Verwenden Sie stattdessen nicht statische Variablen und Collaboration-Eigenschaften, um die Anforderungen der Geschäftslogik umzusetzen. Vermeiden Sie den Einsatz der Java-Qualifikationsmerkmale 'final', 'transient' und 'native' in Java-Snippets. Diese Qualifikationsmerkmale können in den BPEL-Java-Snippets, die bei der Migration der Collaboration-Schablonen entstehen, nicht umgesetzt werden.
Um die künftige Portierbarkeit zu maximieren, verwenden Sie nach Möglichkeit keine expliziten Aufrufe für die Verbindungsfreigabe und expliziten Transaktionsangaben (d. h. explizite COMMIT-Operationen & explizite ROLLBACK-Operationen) für benutzerdefinierte Datenbankverbindungspools. Nutzen Sie stattdessen die containergesteuerte implizite Verbindungsbereinigung und die implizite Transaktionsangabe. Vermeiden Sie des Weiteren Systemverbindungen und Transaktionen, die in einer Collaboration-Schablone über Java-Snippet-Knoten hinweg aktiv sind. Dies gilt für alle Verbindungen zu einem externen System und auch für die benutzerdefinierten Datenbankverbindungspools. Wie bereits erläutert, sollten Operationen mit einem externen EIS-System innerhalb eines Adapters verwaltet werden, und der Code für Datenbankoperationen sollte in einem einzigen Code-Snippet enthalten sein. Dies kann in einer Collaboration erforderlich sein, die bei der Wiedergabe als BPEL-Geschäftsprozesskomponente möglicherweise als unterbrechbarer Ablauf selektiv implementiert wird. In diesem Fall kann der Prozess aus mehreren separaten Transaktionen zusammengesetzt sein, wobei nur Informationen zum Status und zu globalen Variablen zwischen den Aktivitäten übergeben werden. Der Kontext für alle Systemverbindungen zu zugehörigen Transaktionen, die sich über diese Prozesstransaktionen erstrecken, würde verloren gehen.
Verwenden Sie in den Namen von Eigenschaften für Collaboration-Schablonen keine Sonderzeichen. Sonderzeichen sind in den BPEL-Eigenschaftennamen, in die sie migriert werden, ungültig. Benennen Sie vor der Migration Eigenschaften um, und entfernen Sie diese Sonderzeichen aus den Namen, um Syntaxfehler in der durch die Migration generierten BPEL zu verhindern.
Verweisen Sie nicht mithilfe von "this." auf Variablen. Verwenden Sie an Stelle von "this.inputBusObj" einfach "inputBusObj".
Verwenden Sie für Variablen die Gültigkeit auf Klassenebene anstelle des Gültigkeitsbereichs für Szenarien. Der Gültigkeitsbereich für Szenarien wird während der Migration nicht weitergeleitet.
Initialisieren Sie alle Variablen, die in Java-Snippets deklariert sind, mit einem Standardwert, z. B. "Object myObject = null;". Achten Sie darauf, dass vor der Migration alle Variablen während der Deklaration initialisiert werden.
Vergewissern Sie sich, dass die Abschnitte der Collaboration-Schablone, die vom Benutzer geändert werden können, keine Java-Importanweisungen enthalten. Verwenden Sie in der Definition der Collaboration-Schablone die Importfelder, um die zu importierenden Java-Pakete anzugeben.
Viele der für Collaboration-Schablonen beschriebenen Richtlinien gelten auch für Zuordnungen.
Um sicherzustellen, dass Zuordnungen korrekt mit Metadaten beschrieben werden, verwenden Sie zur Erstellung und Änderung von Zuordnungen immer das Zuordnungsentwurfstool, und vermeiden Sie es, die Metadatendateien manuell zu bearbeiten. Verwenden Sie nach Möglichkeit immer den Aktivitätseditor, um den Einsatz von Metadaten bei der Beschreibung der erforderlichen Logik zu maximieren.
Wenn Sie in einer Zuordnung auf ein untergeordnetes Geschäftsobjekt verweisen, verwenden Sie für das untergeordnete Geschäftsobjekt eine Unterzuordnung.
Vermeiden Sie die Verwendung von Java-Code als "Wert" in einer Anweisung SET, da dies in WebSphere Process Server nicht gültig ist. Verwenden Sie stattdessen Konstanten. Wenn der SET-Wert "xml version=" + "1.0" + " encoding=" + "UTF-8" lautet, wird dies in WebSphere Process Server nicht ausgewertet. Ändern Sie diese Angabe in "xml version=1.0 encoding=UTF-8", bevor Sie die Migration ausführen.
Verwenden Sie in den Collaboration-Schablonen nur die dokumentierten APIs, denn dies hält die bei der Migration möglicherweise erforderliche manuelle Nacharbeit gering. Verwenden Sie keine statischen Variablen. Verwenden Sie stattdessen nicht statische Variablen und Collaboration-Eigenschaften, um die Anforderungen der Geschäftslogik umzusetzen. Vermeiden Sie den Einsatz der Java-Qualifikationsmerkmale 'final', 'transient' und 'native' in Java-Snippets.
Wenn Sie in einem Geschäftsobjekt eine Feldgruppe verwenden, können Sie sich bei der Indexierung der Feldgruppe in Zuordnungen nicht auf die Reihenfolge der Feldgruppe verlassen. Die Anweisung, die Feldgruppen in WebSphere Process Server migriert, kann die Indexreihenfolge - insbesondere bei gelöschten Einträgen - nicht garantieren.
Um die künftige Portierbarkeit zu maximieren, verwenden Sie nach Möglichkeit keine expliziten Aufrufe für die Verbindungsfreigabe und expliziten Transaktionsangaben (d. h. explizite COMMIT-Operationen & explizite ROLLBACK-Operationen) für benutzerdefinierte Datenbankverbindungspools. Nutzen Sie stattdessen die containergesteuerte implizite Verbindungsbereinigung und die implizite Transaktionsangabe. Vermeiden Sie des Weiteren Systemverbindungen und Transaktionen, die über die Grenzen von Transaktionsknoten hinweg in Java-Snippet-Code aktiv sind. Dies gilt für alle Verbindungen zu einem externen System und auch für die benutzerdefinierten Datenbankverbindungspools. Wie bereits erläutert, sollten Operationen mit einem externen EIS-System innerhalb eines Adapters verwaltet werden, und der Code für Datenbankoperationen sollte in einem einzigen Code-Snippet enthalten sein.
Denken Sie bei Beziehungen daran, dass Beziehungsdefinitionen zwar für die Verwendung in WebSphere Process Server migriert werden können, das Beziehungstabellenschema und die Instanzdaten jedoch möglicherweise von WebSphere Process Server wiederverwendet und außerdem von WebSphere InterChange Server und WebSphere Process Server gleichzeitig gemeinsam genutzt werden können.
Bei Beziehungen ist es am wichtigsten, nur die bereitgestellten Tools für die Konfiguration der zusammengehörigen Komponenten zu verwenden und ausschließlich die veröffentlichten APIs für Beziehungen in Integrationsartefakten einzusetzen.
Beziehungsdefinitionen sollten nur mit dem Tool 'Relationship Designer' bearbeitet werden. Außerdem sollte nur WebSphere InterChange Server die Konfiguration des Beziehungsschemas ermöglicht werden, das bei der Implementierung von Beziehungsdefinitionen automatisch generiert wird. Ändern Sie das Beziehungstabellenschema nicht direkt mit Datenbanktools oder SQL-Prozeduren.
Falls Sie Beziehungsinstanzdaten im Beziehungstabellenschema ändern müssen, achten Sie außerdem darauf, die von Relationship Designer bereitgestellten Funktionen zu verwenden.
Wie bereits erwähnt, dürfen nur die veröffentlichten APIs für Beziehungen in Integrationsartefakten verwendet werden.