Consumer-Proxy konfigurieren

Sie müssen einen oder mehrere logische Ports anlegen und konfigurieren, um Consumer-Proxys für den Zugriff auf einen bestimmten Service zu konfigurieren.

Ein logischer Port wird für einen bestimmten Consumer-Proxy angelegt, um den Zugriff auf ein bestimmtes Binding im Provider-System zu ermöglichen. Sie können mehrere logische Ports für einen Consumer-Proxy anlegen. Jeder logische Port kann jedoch nur auf ein Binding zeigen.

Sie haben zwei Möglichkeiten, einen logischen Port anzulegen:

Sie können einen logischen Port mit Hilfe eines WSDL-Dokuments oder manuell anlegen. Je nachdem, für welche Möglichkeit Sie sich entscheiden, benötigen Sie die folgenden Informationen:

Verfahren zum Anlegen logischer Ports	Was Sie wissen müssen
Basierend auf dem WSDL-Dokument für einen Service	Die URL, die auf das WSDL-Dokument für den Service zeigt Dies ist die URL für das Binding, das für den Web-Service-Provider generiert wurde. Die Zugriffsparameter für das WSDL-Dokument (alternativ haben Sie das WSDL-Dokument als Datei abgelegt)
Manuell (wenn kein WSDL-Dokument verfügbar ist)	Die URL des Binding die Konfigurationseinstellungen, die der Provider erwartet

Vorgehensweise

Logischen Port anlegen

Wechseln Sie im Einstiegsbild von SOA-Manager auf die Registerkarte Service-Administration.
Wählen Sie Web-Service-Konfiguration.
Geben Sie ein Consumer-Proxy an oder suchen Sie nach einem.
Weitere Informationen:

Consumer-Proxy generieren
Markieren Sie das Consumer-Proxy in der Übersicht und wählen Sie Auswahl übernehmen, um Designzeit-Informationen über den Consumer-Proxy anzuzeigen.
Wechseln Sie auf die Registerkarte Konfigurationen.
Um einen neuen logischen Port anzulegen, wählen Sie Anlegen.
Sie gelangen auf ein Dialogfenster.
Geben Sie einen Namen für den neuen logischen Port an.
Sie können diesen logischen Port als Standard einstellen, indem Sie die Einstellung Logischer Port ist Standard setzen. Wenn eine Consumer-Anwendung nicht für den Aufruf eines bestimmten logischen Ports konfiguriert ist, ruft sie den logischen Standardport auf.

Wählen Sie den Konfigurationstyp.

WSDL-basierte Konfiguration

Das System holt die Binding-URL aus dem WSDL-Dokument für den Service.

Geben Sie die WSDL-Zugriffseinstellungen an. Folgende Möglichkeiten stehen Ihnen zur Verfügung:

Via HTTP-Zugriff
Geben Sie den Pfad zum WSDL-Dokument sowie Benutzer und Kennwort ein.
Via Datei
Geben Sie eine Datei für den WSDL-Zugriff an.

Manuelle Konfiguration

Das System verwendet eine vom Benutzer angegebene Binding-URL, um einen logischen Port anzulegen. Sie müssen einen eindeutigen Namen für den logischen Port angeben.

Process-Integration-Laufzeit

Ein Proxy wird auf einem Integration Server aufgerufen, auf dem SAP NetWeaver XI 3.0. läuft. (Der Integration Server muss zuvor konfiguriert worden sein.)

Hier können keine Werte konfiguriert werden.

Wählen Sie Einstellungen übernehmen.
Die Standardeinstellungen für den logischen Port werden angezeigt. Im nächsten Schritt können Sie die Einstellungen ändern.

Prüfen Sie die Konfiguration.

Die folgenden Konfigurationsoptionen stehen zur Verfügung:

