HTTP-Transportprotokoll mit ICS vor Version 4.2.2 verwenden

WebSphere Business Integration Connect kann Dokumente an eine Version vor 4.2.2 von WebSphere InterChange Server (ICS) über das HTTP-Transportprotokoll senden und von einer solchen Version empfangen.

Anmerkungen:

  1. Informationen zum Senden und Empfangen von Dokumenten zwischen WebSphere Business Integration Connect und einer Version 4.2.2 von InterChange Server über das HTTP-Transportprotokoll finden Sie in HTTP-Transportprotokoll mit ICS Version 4.2.2 verwenden.

  2. Wenn Sie SOAP-Dokumente über das HTTP-Transportprotokoll austauschen möchten, lesen Sie SOAP-Dokumente über HTTP/S senden.

Dieser Abschnitt enthält die folgenden Informationen zur Konfiguration einer Version von InterChange Server vor der Version 4.2.2 und den entsprechenden ICS-kompatiblen Komponenten zur Verwendung mit Business Integration Connect über HTTP:

Dokumente an eine Version von ICS vor 4.2.2 über HTTP senden

Dieser Abschnitt enthält die folgenden Informationen zum Senden von Dokumenten von Business Integration Connect an eine Version von ICS vor Version 4.2.2 über das HTTP-Transportprotokoll:

Das Dokument, das von Business Integration Connect an InterChange Server gesendet wird, leitet eine Ereignisbenachrichtigung innerhalb von InterChange Server ein.

Zum Senden erforderliche Komponenten

Business Integration Connect kann Dokumente an die folgenden Versionen von InterChange Server vor Version 4.2.2 über das HTTP-Transportprotokoll senden:

Das Senden eines Dokuments von Business Integration Connect an eine ICS-Version vor Version 4.2.2 über das HTTP-Transportprotokoll setzt voraus, dass diese beiden Komponenten konfiguriert werden. Tabelle 45 fasst diese Konfigurationsschritte zusammen.

Tabelle 45. Konfigurieren von Business Integration Connect und InterChange Server
Komponente Version Weitere Informationen in
WebSphere Business Integration Connect 4.2.2

Für ausgehende Dokumente über das HTTP-Transportprotokoll konfigurieren

Für eingehende Dokumente über das HTTP-Transportprotokoll konfigurieren

WebSphere InterChange Server 4.1.1, 4.2.0, 4.2.1 Artefakte für eine ICS-Version vor 4.2.2 für HTTP erstellen

Zum Senden eines Dokuments an ICS über das HTTP-Transportprotokoll verwenden Sie außerdem die ICS-kompatiblen Komponenten, die in Tabelle 46 aufgeführt sind. Die meisten dieser Komponenten werden als Teil des Release von Business Integration Connect zur Verfügung gestellt.

Tabelle 46. Erforderliche Komponenten zum Senden von Dokumenten an eine ICS-Version vor 4.2.2 über HTTP
Komponente Beschreibung Anmerkungen und Einschränkungen
WebSphere Business Integration Connect Servlet (Connect Servlet)

Dieses Servlet ist ein WebSphere InterChange Server-Zugriffsclient. Ein Zugriffsclient ist ein Prozess, der für InterChange Server (ICS) extern ist und die Ausführung einer Collaboration innerhalb von ICS anfordern kann.

Das Servlet kann mit den Versionen von WebSphere InterChange Server vor Version 4.2.2 verwendet werden.

Anmerkung:
Das Servlet kann nicht mit der Version 4.2.2 von WebSphere InterChange Server verwendet werden.
Wrapper-Data-Handler

Dieser Data-Handler wird vom Connect Servlet aufgerufen, um die HTTP-Nachricht in das entsprechende Datengeschäftsobjekt zu konvertieren. Er ruft wiederum den für Ihre Nachricht geeigneten Data-Handler auf. Wenn zum Beispiel die Nutzinformationen in XML formatiert sind, kann der Wrapper-Data-Handler so konfiguriert werden, dass er den Data-Handler für XML aufruft.

Keine
Ein Payload-Data-Handler Dieser Data-Handler konvertiert die Nutzinformationen (payload) des Dokuments zwischen dem Dokumentformat (in der Regel XML) und der Geschäftsobjektdarstellung. Dieser Data-Handler ist erforderlich und muss den MIME-Typ Ihres Dokuments mit Nutzinformationen unterstützen.
Attachment-Data-Handler

Dieser Data-Handler behandelt Anhangsdokumente für Ihre Dokumentnachricht.

Dieser Data-Handler ist nur für Dokumente mit Anhängen erforderlich.

Anmerkung:
Alle in Tabelle 46 aufgeführten Komponenten sind auf dem Installationsdatenträger von Business Integration Connect enthalten. Informationen zur Position dieser Komponenten finden Sie in Connect Servlet einrichten.

Abbildung 9 zeigt eine Übersicht über das Senden von Dokumenten durch Business Integration Connect an eine Version von ICS vor Version 4.2.2 über das HTTP-Transportprotokoll.

Anmerkung:
Der Wrapper-Data-Handler, der Attachment-Data-Handler und der Payload-Data-Handler werden sämtlich innerhalb von InterChange Server ausgeführt.

Abbildung 9. Nachrichtenfluss von Business Integration Connect an eine Collaboration über das HTTP-Transportprotokoll


Wie Abbildung 9 veranschaulicht, ist das WebSphere Business Integration Connect Servlet die ICS-kompatible Komponente, mit der Business Integration Connect direkt interagiert. Dieses Connect Servlet ist ein Zugriffsclient, d. h. ein für InterChange Server externer Prozess, der die Ausführung einer ICS-Collaboration anfordern kann. Der Zugriffsclient gibt Aufrufe durch eine Anwendungsprogrammierschnittstelle (API) aus, die als Server Access Interface bezeichnet wird, um mit ICS zu interagieren. Diese Aufrufe werden von WebSphere InterChange Server Access, der Komponente in ICS, die Interaktionen mit Zugriffsclients ausführt, empfangen und interpretiert. Das Server Access Interface ruft die Collaborations synchron auf.

Anmerkungen:

  1. Obgleich einige Interaktionen zwischen Business Integration Connect und Back-End-Systemen asynchron sind, ruft Server Access die Collaboration trotzdem synchron auf und wartet, bis die Ausführung der Collaboration abgeschlossen ist.

  2. Weitere detaillierte Informationen zu Zugriffsclients und Server Access finden Sie im Handbuch Access Development Guide der Dokumentation zu WebSphere InterChange Server.

Die folgenden Schritte beschreiben, wie Business Integration Connect an einer Ereignisbenachrichtigung durch Senden eines Dokuments an eine Collaboration innerhalb von ICS über das HTTP-Transportprotokoll teilnimmt:

  1. Business Integration Connect ruft das WebSphere Business Integration Connect Servlet zum Senden des Dokuments an InterChange Server auf.

    Business Integration Connect sendet das Dokument an die als Zielgateway angegebene URL-Adresse.

    Anmerkung:
    Das Connect Servlet kann zum Aufruf mehrerer Collaborations verwendet werden.
  2. Das Connect Servlet erstellt eine Java-Zeichenfolge aus der HTTP-Anforderungsnachricht, die von Business Integration Connect gesendet wird.

    Die HTTP-Anforderungsnachricht enthält zwei Teile:

  3. Das Connect Servlet überprüft die zugehörigen Servlet-Eigenschaftendateien, um die aufzurufende Collaboration sowie das zu verwendende Verb und den MIME-Typ zu ermitteln.

    Jede URL-Adresse entspricht einer aufzurufenden Collaboration. (Informationen dazu finden Sie in Connect Servlet konfigurieren.)

  4. Das Connect Servlet sendet die Java-Zeichenfolge zusammen mit den Informationen aus der Servlet-Eigenschaftendatei mit Hilfe von Aufrufen in Server Access Interface an WebSphere InterChange Server Access.

    Da das Connect Servlet ein Dokument an InterChange Server nur senden (nicht empfangen) kann, kann es nur an der Ereignisbenachrichtigung mit InterChange Server teilnehmen.

    Anmerkung:
    Zur Unterstützung der Anforderungsverarbeitung mit InterChange Server muss Business Integration Connect mit dem WebSphere Business Integration Adapter für XML interagieren. Weitere Informationen finden Sie in Dokumente von einer ICS-Version vor 4.2.2 über HTTP empfangen.
  5. Innerhalb von InterChange Server empfängt WebSphere InterChange Server Access die Java-Zeichenfolge und ruft den Wrapper-Data-Handler auf.

    Die Aufgabe des Wrapper-Data-Handlers besteht darin, die Java-Zeichenfolge in die entsprechende Geschäftsobjektstruktur zu konvertieren. Geschäftsobjekte sind die von InterChange Server erwartete Eingabe.

  6. Der Wrapper-Data-Handler führt die folgenden Schritte zur Konvertierung der Java-Zeichenfolge in die entsprechende Geschäftsobjektstruktur aus:
    1. Er extrahiert die Header und die Nutzinformationen aus der Java-Zeichenfolge.
      Anmerkung:
      Wenn das von Business Integration Connect gesendete Dokument Anhänge enthält, kann der Wrapper-Data-Handler zum Aufrufen des Attachment-Data-Handlers konfiguriert werden. Die Aktionen des Attachment-Data-Handlers sind in Dokumente mit Anhängen verarbeiten beschrieben.
    2. Er überprüft den MIME-Typ der Nutzinformationen und ruft den Data-Handler auf, der für den ermittelten MIME-Typ zur Konvertierung der Nutzinformationen in ein Geschäftsobjekt für Nutzinformationen konfiguriert wurde.
    3. Er erstellt das Geschäftsobjekt für die HTTP-Eigenschaften und das dynamische Geschäftsobjekt.

      Er definiert die HTTP-Header im Geschäftsobjekt für HTTP-Eigenschaften, das ein untergeordnetes Objekt des dynamischen Metaobjekts dieses Geschäftsobjekts für Nutzinformationen ist.

    4. Er erstellt das Geschäftsobjekt der höchsten Ebene und legt das Ereignisgeschäftsobjekt als Anforderungsgeschäftsobjekt fest.

      Der Wrapper-Data-Handler erwartet, dass das Geschäftsobjekt für Nutzinformationen eine hierarchische Struktur besitzt. Informationen zur Struktur dieses Geschäftsobjekts für Nutzinformationen finden Sie in Geschäftsobjektdefinitionen zum Senden von Dokumenten erstellen.

    5. Er gibt das Geschäftsobjekt der höchsten Ebene an Server Access innerhalb von InterChange Server zurück.
  7. Server Access ruft die Collaboration auf und übergibt ihr das Geschäftsobjekt der höchsten Ebene.

    Stellen Sie sicher, dass der Collaboration-Port für das Collaboration-Objekt, das Sie aufrufen, als externer Port konfiguriert ist. Detaillierte Informationen zur Konfiguration von Ports finden Sie in der Dokumentation zu WebSphere InterChange Server.

  8. Die Collaboration wird ausgeführt und gibt das Geschäftsobjekt der höchsten Ebene an den Wrapper-Data-Handler zurück.

    Ob das Antwortgeschäftsobjekt (innerhalb des Geschäftsobjekts der höchsten Ebene) gefüllt ist, hängt vom Typ der Interaktion zwischen InterChange Server und Business Integration Connect wie folgt ab:

    Weitere Informationen finden Sie in Antwortgeschäftsobjekt.

  9. Wenn die Interaktion erfolgreich ausgeführt wird, gibt das Connect Servlet eine Bestätigung HTTP 200 OK an Business Integration Connect zurück.

