Configuring Web Service Connectivity to Communication Profiles
Use
You use communication profiles that are Web Service connectivity (WS connectivity) enabled to configure SOAP connectivity on multiple Web services or establish a SOAP connection to provider systems. In the WS connectivity profiles, you configure SOAP policies to create secure service endpoints to the deployed Web services. You also use WS connectivity communication profiles to establish a secure communication between the consumer and provider systems over a SOAP protocol.
Procedure
Configuration Options for Communication Profiles
-
On the Authentication area, specify the relevant options.
-
Choose the allowed authentication methods for Web services communication.
The table below outlines the possible authentication methods which you set to a profile.
Option
Description
None
This option sets no authentication.
User Name/Password (Basic)
Authentication with user ID and password in HTTP header.
X.509 Certificate
Authentication with an X.509 certificate using Secure Sockets Layer (SSL).
SAP Logon Ticket
Authentication with SAP authentication assertion ticket in the HTTP header which authenticates the identity of the user.
User Name/Password Doc.Auth.
Authentication with user ID and password in the message header.
SAML Assertion
Authentication with a signed SAML 1.1 assertion in the message header which authenticates the identity of the user.
X.509 Certificate Doc.Auth.
Authentication with an X.509 message certificate in the message header.
-
To enable only secure communication over HTTPS protocol or WS-SecureConversation, choose the Allow Only Secure Communication checkbox.
-
-
On the Reliable Messaging area, set the Web Services Reliable Messaging (WS-RM) settings.
More information: Configuring Web Services Reliable Messaging
The table below lists the available options and explains their meaning.
Option
Description
Lifetime in milliseconds of a sequence
The time for which the WS-RM sequence remains active.
Retransmission interval in milliseconds
The interval at which the Web service client will try to resend each message that has not been acknowledged by the Web service.
Retry Count
The number of attempts a message will be automatically resent in case of delivery failure.
Confirmation Interval
The interval (in milliseconds) at which the Web service has to send acknowledgements to the Web service client. Currently, the Web service sends acknowledgements to every call from the Web service client.
Inactivity Timeout in milliseconds
If the Web service receives no messages within this interval, it considers the sequence terminated due to the lack of activity.
ExponentialBackoff
Exponential backoff sets an algorithm used by the client when it resends messages. If you choose this option, the retransmission interval increases exponentially after each unsuccessful transmission.
-
On the Transport Binding area, specify the transport between the provider side and the consumer side.
The table below lists the available options and explains their meaning.
Option
Description
Use 'Connection: KeepAlive' http header
Enables multiple requests and responses through a single HTTP connection. The provider system keeps the connection alive so that you can use the same connection for multiple request and response cycles.
Support gzip responses
Enables the provider side to return compressed responses to the consumer and, in this way, improves performance. This option is useful when you expect the provider to return responses whose size is several MB. If you want to set this option, the provider system has to support compressed responses (gzip).
Max wait-time for http response
Denotes how long the consumer waits for a response from the provider. If you expect huge load on the provider system that would delay the responses to consumers, increase the default value.
Issue chunked requests
Optimizes the method in which the client communicates to the provider the size of its own requests. If the option is selected, the client communicates the size of the message directly in the stream, and does not write it in memory.
Transport
To use local transport, the following prerequisites must be met:
-
Web service provider and consumer must be deployed on the same physical system.
-
The service endpoint is explicitly configured to receive local calls.
-
The logical port is explicitly configured to send local calls.
You can configure a service endpoint to receive either local calls or HTTP requests. Mixed mode is not supported. However you can create a service endpoint for local transport and a service endpoint for HTTP transport
Security properties of a communication profile are not taken into account when configuration for local calls is created. In case of local calls, the service endpoint is invoked using the same Java thread and context that is opened by the user who calls the consumer proxy.
To configure transport settings, proceed with the following options:
-
local
If only local calls are configured in the communication profile then the system creates a service endpoint for each Web service to which the profile is assigned. The service endpoint is configured to receive only local calls.
If a communication profile that is configured to process only local calls is assigned to a provider system connection and the provider system differs from the client system, then the configuration of logical ports fails. A logical port is created on the consumer side only if a service endpoint configured to receive local calls is available. The created logical port is configured to send local calls.
-
http
If only HTTP calls are allowed in the communication profile then the system creates a service endpoint for each Web service to which the profile is assigned. The created service endpoint is configured to receive HTTP calls and no local calls are enabled.
If a communication profile that is configured to process only HTTP calls is assigned to a provider system connection, then the system creates a logical port only if a service endpoint configured to receive HTTP calls is available. If such an endpoint is not available then the creation of logical port fails. The created logical port is configured to send only HTTP calls.
-
local or http
If both local and HTTP calls are allowed in a communication profile, then a service endpoint is configured to receive local calls and a separate service endpoint is configured to receive HTTP calls.
If a communication profile with both local and HTTP calls is assigned to a provider system connection and the provider system differs from the client system, the option is considered as only HTTP calls. If both local and HTTP calls are allowed in the communication profile then the local call has higher priority. This means that if a service endpoint that is configured to receive local calls is available, then the generated logical port is configured to send local calls. If such a service endpoint is not available then the system searches for a service endpoint that is configured to receive HTTP calls.
-
Proceed with the other tasks of the procedure: Preparing Communication Profiles