Creating a Logical Port
Use
You configure runtime features for Web Service client proxies using logical ports.
Unlike design-time features, runtime features are features that can be configured when the Web-service client is activated. An example of such a feature is the URL call of the Web service, which, if applicable, must be modified by users.
Design-time features are features that are defined by the application developer during development. These features are shipped together with the Web service client proxy and cannot be changed again by users. In this way, an application developer can, for example, define whether communication between the client and server is to be session-based or not.
A Web service client proxy can be instantiated with or without specifying a logical port. If no logical port is specified, the system uses the default port maintained in transaction LPCONFIG. There can only be one default port for each Web service client proxy. To ensure that calls can still be executed when a logical port is not specified, you should have a default port maintained for each client proxy. Each Web service client proxy can have multiple logical ports.
Prerequisites
You have generated a proxy from a WSDL document.
Procedure
...
1. Call transaction LPCONFIG.
Enter the name of the proxy class and the logical port. If applicable, select the Default Logical Port checkbox. If another port is already defined as the default for this proxy class, this setting for the default port will be reset and the new port becomes the default.
Use the value help for the Logical Port field to display any existing ports for a proxy class. In this case, the Description field documents how the logical port is used. When creating a new port, maintain the port description on the subsequent screen.
2. Choose Create.
On the next screen, default values have already been entered for the configurable runtime features. These default values are taken from the logical port template and other default values.
In the General Settings screen area, you configure the runtime features. These are supported by every SOAP client application that uses the logical port registry. The Application-Specific Settings area refers directly to the respective SOAP client application. This division ensures that further SOAP client applications in subsequent releases can be integrated.
Tab Page under General Settings and Application-Specific Settings
Tab Page: |
Meaning: |
||||||||||||||||
Runtime |
Choose the required runtime environment for instantiating the proxy class. If you select the XI runtime environment, the Call Parameters and Error Handling tab pages are hidden in the General Settings screen since this runtime environment does not support these features. The Application-Specific Settings screen area is also hidden since the XI runtime environment does not provide any specific features. |
||||||||||||||||
Call Parameters |
There are three ways of configuring the call address of the Web service: ● As an HTTP destination: Select an RFC destination of type G (HTTP connection to an external server) or of type H (HTTP connection to an SAP System) from transaction SM59. The HTTP destination approves the configuration of the logon procedure, encryption, and state management. This is the preferred access procedure. ● As a URL: The URL of the Web service is written to the corresponding input field when you create the logical port. The disadvantage of this procedure is that, with the exception of the URL, no other parameters for logging on, encryption, or state management can be configured. This is possible only for Web services that do not require a logon procedure, encryption, or state management. ● As a local path prefix: This access procedure is only intended for accessing your own system. The default RFC destination NONE is called to address your own server. The specified local path prefix is used to identify the called Web service. The Binding Type field displays the URI of the transport mechanism used. Currently, only SOAP through HTTP is used and therefore no entry is required here. In the SOAP Action field, you can specify a value for the SOAP action of the HTTP header. Firewalls and servers can use this value to filter SOAP messages. |
||||||||||||||||
Troubleshooting |
Enter the settings for logging and tracing. Messages from tracing are saved in the RFC developer trace of the SAP system. Logging writes messages to the system log of the SAP system. For tracing purposes, the following values can be chosen:
You can set the following values for logging purposes:
|
||||||||||||||||
XI Receiver |
This tab page is intended for applications that want to assign a logical port to an XI receiver. You can only assign one logical port to an XI receiver. This assignment is required for senders that need to reach an XI receiver by means of point-by-point connection using Web services, where the receiver is known but the logical port is not. Example: An
application has saved a series of XI receivers in Customizing. The sender
application program reads this receiver and writes it to the message (refer to
To send the message to the receiver point-to-point using the Web service infrastructure, you require the corresponding logical port. This is assigned to the XI receiver according to the receiver data on the XI Receiver tab page. Using the
|
||||||||||||||||
Global Settings |
You can activate the message ID log by selecting the Message ID checkbox. The runtime environment then sends a unique message ID every time a message is sent. Selecting the State Management checkbox activates state management by means of HTTP cookies. |
||||||||||||||||
Operations |
The operations of the Web service are displayed. Select an operation and assign security profiles. You can guarantee security at message level using WSS profiles. |
Routing
Refer also to:
Programming with Client and Server Proxies.