Informationen zum Mustercode 'TwineBall Example EIS Adapter'

Dieser Mustercode soll die Funktionsweise der WebSphere-Adapterknoten veranschaulichen. Er verwendet dabei die TwineBall-Adapter, die über ein eigenständiges unternehmensweites Informationssystem (EIS) verfügen. In diesem Mustercode fügt ein traditionelles System Daten mittels WebSphere MQ-Warteschlangen in das EIS ein, um die beiden Systeme zu synchronisieren.

Der TwineBall-Adapter

Der TwineBall Example EIS-Adapter enthält mehrere XML-Schemata sowie eine interne Cloudscape-Datenbank und kann daher mithilfe des EMD-Tools (Enterprise Metadata Discovery) zugeordnet werden. Der TwineBall-Adapter lässt sich somit genau wie ein produktionsfertiges EIS und ohne erforderliche Installation, Konfiguration oder Einrichtung verwenden. Das TwineBall-EIS enthält nur ein Geschäftsobjekt (BO) auf höchster Ebene - ein 'Kunde'-Objekt. Ein 'Kunde'-Objekt hat folgende Struktur:

Der Beispielnachrichtenfluss

Der in diesem Mustercode verwendete Nachrichtenfluss ruft das EIS mit dem TwineBallRequest-Knoten auf.

Der Mustercode zeigt, wie ein traditionelles System, das Kundendaten in einfachen Datenstrukturen vom Stil C speichert, in ein EIS integriert werden kann, um die beiden Systeme zu synchronisieren. Die vom TwineBall-EIS generierten Antworten können an eine Warteschlange gesendet werden, die im Header der eingehenden Nachricht definiert ist.

Im folgenden Diagramm ist der Beispielnachrichtenfluss 'TwineBall' dargestellt:

Screenshot TwineBall-Nachrichtenfluss

Der TwineBall-Beispielnachrichtenfluss führt folgende Aktionen aus:

  1. Eine Eingabenachricht im CWF-Format (Custom Wire Format) wird in die Warteschlange CREATE eingestellt. Die Eingabenachricht enthält alle erforderlichen Informationen zur Erstellung eines 'Kunde'-Objekts.
  2. Mithilfe eines Zuordnungsknotens wird die Nachricht für die Datenobjektdomäne konvertiert, sodass sie vom TwineBall-EIS verstanden werden kann.
  3. Das neu erstellte Datenobjekt wird anschließend an den TwineBallRequest-Knoten weitergeleitet, der die Standardmethode CREATE verwendet.
  4. Die Antwort auf die CREATE-Operation wird vom TwineBallRequest-Knoten abgerufen und wieder dem CWF-Format zugeordnet.
  5. Anschließend wird diese CWF-Nachricht an die 'ReplyTo'-Warteschlange weitergeleitet, die im Header der ursprünglichen CWF-Nachricht festgelegt wurde.

Der Rückgabewert ist der Primärschlüssel des neuen 'Kunde'-Objekts, gefolgt von einer 4-Byte-Ganzzahl. Diese hat den Wert 1 (bei Erfolg) oder einen Null-Primärschlüssel, gefolgt von einer 4-Byte-Ganzzahl vom Wert 0 (bei einem Fehler).

Die Ausführung des Beispiels umfasst Folgendes:

Der Mustercode bietet Folgendes:

Zurück zum Beginn des Mustercodes