Connect Servlet konfigurieren

Das WebSphere Business Integration Connect Servlet ist ein Zugriffsclient, der als ein für InterChange Server externer Prozess die Ausführung einer Collaboration innerhalb von InterChange Server anfordern kann. Der Zugriffsclient arbeitet mit Aufrufen aus einer als Server Access Interface bezeichneten Anwendungsprogrammierschnittstelle (API), um mit ICS zu interagieren. Diese Aufrufe werden von WebSphere InterChange Server Access, der Komponente von InterChange Server, die Interaktionen mit Zugriffsclients ausführt, empfangen und interpretiert.

Anmerkung:
Weitere detaillierte Informationen zu Zugriffsclients und Server Access finden Sie im Handbuch Access Development Guide der Dokumentation zu WebSphere InterChange Server.

Die Konfiguration des Connect Servlets erfordert die folgenden Schritte:

Connect Servlet einrichten

Das Connect Servlet, der Wrapper-Data-Handler und die Repository-Datei für den Wrapper-Data-Handler stehen auf dem Installationsdatenträger von Business Integration Connect an den in Tabelle 47 aufgeführten Positionen zur Verfügung.

Tabelle 47. Positionen der Connect Servlet-Komponenten
Komponente Position
Connect Servlet Integration/WBI/WICS/WBICServlet/ bcgwbiservlet.war
Wrapper-Data-Handler Integration/WBI/WICS/WBICServlet/ bcgwbiwrapperdh.jar
Repository-Datei für Wrapper-Data-Handler Integration/WBI/WICS/WBICServlet MO_DataHandler_WBIWrapper.in

Anmerkung:
Wenn Sie beabsichtigen, Dokumente mit Anhängen zu senden, können Sie außerdem den Attachment-Data-Handler und die zugehörige Repository-Datei wie in Attachment-Data-Handler einrichten beschrieben einrichten.

Dieses Servlet kann eine Verbindung zu den WebSphere InterChange Server-Versionen 4.1.1, 4.2.0 und 4.2.1 herstellen. Es kann auf den Plattformen eingerichtet werden, auf denen eine dieser Versionen von InterChange Server unterstützt wird. Darüber hinaus müssen Sie sicherstellen, dass das Server Access Interface auf der verwendeten Plattform unterstützt wird. Eine Liste der Plattformen, auf denen die von Ihnen verwendete ICS-Version unterstützt wird, finden Sie in der Dokumentation zu WebSphere InterChange Server.

Führen Sie die folgenden Schritte aus, um die Komponenten in Tabelle 47 einzurichten:

  1. Richten Sie das Connect Servlet und die zugeordneten Dateien im Webserver entsprechend der Dokumentation zu diesem Webserver ein.
  2. Stellen Sie sicher, dass die folgenden Dateien in der Variablen CLASSPATH für das Connect Servlet enthalten sind:

    Diese Dateien sind im Unterverzeichnis lib des Produktverzeichnisses von InterChange Server zu finden.

    Anmerkungen:

    1. Diese Dateien müssen derselben Version von InterChange Server entstammen, die aufgerufen werden soll.

    2. Diese Dateien müssen für den Web-Container des Connect Servlets in Ihrem Webserver verfügbar sein. Weitere Informationen dazu, wie Sie Dateien für einen Web-Container verfügbar machen, finden Sie in der Dokumentation zu Ihrem Webserver.
  3. Stellen Sie sicher, dass die folgenden Dateien in der Variablen CLASSPATH für das Connect Servlet enthalten sind:

    Diese Dateien befinden sich auf dem Installationsdatenträger von Business Integration Connect im folgenden Verzeichnis:

    integration/wbi/wics/http/lib/thirdparty
     

    Anmerkung:
    Diese Dateien müssen für den Web-Container des Connect Servlets in Ihrem Webserver verfügbar sein. Weitere Informationen dazu, wie Sie Dateien für einen Web-Container verfügbar machen, finden Sie in der Dokumentation zu Ihrem Webserver.
  4. Machen Sie die InterChange Server Interoperable Object Reference-Datei (.ior) auf der Maschine verfügbar, auf der das Connect Servlet eingerichtet ist.

    Wenn sich das Connect Servlet auf einer anderen Maschine als InterChange Server befindet, können Sie eine der folgenden Aktionen ausführen, um die .ior-Datei verfügbar zu machen:

    Anmerkung:
    Darüber hinaus müssen Sie auch die Eigenschaft ICS_IORFILE in der Eigenschaftendatei des Connect Servlets mit der Speicherposition dieser .ior-Datei aktualisieren. Weitere Informationen finden Sie in InterChange Server identifizieren.

Eigenschaften des Connect Servlets definieren

Wie in Dokumente an eine Version von ICS vor 4.2.2 über HTTP senden erwähnt, enthält die Servlet-Eigenschaftendatei Informationen, zum Beispiel den Portnamen und das Verb, die vom WebSphere Business Integration Connect Servlet zum Aufrufen einer Collaboration benötigt werden. Sie müssen diese Servlet-Eigenschaftendatei erstellen, indem Sie Basisinformationen zu WebSphere InterChange Server angeben. Anschließend geben Sie für jede Collaboration, die von dem Servlet aufgerufen werden soll, Informationen über diese Collaboration an.

Dieser Abschnitt enthält die folgenden Informationen zur Definition der Eigenschaften für das Connect Servlet:

Servlet-Eigenschaftendatei erstellen

Eine Servlet-Eigenschaftendatei enthält die in Tabelle 48 aufgeführten Abschnitte.

Tabelle 48. Abschnitte der Servlet-Eigenschaftendatei
Abschnitt der Servlet-Eigenschaftendatei Beschreibung Weitere Informationen in
Basisinformationen Eigenschaften zur Identifizierung der InterChange Server-Instanz InterChange Server identifizieren
Informationen zu Collaborations Eigenschaften zur Angabe jeder einzelnen aufzurufenden Collaboration Aufzurufende Collaborations angeben
Protokollinformationen Eigenschaften zur Konfiguration der Protokollierung des Servlets Position der Servlet-Protokolldatei angeben

InterChange Server identifizieren  Der erste Abschnitt der Eigenschaftendatei des Connect Servlets enthält Basisinformationen zur Identifizierung der InterChange Server-Instanz, mit der Business Integration Connect kommuniziert. Diese ICS-Instanz enthält die Collaboration (bzw. Collaborations), die Business Integration Connect aufrufen muss. In Tabelle 49 sind die Basiseigenschaften der Servlet-Eigenschaftendatei aufgeführt.

Tabelle 49. Basiseigenschaften der Servlet-Eigenschaftendatei
Eigenschaftsname Beschreibung Beispiel
ICS_SERVERNAME Die Hostmaschine, auf der WebSphere InterChange Server aktiv ist. Server1
ICS_VERSION Die Versionsnummer von WebSphere InterChange Server. Mögliche Werte: 4.1.1, 4.2.0 und 4.2.1. 4.2.0
ICS_IORFILE

Der Dateiname der Interoperable Object Reference-Datei (.ior-Datei), die für den Zugriff auf WebSphere InterChange Server Access verwendet wird. Das Beispiel zeigt, wie Sie den Pfad auf einem Windows-System angeben würden.

Anmerkung:
Der Pfad muss in einer Zeile eingegeben werden.
c:/meineiorposition/
Server1ICS.ior
ICS_USERNAME Die Benutzer-ID für die Verbindung zu WebSphere InterChange Server. admin
ICS_PASSWORD Das Kennwort für die Verbindung zu WebSphere InterChange Server. null
ICS_ENCRYPTED_PASSWORD Eine Angabe, ob das Kennwort (ICS_PASSWORD) verschlüsselt ist. Das Servlet setzt dieses Feld auf den Wert true, wenn das Kennwort verschlüsselt ist. false
ICS_DISABLEENCRYPTION Eine Angabe, ob die Kennwortverschlüsselung inaktiviert (true) oder aktiviert (false) ist. Setzen Sie dieses Feld auf den Wert false, wenn Sie verschlüsselte Kennwörter zulassen möchten. true

