standards-based_interoperability_between_sap_netweaver_and_microsoft.net_framework.pdf
TRANSCRIPT
1
Standards-Based Interoperability between SAP
NetWeaver and Microsoft .NET Framework
Summary
This document provides .NET Framework and SAP NetWeaver developers with information about how to set up standards-based Web services communication between Microsoft .NET Framework applications and SAP Application Server ABAP-based consumers and providers.
Interoperability scenarios for setting up reliable and secure end-to-end communication are also described.
This document describes ABAP implementations delivered together with the SAP NetWeaver Application Server and .NET Framework implementations available for download. The purchase order/confirmation service (PO/Confirmation) simulates the request from a purchaser to a sup-plier to deliver a specified quantity of goods. The supplier sends back a purchase order confir-mation.
Additional descriptions refer to technical services that SAP and Microsoft used for testing. These are the Ping/Echo scenarios.
Authors
Annemarie Kiefer, Solution Manager for SOA&BPM, SAP AG
Douglas R. Bunting, Senior Program Manager, Microsoft Corporation
Applies to
Microsoft: o Microsoft .NET Framework 3.5 and 4 o Microsoft Visual Studio 2008 and 2010
SAP: o Application Server ABAP 7.0, enhancement package 2
o Enterprise Services Repository (ES Repository), delivered with SAP NetWeaver Composition Environment (CE) 7.2
Keywords
Interoperability, SOAP, Web services, Standards, SAP Application Server ABAP (Advanced Business Application Programming), Microsoft .NET Framework
Collaboration Technology Support Center – Microsoft – Collaboration Brief
May 2010
2
Level of difficulty
Developers, Technical Consultants, Solution Architects
For the latest information, please visit http://www.microsoft.com/sap or http://www.sdn.sap.com/irj/sdn/dotnet
3
This document is provided to you by the Collaboration Technology Support Center Microsoft, a joint team from SAP and Microsoft that drives interoperability. For feedback or questions you can contact the CTSC at the following fo-rums:
SAP: sdn.sap.com -> SAP NetWeaver .NET Framework Technologies, or
Microsoft: blogs.msdn.com/saptech .
Please check the .NET Framework interoperability area in the SAP Developer Network (http://sdn.sap.com) or SAP interoperability section at the Microsoft SAP customer information center (http://www.microsoft.com/isv/sap) for any updates or further information. This document is a common publication by SAP and Microsoft (“Co-Editors”) who have both contributed to its content and retain respective rights therein. The information contained in this document represents the current view of the Co-Editors on the issues discussed as of the date of publication. Because the Co-Editors must respond to changing market conditions, it should not be in-terpreted to be a commitment on the part of the Co-Editors, and the Co-Editors cannot guarantee the accuracy of any information presented after the date of publication. Please note that this document is subject to change and may be changed by the Co-Editors at any time without notice. This document is for informational purposes only. NEITHER OF THE CO-EDITORS MAKES ANY WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copy-right, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of the Co-Editors. Either Co-Editor may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from the respective Co-Editor(s), the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, any example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred. © 2010 Microsoft Corporation. All rights reserved. © 2010 SAP AG. All rights reserved. Microsoft, Windows, and other Microsoft products and services mentioned herein, as well as their respective logos, are trademarks or registered trademarks of Microsoft Corporation. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelli-gence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP France in the United States and in other countries.
4
Contents
1 Introduction ................................................................................................ 8
1.1 SAP NetWeaver Application Server ABAP and Enterprise Services Repository ....8
1.2 Microsoft .NET Framework 4 .........................................................................................9
1.3 Supported Standards .....................................................................................................9
1.4 Message Exchange Patterns ...................................................................................... 11
2 Demonstration Scenarios Overview ....................................................... 11
2.1 General Remarks ......................................................................................................... 11
2.2 PO/Confirmation Scenario .......................................................................................... 12
2.3 Ping/Echo Scenarios ................................................................................................... 13
2.4 Demonstration Scenarios Delivery ............................................................................ 13
2.4.1 SAP ........................................................................................................................ 13
2.4.2 Microsoft ................................................................................................................ 14
3 Demonstration Scenario Installation and Set up ................................... 14
3.1 Installation and Technical Configuration .................................................................. 14
3.1.1 SAP ........................................................................................................................ 14
3.1.2 Microsoft ................................................................................................................ 14
3.2 Setting up Security and Trust .................................................................................... 19
3.2.1 SAP ........................................................................................................................ 19
3.2.2 Microsoft ................................................................................................................ 20
4 PO/Confirmation Scenario Configuration .............................................. 23
4.1 General Remarks ......................................................................................................... 23
4.2 Information for Testing PO/Confirmation ................................................................. 23
4.3 AS ABAP PO/Confirmation Implementation ............................................................. 26
4.3.1 AS ABAP Provides Service PO ............................................................................. 26
4.3.2 AS ABAP Accesses Service Confirmation ............................................................ 31
4.4 WCF PO/Confirmation Implementation ..................................................................... 33
4.4.1 WCF Solution ......................................................................................................... 33
4.4.2 Update and build the SAPBusinessService solution ............................................. 35
4.4.3 Create the SAPBusinessService and Seller applications in IIS ............................ 36
4.4.4 Start the Windows Process Activation Service application [optional] .................... 37
4.4.5 Special Solutions for the .NET Framework 4 Implementation ............................... 37
4.4.6 An Alternate Approach .......................................................................................... 39
4.5 Running and Monitoring the Scenarios .................................................................... 41
4.5.1 Setting up Simulation in AS ABAP ........................................................................ 41
4.5.2 Testing the PO/Confirmation Scenario .................................................................. 42
5
4.5.3 Service Monitoring in SAP NetWeaver .................................................................. 46
4.5.4 Service Monitoring in WCF .................................................................................... 46
5 Ping/Echo Scenarios ............................................................................... 47
5.1 Testing Procedure Template: Microsoft .................................................................... 48
5.2 Testing Procedure Template: SAP............................................................................. 49
5.3 Security Configurations .............................................................................................. 54
5.3.1 Handling Certificates for Encryption and Authentication in AS ABAP ................... 54
5.3.2 Using Authentication with UsernameToken (WSS Usernametoken) .................... 56
5.3.3 Using Authentication with X.509 Certificate on Message Level ............................ 58
5.3.4 Using Authentication with Issued Token for Single Sign-On ................................. 59
5.3.5 Further Combinations ............................................................................................ 62
5.4 Reliability ...................................................................................................................... 63
5.4.1 SAP Reliable Messaging ....................................................................................... 63
5.4.2 Microsoft Reliable Messaging Scenario ................................................................ 64
5.4.3 SAP Reliable Request-Response Patterns ........................................................... 64
5.4.4 Microsoft Request-Response, Reliable Messaging Using SOAP 1.2 Scenario .... 64
5.4.5 Idempotent Service Handling at SAP .................................................................... 64
5.5 Data Types .................................................................................................................... 67
5.5.1 Base Data Type Testing ........................................................................................ 67
5.5.2 Complex Data Type Testing .................................................................................. 68
5.6 Message Transmission Optimization Mechanism (MTOM) ..................................... 69
5.6.1 SAP ........................................................................................................................ 69
5.6.2 Microsoft ................................................................................................................ 70
5.7 WS-Addressing ............................................................................................................ 71
5.7.1 SAP ........................................................................................................................ 71
5.7.2 Microsoft ................................................................................................................ 72
5.8 WSDLs .......................................................................................................................... 73
5.8.1 Support for WSDL Styles: SAP ............................................................................. 73
5.8.2 Support for WSDL Styles: Microsoft ...................................................................... 73
5.8.3 Requests and Responses that Contain Application-Defined Headers .................. 74
5.8.4 Request with Empty Body Element ....................................................................... 75
6
Table of Figures
Figure 1 PO/Confirmation scenario ............................................................................................ 12
Figure 2 Table of PO/confirmation scenario configurations ........................................................ 25
Figure 3 Service interfaces in ES Repository ............................................................................. 27
Figure 4 Implementation of PO/Confirmation scenario in AS ABAP development environment . 28
Figure 5 Provider security settings for HTTPS and user ID/password authentication on message level ........................................................................................................................................... 29
Figure 6 Provider security settings for HTTPS and user ID/password authentication on transport level ........................................................................................................................................... 30
Figure 7 Implementation of consumer proxy CO_EPM_PO_CONFIRMATION_OUT ................ 31
Figure 8 Consumer security settings in SOA management ........................................................ 33
Figure 9 User ID-/password constants and one example use .................................................... 35
Figure 10 Expected Visual Studio 2010 warnings and messages .............................................. 39
Figure 11 Code-first and WSDL-first defined ............................................................................. 40
Figure 12 Relevant XSD elements for simulation ....................................................................... 41
Figure 13 Initial page of ASP.NET interface for PO/Confirmation scenario ................................ 43
Figure 14 Unable to add price that is not a decimal amount ...................................................... 44
Figure 15 Ready to submit a purchase order that contains 5 items............................................ 45
Figure 16 Message monitor for processed XML messages ....................................................... 46
Figure 17 Ping/Echo scenarios listing ........................................................................................ 48
Figure 18 Input parameters for Ping/Echo testing ...................................................................... 51
Figure 19 Table SRT_BZT_CFG_P2P ...................................................................................... 51
Figure 20 Accessing a Ping/Echo scenario in AS ABAP ............................................................ 52
Figure 21 Selecting a Ping/Echo Scenario ................................................................................. 53
Figure 22 Selecting a Ping/Echo scenario ................................................................................. 54
Figure 23 Provider security settings for symmetric message encryption and user ID/password authentication ............................................................................................................................ 56
Figure 24 Consumer security settings for symmetric message encryption and user ID/Password authentication ............................................................................................................................ 57
Figure 25 Provider security symmetric encryption and X.509 authentication on message level . 58
Figure 26 Provider security settings for SSO scenario 1 ............................................................ 60
Figure 27 Provider security settings for SSO scenario 2 ............................................................ 60
Figure 28 Additional external signature and header protection .................................................. 63
Figure 29 Potential error situations in synchronous communication........................................... 65
Figure 30 UUID validation ......................................................................................................... 67
Figure 31 Consumer proxy configuration for optimized XML transfer ......................................... 70
7
Figure 32 Consumer service configuration for setting wsa:Action .............................................. 71
Figure 33 Generating different document styles in AS ABAP ..................................................... 73
Table of Special Solutions
Generating a WSDL in Document Wrapped Style ..................................................................... 30
Using External Definitions in the ES Repository for Provider WSDL .......................................... 31
Special Solution for the .NET Framework 4 Service Implementation ......................................... 37
Idempotent Service Handling at SAP ......................................................................................... 64
Requests and Responses that Contain XSD Float, Double, or Decimal Data Types ................. 68
Requests and Responses that Contain Arrays Using xsi:nil ...................................................... 68
Requests and Responses that Contain Application-Defined Headers: SAP ............................... 74
Request with Empty Body Element: SAP................................................................................... 75
8
1 Introduction
This document provides .NET Framework and SAP NetWeaver developers with information about how to set up standards-based Web services communication between Microsoft .NET Framework applications and SAP Application Server ABAP-based consumers and providers.
Chapter 1 introduces the products and standards.
Chapter 2 introduces the demonstration scenarios. The purchase order/confirmation service (PO/Confirmation) simulates the request from a purchaser to a supplier to deliver a specified quantity of goods. The supplier sends back a purchase order confirmation. Additional descrip-tions refer to delivered technical services that SAP and Microsoft used for testing. These are the Ping/Echo scenarios. The descriptions in this document are based on ABAP implementations delivered together with the SAP NetWeaver Application Server and .NET Framework implemen-tations available for download.
Chapter 3 provides more information about these implementations and other prerequisites.
Chapter 4 describes configuration, deployment, and testing of the PO/Confirmation scenario.
Chapter 5 describes the same aspects of the Ping/Echo scenarios.
1.1 SAP NetWeaver Application Server ABAP and Enterprise Services Repository
The Application Server ABAP (AS ABAP) is part of the SAP NetWeaver offering. The majority of the SAP solutions run on this foundation.
Each AS ABAP provides an integrated development environment as a built-in capability of the application server. ABAP is designed for creating large-scale business applications with dedicat-ed features, for developing backend business functionality, connecting applications, and provi-sioning services.
The AS ABAP can act as Web service provider and as Web service consumer.
In the development environment, developers have access to the Enterprise Services Repository (ES Repository). The ES Repository is a central repository where you define, access, and man-age at design time the Service-oriented architecture (SOA) assets, for example services, mes-sage interfaces and data types. The services are the basis for the Web service provider imple-mentation and the proxy generation of Web service consumers in AS ABAP. Additionally, AS ABAP provides tools to configure Web services and monitor the Web services runtime.
The latest version of the ES Repository is part of the SAP NetWeaver Composition Environment (CE) 7.2 release.
More information about the ES Repository: Repository-Based Modeling and Design, Managing Services in the Enterprise Services Repository
More information about service enabling in AS ABAP: Creating and Configuring Service Provid-ers and Service Consumers
9
1.2 Microsoft .NET Framework 4
.NET Framework 4 provides developers with a comprehensive and consistent programming
model and a common set of APIs and helps developers build applications that work the way they
want, in the programming language they prefer, across software, services, and devices:
Common Language Runtime – Provides an abstraction layer over the operating system.
Base Class Libraries – Pre-built code for common low-level programming tasks.
Development frameworks and technologies – Reusable, customizable solutions for larger
programming tasks.
.NET Framework 4 includes Windows Communication Foundation (WCF), which is Microsoft’s
unified programming model for building service-oriented applications. It enables developers to
build secure, reliable, transacted solutions that integrate across platforms and interoperate with
existing investments.
While .NET Framework 3.5 supports all the standards and techniques discussed in this docu-
ment, .NET Framework 4 includes implementation enhancements for all scenarios. This guide
assumes that you are using .NET Framework 4.
More information: Microsoft .NET Framework, Microsoft .NET Framework Developer Center,
Windows Communication Foundation
1.3 Supported Standards
SAP NetWeaver and .NET Framework 4 both support Web services protocols and open stand-ards to enable technical interoperability between their platforms.
The following standards are supported as described in the interoperability scenarios:
SOAP 1.1 and SOAP 1.2
SOAP is a lightweight protocol for the exchange of information in a decentralized, distributed environment.
More information: SOAP 1.1, W3C - SOAP 1.2
MTOM (Message Transmission Optimization Mechanism)
The Message Transmission Optimization Mechanism optimizes the transmission and wire format of SOAP messages. The concrete implementation relies on the XML-binary Optimized Packag-ing format for carrying SOAP messages.
More information: W3C - SOAP Message Transmission Optimization Mechanism
WS-Security 1.0 and WS-Security 1.1 (WSS:SOAP Message Security, WSS10, WSS11)
WS-Security describes enhancements to SOAP messaging to provide message integrity and confidentiality. The specified mechanisms can be used to accommodate a wide variety of securi-ty models and encryption technologies.
10
More information: OASIS - Web Services Security: SOAP Message Security 1.0, OASIS - Web Services Security: SOAP Message Security 1.1
WS-SecureConversation 1.3
WS SecureConversation introduces a security context and its usage.
More information: OASIS - WS-SecureConversation 1.3
WS-ReliableMessaging 1.1
This protocol allows messages to be transferred reliably between nodes that implement this pro-tocol in the presence of software component, system, or network failures.
More information: OASIS - Web Services Reliable Messaging (WS-ReliableMessaging)
Both products also support WS-ReliableMessaging 1.0. However, the implementations are not interoperable. Do not use WS-ReliableMessaging 1.0 when exchanging messages between SAP and .NET Framework.
WS-Trust 1.3
WS-Trust defines extensions that build on WS-Security to provide a framework for requesting and issuing security tokens, and to broker trust relationships.
More information: OASIS - WS-Trust 1.3
WS-Policy 1.2
WS-Policy defines a base set of constructs that other Web services specifications can use and extend to describe a broad range of service requirements and capabilities.
More information: Web Services Policy 1.2 - Framework (WS-Policy)
SAP does not support WS-Policy 1.5. .NET Framework 4 supports WS-Policy 1.2 and 1.5.
WS-SecurityPolicy 1.2
WS-SecurityPolicy indicates the policy assertions for use with WS-Policy that apply to WSS: SOAP Message Security (WSS10, WSS11), WS-Trust and WS-SecureConversation
More information: OASIS - WS-SecurityPolicy 1.2
WS-Addressing 1.0
Web Services Addressing provides transport-neutral mechanisms to address Web services and messages.
More information: W3C - WS-Addressing 1.0 Core, W3C - WS-Addressing 1.0 SOAP Binding
WSDL 1.1
11
WSDL is an XML format for describing network services as a set of endpoints operating on mes-sages that contain either document-oriented or procedure-oriented information.
More information: Web Services Description Language (WSDL) 1.1
1.4 Message Exchange Patterns
Only non-addressable client scenarios are supported. This means that a connection is always set up by the consumer and the provider uses the same connection for the response.
Communication is classified by the following characteristics:
Request-Response versus One-Way In a request-response scenario, the consumer sends a business request SOAP mes-sage. The provider sends a business response message.
Using a one-way communication pattern, the consumer sends a business request SOAP message, but there is no response message on business level. The provider sends a sta-tus message.
Reliable versus Unreliable Reliable communication means that SOAP messages are exchanged exactly once and in the correct order independent of software component, system, or network failures.
Blocking versus Non-Blocking In a blocking programming model, the accessing application waits until the response is sent back.
In a non-blocking programming model, the accessing application continues processing after triggering the call.
The following communication patterns are used:
Request-Response, unreliable, blocking. SAP calls this communication pattern synchronous.
Microsoft calls this communication pattern request-reply with an anonymous (non-addressable) client.
One-Way, reliable, non-blocking. SAP calls the communication pattern asynchronous.
Microsoft calls this communication pattern one-way reliable messaging with an anony-mous (non-addressable) client.
2 Demonstration Scenarios Overview
2.1 General Remarks
SAP speaks of Web service providers and Web service consumers. Microsoft generally uses the terms services and clients.
In this document, Microsoft terminology uses accessing services, whereas in SAP terminology, the term consuming services is used.
12
2.2 PO/Confirmation Scenario
The description of how to set up Web services-based communication between AS ABAP and .NET Framework 4 is based on the delivered demonstration scenario purchase or-der/confirmation service (PO/Confirmation). The SAP Enterprise Procurement Model (EPM) sys-tem provides two asynchronous Web services for this. The communication pattern used in this scenario is one-way reliable messaging with anonymous (non-addressable) client.
This demonstration scenario is derived from an SAP Enterprise Service. The detailed description in Chapter 4 is based on this scenario.
WS Consumer/Client WS Provider/Service
PO (Send Purchase Order Request)
Purchaser Supplier
EPM_ PurchaseOrder
Request_In
EPM_PurchaseOrder
Confirmation_In
Confirmation (Send Purchase Order Confirmation)
WS Consumer/ClientWS Provider/Service
Simulate Purchase
Order Processing
WS Message
WS Message
Microsoft SAP
EPM_PurchaseOrder
Request_Out
EPM_PurchaseOrder
Confirmation_Out
Figure 1 PO/Confirmation scenario
In scenario PO (Send Purchase Order Request), AS ABAP (SAP) acts as the Web service pro-vider and WCF (Microsoft) as the Web service consumer/client. The purchaser sends a pur-chase order request to the supplier. All descriptions in section 4.3.1 refer to this scenario.
In a production implementation of a PO/Confirmation scenario the application layer would send out the confirmation after processing the PO request. In this demo scenario however, a simula-tion is implemented instead (Simulate Purchase Order Processing). It processes the purchase order request and sends back a purchase order confirmation to the purchaser. In the simulation, no data is stored in the database.
In the Confirmation (Send Purchase Order Confirmation) scenario, WCF (Microsoft) acts as the Web service provider and AS ABAP (SAP) as the Web service consumer/client. The supplier sends back a purchase order confirmation to the purchaser. All descriptions in section 4.3.2 are based on this scenario.
Note The contract between the Web service provider and the consumer is based on one inter-face. Figure 1, EMP_PurchaseOrderRequest_Out and EPM_PurchaseOrderRequest_In illus-trates the distinction in this contract. This distinction is made in case that you want to set up Web services connectivity using SAP NetWeaver Process Integration. In the following scenario de-
13
scription, Web services connectivity is set up directly between an SAP and a Microsoft system. The distinction between In and Out is not required in the scenarios described in this guide. The message types are identical in both cases.
To secure the exchanged messages, SSL over HTTP is used and user ID/password authentica-tion either on transport level or on message level.
2.3 Ping/Echo Scenarios
The Ping/Echo scenarios are technical scenarios that Microsoft and SAP used for interoperabil-ity testing. All descriptions in Chapter 5 refer to Ping/Echo.
To secure the exchanged messages, various alternatives have been tested:
On transport level you can use either SSL over HTTP or message encryption. For au-thentication, user name/password is available either on transport or on message level.
Alternatively, you can use an X.509 certificate on message level for authentication or SAML based Single Sign-On by involving a security token service.
Other tests included Web Services Reliable Messaging, data type testing, including how XSD elements are mapped to ABAP types. Tests also used different WSDL document types.
Message Transmission Optimization Mechanism (MTOM) combined with message sig-nature and encryption and WS-Addressing scenarios were tested.
In Chapter 5, references to the delivered scenarios in.NET Framework 4 and in the AS ABAP implementation can be found.
2.4 Demonstration Scenarios Delivery
2.4.1 SAP
SAP delivers the PO/Confirmation as ES Repository content in the software component SAP Basis, software component version SAP Basis 7.20, and namespace http://sap.com/xi/NWDemo, folder EPM.
SAP has implemented PO/Confirmation in AS ABAP. The implementation is in the ABAP Work-bench (transaction SE80) in package S_EPM_PI.
SAP does not deliver endpoints or logical ports. For the configuration of endpoints or logical ports, go to SOA Management (transaction SOAMANAGER) and search for EPM*.
There is no ES Repository content available for Ping/Echo.
The Ping/Echo scenarios are implemented in AS ABAP in package SOAP_RT_TESTS_BIZTALK. For the configuration of endpoints, go to SOA Management (transaction SOAMANAGER). Search for I*, Echo or Notify.
For the configuration of logical ports, go to SOA Management (transaction SOAMANAGER). Search by Internal Name for CO_*.
To access the provider WSDLs for configuration, use user ID Alice_ and password _ecilA. Some .NET clients need this information at runtime. The exact credentials could be anything you chose.
14
Note To simplify the WSDL access, you can add the user ID and password to the WSDL URL in the following way: Add &sap-user=Alice_&sap-password=_ecilA at the end of the URL. This is NOT recommended for production scenarios!
2.4.2 Microsoft
Microsoft delivers the PO/Confirmation and the Ping/Echo scenarios as downloads.
You can download the latest .NET PO/Confirmation implementation, SAPBusinessScenario.zip, from the following location: http://code.msdn.microsoft.com/WCFandSAP
You can download the latest .NET Ping/Echo implementations, InteropSourcesAnd-Binaries_SecurityPolicy12.zip, from the following location: http://code.msdn.microsoft.com/WCFInterop
3 Demonstration Scenario Installation and Set up
3.1 Installation and Technical Configuration
3.1.1 SAP
The system landscape on the SAP side consists of an ES Repository connected to an AS ABAP.
Information about how to install AS ABAP 7.0, including enhancement package 2, is provided in SAP Service Marketplace: Installation Guides (login required).
To use Web services with Web Services Reliable Messaging, configure the Web service runtime. The configuration is client-specific and you must perform it in each production client and in client 000.
More information: Configuring the Web Services Runtime
The ES Repository is part of SAP NetWeaver Composition Environment (CE). There is an instal-lation option available for the ES Repository.
Note To configure scenarios used in this guide the ES Repository is not required. Service de-sign has already taken place. However, to develop new services or adjust already existing ser-vices, the ES Repository is the starting point and must be part of your service development.
Information about how to install SAP NetWeaver CE is provided on the SAP Service Market-place: Installation Guides (login required)
After installation, you must perform several steps to set up the ES Repository and connect it to AS ABAP.
More information: Configuring Enterprise Services Repository, Connecting ABAP Backend Sys-tem to ES Repository
3.1.2 Microsoft
This section details how to obtain the necessary software to run the .NET Framework 4 test
suites for SAP/WCF interoperability and the files necessary to set up and configure the WCF
environment in Visual Studio 2010 and Microsoft Internet Information Services (IIS) 7.0 or IIS
7.5.
15
Unless otherwise specified all of the following steps are necessary for the PO/Confirmation sce-
nario as well as the Ping/Echo scenarios.
3.1.2.1 Assumptions
The scenarios in this document assume that you have the following software installed on your
computer:
Microsoft Visual Studio 2010
.NET Framework 4
Windows 7 or Windows Server 2008 R2
Windows 7 SDK
IIS 7.5
3.1.2.2 Minimum Requirements
Microsoft Visual Studio 2008
.NET Framework 3.5
Note While .NET Framework 3.5 supports all the standards and techniques discussed
in this document, .NET Framework 4 includes implementation enhancements for all sce-
narios. This guide assumes that you are using .NET Framework 4.
Windows XP Service Pack 3 or Windows Server 2003 SP 2
Windows Server 2008 SDK
IIS 5.1
3.1.2.3 Install and Configure the .NET Framework 4 Test Suite and Certificates
The following sections include seven procedures that describe how to install the WCF test suite
and how to install and configure your IIS 7.5 server to serve the WCF services:
1. Place the Test Files
2. Create folders to contain test output
3. Install IIS and enable WCF HTTP Activation
4. Configure IIS to use .NET Framework 4 and install the Ping/Echo test suite
5. Configure the IIS Default Application Pool to use the Network Service identity
6. Enable other computers to communicate with IIS
7. Reconfigure the Security.SecureExchange (WS-SX) feature in the test suite
3.1.2.4 Place the Test Files
Places the PO/Confirmation scenario files and the Ping/Echo test case sources and binaries. This procedure also places the required certificate files.
1. Copy SAPBusinessScenario.zip and InteropSourcesAndBinaries_SecurityPolicy12.zip
(see section 2.4.2) to your local computer.
16
2. Unzip the contents of SAPBusinessScenario.zip into the %My Documents%\Visual
Studio 2010\Projects folder.
3. Unzip the contents of InteropSourcesAndBinaries_SecurityPolicy12.zip to the C:\ root
folder.
3.1.2.5 Create folders to contain test output
Creates the folders to contain test output and sets the appropriate permissions on each. The c:\OasisLogs folder is used only for a subset of the Ping/Echo scenarios while the c:\bin folder is used only for the PO/Confirmation scenario.
1. Click Start, click All Programs, click Accessories, and then click Windows Explorer.
2. In Windows Explorer, browse to the C:\ root folder, and then click New Folder.
3. In the New folder box, type OasisLogs, and then press ENTER.
4. Right-click the OasisLogs folder and then click Properties.
5. On the OasisLogs Properties box, click Security, and then click Edit.
6. On the Permissions for OasisLogs property sheet, click Add.
7. In the Enter the object names to select box, type Network Service, click Check
Names, and then click OK.
8. In the Permissions for NETWORK SERVICE box, select the Allow box for the Write
permission, click OK, and then click OK again.
9. In Windows Explorer, browse to the C:\ root folder, and then click New Folder.
10. In the New folder box, type bin, and then press ENTER.
11. Repeat steps 4 through 7 for the bin folder.
12. In the Permissions for NETWORK SERVICE box, confirm that the Allow box for the
Read permission is selected, click OK, and then click OK again.
13. Close Windows Explorer.
Note You must create the OasisLogs folder to allow the Security.SecureExchange (WS-SX)
feature in the test suite to work. This feature writes additional log files to the OasisLogs folder
and if the folder does not exist, those tests fail. The bin folder is used by the SAP Business Ser-
vice deployment.
3.1.2.6 Install IIS and enable WCF HTTP Activation
Installs the required IIS 7.5 features and enables the WCF HTTP Activation service.
1. Click Start, click Control Panel, click Programs, and under Programs and Features
click Turn Windows features on or off.
2. If a User Account Control dialog box appears, type in your administrator credentials if
necessary, and then click Yes.
3. In the Windows Features dialog box, confirm that Internet Information Services is en-
abled along with the following features of IIS:
17
a. In the Web Management Tools node, confirm that IIS Management Console is
selected.
b. In the World Wide Web Services, Common HTTP Features node, confirm that
Default Document is selected.
c. In the World Wide Web Services, Application Development Features node,
confirm that .NET Extensibility and ASP.NET are selected.
4. In the Windows Features dialog box, confirm that the Windows Communication
Foundation HTTP Activation feature of Microsoft .NET Framework 3.5.1 is selected.
3.1.2.7 Configure IIS to use .NET Framework 4 and install the Ping/Echo test suite
Configures IIS 7.5 to use the version of ASP.NET that is included with .NET Framework 4 and installs the Ping/Echo test suite on IIS.
The script executed in step 6 installs a number of certificates used in Ping/Echo scenarios for message-level security protection. Technical committees at OASIS created these certificates and distributed them for interoperability testing and demonstration purposes. Do not use these certificates in production. For production use, follow the alternate approaches described at http://msdn.microsoft.com/en-us/library/ms731899(VS.100).aspx.
The script executed in step 6 (listed below) is part of the Ping/Echo scenarios implementation but creates a c:\WCFLogs folder also used in the PO/Confirmation scenario. Create this direc-tory using the steps described in section 3.1.2.5, Create folders to contain test output, if testing only the PO/Confirmation scenario.
1. Click Start, click All Programs, click Accessories, right-click Command Prompt, and
then click Run as administrator.
2. If a User Account Control dialog box appears, type in your administrator credentials if
necessary, and then click Yes.
3. On the command prompt, navigate to C:\Windows\Microsoft.NET\Framework\v4.0.
30319\ folder.
Note If you have installed the 64-bit version of .NET Framework 4 on a compatible
Windows operating system, the path in this step is
C:\Windows\Microsoft.NET\Framework64\v4.0.30319.
4. Type aspnet_regiis –i –enable, and then press ENTER.
5. On the command prompt, navigate to the
C:\binaries.x86chk\CDF\Test\wcf\Suite\XwsInterop\scripts\deploy folder.
6. On the command prompt, type DeployIndigoEndpoints.cmd
\binaries.x86chk\CDF\Test\wcf and then press ENTER.
7. On the command prompt, type iisreset /restart, and then press ENTER.
After the server restarts, the endpoint browser is available to view at
http://NETServer/endpoints.
18
3.1.2.8 Configure the IIS Default Application Pool to use the Network Service identity
Configures the IIS default application pool to use the NetworkService account as its process identity. This procedure avoids potential problems in private key installation performed when you execute step 6 in section 3.1.2.7.
1. Click Start, click Control Panel, click System and Security, click Administrative
Tools, and then click Internet Information Services (IIS) Manager.1
2. If a User Account Control dialog box appears, type in your administrator credentials if
necessary, and then click Yes.
3. In the Connections pane, expand the local server name, and then click Application
Pools.
4. In the Application Pools pane, right-click DefaultAppPool, and then click Advanced
Settings.
5. In the Advanced Settings dialog box, expand Process Model, click Identity, and then
click … beside to the current value.
6. In the Application Pool Identity dialog box, select Built-in account, select Net-
workService from the drop-down list, click OK, and then click OK again.
7. Close IIS Manager.
3.1.2.9 Enable other computers to communicate with IIS
Configures Windows Firewall so that SAP installations on other computers can communicate with WCF services.
1. Click Start and then click Control Panel.
2. In Control Panel, click System and Security, and in the Windows Firewall section,
click Allow a program though Windows Firewall, and then click Change Settings.
3. If a User Account Control dialog box appears, type in your administrator credentials if
necessary, and then click Yes.
4. In the Allowed programs and features box, select Secure World Wide Web Services
(HTTPS) and World Wide Web Services (HTTP) for the type of network you use.
5. Click OK and then close Control Panel.
3.1.2.10 Reconfigure the Security.SecureExchange (WS-SX) feature in the test suite
Reconfigures the Security.SecureExchange (WS-SX) feature in the test suite to allow it to pass messages through firewalls. This reconfiguration is required because the WS-SX feature uses a Security Token Service (STS) hosted on http://131.107.153.205, which is an Internet-facing server.
Do not perform these steps if testing only the PO/Confirmation scenario.
1 Alternatively, start IIS Manager as follows: Click Start, click Run, type inetmgr, and then press ENTER.
19
1. Click Start, click All Programs, click Microsoft Visual Studio 2010, and then click Mi-
crosoft Visual Studio 2010.
2. Click File, click Open, and then click File.
3. In the Open File dialog box, navigate to
C:\binaries.x86chk\CDF\Test\wcf\Suite\XwsInterop\Security\SecureExchange\SXCli
ent\Indigo, click web.config, and then click Open.
4. In the Visual Studio code pane, find the <defaultProxy> element in the <system.net> element and then change the enabled attribute to true.
5. In the <proxy> element, change the proxyaddress attribute to contain the URI for the proxy server that your organization uses. You may need to consult a system administra-tor to obtain this information.
6. In the <bypasslist> element, use <add> elements with address attributes to add all servers inside your firewall that you use for testing. For example, you can add the SAPS-erver URI to the bypass list if necessary.
Note SAPServer is a placeholder for the hostname of the SAP server in your environ-ment. You must obtain the correct hostname for this server and use that value in the step above.
7. Close Visual Studio.
Note For more information about configuration proxy servers, see Proxy Configuration. For more information about the <defaultProxy> element, see the <defaultProxy> Element (Network Settings).
3.2 Setting up Security and Trust
The PO/Confirmation scenario uses SSL for secure message exchange and requires a user ID and password for user authentication. Some of the Ping/Echo scenarios have similar confidenti-ality and authentication requirements.
3.2.1 SAP
In AS ABAP, the following preliminary steps are necessary to enable SSL for communication.
1. Install The SAP Cryptographic Library of version 1.555.28 or higher.
2. Set profile parameters in AS ABAP instance profile.
3. In Trust Manager (transaction STRUST) create the SSL server PSE:
a. Generate a certificate request for the SSL server PSE.
b. Send the certificate request to a CA to be signed.
Use for example the SAP Trust Center Services at service.sap.com/TCS.
c. Import the certificate request response.
4. In Trust Manager (transaction STRUST) create the anonymous SSL client PSE:
a. In case you are using a self-signed certificate for the NETServer, import the NETServer SSL certificate using the NETServer.cer file exported in steps 5 through 12 of section 3.2.2.1.
20
b. In case your NETServer certificate is signed by a Certification Authority (CA), im-port the root certificate(s) of the CA that issued the certificate to the NETServer that the AS ABAP accesses using the anonymous SSL client PSE.
5. To test the SSL set up, go to transaction SM59, create a connection and specify that it should use SSL.
6. Test the connection.
More information: Configuring the AS ABAP for Using SSL
Troubleshooting information is found in SAP note 1318906 (login required).
Note For Web services communication, you do not need to maintain destinations in transaction SM59; the destinations are automatically created when you create endpoints for your Web ser-vices.
3.2.2 Microsoft
To set up security and trust for providers and consumers of WCF services for the end-to-end
business scenario, you must perform three procedures:
1. Configure SSL on the Web server
2. Create the certificate snap-in and confirm the scenario certificates
3. Test that Windows trusts site certificates for the Microsoft server and the SAP server
3.2.2.1 Configure SSL on the Web server
Uses the Microsoft Internet Information Services Web server to create a self-signed certificate, a file containing the certificate, and an HTTPS binding that uses that certificate.
Internet Information Services (IIS) Manager can import, request, or create certificates appropri-ate for an HTTPS Web site. This procedure creates a self-signed certificate for this demonstra-tion. Do not use such a certificate in production. For production use, follow the alternative ap-proaches described at http://technet.microsoft.com/en-us/library/cc732230(WS.10).aspx.
1. Click Start, click Control Panel, click System and Security, click Administrative Tools,
and then click Internet Information Services (IIS) Manager.
2. If a User Account Control dialog box appears, type in your administrator credentials if nec-
essary, and then click Yes.
3. In the Connections pane of IIS Manager, click the local server name.
4. In the server Home pane, double-click Server Certificates.
5. In the Actions pane, click Create Self-Signed Certificate….
6. On the Specify Friendly Name page of the Create Self-Signed Certificate wizard, in the
Specify a friendly name for the certificate box type in a name for the certificate, and then
click OK.
7. In the Server Certificates pane, double-click the certificate you just created.
8. Click the Details tab of the Certificate dialog, and then click Copy to File…
21
9. In the Certificate Export Wizard, click Next, confirm No, do not export the private key is
selected, click Next, confirm DER encoded binary X.509 (.CER) is selected, click Next, and
then click Browse...
10. In the Save As dialog, navigate to a memorable location, enter a filename such as NET-
Server.cer in the File name field, and click Save.
11. In the Certificate Export Wizard, click Next, confirm the values you have entered, and then
click Finish.
12. Click OK twice to confirm and return to IIS Manager.
13. In the Connections pane, expand Sites, and then click Default Web Site.
14. In the Actions pane, click Bindings….
15. On the Site Bindings dialog box, click Add….
16. On the Add Site Binding dialog box, in the Type box select https, in the SSL certificate
box select the certificate you created in step 5, click OK, and then click Close.
Note In many of the subsequent procedures in this document, NETServer is a placeholder for
the hostname of the .NET Framework 4 server in your environment. The preceding procedure
defines for you the hostname you must use when you replace NETServer. Use the Issued To
value of the self-signed certificate.
3.2.2.2 Create the certificate snap-in and confirm the scenario certificates
Create an MMC certificate snap-in. Then use this snap-in to confirm that the test suite certifi-cates and the SSL certificate you created in Section 3.2.2.1.
1. Click Start and in the Search programs and files box, type mmc, and then press ENTER.2
2. If a User Account Control dialog box appears, type in your administrator credentials if nec-
essary, and then click Yes.
3. On the MMC console root, click File, and then click Add/Remove Snap-in….
4. In the Available snap-ins box of the Add or Remove Snap-ins dialog box, select Certifi-
cates, and then click Add.
5. On the Certificate snap-in box, select Computer account, and then click Next.
6. On the Select Computer box, select Local computer, click Finish, and then click OK.
7. In the console root click File, and then click Save.
8. In the Save As dialog box, in the File name box assign a name to the snap-in that is easy
for you to remember, and then click Save.
Note The snap-in console now appears when you click Start, click All Programs, and then
click Administrative Tools.
2 Alternatively, start the Management Console as follows: Click Start, click Run, type mmc, and then press EN-
TER.
22
9. In the Console Root, click Certificates, click Personal, and then click Certificates.
The self-signed SSL certificate should appear in this store, along with the Alice and Bob cer-
tificates used in a number of the Ping/Echo scenarios. Each certificate should have a small
key in the certificate icon to indicate that a private key is available.
3.2.2.3 Test that Windows trusts site certificates for the Microsoft server and the SAP server
Use Internet Explorer to test that Windows trusts the self-signed certificate on the WCF server over the HTTPS protocol. The first three steps test the HTTPS connection for the local server and the subsequent steps describe what to do if Windows does not trust the certificate. The pro-cedure also includes steps that verify that Windows trusts the certificate on the SAP NetWeaver Application Server.
1. Click Start, click All Programs, right-click Internet Explorer, and then click Run as Admin-
istrator.
2. If a User Account Control dialog box appears, type in your administrator credentials if nec-
essary, and then click Yes.
3. In the address bar, type https://NETServer/ and then press ENTER. NETServer is the host
name for the server that hosts the .NET Framework 4 test client. This name must match the
Subject and Issued To names that IIS assigned to the self-signed certificate that you creat-
ed in section 3.2.2.1. In most cases, IIS assigns the fully-qualified computer name to these
fields.
4. If Internet Explorer displays an SSL Certificate Not Trusted error, confirm the URI to make
sure you are navigating to the correct server and then click Continue to this website (not
recommended).
5. On the Address bar, click Certificate Error, and then click View Certificates.
6. Check that the Issued To information is the same as the Issued By information to verify this
is the self-signed certificate created in section 3.2.2.1.
7. On the General tab of the Certificate dialog box, click Install Certificate….
8. On the Certificate Import Wizard, click Next.
9. In the Certificate Store page of the Certificate Import Wizard, select Place all certificates
in the following store, and then click Browse.
10. In the Select Certificate Store dialog box, expand Trusted Root Certificate Authorities,
click Local Computer, click OK, click Next, and then click Finish.
11. In the Import was successful dialog box, click OK, and then click OK again.
12. Close Internet Explorer and repeat steps 1 through 3.
13. If Internet Explorer displays another error, repeat steps 1 through 3.
Note If you continue to get this error, or any other error, accessing this page, redo the pro-
cedure in Section 3.2.2.1 to create the self-signed certificate and binding again.
14. In the Internet Explorer address bar, type https://SAPServer/ and then press ENTER. SAPS-
erver should be the fully-qualified name of the server on which the SAP NetWeaver Applica-
tion Server is installed.
23
15. If Internet Explorer displays an SSL Certificate Not Trusted error, confirm the URI to make
sure you are navigating to the correct server, and then click Continue to this website (not
recommended).
16. Repeat steps 5 through 11.
17. Close Internet Explorer and repeat steps 1, 2, and 14.
18. Close Internet Explorer.
Note Steps 1 through 4 and 12 through 15 of this procedure work if you open Internet Explorer
without elevated privileges. However, the rest of the procedure requires you to open Internet
Explorer as an administrator.
4 PO/Confirmation Scenario Configuration
4.1 General Remarks
The scenario configurations in the following sections are based on the delivered EPM demon-stration scenario described in the Demonstration Scenarios Overview section. This demonstra-tion scenario is derived from an SAP Enterprise Service.
The PO/Confirmation scenario is designed to replicate high-latency business exchanges. SAP
does not support addressable clients, which is the WS-Addressing approach for messaging in
such situations. The .NET Framework 4 client application code must therefore correlate two dis-
tinct one-way messages, the Purchase Order and Confirmation requests. The approach used in
the Confirm.svc.cs file in the Buyer folder of the solution is appropriate for demonstration pur-
poses.
However, business implementations often share a database between buyer forms and the con-
firmation service. Such a confirmation service would:
Save message content, perhaps even the entire SOAP message, to the database.
Not notify the buyer user interface directly as the confirmation service does in this sce-
nario.
The Confirm.svc.cs and the Buyer forms in this demonstration share static variables rather than
a database. The confirmation service correlates the purchase order with the confirmation mes-
sage immediately upon receipt of the confirmation message. The confirmation service saves the
SOAP message in its entirety and then signals the buyer user interface that it has received the
confirmation message.
The wire-level exchanges are unrealistic only in that the schema is not fully utilized. For exam-
ple, there are no large engineering diagrams or other attachments included in any of the pur-
chase orders.
4.2 Information for Testing PO/Confirmation
The following table contains information about the configurations you can test in the .NET Framework 4 scenario implementation once the endpoints and logical ports exist in AS ABAP on SAP.
24
Identifier Configuration and Endpoint URIs
NET The default .NET Framework 4 endpoints with the same configuration as SAP.
SOAP 1.2, WS-A 1.0, WS-RM 1.1, Username over Transport (user ID/password authentication on message level)
https://NETServer/SAPBusinessService/PO.svc
WSDL: http://NETServer/SAPBusinessService/PO.svc?wsdl
https://NETServer/SAPBusinessService/Confirm.svc
WSDL: http://NETServer/SAPBusinessService/Confirm.svc?wsdl
NETAUTH Used for .NET Framework 4 to .NET Framework 4 testing and has the same con-figuration as SAPAUTH. This is a command-line purchase order service similar to NET but uses basic authentication.
SOAP 1.2, WS-A 1.0, WS-RM 1.1, Basic Auth over HTTPS (user ID/password au-thentication on transport level)
https://NETServer/SAPBusinessService/PO2
WSDL: http://NETServer/SAPBusinessService/PO2?wsdl
There is no command-line confirmation service because the confirmation ser-vice must run in process with the .NET Framework 4 client.
NET.clear Use for set-up confirmation.
SOAP 1.2, WS-Addressing 1.0, WS-RM 1.1, no security
http://NETServer/SAPBusinessService/PO.svc/basic
WSDL: http://NETServer/SAPBusinessService/PO.svc?wsdl
http://NETServer/SAPBusinessService/Confirm.svc/basic
WSDL: http://NETServer/SAPBusinessService/Confirm.svc?wsdl
NETS11 Similar to NET but uses SOAP 1.1.
SOAP 1.1, WS-A 1.0, WS-RM 1.1, Username over Transport (user ID/password authentication on message level)
https://NETServer/SAPBusinessService/PO.svc/soap11
WSDL: http://NETServer/SAPBusinessService/PO.svc?wsdl
https://NETServer/SAPBusinessService/Confirm.svc/soap11
WSDL: http://NETServer/SAPBusinessService/Confirm.svc?wsdl
NETAUTHS11 Similar to NETAUTH but uses SOAP 1.1.
SOAP 1.1, WS-A 1.0, WS-RM 1.1, Basic Auth over HTTPS (user ID/password au-thentication on transport level)
https://NETServer/SAPBusinessService/PO2/soap11
WSDL: http://NETServer/SAPBusinessservice/PO2?wsdl
25
There is no command-line confirmation service because the confirmation ser-vice must run in-process with the .NET Framework 4 client.
SAP SOAP 1.2, WS-A 1.0, WS-RM 1.1, Username over Transport (user ID/password authentication on message level)
You can generate the endpoint URI in SOA Management, refer to Section 4.3.1.4, points 6 and 7, and Section 4.3.1.5.
SAPS11 Similar to SAP but uses SOAP 1.1.
SOAP 1.1, WS-A 1.0, WS-RM 1.1, Username over Transport (user ID/password authentication on message level)
You can generate the endpoint URI in SOA Management, refer to Section 4.3.1.4, points 6 and 7, and Section 4.3.1.5.
Same endpoint as SAP.
SAPAUTH SOAP 1.2, WS-A 1.0, WS-RM 1.1, Basic Auth over HTTPS (user ID/password au-thentication on transport level)
You can generate the endpoint URI in SOA Management (transaction SOA-MANAGER). For details refer to Section 4.3.1.4, point 8, and Section 4.3.1.5.
SAPAUTHS11 Similar to SAPAUTH but uses SOAP 1.1.
SOAP 1.1, WS-A 1.0, WS-RM 1.1, Basic Auth over HTTPS (user ID/password au-thentication on transport level)
You can generate the endpoint URI in SOA Management (transaction SOA-MANAGER). For details refer to Section 4.3.1.4, point 8, and Section 4.3.1.5.
Same endpoint as SAPAUTH.
Figure 2 Table of PO/confirmation scenario configurations
This is an example for an SAP WSDL URL:
http://ldciui2.wdf.sap.corp:50078/sap/bc/srt/wsdl/srvc_00505683359D02EDBBCFA35A90C5C87
B/wsdl11/allinone/ws_policy/document?sap-client=960
See: Provide the Service to the Consumer
If SAP is the service provider, the user that is given to the service consumer for authentication must have assigned a role that contains the authorization object S_SERVICE. For this demon-stration scenario, use the preconfigured user from .NET Framework side.
For a production scenario, use the SAP_BC_WEBSERVICE_CONSUMER role as a template, copy it and then reduce the authorizations accordingly.
If a service consumer uses message-based authentication at an AS ABAP provider, execute the wss_setup report after the system set up.
26
The Internet Communication Framework (ICF) initially performs the logon using the technical user DELAY_LOGON that is stored in the ICF. A direct logon with the authentication data con-tained in the SOAP document is not possible, because the ICF cannot access SOAP data.
4.3 AS ABAP PO/Confirmation Implementation
4.3.1 AS ABAP Provides Service PO
4.3.1.1 Overview
To establish Web services connectivity between a provider/service and a consumer/client, per-form the following steps:
Design the service in the ES Repository (already done in this scenario).
Implement the service in the AS ABAP development environment (ABAP workbench, transaction SE80) (already done in this scenario).
Configure endpoints for the service in the AS ABAP SOA Management (transaction SOAMANAGER).
Provide the WSDL and the user ID and password for authentication to the consumer.
4.3.1.2 Designing the Service Provider
Service design for the PO/Confirmation scenario has already taken place. The design-time ob-jects are in the ES Repository. To display the objects:
1. Log on to the ES Repository.
2. In the navigation tree, expand software component SAP Basis and software component version SAP BASIS 7.20.
3. Expand namespace http://sap.com/xi/NWDemo and open folder EPM. Relevant service interfaces for the demonstration scenario are:
o EPM_PurchaseOrderRequest_In
o EPM_PurchaseOrderConfirmation_Out
27
Figure 3 Service interfaces in ES Repository
To design a service in the ES Repository
1. Log on to the ES Repository.
2. Define a software component version and namespace.
Note If you want to develop objects that can be shipped, you must maintain the soft-ware component in the software catalog of the System Landscape Directory (SLD). The SLD serves as a central information repository for your system landscape. Then import the software component version and namespace into the ES Repository.
3. Design a service in the software component version of the ES Repository.
a. Design data types.
b. Design message types.
c. Design a service interface. More information about service design: Software Component Versions, Interface Objects in the ES Repository
4.3.1.3 Implementing the Service Provider
To find the implementation of the PO/Confirmation scenario services in AS ABAP
1. Log on to AS ABAP.
2. Call the ABAP Workbench (transaction SE80).
3. Select Package S_EPM_PI.
28
4. Open folder Enterprise Services ->Server Proxies and select II_EPM_PO_REQUEST_IN.
Figure 4 Implementation of PO/Confirmation scenario in AS ABAP development environment
General Information about Service Implementation
To implement a service in the ABAP environment by using the design entities from ES Reposito-ry, do the following:
1. In AS ABAP, call the ABAP workbench (transaction SE80).
2. Select the inbound service interface and choose Create Proxy from the context menu. The service definition is generated automatically and then the provider proxy contains methods for each service operation.
3. Save and activate your provider proxy.
4. Add your own functionality (source code) to the provider proxy. More information about service implementation: Developing a Web Service
4.3.1.4 Configuring the Service Provider
Provides endpoints for service provider EPM_PurchaseOrderRequest_In:
1. In AS ABAP, call SOA Management (transaction SOAMANAGER).
2. Go to the Service Administration tab and select Single Service Configuration.
3. Type EPM_PurchaseOrderRequest_In in the Search Pattern field.
4. Select the service and click Apply Selection.
5. To add an endpoint to the service, go to the Configurations tab and select Create End-point.
6. Under New Binding Name type in “bindingbasicauthoverhttps” and select Apply Set-tings.
29
7. On the Provider Security tab, select the following:
o To enable HTTPS for message processing, select SSL (HTTPS, Transport Channel Security).
o For authentication, select User ID/Password under Message Authentication.
Figure 5 Provider security settings for HTTPS and user ID/password authentication on message level
Note This configuration corresponds to the identifiers SAP and SAPS11 in Figure 2, the Table of PO/confirmation scenario configurations. The endpoint is enabled to receive SOAP 1.1 and SOAP 1.2 messages by default.
8. Configure a second endpoint with the settings shown in the following illustration. Use “bindingusernameovertransport” as the name of the new binding name for this end-point.
30
Figure 6 Provider security settings for HTTPS and user ID/password authentication on transport level
Note This configuration corresponds to the identifiers SAPAUTH and SAPAUTHS11 in Figure 2. The endpoint is enabled to receive SOAP 1.1 and SOAP 1.2 messages by default.
4.3.1.5 Providing the Service to the Consumer
Provides the following to the consumer/Client:
WSDL with the selected binding.
The user ID for WSDL access is Alice_, the password is _ecilA.
For this demonstration scenario, you can add the user ID and password to the WSDL URL in the following way: Add &sap-user=Alice_&sap-password=_ecilA at the end of the URL. This is not recommended for production scenarios!
Provide the user ID and password for the technical user to call the service. In this demonstration scenario, the user ID is Alice_, the password _ecilA.
To create the WSDL document
1. ln SOA Management (transaction SOAMANAGER), select EPM_PurchaseOrderRequest_In and select the Overview tab.
2. Select Show WSDL Options and select the following:
o To generate a WSDL that supports only one SOAP version, select a Binding SOAP Version, otherwise the WSDL supports both SOAP versions.
o Click Selected Binding Only and click the link Open WSDL document for se-lected binding or service.
Note If you want to provide the WSDL document with the type document wrapped, re-place document with document_wrapped in the WSDL URL.
3. Copy the WSDL document to a file.
31
Note If a Services Registry is part of your system landscape, the system automatically publish-es services to the Services Registry. You can provide the link to this Services Registry to the consumer and give details about the service.
More information: Publishing Services
4.3.2 AS ABAP Accesses Service Confirmation
To access a service:
Generate the consumer proxy (the proxy is already generated in this scenario).
Configure the consumer proxy.
4.3.2.1 Generating the Consumer Proxy
To find the implementation of the PO/confirmation scenario consumer proxies in AS ABAP
1. Log on to AS ABAP.
2. Call the ABAP Workbench (transaction SE80).
3. Select Package S_EPM_PI.
4. Open folder Enterprise Services Service Consumer and select CO_EPM_PO_CONFIRMATION_OUT.
Figure 7 Implementation of consumer proxy CO_EPM_PO_CONFIRMATION_OUT
Use the service provider WSDL to generate the consumer proxy.
If the provider WSDL contains statements that ABAP proxy generation currently does not sup-port, you can provide all WSDL content (data types, services interfaces, etc.) in the ES Reposi-tory first and use the WSDL from ES Repository instead.
More information: Working with External Definitions
32
4.3.2.2 Configuring the Consumer Proxy
Provides a logical port for consumer proxy EPM_PurchaseOrderConfirmation_Out.
1. In AS ABAP, call SOA Management (transaction SOAMANAGER).
2. Go to the Service Administration tab and select Single Service Configuration.
3. Specify your search for a consumer proxy.
4. Type EPM_PurchaseOrderConfirmation_Out in the Search Pattern field.
5. Select the consumer proxy and click Apply Selection.
6. To add a logical port, go to the Configurations tab and select Create Logical Port.
7. Under Logical Port Name type in a name and provide a description.
8. Under WSDL Access URL, type in information you received from the service provider.
9. Select Copy Settings.
10. Select the endpoint.
11. Enter the user ID and password for authentication provided by the service provider.
In this demonstration scenario, the .NET service accepts user ID Alice_ and password _ecilA.
12. Select Save.
If the provider WSDL supports SOAP 1.2, this configuration corresponds to the NET identifier in Figure 2.
If the provider WSDL supports SOAP 1.1, this configuration corresponds to the NETS11 identifier in Figure 2.
13. If you select the provider WSDL that requires user ID and password authentication on transport level, you create logical ports that correspond to the identifiers NETAUTH (for SOAP 1.2) or NETAUTHS11 (for SOAP 1.1) in Figure 2.
33
Figure 8 Consumer security settings in SOA management
4.4 WCF PO/Confirmation Implementation
The .NET Framework 4 implementation of the PO/Confirmation scenario contains a single Visual
Studio solution. This solution includes projects for the user interface (Buyer), services that pro-
cess Purchase Orders and issue Confirmations (Seller and StandaloneSeller), as well as shared
infrastructure (CodeEditor, Common). These projects are updated, built, and deployed together
in the following instructions.
To set up the .NET Framework 4 scenario implementation and all of its supporting services, you
must perform three procedures. The procedures create the .NET Framework 4 client, the con-
firmation service, and two purchase order services. The purchase order services are used for
.NET Framework 4 to .NET Framework 4 testing, so that you can ensure your client and confir-
mation services are working before you perform interoperability tests with the actual SAP server:
1. Update and build the SAPBusinessService solution.
2. Create the SAPBusinessService and Seller applications in IIS.
3. Start the Windows Process Activation Service application [optional].
Note In all of the following procedures, NETServer is a placeholder for the hostname of the
.NET Framework 4 server in your environment and SAPServer is a placeholder for the hostname
of the SAP server in your environment. In both cases, you must obtain the correct hostname for
each server and replace NETServer and SAPServer with the correct host names.
4.4.1 WCF Solution
The SAPBusinessService solution contains the following projects and solution folders:
34
Examples: Example Purchase Order and Confirmation messages.
Metadata: WSDL for a NetWeaver Application Server deployment of Purchase Order and Confirmation services.
CodeEditor: Small editor that removes one line from the code generated for the service reference in the Common project. See section 4.4.5 for more information about this edi-tor.
Common: Features shared between the Buyer and Seller implementations.
Buyer: Implementation of the Buyer role in this scenario – contains the Web user inter-face for entering Purchase Order information, client to Purchase Order services, and Confirmation service.
Seller: Implementation of the Seller role in this scenario – a Purchase Order service that receives Purchase Order requests and sends Confirmation requests containing the re-ceived information. Use this service to confirm correct deployment and to test the NET and NETS11 (which are similar to the SAP and SAPS11 configurations without NetWeaver).
StandaloneSeller: Command-line implementation of the Seller role in this scenario. Use this service to test the NETAUTH and NETAUTHS11 configurations without NetWeaver.
The Common project includes a service reference to one of the WSDL files in the Metadata solu-tion folder. The generated code is thus available for client and service implementations else-where in the solution. To ensure compatibility with the NetWeaver implementation, optionally change the service reference properties to reference the WSDL for one deployed endpoint.
The Common project also includes constants and a custom authentication validator for the user ID/password authentication used in this scenario. Constants provide the credentials (user ID Alice_ and password _ecilA) every WCF client sends. The authentication validator is used in every WCF service. It accepts only the user ID/password combination identified in the constants.
35
Figure 9 User ID-/password constants and one example use
4.4.2 Update and build the SAPBusinessService solution
Open the SAPBusinessService solution in Microsoft Visual Studio, update it to handle the host names specific to your environment, and build the solution. This involves updating the URIs for the SAP and Microsoft servers.
1. Click Start, click All Programs, click Accessories, and then click Windows Explorer.
2. In Windows Explorer, browse to the %My Documents%\Visual Studio
2010\Projects\SAPBusinessService folder, and then double-click
SAPBusinessService.sln.
Visual Studio 2010 opens the solution.
Note If you are using Visual Studio 2008, double-click SAPBusinessService-VS2008.sln.
3. In Visual Studio, click Edit, click Find and Replace, and then click Replace in Files.
4. On the Find and Replace dialog box, in the Find what: box, type garnet2, in the Replace
with: box, type NETServer, ensure that the Look in: drop-down list displays Entire Solu-
tion, and then click Find Next.
5. On the Find and Replace dialog box, click Replace for each occurrence of garnet2 that the
tool finds.
36
Note If your IIS environment does not use the default HTTP and HTTPS ports for transmis-
sion, you must append a colon and the port number you are using to the replacement text.
For example, if you are using port 8080 for HTTP and port 8443 for HTTPS, replace
http://garnet2 with http://NETServer:8080 and https://garnet2 with https://NETServer:8443.
6. On the Find and Replace dialog box, in the Find what: box, type
https://SAPServer/sap/bc/srt/xip/sap/epm_purchaseorderrequest_in/client/service/bin
dingusernameovertransport. In the Replace with: box, type the specific URI for your SAP
configuration (obtained as described in Section 4.3.1.5 and Figure 2). Ensure that the Look
in: drop-down list displays Entire Solution, and then click Replace All.
7. On the Find and Replace dialog box, in the Find what: box, type
https://SAPServer/sap/bc/srt/xip/sap/epm_purchaseorderrequest_in/client/service/bin
dingbasicauthoverhttps. In the Replace with: box, type the specific URI for your SAP con-
figuration (obtained as described in Section 4.3.1.5 and Figure 2). Ensure that the Look in:
drop-down list displays Entire Solution, click Replace All, and then close the Find and Re-
place dialog box.
8. Click Build and then click Build Solution. When the build completes, check the status mes-
sage for Build Successful.
Note Steps 4 through 7 of this procedure update URIs in the Buyer\Web.config file and the
StandaloneSeller\App.config file in the SAPBusinessService solution.
When you build the solution, Visual Studio places the services in the correct folders. These ser-vices are:
The .NET Framework 4 user interface. You can browse to the service at http://NETServer/SAPBusinessService.
Note You must complete the procedure in Section 4.4.3 before any services are run and available for browsing.
The default purchase order service, which is primarily for .NET Framework 4 to .NET Framework 4 checks before you perform interoperability testing. You can browse to the service at http://NETServer/SAPBusinessService/Seller/PO.svc.
The command-line service that provides basic authentication configuration for the sce-nario implementation. You can start this service with the C:\bin\SAPBusinessService\Seller\bin\SAPBusinessService.exe file, though this is op-tional. If started, you can browse to the service at http://NETServer/SAPBusinessService/Seller/PO2.
The Confirmation service, where the .NET Framework 4 scenario implementation ex-pects Confirmation messages to be returned. You can browse to the service at http://NETServer/SAPBusinessService/Confirm.svc.
You can view the WSDL for each service by appending ?WSDL to the service URI. For example, browse to http://NETServer/SAPBusinessService/Confirm.svc?wsdl to view the WSDL for the Confirmation service.
4.4.3 Create the SAPBusinessService and Seller applications in IIS
Creates two applications in IIS that host the SAPBusinessService components.
37
1. Click Start, click All Programs, click Administrative Tools, and then click IIS Manager.
2. If a User Account Control dialog box appears, type in your administrator credentials if
necessary, and then click Yes.
3. In the Connections pane, expand the local computer name, expand Sites, right-click
Default Web Site, and then click Add Application....
4. In the Alias box of the Add Application dialog box, type SAPBusinessService, and
then click … beside the Physical path box.
5. In the Browse For Folder box, expand C:, click bin, click SAPBusinessService, click
OK, and then click OK again.
6. In the Connections pane, right-click the SAPBusinessService application, and then
click Add Application....
7. In the Alias box of the Add Application dialog box, type Seller, and then click … beside
the Physical path box.
8. In the Browse For Folder box, expand C:, click bin, click SAPBusinessService, click
Seller, click OK, and then click OK again.
4.4.4 Start the Windows Process Activation Service application [optional]
Optionally, starts the Windows Process Activation Service (WAS) self-hosted service using a command-line utility. This is for .NET Framework 4 to .NET Framework 4 testing only and pro-vides a .NET Framework 4 service with simple-to-configure basic authentication. Though the implementation could have enabled and configured Basic Authentication using an IIS-hosted .NET Framework 4 service, for the limited testing that you will do, this solution was much simpler to configure.
1. Click Start, click All Programs, click Accessories, right-click Command Prompt, and
then click Run as administrator.
2. If a User Account Control dialog box appears, type in your administrator credentials if
necessary, and then click Yes.
3. On the command prompt, navigate to the c:\bin\SAPBusinessService\Seller\bin folder.
4. On the command prompt, type SAPBusinessService.exe NETServer, and then press
ENTER. If you have configured IIS to use ports other than port 80 for HTTP and port 443
for HTTPS, type SAPBusinessService.exe NETServer:HTTPPortNumber NETServ-
er:HTTPSPortNumber and then press ENTER.
Note In step 4, NETServer must match the Issued To value on the self-signed HTTPS
certificate that you created in Section 3.2.2.1.
4.4.5 Special Solutions for the .NET Framework 4 Implementation
The .NET Framework 4 implementation includes the following recommendations and solutions
for issues encountered in its development. Other projects developing clients for SAP NetWeaver
services, using code generated from SAP NetWeaver WSDL, or building services to interoperate
with SAP NetWeaver clients may encounter some of these issues.
38
1. Carefully review the Error List and Output windows after building. See Section 4.4.5.1 for
information about warnings and messages expected when using this .NET Framework
solution.
2. Because SAP does not support WS-Policy 1.5, the .NET Framework 4 solution does not
include a policyVersion attribute in the <serviceMetadata
httpGetEnabled="true"/> element in service behaviors.
3. The Microsoft solution provides the ContractOverrides.cs file to ensure that auto-
generated code does not result in invalid WS-Addressing Action values. This code file
removes any Action="" instances from the OperationContractAttribute and ensures
that the .NET Framework 4 client does not send invalid WS-Addressing Action values.
The code in this file also duplicates the generated client and service classes and inter-
faces, rather than requiring you to edit them. This allows you to regenerate code without
requiring edits and eliminates the need to separately generate code for the Purchase Or-
der and Confirmation services.
4. The XML Schema for messages exchanged in this scenario places length restrictions on
many String values. The generated .NET Framework code does not enforce these re-
strictions, resulting in errors when the AS ABAP services receive overlong values. To
avoid these problems, the application code in the SAPBusinessService solution limits the
length of the affected String values.
5. The XML Schema for messages exchanged in this scenario places restrictions on
DateTime values that .NET Framework does not honor by default. To ensure correct
values in all messages sent and received, ContractOverrides.cs extends the
EPM_DateTime type with an XMLSchemaProvider and an implementation of the
IXMLSerializable interface. The IXMLSerializable implementation provides a custom se-
rialization of this type that matches the schema restrictions. The XMLSchemaProvider
informs the default serializer of the customized EPM_DateTime schema. To allow these
extensions, the CodeEditor project removes the XmlType attribute from code generated
for the service reference. (Overrides similar to those used previously in #3 are not avail-
able for a type this low in the schema hierarchy.)
4.4.5.1 Potential Warnings in Visual Studio Builds
When you build the solution, update the service reference on the purchase order service, or open particular files, the Visual Studio Error List may include warnings and messages as shown in Figure 10.
39
Figure 10 Expected Visual Studio 2010 warnings and messages
These warnings and messages occur for the following reasons:
1. If you have the Web.config file from the Buyer project open in Visual Studio, the Error List may contain the warning shown above at line 1. The schema Visual Studio uses to vali-date .NET Framework configuration files cannot handle dynamic additions such as the behavior extension used to log messages in this project.
2. If you have the App.config file from the Standalone Seller project open in Visual Studio, the Error List may contain the three messages shown above at lines 2 through 4. The schema Visual Studio uses to validate .NET Framework configuration files does not in-clude the <supportedRuntime /> element or its content.
3. If you update the service reference on the Purchase Order service in the Common pro-ject and after subsequent builds, the Error list may contain the three warnings shown above at lines 5 through 7. NetWeaver Application Server uses proprietary WS-Policy assertions when describing services. .NET Framework 4 does not support these asser-tions or the WSDL locations where some appear. Fortunately, these particular asser-tions affect only SAP-to-SAP communication and ignoring them does not lead to interop-erability issues. The warnings are thus expected and ignorable.
4.4.6 An Alternate Approach
The SAPBusinessService solution was developed WSDL-first. That is, the solution contains
clients and services that were all generated using SAP-provided WSDL. An alternative ap-
proach is known as “code-first”. In this approach, developers create the service first, then con-
40
figure and expose this interface as a Web service. Please see Figure 11(from
http://msdn.microsoft.com/en-us/library/bb756905.aspx) for more information on these terms.
Figure 11 Code-first and WSDL-first defined
When developing services intended to interoperate with SAP NetWeaver Application Server cli-
ents using the code-first approach:
Use the supported standards listed in section 1.3, Supported Standards. For example,
when you enable metadata retrieval, use WS-Policy 1.2 as described in workaround 2 in
section 4.4.5.
The basicHttpBinding uses the protocol standards listed, but the SAP platform does not
support the binding’s WS-SecurityPolicy version. This specification is used in a WSDL
when you use any value but None for the security mode. This binding is therefore useful
for non-secure request-response operations meant to interoperate with SAP clients.
The wsHttpBinding includes protocol choices such as <reliableSession enabled="true"
/>, which uses protocols that the SAP platform does not support. The basic settings for
this binding are useful for non-secure request-response operations meant to interoperate
with SAP clients.
The ws2007HttpBinding uses only the protocol standards listed. However, it does in-
clude a few options that are not interoperable with the SAP platform. The following is an
example of a non-interoperable option.
<security mode=”Message”>
<message clientCredentialType=”Windows”/>
</security>
The customBindings options cover both supported and unsupported standards. Most
protocol choices, if enabled, should be set to non-default values for interoperability with
the SAP platform. In the following example binding, note the use of the reliableMessag-
ingVersion and messageSecurityVersion attributes.
<configuration>
<system.serviceModel>
<bindings>
<customBinding>
<binding name="Username">
Code-first — Service interfaces are written using a supporting CLR language, such as C# or Vis-
ual Basic .NET, and then declarative programming is used to specify capabilities and message
formats.
WSDL-first — XML Schema and Web Services Description Language (WSDL) documents that
describe the service are created first, then a tool, such as Svcutil.exe, is used to generate im-
plementation classes. (Alternately, classes can also be generated from a running service that
publishes a metadata exchange (MEX) endpoint by using Svcutil.)
41
<reliableSession
reliableMessagingVersion="WSReliableMessaging11"/>
<security authenticationMode="UserNameOverTransport"
messageSecurityVersion="WSSecurity11WSTrust13WSSecureConversation13WSSec
urityPolicy12BasicSecurityProfile10"/>
<mtomMessageEncoding/>
<httpsTransport/>
</binding>
</customBinding>
</bindings>
</system.serviceModel>
</configuration>
Note You can find this example binding in the Buyer\Web.config file and the
StandaloneSeller\App.config file in the Visual Studio solution.
o Other usable messageSecurityVersion values include WSSecuri-
ty10WSTrust13WSSecureConversation13 and WSSecuri-
ty11WSTrust13WSSecureConversation13WSSecurityPolicy12.
o Do not use messageVersion=”Soap11WSAddressingAugust2004” or mes-
sageVersion=”Soap12WSAddressingAugust2004” in the
<mtomMessageEncoding/> or <textMessageEncoding/> elements.
o Do not use the <binaryMessageEncoding> element.
o Do not use transport elements other than <httpTransport/> and <http-
sTransport/>.
Create a different contract for one-way operations than the one you use for request-
response operations.
Use WS-RM 1.1 for contracts that contain one-way operations.
Do not use WS-RM for contracts that contain request-response operations.
Do not create any contracts that contain empty Body elements.
4.5 Running and Monitoring the Scenarios
4.5.1 Setting up Simulation in AS ABAP
Before running the scenarios, set up the Purchase Order Processing simulation in AS ABAP.
The following XSD elements are included in all WSDLs.
Figure 12 Relevant XSD elements for simulation
To trigger the simulation in AS ABAP, the following settings are necessary in the Purchase Or-der Request message:
42
<TestDataIndicator>true</TestDataIndicator>
<BuyerID>X</BuyerID> , X can be set to NET or NETS11 or NETAUTH or NE-TAUTHS11
<SellerID>Y</SellerID> , Y can be set to SAP or SAPS11 or SAPAUTH or SA-PAUTHS11
In the SAP provider, this information triggers the simulation and determines the logical port for the outbound confirmation response message.
To create this configuration
1. In AS ABAP, call the data browser (transaction SE16), type SEPM_PI_RECEIVER in
the table name field and select .
2. In the PROXY_NAME field, type in CO_EPM_PO_CONFIRMATION_OUT. This is the in-ternal name of the consumer proxy, which sends out the purchase order confirmation.
3. In the PORT_NAME field, type in the name of the logical port you defined for the con-sumer proxy EPM_PurchaseOrderConfirmation_Out.
4. In the SENDER_ID field, type in SAP, SAPS11, SAPAUTH, or SAPAUTHS11.
5. In the RECEIVER_ID field, type in NET, NETS11, NETAUTH, NETAUTHS11
Note Both services and consumer proxies are implemented in the AS ABAP. You can also use this table to set up SAP-to-SAP communication, before testing interoperability with WCF.
4.5.2 Testing the PO/Confirmation Scenario
You can use the .NET Framework 4 implementation that you configured in the section 4.4 to test in-
teroperability with SAP on two levels. The first is to test the .NET Framework 4 implementation
to ensure it works correctly in isolation. The second is to test interoperability with the SAP
NetWeaver Application Server. You can use the following procedure to perform both tests.
To test the .NET Framework 4 client that accesses the SAP service
1. Click Start, click All Programs, and then click Internet Explorer.
2. In the Address bar, type http://NETServer/SAPBusinessService and then press ENTER. The .NET Framework 4 scenario implementation appears.
43
Figure 13 Initial page of ASP.NET interface for PO/Confirmation scenario
3. To add an item into the purchase order message, in the Price box type a price, in the Description optionally type a description for the item, and then click Add. This step adds an item to the purchase order and displays a grid that contains all of the items in the current purchase order. You can repeat this step to add as many items to the purchase order as you want.
Note The Price box must contain a number. If the price you typed in is not valid or you left the Price box empty, a white asterisk appears and you must type in a valid value and click Add again.
Note You can send an empty purchase order message by leaving the Price and Description boxes empty and then skipping to step 5.
4. In the purchase order grid, you can edit or remove items that you added previously. If you edit an item, click Update to save the edited item to the purchase order.
Note When you edit an item, the Price box must contain a number. If the price you typed in is not valid or you left the Price box empty, a red asterisk appears and you must type in a valid value and click Update again.
44
Figure 14 Unable to add price that is not a decimal amount
5. After you have typed in all items that you want to include in the purchase order, select a buyer from the Source buyer list, select a seller from the Target seller list, click Submit Purchase Order.
Note You select buyers in the Source Buyer drop-down list and you select sellers in the Target Seller drop-down list. Buyers visible in the implementation all begin with NET. The default is NET. Sellers visible in the implementation begin with both NET and SAP. The default is SAP. .NET Framework 4 sellers are only used for .NET Framework 4 to .NET Framework 4 testing on the NETServer host. For a complete list of these configura-tions, see Figure 2 earlier in this guide.
Note Any items that you have not saved using Add or item edits you have not saved using Update will not be included in the purchase order message.
45
Figure 15 Ready to submit a purchase order that contains 5 items
6. Review the purchase order message on the .NET to SAP NetWeaver Purchase Order page, and then click Review Confirmation message to view the confirmation message sent from the SAP service.
7. To add more items to the purchase order, click Review Purchase Order message, click Start again, and repeat steps 3 through 5.
Note When you click Review Purchase Order and then click Start again, the application returns to the grid that displays all items in the current purchase order. You can repeat these steps to add as many items to the purchase order as you want.
8. To return to the original form in the application and start a new purchase order, click Reset on any page in the application. Then repeat all previous steps in this procedure.
Note Reset appears in the bottom right corner of every form in the application. On the Review Confirmation page, you must scroll to the far right of the page to see Reset.
Use the .NET Framework 4 scenario implementation to send Purchase Order messages to the seller of your choice. There are more buyers than there are sellers because only .NET Frame-work 4 buyers are shown. This tool displays the purchase order message, the confirmation mes-sage returned from the seller, and all other messages associated with this scenario. These mes-sages are mostly boilerplate and auto-generated GUIDs. The form in this procedure supplies only enough message content so that you can recognize the items you input when you read the exchanged messages.
46
4.5.3 Service Monitoring in SAP NetWeaver
Monitor incoming and outgoing messages in monitor Integration Engine – Monitoring (transac-tion SXMB_MONI).
1. In AS ABAP, logon to the client where your Web service is running.
2. Select Integration Engine – Monitoring (transaction SXMB_MONI).
3. Select the interface name you want to monitor, for example EPM_PurchaseOrderConfirmation_Out, and select Execute.
Figure 16 Message monitor for processed XML messages
4. Additionally, you can use the Web Service Utilities (transaction SRT_UTIL) to monitor message processing of asynchronous messages, test Web service providers or set logs and trace levels.
More information: Web Service Logging and Tracing
4.5.4 Service Monitoring in WCF
When you install the Windows SDK, the svcTraceViewer.exe utility is only associated with files
that have the .svclog extension. For convenient WCF monitoring, you should consider associat-
ing this utility to files that have the .e2e file extension as well. You can perform the following pro-
cedure after you run any test described in this document.
To associate .e2e files with the svcTraceViewer.exe utility
1. Click Start, click All Programs, click Accessories, and then click Windows Explorer.
2. In Windows Explorer, navigate to C:\WCFLogs.
3. Right-click any file with the .e2e file extension, and then click Open with….
4. In the Open with dialog box, click Browse.
5. On 32-bit systems, in the Open with… dialog box, browse to C:\Program Files\Microsoft
SDKs\Windows\v7.0\Bin. On 64-bit systems, in the Open with… dialog box, browse to
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64.
6. Click svcTraceViewer.exe, click Open, and then click OK.
When you monitor your client or service in this scenario using the svcTraceViewer.exe utility,
review the following files:
SAPBusinessService.Buyer.e2e. This file contains output from the client that sends the
purchase order message to SAP and the service that receives a confirmation message
from the SAP client.
47
SAPBusinessService.Seller.e2e. This file contains output from the service that receives
the purchase order message and then acts as a client to send the confirmation message.
Again, this client and service are used primarily for .NET Framework 4 to .NET Frame-
work 4 testing.
SAPBusinessService.Seller.Console.e2e. This file contains output from the command-
line purchase order service.
5 Ping/Echo Scenarios
The 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 scenar-ios 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 ref-
erences 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 in-
teroperates with a particular 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 NetWeav-
er Application Server and you should avoid using them. These scenarios are called out in the
section that describes them and Figure 17.
48
Scenario Section Interoperable between
NetWeaver Application
Server ABAP and .NET
Framework
Using Authentication with
UsernameToken (WSS Username-
token)
5.3.2 Yes
Using Authentication with X.509
Certificate on Message Level
5.3.3 Yes
Using Authentication with Issued
Token for Single Sign-On
5.3.4 Yes (2 scenarios)
Further Combinations 5.3.5 Only with SAP consumers
One-way Reliable Messaging 5.4.1 and 5.4.2 Yes
Request-response Reliable
Messaging
5.4.3 and 5.4.4 No
Idempotent Service Handling 5.4.5 Not tested
Base Data Type Testing 5.5.1 Yes
Complex Data Type Testing 5.5.2 Yes
Message Transmission Optimiza-
tion Mechanism (MTOM)
5.6 Yes (2 scenarios)
WS-Addressing 5.7 2 scenarios, 1 yes
Requests and Responses that Con-
tain Application-Defined Headers
5.8.3 Only with SAP consumers
Request with Empty Body Element 5.8.4 No
Figure 17 Ping/Echo scenarios listing
5.1 Testing Procedure Template: Microsoft
Use 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 scenari-
os, replace Security.WsSecurity with the feature you want to test and replace UserName-
OverTransport with the scenario you want to test.
To test interoperability scenarios between Microsoft and SAP
1. Click Start, click All Programs, and then click Internet Explorer.
2. In the address bar, type http://NETServer/endpoints, and then press ENTER.
3. In the Feature drop-down list, select Security.WsSecurity, and then click Click here to
invoke WCF client for Security.WsSecurity.
49
4. Click the new tab, and then expand the UserNameOverTransport scenario.
5. Update the Service Address box and WSDL URI box as appropriate for the SAP
NetWeaver service endpoint.
6. Select the UserNameOverTransport checkbox, and then click Test Selected Scenari-
os at the bottom of the page.
7. On the results page, review the results of the test, which can either be Pass or Fail. Ex-
pand UserNameOverTransport to view detailed results.
8. To see more details, you can expand Debug Log, Request Messages, Response
Messages, and any messages in the request and response messages lists.
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:
The physical path to the source files for the feature area.
The URI for the WSDL associated with the scenario. Most, but not all, of these scenarios
are WS-Policy implementations. The scenario descriptions also indicate whether the
scenario implements WS-Policy.
The physical path to the file that contains binding configuration for the scenario. In most
cases this is a Web.config file, but in some cases the configuration is code-generated.
Other information is included in the descriptions on an as-required basis.
5.2 Testing Procedure Template: SAP
The PingEcho_Scenarios.xlsx Excel spreadsheet provides an overview of all Ping/Echo scenari-os 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:
Target Version: Indicates the SOAP version and determines which test template to use
Attachment: Indicates the test area
o Attachment 1: Security test with WS Security, SecureConversation and WS-Trust
o Attachment 2: WS-RM testing
o Attachment 3: Data type and WSDL style tests
o Attachment 4: MTOM and WS-Addressing tests
Client: Indicates the client in the scenario (MS,SAP)
Scenario: Scenario identifier
SAP Scenario Name
Microsoft Scenario Name
Name of the SAP consumer proxy
50
Name of the SAP service definition
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:
1. Select a scenario you want to look at from the PingEcho_scenarios.xlsx Excel spread-sheet and find the SAP service definition.
2. Go to SOA Management (transaction SOAMANAGER), select the service and define an endpoint for the service.
You can find the detailed settings for the endpoint in the following sections.
3. To run the service from the .NET Framework side, you need the following information:
WSDL URL of the service
To obtain the URL, in SOA Management (transaction SOAMANAGER), click the link Display selected Bindings or Service’s WSDL URL on the Overview tab and copy the link.
Use the WSDL format WS_Policy. Additionally you can generate a WSDL for ei-ther SOAP 1.1 or SOAP 1.2.
Some scenarios might require the document_wrapped WSDL document style. In the WSDL URL, replace document with document_wrapped.
Service URL
Open the WSDL document of the service in a browser.
Go to the bottom of the document and copy the link provided in the location at-tribute of the address element in the port section.
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:
1. Select a scenario you want to look at from the PingEcho_scenarios.xlsx Excel spread-sheet and find the SAP consumer proxy.
2. In SOA Management (transaction SOAMANAGER), configure a logical port for this con-sumer proxy.
Use the WSDL provided by Microsoft.
You get the WSDL from the WCF Interop Endpoint Browser (http://NETServer/endpoints).
3. In the Data Browser (transaction SE 16) type in Table Name SRT_BZT_CFG_P2P and select Create.
4. Make an entry for the scenario you want to test.
51
Figure 18 Input parameters for Ping/Echo testing
a. In the CFG_VARIANT field, type in the SOAP version (SOAP11 or SOAP12). This corresponds with the target version in the PingEcho_scenarios.xlsx Excel spreadsheet.
b. In the SCENARIO field, type in the name of the SAP scenario you want to test. Find the scenario name in the PingEcho_scenarios.xlsx Excel spreadsheet in column Scenario.
c. Type SAP in the SCENARIO_CLIENT field.
d. Type NET in the SCENARIO_ENDPOIN field.
e. Type the name of the logical port you created in the LP field.
Figure 19 Table SRT_BZT_CFG_P2P
5. To run the scenario, call transaction SRT_BIZTALK_TEST2.
The following user interface is displayed:
52
Figure 20 Accessing a Ping/Echo scenario in AS ABAP
a. Select Point-to-point.
Do not select Mediated via PI, this option involves SAP NetWeaver Process In-tegration(PI). SAP NetWeaver PI is not in scope for this guide and the described scenarios cannot be used with a PI system of version SAP NetWeaver 7.0, EHP 2. This option will be made available with the next version of SAP NetWeaver PI.
b. Click the Target version you want to use.
Depending on the target version, a list is displayed:
53
Figure 21 Selecting a Ping/Echo Scenario
6. Select the scenario you want to test. You can find the scenario name in the SAP Scenar-io Name column in the PingEcho_scenarios.xlsx Excel spreadsheet.
The Test values section is not relevant.
7. Select Execute.
The test result is displayed and you can select Display more Details to find further in-formation.
54
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 Security Configurations
You can use the following security features for scenarios between .NET Framework 4 and AS ABAP.
Authentication options:
Authentication with UsernameToken.
Authentication with X.509 certificate at the message level.
Authentication with issued token for Single Sign-On obtained by a security token service (STS).
For secure communication between consumer and provider.
Using SSL for protection at the transport level.
This option is already described in the preceding PO/Confirmation scenarios.
Using WS-Security for protection at the message level.
5.3.1 Handling Certificates for Encryption and Authentication in AS ABAP
For (signature) and authentication with certificates encryption, the following additional certificates are required.
1. Find the certificates in C:\binaries.x86chk\CDF\Test\wcf\Suite\XwsInterop\scripts\deploy after unzipping the Ping/Echo suite downloaded from http://code.msdn.microsoft.com/WCFInterop.
2. Save the certificates to your file system.
55
3. In AS ABAP, go to Trust Manager (transaction STRUST).
4. Use dfault(Alice).pse for signature and for authentication with certificate, use wsskey(Bob).pse for encryption.
5. Import Bob:
a. From the menu select PSE and Import and select the file for Bob.
b. From the menu select PSE and Save as… and WS Security.
c. In the DFAULT field select WSSKEY and (Enter).
6. Import Alice:
a. From the menu select PSE and Import and select the file for Alice.
b. From the menu select PSE and Save as… and WS Security.
c. In the DFAULT field select DFAULT and (Enter).
d. Type a record in table USREXTID to map the certificate to the SAP technical user that is used for the Web service call. Use for example, the table maintenance transaction SM30, view VUSREXTID.
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
1. In AS ABAP, go to Trust Manager (transaction STRUST).
2. If AS ABAP is the provider, export the public key certificate that the consumer should use for encryption from the WS-Security PSE WS Security Keys to a file and hand it over to the consumer.
Double click on WS Security WS Security Keys and select (Export certificate).
3. If AS ABAP is the consumer, import the encryption certificate received from the provider into the WS Security PSE Other System Encryption Certs.
Double click on WS Security Other System Encryption and select (Import certifi-cate.)
To manage certificates in AS ABAP Trust Manager for authentication on message level (and signature)
1. If AS ABAP is the provider, agree with the service consumer on a CA certificate and im-port it into WS-Security PSE WS Security Keys.
2. Type a record in table USREXTID to map the certificate to the SAP technical user that is used for the Web service call. Use for example, the table maintenance transaction SM30, view VUSREXTID.
More information: Maintaining the User Mapping for Incoming Connections that Use Au-thentication
More information: Trust Manager
56
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 Trust section.
5.3.2.1 Settings in AS ABAP Provider
For 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 SOAMANAG-ER):
On the Provider Security tab, select the following:
Figure 23 Provider security settings for symmetric message encryption and user ID/password authentica-tion
Provide the user ID and password to the consumer.
57
5.3.2.2 Settings in AS ABAP Consumer
In SOA Management (transaction SOAMANAGER), on the Service Administration tab page, choose the Single Service Configuration link.
1. Find the consumer proxy to access the service endpoint and for which you want to define a logical port.
2. Select the consumer proxy in the list of search results and choose Apply Selection. 3. On the Configurations tab page, select the Create Log. Port button. 4. Specify the following in the dialog box:
1. The name of the logical port and its description. 2. For configuration type, select the WSDL-Based Configuration button. 3. Under WSDL access settings, select the Via HTTP Access radio button. 4. Under WSDL location, type in the URL of WSDL. 5. If required, provide the user ID and password for WSDL access. 6. Select the endpoint. 7. Select Apply Settings.
5. In the User Name field, specify the user name, and in the Password field, type in the password of the user for authentication provided by the service provider.
6. In the Certificate field, select the PSE.
Figure 24 Consumer security settings for symmetric message encryption and user ID/Password authenti-cation
5.3.2.3 SAP Scenario Details
SAP Provider
Service Definition: IPingService
SAP Consumer
Consumer Proxy: CO_SRT_IPING_SERVICE_OUT
5.3.2.4 Microsoft Scenario Details
Microsoft name: Username over Certificate
Feature area: Security.WsSecurity
Scenario: UXD_Addressing10 (which means Username over Certificate with derived
keys and WS-Addressing 1.0)
58
Source folder: C:\test\wcf\src\suite\XwsInterop\Security\WsSecurity
The specific WS-Policy of interest is UXD_Addressing10_IPingService_policy in
http://NETServer/Security_WsSecurity_Service_Indigo/WsSecurity11.svc?wsdl=wsdl0
Specific configuration binding: UXD_Addressing10 in the
C:\test\wcf\src\suite\XwsInterop\Security\WsSecurity\service\indigo\Web.Config file.
5.3.3 Using Authentication with X.509 Certificate on Message Level
Instead 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 en-cryption. 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 Service
Select 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 Service
In transaction SOAMANAGER, type in:
In the Encryption Certificate field, select the PSE for encryption.
In the X.509 Certificate field, select the PSE for authentication.
5.3.3.3 SAP Scenario Details
SAP Provider
59
Service Definition: IPingService
SAP Consumer
Consumer Proxy: CO_SRT_IPING_SERVICE_OUT
5.3.3.4 Microsoft Scenario Details
Details of specific scenario: Mutual X.509 Certificate Authentication; Sign Encrypt, De-
rived Keys, and Signature Confirmation features enabled; WS-Security 1.1.
Feature area: Security.WsSecurity.
Scenario: XD-SEES_Addressing10.
Source folder: C:\test\wcf\src\suite\XwsInterop\Security\WsSecurity.
Specific WS-Policy of interest: XD-SEES_Addressing10_IPingService_policy in
http://NETServer/Security_WsSecurity_Service_Indigo/WsSecurity11.svc?wsdl=wsdl0.
Specific configuration binding: XD-SEES_Addressing10 in the
C:\test\wcf\src\suite\XwsInterop\Security\WsSecurity\service\indigo\Web.Config file.
5.3.4 Using Authentication with Issued Token for Single Sign-On
The 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 au-thentication at the provider.
SAP supports the following SAML-based scenarios:
Endorsing issued tokens: STS Scenario with Symmetric Key for Endorsing Signature (Authentication Only).
Tokens for signature, encryption and authentication: STS Scenario with Symmetric Key for Message Protection (Signature, Encryption, and Authentication).
Tokens as protection token: STS Scenario with Asymmetric Consumer Key for Confirm-ing Signature (Authentication Only).
This scenario was not part of the interoperability tests.
5.3.4.1 AS ABAP Provides a Service
Some 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 sym-metric encryption.
Select the following options in SOA Management (transaction SOAMANAGER) on the Provider Security tab.
60
Figure 26 Provider security settings for SSO scenario 1
Figure 27 Provider security settings for SSO scenario 2
61
5.3.4.1.1 Settings in AS ABAP Consumer
AS ABAP is the consumer: Configuring SSO/STS Scenario SAML Holder-of-key in the Consum-er System AS ABAP
5.3.4.2 SAP Scenario Details
5.3.4.2.1 Scenario 1
SAP Provider
Service Definition: IPingServiceContract
SAP Consumer
Consumer Proxy: CO_SRT_IPING_SERVICE_CONTR_OUT
5.3.4.2.2 Scenario 2
SAP Provider
Service Definition: IPingServiceContract
SAP Consumer
Consumer Proxy: CO_SRT_IPING_SERVICE_CONTR_OUT
5.3.4.3 Microsoft Scenario Details
The 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.
5.3.4.3.1 Scenario 1
Username over HTTPs, Asymmetric key SAML token over HTTPS
Details of specific scenario: Username over Transport from client to STS. STS issues
asymmetric key SAML token. That token is carried over HTTPS from client to service (re-
lying party)
Feature area: Security.SecureExchange
Scenario: OasisScenario9
Source directory: C:\test\wcf\src\suite\XwsInterop\Security\SecureExchange
Specific service WS-Policy of interest: CustomBinding_IPingServiceContract4_policy in
http://NETServer/Security_SecureExchange_FederatedService_Indigo/Ping.svc?wsdl
Specific configuration binding: OasisScenario9Binding in the
C:\test\wcf\src\suite\XwsInterop\Security\SecureExchange\FederatedService\Indigo\Web
.config file.
Specific STS WS-Policy of interest: CustomBinding_IWSTrust13Sync_policy in
http://131.107.153.205:8080/trust?wsdl=wsdl0
Additional details about this STS are not currently available.
62
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 in-
teroperability scenarios, see the Supported Standards section in this document.
5.3.4.3.2 Scenario 2
Mutual Certificate (WSS11), Asymmetric key SAML token for Certificate
Details of specific scenario: Certificate over Transport from client to STS. STS issues
asymmetric key SAML token. That token carried using mutual certificate message pro-
tection from client to service (relying party).
SAML token used as an endorsing supporting token – authentication only. HTTPS (SSL
within that protocol) provides protection between client and STS. Mutual certificates pro-
vide protection between client and service (relying party).
Feature area: Security.SecureExchange
Scenario: OasisScenario10_EncSig
Source folder: C:\test\wcf\src\suite\XwsInterop\Security\SecureExchange
Specific WS-Policy of interest: CustomBinding_IPingServiceContract16_policy at
http://NETServer/Security_SecureExchange_FederatedService_Indigo/Ping.svc?wsdl
Specific configuration binding: OasisScenario10Binding_EncSig in the
C:\test\wcf\src\suite\XwsInterop\Security\SecureExchange\FederatedService\Indigo\Web
.config file.
Specific STS WS-Policy of interest: CustomBinding_IWSTrust13Sync1_policy at
http://131.107.153.205:8080/trust?wsdl=wsdl0
Additional details about this STS are not currently available.
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 Combinations
You 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, signa-ture encryption, and header encryption of the WS-Security 1.1 standard.
If a request contains the signature, the response confirms the contained signature. The signa-ture 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.
63
Figure 28 Additional external signature and header protection
5.3.5.1 SAP Scenario Details
SAP Provider
Custom headers are not supported on SAP provider side.
SAP Consumer
Consumer Proxy: CO_IPING_SERVICE_HEADER_ONLY_E
5.3.5.2 Microsoft Scenario Details
Details of specific scenario: Mutual X509 Certificate Authentication, Sign Encrypt, Derived
Keys, Encrypted Header, Signature Confirmation.
Feature area: Security.WsSecurity.
Scenario: XD-SEES_HeaderOnly.
Source folder: C:\test\wcf\src\suite\XwsInterop\Security\WsSecurity.
Specific WS-Policy of interest: XD-SEES_IPingServiceHeaderOnlyEncryptAndSign_policy in
http://NETServer/Security_WsSecurity_Service_Indigo/WsSecurity11HeaderOnly.svc?wsdl=wsdl0
.
Specific configuration binding: XD-SEES_Addressing103 in the
C:\test\wcf\src\suite\XwsInterop\Security\WsSecurity\service\indigo\Web.Config file.
5.4 Reliability
5.4.1 SAP Reliable Messaging
Information 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
Service Definition: IPing
3 This scenario uses the same .NET configuration as that in section 5.3.3. Difference is encrypted application header
in the contract for the tested operation.
64
SAP Consumer
External Name: IPingOut
5.4.2 Microsoft Reliable Messaging Scenario
The preceding Business scenario uses the protocols found in this scenario.
Feature area: ReliableMessaging
Scenario: OneWay_SecureReliable_Anonymous_SOAP12_WSAddressing10_RM11
Source folder: C:\test\wcf\src\suite\XwsInterop\ReliableMessaging
Specific WS-Policy of interest: CustomBinding_IPing12_policy in
http://NETServer/ReliableMessaging_Service_WSAddressing10_Indigo/OneWay.svc?ws
dl
Specific configuration binding: SecureRelia-
ble_Anonymous_Soap12_WSAddressing10_RM11_Binding in the
C:\test\wcf\src\suite\XwsInterop\ReliableMessaging\Service_WSAddressing10\Indigo\We
b.config file.
5.4.3 SAP Reliable Request-Response Patterns
AS ABAP does not support reliable request-response patterns. SAP introduced idempotent ser-
vice handling instead. Find more information about idempotent services in the Idempotent Ser-
vice Handling at SAP section.
5.4.4 Microsoft Request-Response, Reliable Messaging Using SOAP 1.2 Scenario
This 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.
Feature area: ReliableMessaging
Scenario: RequestReply_Reliable_Anonymous_Soap12_WSAddressing10_RM11
Source folder: C:\test\wcf\src\suite\XwsInterop\ReliableMessaging
Specific WS-Policy of interest: CustomBinding_IEchoString8_policy in
http://NETServer/ReliableMessaging_Service_WSAddressing10_Indigo/RequestReply.svc?wsdl.
Specific configuration binding: Relia-
ble_Anonymous_Soap12_WSAddressing10_RM11_Binding in the
C:\test\wcf\src\suite\XwsInterop\ReliableMessaging\Service_WSAddressing10\Indigo\We
b.config file.
5.4.5 Idempotent Service Handling at SAP
AS ABAP does not support reliable request-response communication based on the WS-RM standard. SAP recommends using the idempotent service handling instead.
65
Service Consumer /
Client
Service Consumer /
Client
Service Consumer
/ Client
Service Provider /
Service
Service Provider /
Service
Service Provider /
Service
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 request-ed. 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 applica-tion 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 SAP
To ensure that a service is idempotent, you have to do the following:
As a service consumer, use the MessageHeader element and its sub-element UUID in the services’ request messages.
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.
66
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.
Before calling the idempotent services, use transaction WSIDPADMIN (Administration of Idempotent Service Layer) to configure the underlying framework, essentially the period for which the system keeps responses for already processed service calls.
Now, a consumer can safely re-send request messages.
Incorporate this retry decision in the consumer application's logic, using appropriate con-sumer application code, model, or, if the underlying framework already supports retry, by appropriate parameterization of the call to the framework when issuing the (first) service call.
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 situa-tion.
5.4.5.2 Microsoft
An 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 correct-ly 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 for-mat of an ABAP application using the internal UUID format it expects. Figure 30 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 Mes-sageHeader, 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.
67
Figure 30 UUID validation
5.5 Data Types
5.5.1 Base Data Type Testing
SAP 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.
68
5.5.1.1 Requests and Responses that Contain XSD Float, Double, or Decimal Data Types
If 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 ap-plication layer.
5.5.1.2 Requests and Responses that Contain XSD Long, unsignedLong, and unsignedInt Datatypes
In AS ABAP during generation xsd_long (64-bit signed integers), xsd:unsignedLong (un-
signed 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:
Map xsd:long (64-bit signed integers) to DEC(19).
Map xsd:unsignedLong (unsigned integer of 64 bits) to DEC(20).
Map xsd:unsignedInt (unsigned integer of 32 bits) to DEC(10).
5.5.1.3 Base Datatype Testing Scenario SAP
SAP Provider
Service Definition: IBaseDataTypesDocLitB
SAP Consumer
Consumer Proxy: CO_SRT_IBDT_DOCLITB_OUT
5.5.1.4 Base DatatypeTesting using .NET Framework 4 XML Formatter and Document Literal Encoding Scenario
Feature area: SoapWsdl.BaseDataTypes.XmlFormatter.DocLitBare
Scenario: RetDouble and RetULong
Source folders: C:\test\wcf\src\suite\XwsInterop\Common\Indigo\SoapWsdl\BaseDataTypes provides test values for each data type and C:\test\wcf\src\suite\XwsInterop\SoapWsdl\BaseDataTypes\XmlFormatter implements the client and service with the client relying on values from Common folder.
Specific WSDL: http://NETServer/SoapWsdl_BaseDataTypes_XmlFormatter_Service_Indigo/BaseDataTypesDocLitB.svc?wsdl
Note WS-Policy is not used with this scenario.
Specific configuration binding: Code-supplied configuration can be found in the C:\test\wcf\src\suite\XwsInterop\SoapWsdl\BaseDataTypes\XmlFormatter\service\Indigo\ BaseDataTypesServiceHostFactory.cs file.
5.5.2 Complex Data Type Testing
5.5.2.1 Requests and Responses that Contain Arrays Using xsi:nil
In 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.
69
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 SAP
SAP Provider
Service Definition: IComplexDataTypesDocLitB
SAP Consumer
Consumer Proxy: CO_SRT_ICDT_DOCLITB_OUT
5.5.2.3 Complex Data Type Testing Scenario Microsoft
Feature area: SoapWsdl.ComplexDataTypes.XmlFormatter.DocLitBare
Scenario: RetArrayString2D
Source folders: The
C:\test\wcf\src\suite\XwsInterop\Common\Indigo\SoapWsdl\ComplexDataTypes folder
provides test values for each data type and the
C:\test\wcf\src\suite\XwsInterop\SoapWsdl\ComplexDataTypes\XmlFormatter folder im-
plements the client and service with the client relying on values from the Common folder.
Specific WSDL:
http://NETServer/SoapWsdl_ComplexDataTypes_XmlFormatter_Service_Indigo/Comple
xDataTypesDocLitB.svc?wsdl
Note WS-Policy is not used with this scenario.
Specific configuration binding: Code-supplied configuration can be found in the
C:\test\wcf\src\suite\XwsInterop\SoapWsdl\ComplexDataTypes\XmlFormatter\Service\Ind
igo\ComplexDataTypesServiceHost.cs file.
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, be-cause the message is smaller and parsing overhead is reduced.
5.6.1 SAP
All SAP providers support XOP optimization, there is no configuration necessary.
SAP consumers can choose to use XOP optimization when offered by the provider.
70
Figure 31 Consumer proxy configuration for optimized XML transfer
5.6.1.1 MTOM with WS-Security 1.0 (Mutual certificate authentication) Scenario
SAP Provider
Service Definition: IMtomTestLite
SAP Consumer
Consumer Proxy: CO_SRT_IMTOM_TEST_LITE_OUT
5.6.1.2 One-way reliable messaging using SOAP 1.2, composed with MTOM Scenario
SAP Provider
Service Definition: IMtomTestLite
SAP Consumer
Consumer Proxy: CO_SRT_IMTOM_TEST_LITE_OUT
5.6.2 Microsoft
The 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 sim-pler because it uses a configuration file instead.
5.6.2.1 MTOM with WS-Security 1.0 (Mutual certificate authentication) Scenario
Feature area: MTOM
Scenario: Soap12Utf8WithSecurityEnabled
C:\test\wcf\src\suite\XwsInterop\MTOM
Specific WS-Policy of interest is CustomBinding_IMtomTestLite_policy in http://NETServer/MTOM_Service_Indigo/Soap12Utf8WithSecurity.svc?wsdl
Specific configuration binding: Code-supplied configuration can be found in the C:\test\wcf\src\suite\XwsInterop\MTOM\Service\Indigo\MtomServiceHost.cs file, specifi-
71
cally the MtomServiceHostSoap12Utf8WithSecurityEnabledFactory and MtomService-HostSoap12Utf8WithSecurityEnabled classes.
5.6.2.2 One-way reliable messaging using SOAP 1.2, composed with MTOM Scenario
Feature area: ReliableMessaging
Scenario: One-
Way_Reliable_Anonymous_SOAP12_WSAddressing10_RM11_ContractUsesByteArray
Source folder: C:\test\wcf\src\suite\XwsInterop\ReliableMessaging
Specific WS-Policy of interest: CustomBinding_IPingByteArray1_policy at
http://NETServer/ReliableMessaging_Service_WSAddressing10_Indigo/OneWay.svc?ws
dl
Specific configuration binding: Relia-
ble_Anonymous_Soap12_WSAddressing10_RM11_ContractUsesByteArray_Binding in
the
C:\test\wcf\src\suite\XwsInterop\ReliableMessaging\Service_WSAddressing10\Indigo\We
b.config file.
5.7 WS-Addressing
WS-Addressing defines a standard mechanism for identifying and exchanging Web services messages between multiple endpoints.
5.7.1 SAP
SAP 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 31 Consumer service configuration for setting wsa:Action
5.7.1.1 Request-response WS-Addressing with Anonymous ReplyTo, SOAP 1.2 Scenario
SAP Provider
Service Definition: Echo1
SAP Consumer
72
Consumer Proxy: CO_SRT_ECHO_OUT
5.7.1.2 One-way WS-Addressing with Anonymous ReplyTo, SOAP 1.2 Scenario
SAP Provider
Service Definition: Notify
SAP Consumer
Consumer Proxy: CO_SRT_NOTIFY_OUT
5.7.2 Microsoft
5.7.2.1 Request-response WS-Addressing with Anonymous ReplyTo, SOAP 1.2 Scenario
This example is interoperable between the .NET Framework 4 and SAP NetWeaver platforms.
Feature area: WSAddressing
Scenario: Test1231
Source folder: C:\test\wcf\src\suite\XwsInterop\WSAddressingCR
Specific WS-Policy of interest: CustomBinding_Echo1_policy at
http://NETServer/WSAddressingCR_Service_WCF/WSAddressing10.svc?wsdl=wsdl1
Specific configuration binding: Code-supplied configuration can be found in the
C:\test\wcf\src\suite\XwsInterop\WSAddressingCR\Service\WCF\WSAddressingCRServi
ceHostFactory.cs file.
5.7.2.2 One-way WS-Addressing with Anonymous ReplyTo, SOAP 1.2 Scenario
This 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.
Feature area: WSAddressing
Scenario: Test1200
Source folder: C:\test\wcf\src\suite\XwsInterop\WSAddressingCR
Specific WS-Policy of interest: CustomBinding_Notify1_policy in
http://NETServer/WSAddressingCR_Service_WCF/WSAddressing10.svc?wsdl=wsdl1
Specific configuration binding: Code-supplied configuration can be found in the
C:\test\wcf\src\suite\XwsInterop\WSAddressingCR\Service\WCF\WSAddressingCRServi
ceHostFactory.cs file.
73
5.8 WSDLs
5.8.1 Support for WSDL Styles: SAP
SAP 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).
1. Select a service definition and apply the selection.
2. On the Overview tab page, select Show WSDL Options.
3. Under WSDL Styles, you can select either Document or RPC.
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 ad-
dresses 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
1. Click Start, click All Programs, click Microsoft Visual Studio 2010, right-click Mi-
crosoft Visual Studio 2010, and then click Run as Administrator
74
2. If a User Account Control dialog box appears, type in your administrator credentials if
necessary, and then click Yes.
3. Click File, click Open, and then click File.
4. In the Open File dialog box, navigate to C:\Windows\Microsoft.NET\Framework\v4.0.
30319\Config or C:\Windows\Microsoft.NET\Framework64\v4.0. 30319\Config on a
64-bit version of Windows, select Machine.config, and then click Open.
5. Search through the file to find the end tag of the <system.serviceModel> element.
6. On the line before the end tag, add the following elements:
<commonBehaviors>
<serviceBehaviors>
<useRequestHeadersForMetadataAddress/>
</serviceBehaviors>
</commonBehaviors>
7. Click File, and then click Save Machine.config.
8. Close Visual Studio.
5.8.3 Requests and Responses that Contain Application-Defined Headers
Application-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 Details
SAP Web service clients can interoperate with the service in the following configuration. How-ever the SAP platform does not support a similar service.
Details of specific scenario: Mutual X509 Certificate Authentication, Sign Encrypt, Encrypted
Header.
Feature area: Security.WsSecurity.
Scenario: XD_NoDerivedkeys_HeaderOnly-NoSignatureConfirmation.
Source folder: C:\test\wcf\src\suite\XwsInterop\Security\WsSecurity.
Specific WS-Policy of interest: XD_NoDerivedKeys-
NoSignatureConfirmation_IPingServiceHeaderOnlyEncryptAndSign_policy in
http://NETServer/Security_WsSecurity_Service_Indigo/WsSecurity11.svc?wsdl=wsdl0.
Specific configuration binding: XD_NoDerivedKeys-NoSignatureConfirmation in the
C:\test\wcf\src\suite\XwsInterop\Security\WsSecurity\service\indigo\Web.Config file.
5.8.3.2 SAP Scenario Details
SAP Consumer
Consumer Proxy: CO_SRT_IPING_SERVICE_OUT
75
5.8.4 Request with Empty Body Element
5.8.4.1 SAP Scenario Details
SAP 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 Details
This 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 ser-vice.
Details of specific scenario: WS-Addressing Dispatch test (not part of W3C WS-
Addressing WG suite), SOAP 1.2
Feature area: WSAddressing
Scenario: Test1299
Source folder: C:\test\wcf\src\suite\XwsInterop\WSAddressingCR
Specific WS-Policy of interest: CustomBinding_Dispatch_policy at
http://NETServer/WSAddressingCR_Service_WCF/WSAddressing10.svc?wsdl=wsdl1
Specific configuration binding: Code-supplied configuration can be found in the
C:\test\wcf\src\suite\XwsInterop\WSAddressingCR\Service\WCF\WSAddressingCRServi
ceHostFactory.cs file.
Specific contract of interest:
http://NETServer/WSAddressingCR_Service_WCF/WSAddressing10.svc?wsdl=wsdl3
Contract code location:
C:\test\wcf\src\suite\XwsInterop\WSAddressingCR\Service\WCF\DispatchContract.cs.
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.