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 descriptions 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 implementations 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 dedicated features, for developing backend business functionality, connecting applications, and provisioning 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 manage at design time the Service-oriented architecture (SOA) assets, for example services, message interfaces and data types. The services are the basis for the Web service provider implementation 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 Providers and Service Consumers

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 document, .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 standards 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 Packaging 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 security models and encryption technologies.

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 protocol 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

WSDL is an XML format for describing network services as a set of endpoints operating on messages 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 message. 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 status 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 anonymous (non-addressable) client.