Anmerkung:
Ein Beispiel für eine Servlet-Eigenschaftendatei, die die in der Spalte 'Beispiel' von Tabelle 49 aufgeführten Werte definiert, finden Sie in Beispiel für eine Servlet-Eigenschaftendatei.

Aufzurufende Collaborations angeben 

Der zweite Abschnitt der Eigenschaftendatei des Connect Servlets enthält Collaboration-Informationen, durch die der Collaboration-URL-Adresse die zugehörigen Collaboration-Eigenschaften zugeordnet werden. Dieser Abschnitt gibt Collaboration-URLs in zwei Teilen wie folgt an:


Tabelle 50. Collaboration-Eigenschaften der Servlet-Eigenschaftendatei
Eigenschaftsname Beschreibung Beispiel
WBIC_SERVLET_COUNT

Die Anzahl der in dieser Datei konfigurierten URL-Adressen:

  • Wenn sie auf 1 gesetzt ist, verarbeitet das Servlet die URL-Adresse und die Eigenschaften für WBIC_URL_1.
  • Wenn sie auf den Wert 2 gesetzt ist, verarbeitet das Servlet die URL-Adressen und die Eigenschaften für WBIC_URL_1 und WBIC_URL_2.

1
WBIC_URL_1 Der Name für die relative URL-Adresse PurchaseOrder
WBIC_URL_1_COLLAB Der Name der Collaboration PurchaseOrderCollab
WBIC_URL_1_PORT Der Portname der Collaboration From
WBIC_URL_1_VERB Das Verb, das von der Collaboration subskribiert wird Create
WBIC_URL_1_WRAPPER_MIME Der MIME-Typ, der vom Wrapper-Data-Handler unterstützt wird. Beachten Sie, dass das Beispiel Kleinbuchstaben verwendet. wbic/wrapper
WBIC_URL_1_CHARENCODE Die für HTTP-Anforderungen zu verwendende Zeichencodierung. Geben Sie eine gültige Java-Zeichencodierung an. UTF-8

Anmerkung:
Ein Beispiel für eine Servlet-Eigenschaftendatei, die die in der Spalte 'Beispiel' von Tabelle 50 aufgeführten Werte definiert, finden Sie in Beispiel für eine Servlet-Eigenschaftendatei.

Der Collaboration-Abschnitt der Servlet-Eigenschaftendatei gibt eine relative URL-Adresse zur Identifizierung der auszuführenden Collaboration an. Zur Ermittlung der Collaboration während der Ausführung kombiniert Connect Servlet die folgenden Einzelinformationen:

Wenn Sie zum Beispiel die in Tabelle 50 gezeigten Werte verwenden würden, müsste das Connect Servlet die URL-Adresse der Collaboration 'PurchaseOrderCollab' ermitteln. Zur Ermittlung dieser URL-Adresse unternimmt das Servlet die folgenden Schritte:

  1. Es ruft die Servlet-URL-Adresse ab, die die Position des Connect Servlet angibt.

    Das Servlet ruft die Servlet-URL-Adresse aus Ihrem Webserver ab. Nehmen Sie zum Beispiel an, dass Sie das Connect Servlet an folgender Position eingerichtet haben:

    http://www.ihrefirma.com/tasks
     
  2. Es hängt an die Servlet-URL-Adresse den Pfad in der Eigenschaft WBIC_URL_zahl an.

    In Tabelle 50 enthält die Eigenschaft WBIC_URL_1 den Wert "PurchaseOrder". Daher würde das Connect Servlet diese Zeichenfolge an die Servlet-URL-Adresse anhängen, um die folgende URL-Adresse für die Collaboration zu erhalten:

    http://www.ihrefirma.com/tasks/PurchaseOrder
     

In den Collaboration-Eigenschaften gibt die Eigenschaft WBIC_URL_1_WRAPPER_MIME den MIME-Typ für den Wrapper-Data-Handler an. Wenn Sie mehr als einen MIME-Typ angeben, benötigen Sie mehrere Metaobjekte. Weitere Informationen finden Sie in Untergeordnetes Metaobjekt des Wrapper-Data-Handlers erstellen.

Position der Servlet-Protokolldatei angeben  Im dritten Abschnitt der Eigenschaftendatei des Connect Servlets geben Sie die Protokolleigenschaften an. Sie geben die Position der Servlet-Protokolldatei in der Eigenschaftendatei an, indem Sie die folgende Anweisung hinzufügen:

log4jappender.RollingFile.File=protokolldateiposition
 

Wie Abbildung 10 zu entnehmen ist, befindet sich die Eigenschaft log4jappender.RollingFile.File in dem Abschnitt der Servlet-Eigenschaftendatei, in dem das Protokoll 'Log4J' konfiguriert wird. Zur Konfiguration des Connect Servlets brauchen Sie nur die Position der Protokolldatei anzugeben, indem Sie die Eigenschaft log4jappender.RollingFile.File definieren. Wenn Sie mit Log4J vertraut sind, können Sie auch andere Log4J-Eigenschaften festlegen.

Beispiel für eine Servlet-Eigenschaftendatei  Abbildung 10 zeigt ein Beispiel der Servlet-Eigenschaftendatei, das die Werte aus der Spalte 'Beispiel' von Tabelle 49 und Tabelle 50 konfiguriert.

Abbildung 10. Beispiel für eine Servlet-Eigenschaftendatei

# Beispiel für Eigenschaftendatei für WebSphere Business Integration
 # Connect Servlet
  ICS_SERVERNAME=Server1
  ICS_VERSION=4.2
  ICS_IORFILE=C:/meineiorposition/Server1InterChangeServer.ior
  ICS_USERNAME=admin
  ICS_PASSWORD=null
  ICS_ENCRYPTED_PASSWORD=false
  ICS_DISABLEENCRYPTION=true
 
# Collaboration-Eigenschaften für eine Collaboration
  WBIC_SERVLET_COUNT=1
 
 WBIC_URL_1=PurchaseOrder
  WBIC_URL_1_COLLAB=PurchaseOrderCollab
  WBIC_URL_1_CHARENCODE=UTF-8
  WBIC_URL_1_PORT=From
  WBIC_URL_1_VERB=Create
  WBIC_URL_1_WRAPPER_MIME=wbic/wrapper
 
#Log4J-Debugging-Eigenschaften
 #Mögliche Kategorien - debug/info/warn/error/fatal
 #Standardkategorie "error". Ausgabe an: stdout und RollingFile
 log4j.rootCategory=debug,RollingFile
 log4j.appender.RollingFile=org.apache.log4j.RollingFileAppender
 
#Protokolldateiname
 log4j.appender.RollingFile.File=D:\\_DEV\\servlet.log
 log4j.appender.RollingFile.MaxFileSize=1000KB
 
#Anzahl zu behaltender Sicherungsdateien
 log4j.appender.RollingFile.MaxBackupIndex=10
 log4j.appender.RollingFile.layout=org.apache.log4j.PatternLayout
 log4j.appender.RollingFile.layout.ConversionPattern=
    %d{yyyy-MM-ddHH:mm:SS} %-5p [%c{1}] - %m%n
 

Außerdem finden Sie ein Beispiel für eine Servlet-Eigenschaftendatei im Verzeichnis SAMPLES auf dem Installationsdatenträger von Business Integration Connect.

Position der Servlet-Eigenschaftendatei angeben

Der Deploymentdeskriptor web.xml des Connect Servlets stellt Initialisierungsparameter für das Servlet bereit. Zur Angabe der Position der Servlet-Eigenschaftendatei definieren Sie den Parameter WBIC_FILENAME in diesem Deploymentdeskriptor. Dieser Parameter gibt den absoluten Pfadnamen der Eigenschaftendatei für das Connect Servlet an.

Wenn die in Abbildung 10 gezeigte Beispieleigenschaftendatei für das Servlet den Namen connectServlet.cfg hätte und sich im Einrichtungsverzeichnis des Connect Servlets (z. B. C:\WBIC\integration) befände, müssten Sie den Parameter WBIC_FILENAME wie folgt definieren:

C:\WBIC\integration\connectServlet.cfg
 

Wrapper-Data-Handler konfigurieren

Der Wrapper-Data-Handler konvertiert ein Dokument aus seinem serialisierten Format (das vom Connect Servlet aus der HTTP-Nachricht erstellt wurde) in sein entsprechendes Geschäftsobjekt. Wenn das Connect Servlet eine Collaboration aufruft, sendet es das serialisierte Format des Dokuments, das ihm von Business Integration Connect gesendet wurde, an InterChange Server. Diese Collaboration-Anforderung wird von WebSphere Server Access innerhalb von InterChange Server empfangen. Wie Abbildung 9 zeigt, ruft Server Access den Wrapper-Data-Handler auf und übergibt ihm das Business Integration Connect-Dokument. Der Data-Handler gibt das entsprechende Geschäftsobjekt für Nutzinformationen zurück.

Führen Sie zur Konfiguration des Wrapper-Data-Handlers die folgenden Schritte aus:

Die Schritte zur Konfiguration des Wrapper-Data-Handlers werden in den folgenden Abschnitten zusammengefasst. Allgemeine Informationen zu Data-Handlern finden Sie im Handbuch Data Handler Guide der Dokumentation zu WebSphere InterChange Server.

Position des Wrapper-Data-Handlers angeben

