Contents

Plain SOAP

Feature description

SAP ABAP web service endpoints can consist of one-way and/or request-response operations. Web service messages for one-way operations are sent asynchronously (i.e. for the sending application in a non-blocking way) and always required the WS-RM standard to be used, either WS-RM 1.0 or WS-RM 1.1.

With the new Plain SOAP feature, one-way messages can also be sent without using WS-RM.

Advantages:

• Enables communication via one-way messages with partner software that does not support WS-RM.
• Less messaging traffic, as technical WS-RM messages (wsrm:CreateSequence, wsrm:TerminateSequence, ...) are avoided
• SAP-proprietary extensions for Qualities of Service (ExactlyOnce, ExactlyOnceInOrder) are aligned with the Plain SOAP Adapter of PI. So interoperability with PI via Plain SOAP keeps the QoS property (with one exception, see below).

Disadvantages:

• No standardized way for Qualities of Service (ExactlyOnce, ExactlyOnceInOrder). WS-RM allows SOAP messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. With Plain SOAP, this is only possible in a proprietary way. In communication with non-SAP software, duplicate message delivery, lost messages or out-of-order processing may happen.

Availability

This feature is offered starting with

• NGAP 1.0
• NetWeaver Release 7.31

and was downported to

• NetWeaver Release 7.00 SP27
• NetWeaver Release 7.01 SP12
• NetWeaver Release 7.02 SP8
• NetWeaver Release 7.10 SP15
• NetWeaver Release 7.11 SP10
• NetWeaver Release 7.30 SP3

Design Time

Service Provider

For operations of a service with profile  “Stateless”, now there are three operation profile values:

• Asynchronous reliable
• Asynchronous
• Synchronous

Request-response operations always have operation profile “Synchronous”. For one-way operations, one of the operation profiles “Asynchronous reliable” or “Asynchronous” is assigned.

Note: In case a service operation is modeled in ESR as "Asynchronous", the corresponding proxy operation in the backend (MDR, se80) has the profile "Asynchronous reliable" assigned. Asynchrnous processing without the reliablity feature (i.e. no guarantee for excatly once processing) is only supported when the service is modeled in the MDR and when the operation profile "Asynchronous" is selected.

WSDL implications

In the WSDL, the difference between “Asynchronous reliable” and “Asynchronous” manifests as value of an operation policy assertion:

Consumer Proxy

Here the same as for Service Providers applies.

Configuration

Provider side

On provider side, there is no configuration option for Plain SOAP. A single provider endpoint can process WS-RM 1.0, WS-RM 1.1 and Plain SOAP messages. It depends on the incoming message, according to which protocol the message is processed.

Consumer side

On consumer side, a service can be configured via soamanager by WSDL or by manual settings.

WSDL-based configuration

As stated above, the provider endpoint is not configured for WS-RM or Plain SOAP, but the endpoint reacts according to the inbound message. So a WSDL will not include information that Plain SOAP shall be used. That´s why a configurator has to select appropriate options as described below for manual configuration also in case of a WSDL-based configuration.

Manual configuration

Whereas the design time model defines, if reliablity shall be used or not, the configuration specifies the protocol, that shall be used at runtime to achieve reliablity for "Asynchronous reliable" operations.

The consumer side configuration (=logical port)  offers tab “Messaging” with section “Reliable Messaging (Asynchronous)” and field “RM Protocol” with the following options:

• WS-RM 2005/02 (= WS-RM 1.0)
• WS-RM 1.1
• SAP RM

Select the value "SAP RM" to use the Plain SOAP protocol. The term "SAP RM" indicates that an SAP proprietary extension to the standard SOAP protocol is used to achieve reliablity.

For message ID transfer, there is section “Message ID (Synchronous)” with field “Message ID Protocol” with the options

• WS-A Message ID (=WS-A 2004/08)
• WS-A Message ID 1.0
• SAP message ID
• Suppress ID transfer

The field “RM Protocol” only affects asynchronous operations.

The field  “Message ID Protocol” affects synchronous operations and also asynchronous operations, if the field “RM protocol” is set to “SAP RM”.

Under options WS-RM 2005/02 and WS-RM 1.1, the message ID is automatically transferred by the WS-Addressing protocol, that is assigned by the WS-RM specifications (WS-A 2004/08 for WS-RM 1.0 / WS-A 1.0 for WS-RM 1.1), no matter what is selected in field “Message ID Transfer (Synchronous)”.

SAP RM corresponds to Plain SOAP for asynchronous operations. Under this option, the message ID is transferred according to the value in field “Message ID Protocol”, with one exception:

In case the operation profile is “Asynchronous reliable”, the transfer of a message ID is required to enable ExactlyOnce processing on provider side, which is essential for reliability. Thus the message ID will be transferred as if “SAP message ID” was selected.

Runtime behavior

The programming model for SAP consumer proxies is not affected. Proxy calls and all WS protocols can be used the same way as with WS-RM configured services. In-order processing is also executed with logical sequences and through bgRFC queues.

In case an operation of a service provider has profile “Asynchronous reliable” assigned, an inbound message must have a message ID included. Otherwise the recognition of duplicates is not possible, and an exception will be thrown.

In case an operation of a service provider has profile “Asynchronous” assigned, an inbound message without WS-RM header is not checked for duplicates, no matter if the message has a message ID included or not. In this case, a message, that is sent mulitple times with the same message ID, will be processed multiple times.

