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:
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:
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.
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.
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.
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:
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:
Business Integration Connect sendet das Dokument an die als Zielgateway angegebene URL-Adresse.
Die HTTP-Anforderungsnachricht enthält zwei Teile:
Jede URL-Adresse entspricht einer aufzurufenden Collaboration. (Informationen dazu finden Sie in Connect Servlet konfigurieren.)
Da das Connect Servlet ein Dokument an InterChange Server nur senden (nicht empfangen) kann, kann es nur an der Ereignisbenachrichtigung mit InterChange Server teilnehmen.
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.
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.
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.
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.
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.
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.
Die Konfiguration des Connect Servlets erfordert die folgenden Schritte:
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
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:
Diese Dateien sind im Unterverzeichnis lib des Produktverzeichnisses von InterChange Server zu finden.
Anmerkungen:
Diese Dateien befinden sich auf dem Installationsdatenträger von Business Integration Connect im folgenden Verzeichnis:
integration/wbi/wics/http/lib/thirdparty
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:
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:
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.
| 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 |
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:
Sie gibt eine ganze Zahl als Anzahl für die in dieser Datei konfigurierten URLs an:
Die zugeordneten Collaboration-Eigenschaften besitzen Eigenschaftsnamen der Form WBIC_URL_zahl_eigenschaftsname. Tabelle 50 zeigt Beispiele dieser Eigenschaften der Form WBIC_URL_zahl_eigenschaftsname. In der Spalte 'Beispiel' dieser Tabelle werden Beispielwerte für die Eigenschaften der Form WBIC_URL_zahl_eigenschaftsname für die erste Collaboration-URL-Adresse (zahl hat den Wert 1).
Tabelle 50. Collaboration-Eigenschaften der Servlet-Eigenschaftendatei
Eigenschaftsname | Beschreibung | Beispiel |
---|---|---|
WBIC_SERVLET_COUNT |
Die Anzahl der in dieser Datei konfigurierten URL-Adressen:
| 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 |
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:
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
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.
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
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.
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:
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:
Sie müssen ein untergeordnetes Metaobjekt mit den Konfigurationsinformationen des Wrapper-Data-Handlers initialisieren.
Sie müssen einen Eintrag in diesem Metaobjekt erstellen, der einem MIME-Typ den Namen des untergeordneten Metaobjekts des Wrapper-Data-Handlers zuordnet.
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.
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.
|
wbic_response_mime |
Der MIME-Typ des Data-Handlers, der vom Wrapper-Data-Handler aufgerufen wird, um die Nutzinformationen der Antwortnachricht zu verarbeiten.
|
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.
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:
Der Attributtyp dieses Attributs ist die Geschäftsobjektdefinition für das untergeordnete Metaobjekt des Wrapper-Data-Handlers (siehe Untergeordnetes Metaobjekt des Wrapper-Data-Handlers erstellen).
Der Attributtyp dieser Attribute ist jeweils das untergeordnete Metaobjekt des zugeordneten Data-Handlers.
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.
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
Weitere Informationen zur Erstellung dieser Geschäftsobjektstruktur finden Sie in Geschäftsobjektdefinitionen für Versionen vor 4.2.2 von ICS über HTTP erstellen.
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.
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.
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.
|
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.
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:
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.
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.
Der HTTP-Protokollhandler ruft den Data-Handler auf, um das Geschäftsobjekt in einen HTTP-Datenstrom umzuwandeln.
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.
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.
Business Integration Connect ist an dieser als Ziel für Business Integration Connect konfigurierten URL-Adresse empfangsbereit.
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.
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 |
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:
connectors/xml
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:
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.
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.
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.
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
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.
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.
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
Weitere Informationen zur Erstellung dieser Geschäftsobjektstruktur finden Sie in 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:
| 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:
| 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 |
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.
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.
|
MimeType | String |
Definiert den Inhaltstyp und das Format der Daten, die an die URL-Adresse übergeben werden.
|
BOPrefix | String |
Dient zur Bestimmung des aufzurufenden Data-Handlers.
|
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. |
Eine vollständige Beschreibung der Struktur dieses Geschäftsobjekts der höchsten Ebene finden Sie im Handbuch Adapter for XML User Guide.
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:
Weitere Informationen finden Sie in Geschäftsobjektdefinitionen zum Senden von Dokumenten erstellen.
Weitere Informationen finden Sie in Geschäftsobjektdefinitionen zum Empfangen von Dokumenten erstellen.
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:
Dieses Attribut liefert Konfigurationsdaten für die Header der Nachricht. Weitere Informationen finden Sie in HTTP-Headerinformationen der Transportebene für InterChange Server-Versionen vor 4.2.2 erstellen.
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) |
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:
Dieser Tag hat folgende Syntax:
wbic_type=reply
Wenn dieser Tag nicht angegeben wird, verwendet der Wrapper-Data-Handler das untergeordnete Metaobjekt, das durch das Attribut wbic_response_mime (im Geschäftsobjekt der höchsten Ebene) angegeben wird, um den für die Antwort zu verwendenden Data-Handler zu bestimmen.
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.
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.
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:
Jeder dieser Schritte wird in den folgenden Abschnitten beschrieben.
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:
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.
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
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.
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:
Der Attributtyp für dieses Attribut ist die Geschäftsobjektdefinition für das dynamische Metaobjekt (siehe Dynamisches HTTP-Metaobjekt erstellen).
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
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.
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 |
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:
Informationen zur Konfiguration Ihres Adapters für XML zur Verwendung mit Business Integration Connect finden Sie in Adapter für XML konfigurieren.
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.