InterChange Server muss die Speicherposition des Wrapper-Data-Handlers kennen, um ihn während der Ausführung laden zu können. Führen Sie die folgenden Schritte aus, um die Position anzugeben:

  1. Bearbeiten Sie das ICS-Startscript start_server.bat, das sich im Unterverzeichnis bin des Produktverzeichnisses von InterChange Server befindet (auf der Maschine, auf der sich InterChange Server befindet).
  2. Fügen Sie in dieser Datei die JAR-Datei für den Wrapper-Data-Handler bcgwbiwrapperdh.jar der Liste der JAR-Dateien hinzu, die beim Starten von ICS berücksichtigt werden. Für gewöhnlich werden die JAR-Dateien von Data-Handlern der Variablen DATAHANDLER im ICS-Startscript hinzugefügt.
    Anmerkung:
    Wenn Sie den optionalen Attachment-Data-Handler installiert haben, müssen Sie dessen JAR-Datei ebenfalls dem ICS-Startscript hinzufügen. Weitere Informationen finden Sie in Position des Attachment-Data-Handlers angeben.

Konfigurationsgeschäftsobjekte für den Wrapper-Data-Handler erstellen

Zur Ermittlung des aufzurufenden Data-Handlers überprüft Server Access (innerhalb von InterChange Server) das Data-Handler-Metaobjekt der höchsten Ebene MO_Server_DataHandler. Diese Datei befindet sich im folgenden Unterverzeichnis des Produktverzeichnisses von InterChange Server:

repository\edk
 

Dieses Metaobjekt der höchsten Ebene ordnet einen MIME-Typ einem untergeordneten Metaobjekt zu, das wiederum die Konfigurationsinformationen für den Data-Handler enthält. Daher erfordert die Erstellung des Konfigurationsgeschäftsobjekts die folgenden Schritte:

  1. Untergeordnetes Metaobjekt des Wrapper-Data-Handlers erstellen

    Sie müssen ein untergeordnetes Metaobjekt mit den Konfigurationsinformationen des Wrapper-Data-Handlers initialisieren.

  2. Metaobjekt 'MO_Server_DataHandler' bearbeiten

    Sie müssen einen Eintrag in diesem Metaobjekt erstellen, der einem MIME-Typ den Namen des untergeordneten Metaobjekts des Wrapper-Data-Handlers zuordnet.

Untergeordnetes Metaobjekt des Wrapper-Data-Handlers erstellen

Zur Konfiguration des Wrapper-Data-Handlers müssen Sie das zugehörige untergeordnete Metaobjekt erstellen und mit Konfigurationsinformationen initialisieren. Der Data-Handler verwendet die Attribute dieses Metaobjekts, um die zugehörigen Konfigurationsinformationen, einschließlich des Namens der zu instanzierenden DataHandler-Klasse, abzurufen. Zur Erstellung dieses Metaobjekts erstellen Sie eine Geschäftsobjektdefinition, welche die in Tabelle 51 aufgeführten Attribute enthält.

Anmerkung:
Verwenden Sie zur Erstellung dieser Geschäftsobjektdefinition das Tool 'Business Object Designer'.

Tabelle 51. Konfigurationseigenschaften im untergeordneten Metaobjekt für den Wrapper-Data-Handler
Attribut Beschreibung
ClassName

Der Klassenname (erforderlich), der auf die folgende DataHandler-Klasse verweist:

com.ibm.bcg.integration.wbi.datahandlers.
 WBICWrapperDataHandler
 
TopBOPrefix Das Präfix dient zur Bestimmung des Namens des Geschäftsobjekts der höchsten Ebene. Wenn das Anforderungsgeschäftsobjekt, das von dem für die Anforderung konfigurierten Data-Handler zurückgegeben wird, keinen Tag wbic_mainboname in seinen anwendungsspezifischen Informationen auf Geschäftsobjektebene enthält, wird der Name des Objekts der höchsten Ebene gebildet, indem der Wert von TopBOPrefix dem Namen des Anforderungsgeschäftsobjekts hinzugefügt wird.
wbic_request_mime

Der MIME-Typ, der von dem Data-Handler unterstützt wird, den der Wrapper-Data-Handler zur Verarbeitung der Nutzinformationen der Anforderungsnachricht aufruft. Stellen Sie sicher, dass dieser Data-Handler so konfiguriert wurde, dass er von WebSphere InterChange Server Access aufgerufen werden kann. Weitere Informationen finden Sie in Metaobjekt 'MO_Server_DataHandler' bearbeiten.

Anmerkung:
Wenn Ihre Dokumente Anhänge enthalten, sollte der MIME-Typ für diese Konfigurationseigenschaft der MIME-Typ sein, der den Attachment-Data-Handler aufruft. Weitere Informationen finden Sie in Dokumente mit Anhängen verarbeiten.
wbic_response_mime

Der MIME-Typ des Data-Handlers, der vom Wrapper-Data-Handler aufgerufen wird, um die Nutzinformationen der Antwortnachricht zu verarbeiten.

Anmerkung:
Sie müssen die Eigenschaft wbic_response_mime nicht definieren, wenn Business Integration Connect keine Antwort erwartet.

Wichtig:
Um den in Tabelle 51 aufgeführten Attributen einen Wert zuzuordnen, geben Sie den Standardwert (Default Value) für das jeweilige Attribut an. Wenn der Wrapper-Data-Handler zum Beispiel den Delimited-Data-Handler für die Anforderungsnachricht verwenden soll, setzen Sie den Standardwert des Attributs wbic_request_mime auf text/delimited.

Sie können ein untergeordnetes Metaobjekt für jede Instanz des Wrapper-Data-Handlers definieren, die Sie benötigen. Wenn Sie zum Beispiel nur einen Anforderungs-MIME-Typ oder eine Kombination aus Anforderungs- und Antwort-MIME-Typen unterstützen müssen, können Sie ein einziges untergeordnetes Metaobjekt erstellen und die Standardwerte der Attribute wbic_request_mime und wbic_response_mime entsprechend definieren. Wenn Sie jedoch verschiedene Kombinationen aus Anforderungs- und Antwort-MIME-Typen unterstützen müssen, können Sie jeweils ein untergeordnetes Metaobjekt für jede der zu unterstützenden Kombinationen erstellen.

Business Integration Connect stellt die folgende Repository-Datei für InterChange Server zur Verfügung, die ein Beispiel eines untergeordneten Metaobjekts für den Wrapper-Data-Handler enthält:

Produktverzeichnis/Integration/WBI/WICS/WBICServlet/MO_DataHandler_WBICWrapper.in
 

Dabei steht Produktverzeichnis für das Verzeichnis, in dem Ihr Produkt Business Integration Connect installiert ist. Diese Repository-Datei definiert eine einzige Instanz des Wrapper-Data-Handlers, die so konfiguriert ist, dass sie sowohl für Anforderungs- als auch für Antwortgeschäftsobjekte den Delimited-Data-Handler aufruft. Abbildung 11 zeigt das Beispiel eines untergeordneten Metaobjekts mit dem Namen MO_DataHandler_WBICWrapper.

Abbildung 11. Beispiel eines untergeordneten Metaobjekts für einen Wrapper-Data-Handler


Wenn Sie außerdem ein Dokument unterstützen müssen, dessen Anforderungsnachricht in XML ist, erstellen Sie ein zweites untergeordnetes Metaobjekt, das eine zweite Instanz des Wrapper-Data-Handlers darstellt. In diesem untergeordneten Metaobjekt hat der Standardwert des Attributs wbic_request_mime dann den MIME-Typ text/xml.

Metaobjekt 'MO_Server_DataHandler' bearbeiten

WebSphere InterChange Server Access verwendet ein Metaobjekt der höchsten Ebene mit dem Namen MO_Server_DataHandler, um MIME-Typen zuzuordnen, die Zugriffsclients mit Hilfe von Data-Handlern, die Unterstützung für diese MIME-Typen bereitstellen, verarbeiten können. Insbesondere dient dieses Metaobjekt der höchsten Ebene dazu, MIME-Typen untergeordneten Metaobjekten von Data-Handlern zuzuordnen.

Das Metaobjekt MO_Server_DataHandler ist eine Geschäftsobjektdefinition. Um dieses Metaobjekt zu bearbeiten, müssen Sie MO_Server_DataHandler in Business Object Designer öffnen und dem Objekt ein neues Attribut für jede unterstützte Instanz des Wrapper-Data-Handlers hinzufügen. Jede Instanz dieses Data-Handlers ist eine eindeutige Kombination aus Anforderungs- und Antwort-MIME-Typen.

Sie nehmen folgende Änderungen am Metaobjekt MO_Server_DataHandler vor:

Nehmen Sie zum Beispiel an, Sie haben den Wrapper-Data-Handler wie in Abbildung 11 konfiguriert. Abbildung 12 zeigt das Metaobjekt MO_Server_DataHandler mit einem Attribut, das den MIME-Typ wbic_wrapper der Instanz des Wrapper-Data-Handlers zuordnet, die durch das untergeordnete Metaobjekt MO_DataHandler_WBICWrapper konfiguriert wird. Dieses Metaobjekt MO_Server_DataHandler ordnet außerdem die Anforderungs- und Antwort-MIME-Typen (text/delimited) dem untergeordneten Metaobjekt des Delimited-Data-Handlers zu.

Abbildung 12. Zuordnen des MIME-Typs 'wbic_wrapper' zum Wrapper-Data-Handler


Wiederholen Sie diesen Prozess für jede eindeutige Kombination aus Anforderungs- und Antwort-MIME-Typ, die Sie unterstützen müssen, indem Sie ein Attribut im Metaobjekt MO_Server_DataHandler der höchsten Ebene hinzufügen, dessen Attributname der der Instanz des Wrapper-Data-Handlers zugeordnete MIME-Typ ist und dessen Typ der Name des zugeordneten untergeordneten Metaobjekts ist. Stellen Sie darüber hinaus sicher, dass die konfigurierten Anforderungs- und Antwort-MIME-Typen (und ihre untergeordneten Metaobjekte) im Metaobjekt MO_Server_DataHandler vorhanden sind.

