5 Ping/Echo ScenariosThe PO/Confirmation scenario describes general steps that have to be performed end-to-end to set up Web services standards-based connectivity. If you want to set up other scenarios, using different security settings for example or you are looking for additional information about scenarios that are not interoperable, refer to the detailed descriptions provided in the following sections. They contain additional information about special settings and refer to the Ping/Echo scenarios that were used for testing between Microsoft and SAP. The first two sections describe what you must do to test specific Ping/Echo scenarios. In the following sections, this chapter provides additional information about security settings, reliability, data types, Message Transmission Optimization Mechanism (MTOM), WS-Addressing and the different WSDL document styles. The WCF test suite includes code for a number of feature areas and scenarios. Feature areas are collections of scenarios and each scenario is typically linked to a particular protocol. You can find the code for these scenarios in the C:\test\wcf\src\suite\XwsInterop folder. Feature areas generally correspond to a folder within the XwsInterop folder and most of them have a Visual Studio solution file associated with them, which makes navigation easier. Implementations of some of these scenarios are shipped with SAP NetWeaver Application Server. Note Code for some of the scenarios is separated from its associated feature areas. If the references to the following scenarios are incomplete, search in the Common folders in the solution. You can use the Svcutil.exe utility or Visual Studio to create a .NET Framework 4 client that interoperates with aparticular SAP service. The ContractOverrides.cs file included in the .NET Framework 4 implementation in the test suite is generally useful to help you create a .NET Framework 4 client, also. Note If you use Visual Studio to create a client, add the service reference by right-clicking the project file in Solution Explorer and then clicking Add Service Reference. The tests included in this section are examples of .NET Framework 4 configurations that are verified to work in the SAP/WCF interoperability environment. Note Some of the test cases listed in this section are not interoperable with the SAP NetWeaver Application Server and you should avoid using them. These scenarios are called out in the section that describes them and Figure 17.
Figure 17 Ping/Echo scenarios listing 5.1 Testing Procedure Template: MicrosoftUse the following procedure as a template to test particular interoperability scenarios between WCF and the SAP NetWeaver application. To use the procedure for other features and scenarios, replace Security.WsSecurity with the feature you want to test and replace UserNameOverTransport with the scenario you want to test. To test interoperability scenarios between Microsoft and SAP
The following sections contain the names of feature areas and associated scenarios for you to test known working interoperability scenarios. All of the scenarios include:
5.2 Testing Procedure Template: SAPThe PingEcho_Scenarios.xlsx Excel spreadsheet provides an overview of all Ping/Echo scenarios that SAP and Microsoft used for interoperability testing. Download the Excel spreadsheet from the following location on SAP Developer NetWork (SDN): http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/301f7062-e043-2d10-cc9b-c3ecf63c50ac The PingEcho_scenarios.xlsx Excel spreadsheet contains the following information:
With this file, you can find the implementation of the Ping/Echo scenarios in the AS ABAP and in the Microsoft project. If SAP provides a service, you have to do the following to test a scenario:
You need this information to access this service from .NET Framework side in the WCF Interop Endpoint Browser (http://NETServer/endpoints). If SAP accesses a service, you have to do the following to test a scenario:
Figure 21 Selecting a Ping/Echo Scenario
Figure 22 Selecting a Ping/Echo scenario In the following sections, you find information about the service definition and consumer proxy required to execute the tests. 5.3 SecurityConfigurationsYou can use the following security features for scenarios between .NET Framework 4 and AS ABAP. Authentication options:
For secure communication between consumer and provider.
5.3.1 Handling Certificates for Encryption and Authentication in AS ABAPFor (signature) and authentication with certificates encryption, the following additional certificates are required.
Note…Do not use these certificates in production scenarios. Refer to the following description to import certificates for production scenarios. To manage certificates in AS ABAP Trust Manager for encryption
To manage certificates in AS ABAP Trust Manager for authentication on message level (and signature)
More information: Trust Manager 5.3.2 Using Authentication with UsernameToken (WSS Usernametoken)UsernameToken is a security token defined in the WS Security standard to transport the user ID and password in a SOAP message. A SOAP:Envelope/SOAP:Header/wsse:Security/wsse:Username element is added to the message, which contains a timestamp, a user ID and a password. For communication security, use either HTTP over SSL or secure the message by symmetric encryption. Enabling HTTP over SSL is already described in the Setting up Security and Trustsection. 5.3.2.1 Settings in AS ABAP ProviderFor performance reasons, using WS-SecureConversation is recommended whenever multiple messages require identical security in a relatively short period. WS-SecureConversation involves some set up overhead but avoids repeated X.509 operations. This particular scenario, however, involves only one message and therefore does not use WS-SecureConversation. In AS ABAP, provide an endpoint to a service in SOA Management (transaction SOAMANAGER): On the Provider Security tab, select the following:
Figure 23 Provider security settings for symmetric message encryption and user ID/password authentication Provide the user ID and password to the consumer. 5.3.2.2 Settings in AS ABAP ConsumerIn SOA Management (transaction SOAMANAGER), on the Service Administration tab page, choose the Single Service Configuration link.
Figure 24 Consumer security settings for symmetric message encryption and user ID/Password authentication 5.3.2.3 SAP Scenario DetailsSAP Provider
SAP Consumer
5.3.2.4 Microsoft Scenario Details
5.3.3 Using Authentication with X.509 Certificate on Message LevelInstead of providing a user ID and password, consumers can authenticate themselves using an X.509 certificate token on message level. Message transport is secured by using symmetric encryption. Optionally you can enable WS-SecureConversation. See the Authentication with UsernameToken (WSS Usernametoken) section for more information about WS-SecureConversation. 5.3.3.1 AS ABAP Provides a ServiceSelect the following options in transaction SOAMANAGER on the Provider Security tab.
Figure 25 Provider security symmetric encryption and X.509 authentication on message level 5.3.3.2 AS ABAP Consumes a ServiceIn transaction SOAMANAGER, type in:
5.3.3.3 SAP Scenario DetailsSAP Provider
SAP Consumer
5.3.3.4 Microsoft Scenario Details
5.3.4 Using Authentication with Issued Token for Single Sign-OnThe following scenarios allow you to enable Single Sign-On of the consumer at the provider. You integrate an external Security Token Service (STS) into your system landscape and use it as a token broker. If the consumer system successfully authenticates at the STS, it gets a security token for authentication at the provider. SAP supports the following SAML-based scenarios:
This scenario was not part of the interoperability tests. 5.3.4.1 AS ABAP Provides a ServiceSome preliminary steps are necessary to enable the scenarios. AS ABAP is the provider: Configuring SSO/STS Scenario SAML Holder-of-key in the Provider System AS ABAP Combine the authentication methods with the transport security on message level using symmetric encryption. Select the following options in SOA Management (transaction SOAMANAGER) on the Provider Security tab.
Figure 26 Provider security settings for SSO scenario 1
Figure 27 Provider security settings for SSO scenario 2 AS ABAP is the consumer: Configuring SSO/STS Scenario SAML Holder-of-key in the Consumer System AS ABAP 5.3.4.2 SAP Scenario DetailsSAP Provider
SAP Consumer
SAP Provider
SAP Consumer
5.3.4.3 Microsoft Scenario DetailsThe WCF Ping/Echo sources and binaries include clients and services for these scenarios. However the STS is available only over the Internet. This STS was implemented using an older version of Microsoft’s Windows Identity Foundation (WIF) product, a WCF extension. That product and later versions used in Microsoft’s Active Directory Federation Services v2 (ADFS v2) product as well as ADFS v2 itself support many configurations that are interoperable with NetWeaver Application Server.
Note This scenario uses the STS endpoint at https://131.107.153.205:8443/trust/UserName. The non-default port 8443 is important because the STS implementation hosted at http://131.107.153.205/trust uses WS-Policy 1.5, which SAP does not support. To review the list of supported protocols for these interoperability scenarios, see the Supported Standards section in this document.
Note This scenario uses the STS endpoint at http://131.107.153.205:8080/trust/X509. The non-default HTTP port 8080 is important because the STS implementation hosted at http://131.107.153.205/trust uses WS-Policy 1.5. To review the list of supported protocols for these interoperability scenarios, see the Supported Standards section of this document. 5.3.5 Further CombinationsYou can combine all security scenarios with Message Transmission Optimization Mechanism (MTOM) and Web Services Reliable Messaging 1.1. When you are using message signature and encryption, on the SAP side you can select Ext. Signature and Header Protection. This activates the function’s signature confirmation, signature encryption, and header encryption of the WS-Security 1.1 standard. If a request contains the signature, the response confirms the contained signature. The signature and signature confirmation are encrypted. An SAP provider encrypts trace and session headers, not the protocol headers provided by for example WS-RM, WS-Addressing, etc. An SAP consumer encrypts headers, if the WSDL document requires it.
Figure 28 Additional external signature and header protection 5.3.5.1 SAP Scenario DetailsSAP Provider
SAP Consumer
5.3.5.2 Microsoft Scenario Details
5.4 Reliability5.4.1 SAP Reliable MessagingInformation about how to implement reliable messaging based on the WS-RM specification in AS ABAP is provided in documentation on the SAP Help Portal: Programming with Sequences SAP Provider
SAP Consumer
5.4.2 Microsoft Reliable Messaging ScenarioThe preceding Business scenario uses the protocols found in this scenario.
5.4.3 SAP Reliable Request-Response PatternsAS ABAP does not support reliable request-response patterns. SAP introduced idempotent service handling instead. Find more information about idempotent services in the Idempotent Service Handling at SAP section. 5.4.4 Microsoft Request-Response, Reliable Messaging Using SOAP 1.2 ScenarioThis service is included as an example of a configuration to avoid. It is not interoperable with SAP clients. The SAP platform does not support a similar service. Note On the SAP NetWeaver platform, all one-way services use reliable messaging and all request-response services do not.
5.4.5 Idempotent Service Handling at SAPAS ABAP does not support reliable request-response communication based on the WS-RM standard. SAP recommends using the idempotent service handling instead.
Figure 29 Potential error situations in synchronous communication Synchronous communication does not guarantee message delivery. If a request or the response to the request is not delivered, the service consumer/client retries to send the request. That could lead to more than one service executions in the service provider system. For many services however, it is crucial that the service is executed reliably once when requested. For example, if a new purchase order is to be created using a service invocation, it is neither acceptable to have no purchase order created nor to have two or more duplicates created. To ensure reliable messaging for synchronous services, SAP provides a protocol on the application layer. All synchronous services that result in a database change have to be idempotent. That means a service call has the same effect irrespective of whether the provider receives the request message once or multiple times. More information: Enterprise Services Index > Technical Concepts > Idempotent Service 5.4.5.1 SAPTo ensure that a service is idempotent, you have to do the following:
The UUID values must be globally recognizable and satisfy the format that is specified, for example, in IETF RFC 4122. If you do not use the element when you call the services, the services do not behave in an idempotent manner. If you use the special ABAP data type XSDUUID_RAW on provider the side, the parser checks for the pattern [0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F ]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12} and when matching removes the dashes and leaves only the characters. If you do not use this data type, you have to handle the UUID on the application layer. At the latest when calling the IDP helper APIs on the provider side, the internal UUID format (char32 like GUID, not case sensitive, without dashes) is required. Note that the GUIDs used internally in ABAP systems do not satisfy the UUID format.
Now, a consumer can safely re-send request messages.
There is a locking mechanism in place in case a message is resent during message processing. The developer on the application layer has then to decide how to handle and resolve this situation. 5.4.5.2 MicrosoftAn application may use the System.Guid class to generate a UUID in the RFC 4122 format. For example the messageHeader() method in default.aspx.cs of the Buyer project in the .NET Framework PO/Confirmation scenario implementation sets the MessageHeader element correctly though Idempotent Service Handling was not used in that scenario. The UUID sub-element contains a value matching the format of an ABAP provider using the XSDUUID_RAW data type it expects. If this value had instead been set as the ID sub-element was, it would match the format of an ABAP application using the internal UUID format it expects. Figure 29 provides a generalization of this approach that may be useful in a .NET Framework service that implements Idempotent Service Handling. If applied to the UUID element in a MessageHeader, the .NET Framework application would accept values in the format described above for the XSDUUID_RAW data type. The guidValue field of the class also provides simple comparisons to lists of executing and past requests that the application should maintain.
Figure 30 UUID validation 5.5 Data Types5.5.1 Base Data Type TestingSAP note 944029 (login required) provides an overview of the elements of the XML schema and Web Services Description Language (WSDL) supported by ABAP proxy generation. Find detailed information and recommendations about how to map XSD elements to ABAP data types in the ABAP workbench (transaction SE 80). Select (Tips&Tricks for Proxy Generation) > Mapping XSD to ABAP Data Types. 5.5.1.1 Requests and Responses that Contain XSD Float, Double, or Decimal Data TypesIf for requests and responses the value for xsd:float (32-bit floating-point numbers), xsd:double (64-bit floating-point), xsd:decimal can be outside the ABAP range, set the ABAP technical type to STRING and implement the mapping to a suitable data type on the application layer. 5.5.1.2 Requests and Responses that Contain XSD Long, unsignedLong, and unsignedInt DatatypesIn AS ABAP during generation xsd_long (64-bit signed integers), xsd:unsignedLong (unsigned integer of 64 bits) and xsd:unsignedInt (unsigned integer of 32 bits) data types are mapped to INT4 for each default. Alternatively, you can select the following:
5.5.1.3 Base Datatype Testing Scenario SAPSAP Provider
SAP Consumer
5.5.1.4 Base DatatypeTesting using .NET Framework 4 XML Formatter and Document Literal Encoding Scenario
Note WS-Policy is not used with this scenario.
5.5.2 Complex Data Type Testing5.5.2.1 Requests and Responses that Contain Arrays Using xsi:nilIn AS ABAP, map arrays that may contain xsi:nil elements, for example empty rows, to xsdany and additionally implement on the application layer how this array must be read. A standard procedure is in place, if fields have xsi:nil elements. More information: Activating Extended XML Handling Additionally, system documentation is available in AS ABAP that describes how you can use extended XML handling. In AS ABAP, go to the ABAP workbench (transaction SE 80) and select > ABAP Proxy Generation > Proxy Programming Model> Scroll down to Protocols and click the Protocols>IF_WSPROTOCOL_PAYLOAD link. 5.5.2.2 Complex Data Type Testing Scenario SAPSAP Provider
SAP Consumer
5.5.2.3 Complex Data Type Testing Scenario Microsoft
Note WS-Policy is not used with this scenario.
5.6 Message Transmission Optimization Mechanism (MTOM)Using MTOM, you can separate binary data from a SOAP message and attach it as an XOP attachment. The attachment is connected to the message by a reference called XOPInclude. Each binary data gets its own attachment. Using MTOM can result in better performance, because the message is smaller and parsing overhead is reduced. 5.6.1 SAPAll SAP providers support XOP optimization, there is no configuration necessary. SAP consumers can choose to use XOP optimization when offered by the provider.
Figure 31 Consumer proxy configuration for optimized XML transfer 5.6.1.1 MTOM with WS-Security 1.0 (Mutual certificate authentication) ScenarioSAP Provider
SAP Consumer
5.6.1.2 One-way reliable messaging using SOAP 1.2, composed with MTOM ScenarioSAP Provider
SAP Consumer
5.6.2 MicrosoftThe Business scenario detailed in this guide uses the protocols found in MTOM feature area. Two scenarios are covered in this section to illustrate different approaches. The MTOM feature area is built using the configuration object model. The ReliableMessaging test is somewhat simpler because it uses a configuration file instead. 5.6.2.1 MTOM with WS-Security 1.0 (Mutual certificate authentication) Scenario
5.6.2.2 One-way reliable messaging using SOAP 1.2, composed with MTOM Scenario
5.7 WS-AddressingWS-Addressing defines a standard mechanism for identifying and exchanging Web services messages between multiple endpoints. 5.7.1 SAPSAP providers do not define wsa:Action in the WSDL. However, you can configure a response action on the provider side. In SOA Management (transaction SOAMANAGER), select a service with an endpoint and go to the Operation specific tab. There you can configure the action for the response message.
Figure 32 Consumer service configuration for setting wsa:Action 5.7.1.1 Request-response WS-Addressing with Anonymous ReplyTo, SOAP 1.2 ScenarioSAP Provider
SAP Consumer
5.7.1.2 One-way WS-Addressing with Anonymous ReplyTo, SOAP 1.2 ScenarioSAP Provider
SAP Consumer
5.7.2 Microsoft5.7.2.1 Request-response WS-Addressing with Anonymous ReplyTo, SOAP 1.2 ScenarioThis example is interoperable between the .NET Framework 4 and SAP NetWeaver platforms.
5.7.2.2 One-way WS-Addressing with Anonymous ReplyTo, SOAP 1.2 ScenarioThis service is included as an example of a configuration to avoid. It is not interoperable with SAP clients. The SAP platform does not support a similar service. Note On the SAP NetWeaver platform, all one-way services use reliable messaging and all request-response services do not.
5.8 WSDLs5.8.1 Support for WSDL Styles: SAPSAP supports WSDL styles document/literal, rpc/literal and document/literal wrapped. You can change the WSDL style by exchanging rpc with document or document_wrapped in the address of the service endpoint.
Figure 33 Generating different document styles in AS ABAP You can also set the document style in SOA Management (transaction SOAMANAGER).
It is the default that SAP generates WSDL document style document/literal and recommends using this style. 5.8.2 Support for WSDL Styles: Microsoft.NET Framework 4 also supports document/literal, rpc/literal, and document/literal wrapped styles. Attributes applied to the service interface such as ServiceContractAttribute determine the message format. WSDL generated for the service matches the chosen format. 5.8.2.1 Runtime WSDL generation.NET Framework 4 adds a new feature that avoids the problems of unreachable endpoint addresses in WCF-generated WSDLs. The default has been to generate the WSDL for a service once, when the service is loaded. This generation uses the fully-qualified hostname – NETServer or NETServer.domain.example.com if the computer is part of a domain. In some cases, other computers may not know this name. Those computers might require the use of an IP address or a separate DNS name. This is a particular problem for Internet-facing services as changing names can cause confusion in many tools reading the WSDL. .NET Framework 4 supports a service behavior that causes the runtime to generate a WSDL for each request, using the hostname in the request for all endpoint addresses. Therefore, if a client can reach a service to request its WSDL, the endpoints listed are also reachable. To enable runtime WSDL generation
<commonBehaviors>
5.8.3 Requests and Responses that Contain Application-Defined HeadersApplication-defined “custom” headers are generally not part of the SAP programming model. The provider system can only support unencrypted technical headers (that are part of the RM protocol) for the SOAP runtime. Only SAP headers (such as trace and session headers) are encrypted. SAP Web service consumers can set custom headers in the header protocol. If custom headers are indicated in a provider WSDL, you can set and encrypt them if this is required. 5.8.3.1 Microsoft Scenario DetailsSAP Web service clients can interoperate with the service in the following configuration. However the SAP platform does not support a similar service.
5.8.3.2 SAP Scenario DetailsSAP Consumer
5.8.4 Request with Empty Body Element5.8.4.1 SAP Scenario DetailsSAP NetWeaver does not support empty SOAP bodies in request and response messages. SAP’s programming model does not support empty bodies, neither on the consumer, nor on the provider. In the ES Repository, it is not possible to model services without a message type for the request message. The SAP runtimes require this request message type (non-empty) in the message body. Adjust the WSDL so that it does not contain an empty body. 5.8.4.2 Microsoft Scenario DetailsThis service is included as an example of a configuration to avoid. It is not interoperable with SAP clients due to the empty Body element. The SAP platform does not support a similar service.
Note This file includes multiple pairs of operations that are distinguished only by their WS-Addressing Action values; one pair of operations has empty Body elements. |
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)