Show TOC

Procedure documentationConfiguring Web Service Connectivity to Communication Profiles Locate this document in the navigation structure

 

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.

    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