Anmerkung:
Wenn Sie den Attachment-Data-Handler zur Verarbeitung von Anhängen in Ihren Business Integration Connect-Dokumenten verwenden, müssen Sie ebenfalls das Metaobjekt MO_Server_DataHandler ändern, um den Attachment-Data-Handler zu unterstützen, wie dies in Attachment-Data-Handler konfigurieren beschrieben ist.

Geschäftsobjektdefinitionen zum Senden von Dokumenten erstellen

Das WebSphere Business Integration Connect Servlet sendet Ihr Dokument in Form eines Geschäftsobjekts für Nutzinformationen (payload) an InterChange Server. Für das Connect Servlet stellt sich das Geschäftsobjekt für Nutzinformationen als Hierarchie von Geschäftsobjekten dar. Der Wrapper-Data-Handler erstellt diese Geschäftsobjekthierarchie, wenn er ein Business Integration Connect-Dokument empfängt. Daher müssen Sie Geschäftsobjektdefinitionen erstellen, die diese Hierarchie darstellen.

Da das Connect Servlet nur an der Ereignisbenachrichtigung mit InterChange Server teilnimmt, werden die Anforderungs- und Antwortattribute des Geschäftsobjekts der höchsten Ebene wie in Tabelle 52 gezeigt interpretiert.

Tabelle 52. Anforderungs- und Antwortgeschäftsobjekte in der Ereignisbenachrichtigung
Attribut Verwendung
Request - Anforderungsgeschäftsobjekt Enthält die Anforderungsnachricht aus Business Integration Connect. Diese Nachricht ist das Ereignis, das die Collaboration auslöst.
Response - Antwortgeschäftsobjekt Enthält die Antwortnachricht, wenn die Interaktion synchron erfolgt.

Weitere Informationen zur Erstellung dieser Geschäftsobjektstruktur finden Sie in Geschäftsobjektdefinitionen für Versionen vor 4.2.2 von ICS über HTTP erstellen.

Dokumente von einer ICS-Version vor 4.2.2 über HTTP empfangen

Dieser Abschnitt enthält die folgenden Informationen zum Empfangen von Dokumenten durch Business Integration Connect von einer InterChange Server-Version vor 4.2.2 über das HTTP-Transportprotokoll:

Das Dokument, das Business Integration Connect von InterChange Server empfängt, wurde durch die Anforderungsverarbeitung innerhalb von InterChange Server initiiert.

Zum Empfangen erforderliche Komponenten

Business Integration Connect kann Dokumente von den folgenden Versionen von InterChange Server vor Version 4.2.2 über das HTTP-Transportprotokoll empfangen:

Das Empfangen eines Dokuments von Business Integration Connect von einer ICS-Version vor Version 4.2.2 über das HTTP-Transportprotokoll setzt voraus, dass diese beiden Komponenten konfiguriert werden. Tabelle 45 fasst diese Konfigurationsschritte zusammen. Zum Empfangen eines Dokuments von InterChange Server über das HTTP-Protokoll verwenden Sie außerdem die ICS-kompatiblen Komponenten, die in Tabelle 53 aufgeführt sind.

Tabelle 53. Erforderliche Komponenten für den Empfang von Dokumenten von einer InterChange Server-Version vor 4.2.2 über HTTP
Komponente Beschreibung Anmerkungen und Einschränkungen

WebSphere Business Integration Adapter für XML

(Adapter für XML)

Dieser Adapter gibt InterChange Server die Möglichkeit, Geschäftsobjekte mit Anwendungen auszutauschen, die Daten in Form von HTTP-Nachrichten empfangen. Der Adapter für XML und Business Integration Connect kommunizieren über eine URL-Adresse.

Der Adapter für XML wird nicht mit Business Integration Connect geliefert. Sie müssen eine Version 3.1.x oder eine höhere Version dieses Adapters verwenden.

Anmerkung:
Der Adapter kann nur mit Version 4.2.2 von WebSphere InterChange Server verwendet werden.
Der HTTP- oder HTTPS-Protokollhandler

Dieser Protokollhandler arbeitet mit dem Adapter für XML zusammen, um Informationsdatenströme an die URL-Adresse zu senden und sie von ihr zu empfangen.

Dieser Protokollhandler wird mit Business Integration Connect zur Verfügung gestellt. Weitere Informationen finden Sie in HTTP-Protokollhandler implementieren.
Ein Payload-Data-Handler Dieser Data-Handler konvertiert die Nutzinformationen (payload) des Dokuments zwischen dem Dokumentformat (in der Regel XML) und der Geschäftsobjektdarstellung. Dieser Data-Handler ist erforderlich und muss den MIME-Typ Ihres Dokuments mit Nutzinformationen unterstützen.
Attachment-Data-Handler Dieser Data-Handler konvertiert Dokumente, die Anhänge enthalten, zwischen ihrem Dokumentformat und ihrer Geschäftsobjektdarstellung. Dieser Data-Handler ist nur erforderlich, wenn Ihre Dokumente Anhänge enthalten. Weitere Informationen finden Sie in Dokumente mit Anhängen verarbeiten.

Abbildung 13 zeigt eine Übersicht über das Empfangen von Dokumenten durch Business Integration Connect von einer Version von InterChange Server vor Version 4.2.2 über das HTTP-Transportprotokoll.

Anmerkung:
Alle Verweise auf den HTTP-Transporthandler sind ebenso auf den HTTPS-Protokollhandler anwendbar.

Abbildung 13. Nachrichtenfluss aus einer Collaboration an Business Integration Connect über das HTTP-Transportprotokoll


Die folgenden Schritte beschreiben, wie Business Integration Connect an einer Anforderungsverarbeitung durch Empfangen eines Dokuments teilnimmt, das durch eine Collaboration innerhalb von InterChange Server initiiert wurde:

  1. Die Collaboration innerhalb von InterChange Server führt einen Serviceaufruf an den Adapter für XML aus, indem sie ein Geschäftsobjekt der höchsten Ebene sendet, das untergeordnete Anforderungs- und Antwortobjekte enthält.

    Das untergeordnete Anforderungsobjekt ('Request') enthält anwendungsspezifische Informationen, die auf ein dynamisches Metaobjekt verweisen, das wiederum die angepassten HTTP-Header enthält, die von Business Integration Connect erwartet werden.

  2. Der Adapter für XML ruft den HTTP-Protokollhandler auf.
  3. Der HTTP-Protokollhandler verwendet einen Data-Handler, um das von der Collaboration gesendete Geschäftsobjekt in einen HTTP-Datenstrom zu konvertieren.

    Der Protokollhandler liest den MIME-Typ und die URL-Adresse aus dem Geschäftsobjekt der höchsten Ebene, um den zu verwendenden Data-Handler und die Adresse des Empfängers zu ermitteln.

  4. Der HTTP-Protokollhandler ruft das erste mit Daten gefüllte Geschäftsobjekt aus dem Geschäftsobjekt der höchsten Ebene ab. Dies ist das Anforderungsgeschäftsobjekt.

    Der HTTP-Protokollhandler ruft den Data-Handler auf, um das Geschäftsobjekt in einen HTTP-Datenstrom umzuwandeln.

    Anmerkung:
    Wenn Ihre Dokumente Anhänge haben, installieren Sie den Attachment-Data-Handler und konfigurieren anschließend den Adapter für XML so, dass er den Attachment-Data-Handler aufruft, um das Anforderungsgeschäftsobjekt in ein Dokument mit Anhängen zu konvertieren. Weitere Informationen finden Sie in Dokumente mit Anhängen verarbeiten.
  5. Der HTTP-Protokollhandler ermittelt aus dem Anforderungsgeschäftsobjekt den Namen des dynamischen Metaobjekts.

    Der HTTP-Protokollhandler durchsucht die anwendungsspezifischen Informationen des Anforderungsgeschäftsobjekts nach dem Tag cw_mo_conn, in dem das Attribut angegeben ist, das dem dynamischen Metaobjekt entspricht. Wenn Sie mit dem Back-End-Integrationspaket für Ihre Dokumente arbeiten, können Sie die angepassten HTTP-Headerinformationen in diesem dynamischen Metaobjekt angeben.

  6. Der HTTP-Protokollhandler durchsucht das dynamische Metaobjekt nach dem Attribut HTTPProperties.

    Wenn dieses Attribut Daten enthält, definiert der Protokollhandler die Header der Transportebene in der Anforderungsnachricht. Innerhalb des Attributs HTTPProperties können Sie außerdem den Standard-HTTP-Header des Inhaltstyps (Content-Type) angeben. Weitere Informationen finden Sie in HTTP-Headerinformationen der Transportebene für ICS Version 4.2.2 erstellen.

  7. Der HTTP-Protokollhandler erstellt einen HTTP-Datenstrom unter Verwendung der vom Data-Handler zurückgegebenen Zeichenfolge. Darüber hinaus legt er alle vorhandenen angepassten Headerinformationen fest, wie sie im dynamischen Metaobjekt definiert sind.
  8. Der HTTP-Protokollhandler sendet die resultierende Anforderungsnachricht als Datenstrom an die angegebene URL-Adresse.

    Business Integration Connect ist an dieser als Ziel für Business Integration Connect konfigurierten URL-Adresse empfangsbereit.

  9. Business Integration Connect antwortet mit einer Nachricht HTTP 200 OK.

    Wenn die Connectoreigenschaft ReturnBusObjResponse (des Adapters für XML) den Wert 'true' hat, erfolgt der Aufruf synchron. Der Protokollhandler konvertiert die Antwortnachricht in ein Antwortgeschäftsobjekt und gibt dieses Objekt an den Adapter für XML zurück. Der Adapter definiert das Geschäftsobjekt im Geschäftsobjekt der höchsten Ebene. Das Geschäftsobjekt der höchsten Ebene wird anschließend an die Collaboration innerhalb von InterChange Server zurückgegeben.

