Share via

4     PO/Confirmation Scenario Configuration

4.1    General Remarks

The scenario configurations in the following sections are based on the delivered EPM demonstration scenario described in the Demonstration Scenarios Overviewsection. This demonstration 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 distinct 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 purposes.

However, business implementations often share a database between buyer forms and the confirmation 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 scenario.

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 message 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 example, there are no large engineering diagrams or other attachments included in any of the purchase 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.

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 configuration 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 authentication on transport level)
 

https://NETServer/SAPBusinessService/PO2

WSDL: http://NETServer/SAPBusinessService/PO2?wsdl

There is no command-line confirmation service because the confirmation service 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 authentication on transport level)
 

https://NETServer/SAPBusinessService/PO2/soap11

WSDL: http://NETServer/SAPBusinessservice/PO2?wsdl

There is no command-line confirmation service because the confirmation service 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 authentication on transport level)

You can generate the endpoint URI in SOA Management (transaction SOAMANAGER). 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 authentication on transport level)

You can generate the endpoint URI in SOA Management (transaction SOAMANAGER). 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_00505683359D02EDBBCFA35A90C5C87B/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 demonstration 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.

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 contained 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, perform 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 objects 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:
    • EPM_PurchaseOrderRequest_In
    • EPM_PurchaseOrderConfirmation_Out

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 software 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.
    1. Design data types.
    2. Design message types.
    3. 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 PackageS_EPM_PI.
  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 Repository, 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_Inin 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 Endpoint.
  6. Under New Binding Name type in “bindingbasicauthoverhttps” and select Apply Settings.
  7. On the Provider Security tab, select the following:
    • To enable HTTPS for message processing, select SSL (HTTPS, Transport Channel Security).
    • 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.

  1. Configure a second endpoint with the settings shown in the following illustration.  Use “bindingusernameovertransport” as the name of the new binding name for this endpoint.

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_Inand select the Overview tab.
  2. Select Show WSDL Options and select the following:
    • To generate a WSDL that supports only one SOAP version, select a Binding SOAP Version, otherwise the WSDL supports both SOAP versions.
    • Click Selected Binding Only and click the link Open WSDL document for selected binding or service.

Note   If you want to provide the WSDL document with the type document wrapped, replace document with document_wrapped in the WSDL URL.

  1. Copy the WSDL document to a file.

Note   If a Services Registry is part of your system landscape, the system automatically publishes 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 PackageS_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 support, you can provide all WSDL content (data types, services interfaces, etc.) in the ES Repository first and use the WSDL from ES Repository instead.

More information: Working with External Definitions

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_Outin the Search Pattern field.
  5. Select the consumer proxy and click ApplySelection.
  6. To add a logical port, go to the Configurationstab 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.

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 process 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 confirmation 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 confirmation 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:

  • 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 editor.
  • Common: Features shared between the Buyer and Seller implementations.
  • Buyer: Implementation of the Buyer role in this scenario – contains the Web user interface 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 received 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 solution folder. The generated code is thus available for client and service implementations elsewhere 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.

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 Solution, and then click Find Next.
  5. On the Find and Replace dialog box, click Replace for each occurrence of garnet2 that the tool finds.
    Note   If your IIS environment does not use the default HTTP and HTTPS ports for transmission, 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/bindingusernameovertransport. 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/bindingbasicauthoverhttps. 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, click Replace All, and then close the Find and Replace dialog box.
  8. Click Build and then click Build Solution. When the build completes, check the status message 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 services are:

Note   You must complete the procedure in Section 4.4.3 before any services are run and available for browsing.

4.4.3      Create the SAPBusinessService and Seller applications in IIS

Creates two applications in IIS that host the SAPBusinessService components.

  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 provides 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 NETServer: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.

  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 interfaces, 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 Order 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 restrictions, 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 serialization 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 available 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.

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 validate .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 include the <supportedRuntime /> element or its content.
  3. If you update the service reference on the Purchase Order service in the Common project 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 assertions or the WSDL locations where some appear.  Fortunately, these particular assertions affect only SAP-to-SAP communication and ignoring them does not lead to interoperability 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 approach is known as “code-first”.  In this approach, developers create the service first, then configure and expose this interface as a Web service.  Please see Figure 11(from https://msdn.microsoft.com/en-us/library/bb756905.aspx) for more information on these terms.

  • Code-first — Service interfaces are written using a supporting CLR language, such as C# or Visual 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 implementation classes. (Alternately, classes can also be generated from a running service that publishes a metadata exchange (MEX) endpoint by using Svcutil.)

Figure 11 Code-first and WSDL-first defined

When developing services intended to interoperate with SAP NetWeaver Application Server clients 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 include 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 reliableMessagingVersion and messageSecurityVersion attributes.

<configuration>
  <system.serviceModel>
    <bindings>
      <customBinding>
        <binding name="Username">
          <reliableSession reliableMessagingVersion="WSReliableMessaging11"/>
          <security authenticationMode="UserNameOverTransport"
              messageSecurityVersion="WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10"/>
          <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.

 

    • Other usable messageSecurityVersion values include WSSecurity10WSTrust13WSSecureConversation13 and WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12.
    • Do not use messageVersion=”Soap11WSAddressingAugust2004” or messageVersion=”Soap12WSAddressingAugust2004” in the <mtomMessageEncoding/> or <textMessageEncoding/> elements.
    • Do not use the <binaryMessageEncoding> element.
    • Do not use transport elements other than <httpTransport/> and <httpsTransport/>.
  • 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 Order Request message:

  • <TestDataIndicator>true</TestDataIndicator>
  • <BuyerID>X</BuyerID> , X can be set to NET or NETS11 or NETAUTH or NETAUTHS11
  • <SellerID>Y</SellerID> , Y can be set to SAP or SAPS11 or SAPAUTH or SAPAUTHS11

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 namefield and select .
  2. In the PROXY_NAME field, type in CO_EPM_PO_CONFIRMATION_OUT. This is the internal 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 consumer 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 interoperability 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/SAPBusinessServiceand then press ENTER. The .NET Framework 4 scenario implementation appears.

Figure 13 Initial page of ASP.NET interface for PO/Confirmation scenario

  1. 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.

  1. 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.

Figure 14 Unable to add price that is not a decimal amount

  1. 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 configurations, 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.

Figure 15 Ready to submit a purchase order that contains 5 items

  1. Review the purchase order message on the .NET to SAP NetWeaver Purchase Order page, and then click Review Confirmationmessage to view the confirmation message sent from the SAP service.
  2. 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.

  1. 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 Framework 4 buyers are shown. This tool displays the purchase order message, the confirmation message returned from the seller, and all other messages associated with this scenario. These messages 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.

4.5.3      Service Monitoring in SAP NetWeaver

Monitor incoming and outgoing messages in monitor Integration Engine – Monitoring (transaction 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

  1. 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 associating this utility to files that have the .e2e file extension as well. You can perform the following procedure 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.
  • 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 Framework 4 testing.
  • SAPBusinessService.Seller.Console.e2e. This file contains output from the command-line purchase order service.

Download

Source code

Document Sections

Additional Resources
  • Last updated on