For SAP ABAP to SAP ABAP communication, always make sure that a service provider operation and the according consumer proxy operation have the same operation profile. As a summary, here the consequences of the different combinations:

Interoperability with PI

The extensions for Qualities of Service (ExactlyOnce, ExactlyOnceInOrder) are aligned with the Plain SOAP Adapter of PI, as long as the message ID is transferred either via WS-Addressing or via URL query extension. According to the PI Plain SOAP protocol, the message ID can be specified also as part of the payload. The present SAP ABAP implementation of Plain SOAP is not capable to extract the message ID out of the payload, so ExactlyOnce processing cannot be guaranteed in such a case.

For successful communication between Plain SOAP connectivity on ABAP backend and Plain SOAP Adapter on PI, make PI Directory settings as indicated by the following screen shots. Pay attention to the Conversion Parameters and to the '?' character at the end of the Target URL of the receiver channel.

Currently, there are problems with Exactly Once in Order processing via PI. Do not use Exactly Once in Order at the moment for Plain SOAP scenarios via PI. Once the problems are solved, this lines will be removed.

Sender Channel:

 Note that a value of "Exactly Once in Order" for the field "Quality of Service" opens a field that prompts for a queue name.

Receiver Channel:

Interoperability with 3^rd party products

Interoperability with 3^rd party products according to standards SOAP 1.1. and SOAP 1.2 is supported with a Quality of Service described as Best Effort. As mentioned above, Exactly Once (EO) and Exactly Once in Order (EOIO) can be achieved by SAP proprietary extensions to plain SOAP.

Message ID

In order to achieve EO, a message ID must be transferred to allow for detection of duplicate messages.

The message ID can be transferred the following ways:

• By using the WS Addressing standard (Version 08/2004 or Version WS-A 1.0). In this case, the message ID is transferred as the according SOAP header field.
• By using a SAP proprietary SOAP header for the message ID. Use a SOAP header like this:
  <messageId xmlns="http://www.sap.com/webas/640/soap/features/messageId/">urn:uuid:989c6e5c-2cc1-11ca-a044-08002b1bb4f5</messageId>
  (element name messagId is recommended for all releases, although element name MessageID works also for 7.02, SP level >= 8, for 7.30, SP level >= 3 and for releases >= 7.31) 
• As a field in the query part of the URL, with a field name “MessageId” and a value representing a String UUID (contains the canonical character-array representation of a UUID format, e.g. 989C6E5C-2CC1-11CA-A044-08002B1BB4F5). The URL then looks e.g. like that:
  https://server:port/path/to/myservice?MessageId=989C6E5C-2CC1-11CA-A044-08002B1BB4F5

Queue ID

In order to achieve EOIO, a queue ID (sequence ID) must be transferred to allow for sequencing. The order of the message processing on provider side is defined by the chronological order of the requests. There is no message numbering or staging. A message must only be sent when the predecessor message has been acknowledged by a technical success response (HTTP return code 200 or 202).

The queue ID must be transferred as a field in the query part of the URL, with a field name “QueueId” and a significant string value. The URL then looks e.g. like that:

https://server:port/path/to/myservice?MessageId=989C6E5C-2CC1-11CA-A044-08002B1BB4F5&QueueId=550E8400-E29B-41D4-A716-446655440000

Quality of service 

This implicit determination of the quality of service by checking the presence of a message ID and the presence of a queue ID does not allow to include a message ID only for monitoring reasons, it automatically triggers ExactlyOnce processing when the message ID is present. With note 1661904 (releases 7.02, 7.30, 7.31) resp. the downport (releases 7.0, 7.01, 7.10, 7.11), an explicit URL query part with a field name “QualityOfService” and a significant string value was introduced for an explicit determination of the quality of service. Valid values are "BestEffort", "ExactlyOnce" and "ExactlyOnceInOrder". The URL then looks e.g. like that:

https://server:port/path/to/myservice?MessageId=989C6E5C--2CC1-11CA-A044-08002B1BB4F5&QualityOfService=BestEffort
 

HTTP return code

For one-way operations, WS-I Basic Profile 1.0, R2714 (http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html) prohibts to send a response with a SOAP envelope. WS-I Basic Profile 2.0, R2714 (http://ws-i.org/profiles/basicprofile-2.0-2010-11-09.html) relaxes this restriction, e.g. to allow also in non-addressable scenarios for SOAP faults. Originally, the SAP ABAP provider implementation returned an empty SOAP envelope and an HTTP return code 200 in case of success. To comply not only to Basic Profile 2.0, but also to to Basic Profile 1.0, with note 1676994 (releases 7.02, 7.30, 7.31) resp. the downport (releases 7.0, 7.01, 7.10, 7.11), the default HTTP response was changed to return no HTTP body (thus also no SOAP enevlope) and an HTTP return code 202. To request the old bahvior with an empty SOAP envelope and a HTTP return code 200, a consumer can add a URL query part with a field name “responsecode200” and a field value of ''true'. 
 

The URL then looks e.g. like that:

https://server:port/path/to/myservice?responsecode200='true

Monitoring

Messages that are sent via Plain SOAP are displayed in the PI message monitor and the WS message monitor. The Adapter Type is displayed as “PLAINSOAP”. This Adapter Type can also be used as selection criterion.