Umgebung für HTTP mit einer ICS-Version vor 4.2.2. einrichten

Da der Empfang von Dokumenten von InterChange Server die Verwendung ICS-kompatibler Komponenten erfordert, müssen Sie die in Tabelle 54 beschriebenen Einrichtungs- und Konfigurationsschritte ausführen. Informationen zur Konfiguration von Business Integration Connect zur Kommunikation mit einer InterChange Server-Version vor 4.2.2 über HTTP finden Sie in Unterstützung für ausgehende Dokumente bereitstellen.

Tabelle 54. Einrichten der Umgebung zum Senden von Dokumenten
Schritt Weitere Informationen in

1. Implementieren Sie den HTTP-Protokollhandler.

HTTP-Protokollhandler implementieren

2. Konfigurieren Sie den WebSphere Business Integration Adapter für XML.

Adapter für XML konfigurieren

Anmerkung:
Wenn Ihre Dokumente Anhänge enthalten, müssen Sie außerdem den Attachment-Data-Handler installieren und konfigurieren, wie dies in Dokumente mit Anhängen verarbeiten beschrieben ist.

HTTP-Protokollhandler implementieren

Business Integration Connect stellt einen angepassten HTTP-Protokollhandler zum Senden und Empfangen von Nachrichten mit Business Integration Connect zur Verfügung. Dieser HTTP-Protokollhandler befindet sich in der folgenden Datei auf dem Installationsdatenträger von Business Integration Connect:

Integration/WBI/WICS/WBICServlet/bcgwbiprotocol.jar
 

Dieser angepasste Protokollhandler kann als Plug-in in den Adapter für XML der Version 3.1.x oder einer höheren Version integriert werden. Eine Liste der unterstützten InterChange Server-Versionen und Plattformen finden Sie im Handbuch Adapter for XML User Guide für die Version des von Ihnen eingesetzten Adapters.

Zur Implementierung des HTTP-Protokollhandlers für den Adapter für XML müssen Sie dem Adapter für XML die Speicherposition des HTTP-Protokollhandlers mitteilen, so dass er ihn während der Ausführung laden kann. Zur Angabe der Speicherposition des HTTP-Protokollhandlers führen Sie folgende Schritte aus:

  1. Bearbeiten Sie das Startscript start_xml.bat für den Adapter für XML, das sich im folgenden Unterverzeichnis des Produktverzeichnisses befindet, in dem Ihre WebSphere Business Integration Adapter installiert sind:
    connectors/xml
     
  2. Fügen Sie in diesem Startscript die JAR-Datei für den angepassten HTTP-Protokollhandler bcgwbiprotocol.jar der Liste der JAR-Dateien in der Variablen CLASSPATH des Adapters für XML hinzu.

Adapter für XML konfigurieren

Der Adapter für XML ist die ICS-kompatible Komponente, die Business Integration Connect den Austausch von Dokumenten mit InterChange Server in Form von HTTP-Nachrichten ermöglicht. Er unterstützt die Interaktion der Anforderungsverarbeitung mit InterChange Server wie folgt:

Anmerkung:
Die Funktion der Ereignisbenachrichtigung dieses Adapters wird nicht verwendet. Verwendet Sie zum Senden von HTTP-Nachrichten von Business Integration Connect an InterChange Server das WebSphere Business Integration Connect Servlet, wie in Dokumente an eine Version von ICS vor 4.2.2 über HTTP senden beschrieben.
Wichtig:
WebSphere Business Integration Connect enthält den WebSphere Business Integration Adapter für XML nicht. Sie müssen dieses Produkt getrennt erwerben und entsprechend den Anweisungen im zugehörigen Handbuch Adapter for XML User Guide installieren. Vergewissern Sie sich anhand der Adapterdokumentation, dass die Version des Adapters mit der von Ihnen verwendeten Version von InterChange Server kompatibel ist.

Wenn Sie den Adapter für XML zur Kommunikation mit InterChange Server konfiguriert haben, führen Sie die in den folgenden Abschnitten beschriebenen Schritte aus, um diesen Adapter zum Empfang von HTTP-Nachrichten aus Business Integration Connect zu konfigurieren.

Payload-Data-Handler angeben

Wie Abbildung 13 zeigt, verwendet der Protokollhandler des Adapters für XML einen Data-Handler, um die von InterChange Server empfangenen Geschäftsobjekte in die entsprechenden HTTP-Datenströme zu konvertieren.

Anmerkung:
Der Data-Handler, der vom Adapter für HTTP aufgerufen wird, konvertiert die Nutzinformationen des Dokuments. Wenn Ihr Dokument in eine XML-Transporthülle gepackt ist (d. h. wenn es Anhänge enthält oder die Umhüllungsmarkierung auf 'Ja' gesetzt ist), konfigurieren Sie den Attachment-Data-Handler als Payload-Data-Handler. Weitere Informationen finden Sie in Dokumente mit Anhängen verarbeiten.

Zur Angabe, welcher Data-Handler zur Konvertierung der Nutzinformationen zu verwenden ist, müssen Sie die in Konvertierung von Geschäftsobjekten aufgeführten Schritte ausführen. Darüber hinaus müssen Sie den Adapter für XML zur Verwendung dieses Payload-Data-Handlers konfigurieren. Definieren Sie in Connector Configurator die Connectorkonfigurationseigenschaft DataHandlerConfigMO, um das Data-Handler-Metaobjekt der höchsten Ebene anzugeben, das vom Adapter für XML zur Identifizierung von Data-Handlern verwendet wird. Stellen Sie sicher, dass der Name des Data-Handler-Metaobjekts der höchsten Ebene in der Liste der unterstützten Geschäftsobjekte für den Adapter enthalten ist.

Paketname des Protokollhandlers konfigurieren

Der Adapter für XML verwendet die Connectorkonfigurationseigenschaft JavaProtocolHandlerPkgs zur Angabe des Namens der Java Protocol Handler-Pakete. Zur Integration mit Business Integration Connect müssen Sie sicherstellen, dass die Eigenschaft JavaProtocolHandlerPkgs auf den Paketnamen für den von Business Integration Connect bereitgestellten HTTP-Protokollhandler gesetzt wird:

com.ibm.bcg.integration.wbi.utils.protocolhandlers
 

Unterstützung für ein Antwortgeschäftsobjekt angeben

Der Adapter für XML verwendet die Connectorkonfigurationseigenschaft ReturnBusObjResponse zur Angabe, ob ein Antwortgeschäftsobjekt zuzurückzugeben ist. Ein Antwortgeschäftsobjekt wird nur zurückgegeben, wenn die Interaktion synchron erfolgt. Standardmäßig ist die Connectorkonfigurationseigenschaft ReturnBusObjResponse auf den Wert 'false' gesetzt. Setzen Sie die Connectorkonfigurationseigenschaft ReturnBusObjResponse auf den Wert 'true', um den Adapter für XML zur Rückgabe eines Antwortgeschäftsobjekts zu konfigurieren.

Anmerkung:
Wenn Business Integration Connect synchrone Interaktionen für das Paket und das Geschäftsprotokoll unterstützt, die vom Community Manager verwendet werden, setzen Sie die Connectorkonfigurationseigenschaft ReturnBusObjResponse auf den Wert true und definieren ein Antwortgeschäftsobjekt in Ihrem Geschäftsobjekt der höchsten Ebene.

Zur Definition von Connectorkonfigurationseigenschaften verwenden Sie das Tool Connector Configurator, das als Komponente des Release für Ihren WebSphere Business Integration Adapter für XML geliefert wird. In Connector Configurator sollte die Eigenschaft ReturnBusObjResponse auf der connectorspezifischen Registerkarte der Connectoreigenschaften angezeigt werden.

Geschäftsobjektdefinitionen zum Empfangen von Dokumenten erstellen

Der WebSphere Business Integration Adapter für XML empfängt Informationen von InterChange Server in Form eines Geschäftsobjekts für Nutzinformationen (payload). Für den Adapter für XML stellt sich das Geschäftsobjekt für Nutzinformationen als Hierarchie von Geschäftsobjekten dar. Der Adapter für XML erstellt diese Geschäftsobjekthierarchie, wenn er ein Business Integration Connect-Dokument empfängt. Daher müssen Sie Geschäftsobjektdefinitionen erstellen, die diese Hierarchie darstellen.

Da der Adapter für XML nur an der Anforderungsverarbeitung mit InterChange Server teilnimmt, werden die Anforderungs- und Antwortattribute des Geschäftsobjekts der höchsten Ebene wie in Tabelle 55 gezeigt interpretiert.

Tabelle 55. Anforderungs- und Antwortgeschäftsobjekte in der Anforderungsverarbeitung
Attribut Verwendung
Request - Anforderungsgeschäftsobjekt Enthält die Anforderungsinformationen von InterChange Server. Der Protokollhandler und der Data-Handler konvertieren diese Informationen und senden sie an die URL-Adresse, an der Business Integration Connect empfangsbereit ist.
Response - Antwortgeschäftsobjekt Enthält die Antwortinformationen aus Business Integration Connect, wenn die Interaktion synchron erfolgt.

Weitere Informationen zur Erstellung dieser Geschäftsobjektstruktur finden Sie in Geschäftsobjektdefinitionen für Versionen vor 4.2.2 von ICS über HTTP erstellen.

Geschäftsobjektdefinitionen für Versionen vor 4.2.2 von ICS über HTTP erstellen