Consumer-Sicherheit	Benutzer und Kennwort für die Authentifizierung beim Service-Provider
Einstellungen des Event-Providers	Diese Registerkarte zeigt eine Übersicht der Operationen und Messages für den Proxy an. Operationen für speziell angelegte Ereignis-Proxys können service-fähig sein, damit Anwendungen in einer Landschaft miteinander über Geschäftsereignisse kommunizieren können. Um ein Ereignis für eine Operation zu aktivieren, wählen Sie Event aktivieren. Wird danach ein Ereignis ausgelöst und eine Message gesendet, so erkennt das Proxy diese Message. Ist ein Ereignis nicht für eine Operation aktiviert, ignoriert das Proxy solche Messages. Hinweis Diese Registerkarte wird nur angezeigt, wenn Sie mit einem Ereignis-Proxy arbeiten. Mit SOA-Manager werden Ereignis-Proxys auf dieselbe Art wie Consumer-Proxys konfiguriert. Weitere Informationen: Event Enabling for Communication Across Systems in Distributed Landscapes Ende des Hinweises.
Message-Austausch	Reliable Messaging (asynchron) Geben Sie das Protokoll für zuverlässigen Message-Austausch an. WS-RM 2005/02 (WS-RM 1.0) WS-RM 1.1 SAP RM Wenn nur 1 Protokoll unterstützt wird, ist das Protokoll voreingestellt. Wenn keine Protokolle unterstützt werden, ist das Feld leer. Beachten Sie: Wenn Sie WS-RM 2005/02 (WSRM 1.0) oder WS-RM 1.1 als Message-Protokoll verwenden, wird die Message-ID automatisch von dem WS-Addressing-Protokoll übergeben, das in den WS-RM-Spezifikationen zugeordnet ist (WS-A 2004/08 für WS-RM 1.0 / WS-A 1.0 für WS-RM 1.1). Dabei spielt es keine Rolle, welches Message-ID-Protokoll Sie auswählen. Wenn Sie SAP RM wählen, wird die Message-ID entsprechend des Message-ID-Protokolls übertragen, mit einer Ausnahme: Wenn das Operationsprofil Asynchron zuverlässig ist, muss die Message-ID übertragen werden, um die ExactlyOnce-Verarbeitung auf der Provider-Seite zu aktivieren. Die Message-ID wird daher so übertragen, als ob SAP-Message-ID ausgewählt wäre. Message-ID (synchron) Beachten Sie: Wenn das Feld RM-Protokoll auf SAP RM steht, wirkt sich das Message-ID-Protokoll auf synchrone und asynchrone Operationen aus. Jede Message benötigt eine ID für zwei Protokolle: WS-A-Message-ID und SAP-Message-ID. Hinweis Achten Sie darauf, dass eine Operation mit dem Profil "Asynchron" auf der Consumer-Seite nicht so konfiguriert ist, dass sie eine Operation mit dem Profil "Asynchron zuverlässig" auf der Provider-Seite konsumiert. Im umgekehrten Fall würde die Message erfolgreich verarbeitet, aber entsprechend der Einstellungen auf Provider-Seite auf nicht zuverlässige Art. Ende des Hinweises. Statistik von Service-Aufrufen Bestimmen Sie das übertragene Datenvolumen und das Protokoll zur Übertragung der Statistikdaten. Mit der Service-Aufrufstatistik können SAP-NetWeaver-Komponenten, die am Konsumieren und Anbieten von Web-Services beteiligt sind, Informationen darüber sammeln, welche Consumer-Komponenten welche Web-Services konsumieren. Die Informationen, die in den SOA-Backend-Systemen gesammelt werden, können von SAP EarlyWatch gelesen und analysiert werden, um SOA-Szenarien und Enterprise Services zu optimieren. Folgende Optionen ermitteln, von welchen Feldern Daten übertragen werden: Minimaler Datentransfer Die Consumer-Anwendung schickt nur `Calling Application Type` an den Provider. Standard-Datentransfer Die Consumer-Anwendung schickt `Calling Application Type`, `Calling Component` und `Calling Application ID` an den Provider. Erweiterter Datentransfer Die Consumer-Anwendung schickt alle Informationsattribute des Aufrufers an den Provider, außer `Calling User Code`. Achtung Wenn Sie die Ebene der Service-Aufrufstatistik erhöhen, kann dies Sicherheitsrisiken mit sich bringen. Wenn Sie festlegen, wie viele Informationen in der Service-Aufrufstatistik bereitgestellt werden, sollten Sie also die Vertrauenswürdigkeit des Web-Service-Providers bedenken. Ende der Warnung. Hinweis Informationen zur Service-Aufrufstatistik werden auf Provider-Seite momentan nicht verwendet. Ende des Hinweises.
Transporteinstellungen	Einstellungen für den Transport zwischen Provider und Consumer. Die Einstellungen hier werden zusammen in der vollständigen URL abgelegt. Lokalen Aufruf ausführen: Ein lokaler Aufruf wird nur ausgeführt, wenn die Verarbeitung innerhalb des gleichen Provider-Systems vorgenommen wird. Wenn nur lokale Aufrufe ausgeführt werden, können unnötige Schritte wie die Authentifizierung ausgelassen werden. Maximale Wartezeit für WS-Consumer: Der HTTP-Timeout legt fest, wie lange der Consumer auf eine Antwort vom Provider wartet. Wenn Sie eine hohe Systemlast auf dem Provider-System erwarten, die die Antworten an Consumer verzögert, so ziehen Sie eine Erhöhung der Standardwerte in Betracht. 0 Sekunden steht für keinerlei Begrenzung. Optimierter XML-Transfer: Legt den XML-Transfer zwischen Consumer und Provider fest. Wenn es sich sowohl beim Consumer als auch beim Provider um ABAP-Systeme handelt, können Sie binäres XML auswählen, um den Konvertierungsaufwand dieser Systeme zu reduzieren. HTTP-Message komprimieren: Ermöglicht dem Consumer, ZIP-komprimierte Requests zu senden. Diese Option ist nur dann interessant, wenn Sie sehr große Messages erwarten. Bei normalen Message-Größen, wäre die Komprimierung zu zeitaufwändig, um sich günstig auszuwirken. Response komprimieren: Ermöglicht dem Provider, ZIP-komprimierte Antworten an den Consumer zurückzugeben. Diese Option ist dann nützlich, wenn Sie erwarten, dass der Provider Datenvolumen von mehreren Megabyte zurückgeben wird.
Operationsspezifisch	Transport-Binding Geben Sie eine SOAP-Aktion an. Transportsicherheit Sind die entsprechenden Transportsicherheitsoptionen im WSDL-Dokument definiert, auf dem der logische Port basiert, wird die zulässige Anzahl der signierten und verschlüsselten Message-Elemente angezeigt. WS-Addressing Geben Sie das Protokoll für die Web-Service-Adressierung an. Die Angabe eines Referenzparameters ist optional. Wenn nur 1 Protokoll unterstützt wird, ist das Protokoll voreingestellt. Wenn keine Protokolle unterstützt werden, ist das Feld leer.

Sichern Sie.
Der Consumer-Proxy wird generiert und konfiguriert.

Logischen Port bearbeiten

Wechseln Sie auf die Registerkarte Service-Administration und wählen Sie Web-Service-Konfiguration.
Geben Sie einen Consumer-Proxy an.
Markieren Sie den Consumer-Proxy und wählen Sie Auswahl übernehmen, um weitere Designzeit-Informationen anzuzeigen.
Um einen logischen Port zu bearbeiten, markieren Sie diesen und wählen Sie Bearbeiten.
Nehmen Sie die gewünschten Einstellungen vor.
Weitere Informationen: Logischen Port anlegen (oben).
Sichern Sie.

Weitere Informationen

Consumer-Proxy generieren

Fallback-Konfiguration anlegen

Web Services Reliable Messaging