Das Connect Servlet sendet Ihr Dokument in Form eines Geschäftsobjekts für Nutzinformationen (payload) an InterChange Server. Der Adapter für XML empfängt Ihre Nachricht in derselben Form von InterChange Server. Diese beiden Komponenten rufen den Payload-Data-Handler auf, um dieses Geschäftsobjekt wie folgt zu verarbeiten, wenn sie ein Business Integration Connect-Dokument empfangen bzw. senden:

Daher müssen Sie die in Tabelle 56 gezeigten Geschäftsobjektdefinitionen erstellen, um die Struktur des Geschäftsobjekts für Nutzinformationen darzustellen, die der Adapter für XML und das Connect Servlet erwarten.

Tabelle 56. Geschäftsobjektdefinitionen für das HTTP-Transportprotokoll
Bedingung Geschäftsobjektdefinition Weitere Informationen in
Wenn Sie entweder 'Kein Paket' oder 'Back-End-Integrationspaket' für Ihre Dokumente verwenden und Ihre Dokumente keine Anhänge enthalten

Hierarchie der Geschäftsobjekte für das Geschäftsobjekt für Nutzinformationen:

  • Geschäftsobjekt der höchsten Ebene
  • Anforderungsgeschäftsobjekt
  • Antwortgeschäftsobjekt (nur wenn eine Antwort erwartet wird)

Struktur des Geschäftsobjekts für Nutzinformationen für eine Version vor 4.2.2 von ICS über HTTP erstellen
Wenn Sie mit dem Back-End-Integrationspaket für Ihr Dokument arbeiten

Fügen Sie dem Geschäftsobjekt für Nutzinformationen die Geschäftsobjekte hinzu, die die Headerinformationen der Transportebene enthalten:

  • Dynamisches Metaobjekt
  • Geschäftsobjekt für HTTP-Eigenschaften

HTTP-Headerinformationen der Transportebene für InterChange Server-Versionen vor 4.2.2 erstellen
Wenn das Dokument Anhänge enthält ('Back-End-Integrationspaket' ist erforderlich) Sie müssen außerdem zusätzliche Geschäftsobjekte zur Darstellung der Anhänge erstellen. Anhangsbezogene Geschäftsobjektdefinitionen erstellen

Anmerkung:
Wenn Sie Geschäftsobjekte für cXML-Dokumente definieren, lesen Sie Geschäftsobjekte für cXML erstellen.

Struktur des Geschäftsobjekts für Nutzinformationen für eine Version vor 4.2.2 von ICS über HTTP erstellen

Der Wrapper-Data-Handler (zum Senden von Dokumenten) sowie der Adapter für XML und der HTTP-Protokollhandler (zum Empfangen von Dokumenten) erwarten die gleiche Geschäftsobjektstruktur für das Geschäftsobjekt für Nutzinformationen. Diese Geschäftsobjektstruktur besteht aus den folgenden Geschäftsobjekten:

Abbildung 14 zeigt ein Beispiel einer Geschäftsobjektstruktur für die Geschäftsobjektdefinition für Nutzinformationen zur Verwendung mit einer InterChange Server-Version vor 4.2.2 über das HTTP-Transportprotokoll.

Anmerkung:
Eine detaillierte Beschreibung dieser Geschäftsobjektstruktur finden Sie im Handbuch Adapter for XML User Guide.

Abbildung 14. Geschäftsobjektstruktur für das HTTP-Geschäftsobjekt für Nutzinformationen für eine InterChange Server-Version vor 4.2.2


Geschäftsobjekt der höchsten Ebene

Das Geschäftsobjekt der höchsten Ebene ist ein Wrapper für die Anforderungs- und Antwortgeschäftsobjekte. Sie müssen eine Geschäftsobjektdefinition für dieses Geschäftsobjekt erstellen. Tabelle 57 gibt eine Übersicht über die Attribute dieser Geschäftsobjektdefinition der höchsten Ebene.

Tabelle 57. Attribute des Geschäftsobjekts der höchsten Ebene
Attribut Attributtyp Beschreibung
URL String

Zieladresse für die Daten im Geschäftsobjekt.

Wichtig:
Dieses Attribut wird vom Wrapper-Data-Handler nicht verwendet. Es wird jedoch vom Adapter für XML verwendet.
MimeType String

Definiert den Inhaltstyp und das Format der Daten, die an die URL-Adresse übergeben werden.

Wichtig:
Dieses Attribut wird vom Wrapper-Data-Handler nicht verwendet. Es wird jedoch vom Adapter für XML verwendet.
BOPrefix String

Dient zur Bestimmung des aufzurufenden Data-Handlers.

Wichtig:
Dieses Attribut wird vom Wrapper-Data-Handler nicht verwendet.
Response Geschäftsobjekt Das untergeordnete Geschäftsobjekt, das die Antwortnachricht darstellt (wenn Sie eine Antwort erwarten). Der Zweck dieses Geschäftsobjekts hängt davon ab, ob es an einer Anforderungsverarbeitung oder einer Ereignisbenachrichtigung beteiligt ist. Weitere Informationen zur Struktur dieses Geschäftsobjekts finden Sie in Antwortgeschäftsobjekt.
Request Geschäftsobjekt Das untergeordnete Geschäftsobjekt, das die Anforderungsnachricht darstellt. Der Zweck dieses Geschäftsobjekts hängt davon ab, ob es an einer Anforderungsverarbeitung oder einer Ereignisbenachrichtigung beteiligt ist. Weitere Informationen zur Struktur dieses Geschäftsobjekts finden Sie in Anforderungsgeschäftsobjekt.

Anmerkung:
Wenn Sie den Attachment-Data-Handler zur Verarbeitung von Anhängen verwenden, müssen Sie Ihr Anforderungsgeschäftsobjekt zur Aufnahme der Anhänge ändern, wie dies in Anhangsbezogene Geschäftsobjektdefinitionen erstellen beschrieben ist.

Eine vollständige Beschreibung der Struktur dieses Geschäftsobjekts der höchsten Ebene finden Sie im Handbuch Adapter for XML User Guide.

Anforderungsgeschäftsobjekt

Das Anforderungsgeschäftsobjekt enthält die Daten, die an die URL-Adresse zu übergeben sind. Es enthält Attribute für die verschiedenen XML-Tags in der Anforderungsnachricht. Der Zweck dieses Anforderungsgeschäftsobjekts hängt wie folgt davon ab, an welchem InterChange Server-Vorgang es beteiligt ist:

Anmerkung:
Diese Geschäftsobjektstruktur gibt die beiden zugehörigen untergeordneten Geschäftsobjekte als Anforderungs- und Antwortgeschäftsobjekte an. Diese Struktur wird jedoch sowohl bei der Anforderungsverarbeitung als auch bei der Ereignisbenachrichtigung verwendet.

Eine grundsätzliche Beschreibung der Struktur des Anforderungsobjekts finden Sie im Handbuch Adapter for XML User Guide. Zur Verwendung mit Business Integration Connect müssen Sie zwei Anpassungen an der Struktur der Anforderungsgeschäftsobjektdefinition vornehmen:


Tabelle 58. Tags in den anwendungsspezifischen Informationen des Anforderungsgeschäftsobjekts
Tag in den anwendungsspezifischen Informationen Beschreibung Erforderlich?
wbic_mainboname Gibt den Namen des Geschäftsobjekts der höchsten Ebene an. Ja
cw_mo_conn Gibt das dynamische Metaobjekt an, das die Felder für den HTTP-Header auf Transportebene enthält. Weitere Informationen finden Sie in HTTP-Headerinformationen der Transportebene für InterChange Server-Versionen vor 4.2.2 erstellen. Nein (nur erforderlich für Back-End-Integrationspaket)

Antwortgeschäftsobjekt

Das Antwortgeschäftsobjekt enthält die Daten, die von der URL-Adresse zu empfangen sind. Es enthält Attribute für die verschiedenen XML-Tags in der Antwortnachricht. Der Zweck dieses Antwortgeschäftsobjekts hängt wie folgt davon ab, an welchem InterChange Server-Vorgang es beteiligt ist:

Unabhängig davon, ob die Antwort Teil einer Ereignisbenachrichtigung oder einer Anforderungsverarbeitung ist, wird ein Antwortgeschäftsobjekt nur gesendet, wenn der Austausch zwischen Business Integration Connect und InterChange Server synchron erfolgt und eine Geschäftsantwort als Reaktion auf die Anforderung erwartet wird. Wenn dies der Fall ist, müssen Sie die folgenden zusätzlichen Schritte ausführen:

Anmerkung:
Das Antwortgeschäftsobjekt enthält kein Attribut für das dynamische Metaobjekt.

Wenn der Austausch zwischen Business Integration Connect und InterChange Server asynchron erfolgt, erwartet Business Integration Connect keine Antwort, so dass Sie kein Antwortgeschäftsobjekt erstellen müssen.

Geschäftsobjekte für cXML erstellen

Für cXML-Dokumente können Sie den XML Object Discovery Agent (ODA) zur Erstellung des Geschäftsobjekts verwenden. Der XML-ODA kann die cXML-DTD verwenden. Beachten Sie jedoch, dass der XML-ODA das Element ENTITY nicht unterstützt. Daher müssen Sie vor der Ausführung der cXML-DTD mit dem XML-ODA das Element ENTITY aus der DTD entfernen.

Beim Generieren von Geschäftsobjekten mit Hilfe des XML-ODA können Sie den cXML-Tag als Stammelement auswählen. Dies kann jedoch bedeuten, dass das Geschäftsobjekt sehr groß wird, da die gesamte cXML-DTD erfasst wird. Wenn Sie ein kleineres Geschäftsobjekt erstellen möchten, können Sie einen anderen Tag als Stammelement auswählen, was jedoch bedeutet, dass Sie eine angepasste Namensbehandlungsroutine für den Data-Handler für XML schreiben müssen. Der Data-Handler ruft diese Namensbehandlungsroutine zur Auflösung von Objektnamen auf der höchsten Ebene auf. Informationen zum Schreiben angepasster Namensbehandlungsroutinen (Name Handlers) finden Sie in der Dokumentation zum Data-Handler für XML.

HTTP-Headerinformationen der Transportebene für InterChange Server-Versionen vor 4.2.2 erstellen

Wenn Sie Dokumente mit 'Back-End-Integrationspaket' über das HTTP-Transportprotokoll senden, muss Ihr Anforderungsgeschäftsobjekt angepasste Headerinformationen der Transportebene enthalten. Sowohl der Wrapper-Data-Handler als auch der Adapter für XML erwarten, dass sich diese angepassten Headerinformationen in einem dynamischen Metaobjekt befinden.

Abbildung 15 zeigt die Geschäftsobjektstruktur für ein Anforderungsgeschäftsobjekt, das ein Business Integration Connect-Dokument mit 'Back-End-Integrationspaket' zum Senden über das HTTP-Transportprotokoll darstellt.

Abbildung 15. Beziehung zwischen dem Anforderungsgeschäftsobjekt und dem dynamischen HTTP-Metaobjekt


Stellen Sie sicher, dass Ihre Geschäftsobjektstruktur ein dynamisches Metaobjekt enthält, indem Sie die folgenden Schritte ausführen:

  1. Erstellen Sie eine Geschäftsobjektdefinition, die die HTTP-Eigenschaften enthält, die für das Back-End-Integrationspaket erforderlich sind.
  2. Erstellen Sie eine Geschäftsobjektdefinition für das dynamische Metaobjekt.
  3. Ändern Sie die Geschäftsobjektdefinition für Ihr Anforderungsgeschäftsobjekt, so dass sie ein Attribut für das dynamische Metaobjekt enthält.

Jeder dieser Schritte wird in den folgenden Abschnitten beschrieben.

Geschäftsobjekt für HTTP-Eigenschaften erstellen

Ein Geschäftsobjekt für HTTP-Eigenschaften enthält die HTTP-Eigenschaften, die für das Back-End-Integrationspaket erforderlich sind. Es kann außerdem das Attribut Content-Type, das den Content-Type-Header angibt, der in der Anforderungsnachricht einzufügen ist, und das Attribut content-length enthalten, das die Länge der Nachricht in Byte angibt. Die einzelnen gültigen Transportheaderfelder werden in Tabelle 4 beschrieben.

Zur Erstellung der Geschäftsobjektdefinition für HTTP-Eigenschaften führen Sie die folgenden Schritte aus:

  1. Erstellen Sie innerhalb der Geschäftsobjektdefinition ein Attribut für jedes einzelne Transportheaderfeld.

    Alle Attribute müssen den Attributtyp 'String' haben. Sie können das Attribut mit dem exakten Namen der HTTP-Eigenschaft (wie in der Spalte Headerfeld von Tabelle 4 aufgeführt) benennen.

    Anmerkung:
    Die einzige Ausnahme bei den Namen von HTTP-Eigenschaften bildet das Feld für den Inhaltstyp (content-type), dessen Attribut den Namen Content_Type erhalten muss.
  2. Fügen Sie für jedes Attribut im Geschäftsobjekt für HTTP-Eigenschaften anwendungsspezifische Informationen hinzu, um den Zweck des zugeordneten Attributs anzugeben.

    Diese anwendungsspezifischen Informationen auf Attributebene haben folgendes Format:

    name=HTTPeigenschaft
     

    Dabei steht HTTPeigenschaft für einen der Werte in der Spalte Headerfeld von Tabelle 4.

In Abbildung 15 enthält die Geschäftsobjektdefinition HttpProps_BusObj Attribute für die verschiedenen Transportheaderfelder. Diese Attribute haben alle anwendungsspezifische Informationen auf Attributebene zur Angabe des Namens des zugehörigen Protokollheaders. Zum Beispiel sind für das Attribut x-aux-sender-id die anwendungsspezifischen Informationen wie folgt definiert:

name=x-aux-sender-id
 

Dynamisches HTTP-Metaobjekt erstellen

Das dynamische Metaobjekt enthält ein untergeordnetes Geschäftsobjekt mit Konfigurationsdaten für die HTTP-Headerinformationen. Sie müssen sicherstellen, dass Ihre Geschäftsobjektstruktur ein dynamisches Metaobjekt enthält. Die Geschäftsobjektdefinition für das dynamische Metaobjekt muss ein Attribut mit dem Namen HttpProperties enthalten, dessen Attributtyp die Geschäftsobjektdefinition für das Geschäftsobjekt der HTTP-Eigenschaften ist (siehe Geschäftsobjekt für HTTP-Eigenschaften erstellen).

Zum Beispiel enthält die Geschäftsobjektdefinition HttpDynMO_BusObj in Abbildung 15 das Attribut HttpProperties, dessen Attributtyp HttpProps_BusObj ist.

Anforderungsgeschäftsobjektdefinition ändern

Die Anforderungsgeschäftsobjektdefinition stellt die Informationen dar, die von Business Integration Connect angefordert werden. Informationen zur Erstellung des Anforderungsgeschäftsobjekts finden Sie in Anforderungsgeschäftsobjekt. Zum Einfügen des dynamischen Metaobjekts in die Struktur Ihres Geschäftsobjekts für Nutzinformationen müssen Sie die folgenden Änderungen an Ihrer Anforderungsgeschäftsobjektdefinition vornehmen:

  1. Fügen Sie Ihrer Anforderungsgeschäftsobjektdefinition ein Attribut hinzu, in dem Ihr untergeordnetes dynamisches Metaobjekt enthalten ist.

    Der Attributtyp für dieses Attribut ist die Geschäftsobjektdefinition für das dynamische Metaobjekt (siehe Dynamisches HTTP-Metaobjekt erstellen).

  2. Fügen Sie den anwendungsspezifischen Informationen auf Geschäftsobjektebene Ihrer Anforderungsgeschäftsobjektdefinition den Tag cw_mo_conn hinzu, um das Attribut anzugeben, in dem das dynamische Metaobjekt enthalten ist.

    Der Tag cw_mo_conn hat folgendes Format:

    cw_mo_conn=dynamischesMetaObjAttr
     

    Dabei ist dynamischesMetaObjAttr der Name des Attributs in dem Anforderungsgeschäftsobjekt, in dem das dynamische Metaobjekt enthalten ist.

In Abbildung 15 wurde der Anforderungsgeschäftsobjektdefinition WBIC_HttpRequest_BusObj zum Beispiel ein Attribut mit dem Namen HttpDynMO hinzugefügt. Dieses Attribut enthält das dynamische Metaobjekt, das ein untergeordnetes Geschäftsobjekt des Typs HttpDynMO_BusObj ist. Darüber hinaus wurden die anwendungsspezifischen Informationen des Anforderungsgeschäftsobjekts modifiziert, um den folgenden Tag cw_mo_conn zur Angabe dieses dynamischen Metaobjekts einzufügen:

cw_mo_conn=HttpDynMO
 

Artefakte für eine ICS-Version vor 4.2.2 für HTTP erstellen

Zur Konfiguration einer InterChange Server-Version vor 4.2.2 zur Kommunikation mit Business Integration Connect über das HTTP-Transportprotokoll müssen Sie die in Tabelle 59 aufgeführten InterChange Server-Artefakte erstellen.

Tabelle 59. Artefakte für die Kommunikation mit einer ICS-Version vor 4.2.2 über das HTTP-Transportprotokoll
ICS-Artefakt Zweck Weitere Informationen in
Geschäftsobjektdefinitionen Stellen das Dokument dar. Geschäftsobjektdefinitionen für Versionen vor 4.2.2 von ICS über HTTP erstellen
Connectorobjekt (nur für Anforderungsverarbeitung erforderlich) Stellt den Adapter für XML während der Ausführung dar. XML-Connectorobjekt erstellen
Collaboration-Schablone und Collaboration-Objekt Stellen den Geschäftsprozess dar, der von InterChange Server zur Verarbeitung des Dokuments verwendet wird. Collaborations zur Kommunikation mit dem Adapter für XML binden

XML-Connectorobjekt erstellen

Zur Unterstützung der Anforderungsverarbeitung mit einer InterChange Server-Version vor 4.2.2 über das HTTP-Transportprotokoll verwenden Sie den Adapter für XML zum Senden eines Dokuments an InterChange Server. Zum Aufruf einer Instanz des Adapters für XML während der Ausführung führen Sie im Tool 'System Manager' die folgenden Schritte aus:

  1. Erstellen Sie die Connectorobjekte:
  2. Konfigurieren Sie die Connectorobjekte.

    Informationen zur Konfiguration Ihres Adapters für XML zur Verwendung mit Business Integration Connect finden Sie in Adapter für XML konfigurieren.

Collaborations zur Kommunikation mit dem Adapter für XML binden

Wie in Collaborations erstellen beschrieben, muss ein Collaboration-Objekt während der Ausführung vorhanden sein, damit InterChange Server ermitteln kann, wo Geschäftsobjekte zu empfangen sind und wohin Geschäftsobjekte zu senden sind. Wenn Sie das Collaboration-Objekt für die Collaboration erstellen, die Informationen an Business Integration Connect sendet, binden Sie die zugehörigen Ports. Für die Anforderungsverarbeitung setzen Sie den Empfänger-Collaboration-Port ('To'), der den Adapter für XML zum Senden von Anforderungen an Business Integration Connect verwendet, auf das Connectorobjekt, das Sie für den Adapter für XML erstellt haben. Das heißt, der Adapter für XML ist der Zieladapter.

Copyright IBM Corp. 1997, 2004