SAP XI 3.0 EX3 - HTTP to RFC

7/30/2019 SAP XI 3.0 EX3 - HTTP to RFC

1/14

Exercise 3 HTTP client to (a)synchronous BAPI

Overview

In this exercise we will implement a simple synchronous link between an external web applicationand R/3, via XI. The focus is on reusing external objects based on the open standards, XSD,

XSLT and XPath.

The more advanced variant of this exercise will focus on asynchronous tRFC-based connectivity.As part of this topic, we will review the basics of tRFC communication and the implications for XI-based interfaces (TIDs, implicit/explicit commits, monitoring).

Prerequisites

- Good understanding of basic XI features, or previous experience with XI 2.0.- Basic knowledge of XML standards XSD, XSLT and XPath.- Basic knowledge of RFC/tRFC concepts.

Description

An HTTP client application issues a synchronous request to XI. The request contains purchaseorder information in a custom XML format. The metadata for the XML document is available as anXML Schema (XSD) from an external source. The request reaches the Integration Server via theplain HTTP adapter. Based on the vendor number the message is routed to the R/3 system

(content-based routing). The request is mapped to RFC-XML format. Via the RFC adapter, XImakes a BAPI call into the backend R/3 system to post the purchase order. The response fromthe BAPI, containing the PO number, is returned to the HTTP client.In the advanced variant, the BAPI is called asynchronously and thus there is no response.

We assume that the R/3 system has been properly configured for creating purchase orders. Inparticular, a vendor has been created in the system (for example by completing exercise 1above).

Note: the BAPI (ZBAPI_PO_CREATE) is in fact a custom wrapper for the standard BAPI(BAPI_PO_CREATE). This is done for convenience purposes:

- The custom BAPI has only a minimal number of import parameters, representing themandatory fields. This will simplify the mapping definition process.

-The custom BAPI contains an additional optional field bypass_bapi. If this field ischecked, then the standard BAPI will not be called, and the wrapper returns a randomlygenerated PO number. This can be used when the R/3 system is not properly configuredfor creating purchase orders, or simply for test purposes.

This exercise will introduce the concept of Business Service. Business Services are used in theIntegration Directory during the configuration of Receiver Determination. Traditionally theBusiness Systems, defined in the System Landscape Directory, are used as sender or receiver in

XML Order DataBAPI

Z_BAPI_PO_CREATE

SAPR/3 4.6C

Web PurchasingApplication

HTTP

RFC


2/14

the Integration Directory. However, in some cases, the details of the implementing application arenot available (for example in the case of B2B communication, where the system belongs to adifferent company). A Business Service represents an abstract entity for addressing the sendersand receivers of messages. Therefore, when using Business Services, it is no longer necessaryto define any Business Systems in the System Landscape Directory.

Exercise steps

Step 1 System Landscape Directory

Since we will be using Business Services, no configuration will be required in the SystemLandscape Directory.

Step 2 Repository

2.1 In the software component XI RIG US workshop base comp, open the node importedobjects. Open the object ZBAPI_PO_CREATE and examine the metadata for therequest and the response message.

2.2 In your software component, create a new namespaceurn:xiworkshop:group[XX]:webapp. This will be the namespace for all objects related tothe web application.

2.3 Import the external schema definition for the custom XML interface

2.3.1 Under the node Interface objects, create a new object of type ExternalDefinition, called PurchaseOrderCombined.


3/14

2.3.2 Select the following:

Category: xsd

Messages: From all available global elements

File: PurchaseOrderCombined.xsd (this containsPurchaseOrderRequest.xsd & PurchaseOrderResponse.xsd)

2.3.3 Once the XSD file has been imported, click on the Message tab, you shouldsee 2 messages (as shown below): PurchaseOrderResponse andPurchaseOrderRequest

2.4 Create a new message interface object (synchronous, outbound) referencing the requestand response messages.

2.4.1 Create a new outbound Message Interface object PurchaseOrder_out(outbound, synchronous).

2.4.2 Using the input help (F4), assign the request and response message typesderived from the external definitions: PurchaseOrderRequest andPurchaseOrderResponse.


4/14

2.5 Import the XSLT archive containing request/response mapping2.5.1 Inspect the following stylesheets, provided to you for the workshop:

POReq__ZBAPI_PO_CREATE_req.xsl (request mapping)

ZBAPI_PO_CREATE_resp__POResp.xsl (response mapping)

2.5.2 Using WinZip, create a ZIP archive file on your PC containing the 2 XSL files.

2.5.3 Create an Imported Archive object with name:PurchaseOrder__ZBAPI_PO_CREATE


5/14

2.5.4 Import the ZIP file create in the previous step

2.5.5 After importing the ZIP file, the 2 XSL mapping programs should show up.

2.6 Create an interface mapping object

2.6.1 Create a new Interface Mapping with the name:PO_out__ZBAPI_PO_CREATE

2.6.2 Assign the following Message Interfaces and Mappings:

Source interface: PurchaseOrder_out

Target interface: ZBAPI_PO_CREATE

Request Mapping program: POReq__ZBAPI_PO_CREATE_req (typeXSL)


6/14

Response Mapping program: ZBAPI_PO_CREATE_resp__POResp(type XSL).

2.7 Create Context Object. Context Objects represent XPath expressions. It is a variablename which can be used to represent a complex (or long) element path in XML. Thisallows for readability, reusability, and minimizes errors during configuration.

2.7.1 Create a new Context Object with the name: vendor


7/14

2.7.2 Give the Context Object, vendor, the following attribute:

Reference type: xsd:string

2.7.3 Assign vendor to an XML element in the Message Interface by opening up theMessage Interface with the name PurchaseOrder_out. Click on the tabContexts Object and assign vendor to Vendor in the Header.


8/14

Step 3 Directory

3.1 In the Integration Directory, we will need to define the Business Service first.

3.1.1 Create a new Business Service under your own scenario:

3.1.2 Assign a name to the Business Service: XIWS_web_purchasing_XX

3.1.3 Assign outbound interface name defined in the Integration Repository:PurchaseOrder_out.


9/14

3.1.4 Save the Business Service.3.1.5 Note that for plain HTTP communication, no sender communication channel isrequired.

3.2 For the target business system, the Receiver Communication Channel of type RFC hasalready been defined. Please locate the target business system (i.e. the R/3 system) andexamine the receiver communication channel of type RFC, named XIWS_RFC_receiver.

3.3 Create a new Receiver Determination object under your own scenario3.3.1 Specify the following in the sender information:

Service: XIWS_web_purchasing_[XX]

Interface: PurchaseOrder_out

Namespace: urn:xiworkshop:group[XX]:webapp

3.3.2 As receiver service, select the Business System for the backend R/3 system.3.3.3 In this exercise we will use content-based routing. Specify a condition such that

the request is sent to the target service, only if the vendor number matchesyours:

3.3.3.1 Open up the condition editor by choosing the input help (F4) from the fieldCondition. You should now see the condition editor screen:


10/14

3.3.3.2 For the Left Operand, select the input help (F4) and enter the expressioneditor:

3.3.3.3 Here you can either specify an XPath expression or use a context object.Choose the context object vendor which you have defined at design time.

3.3.3.4 In the Right Operand, enter your Vendor ID in the R/3 system. This shouldbe the same vendor ID used in exercise 1. Please check with the instructor.

3.3.3.5 Click OK to exit the condition editor. The completed condition should look

like this:


11/14

3.3.4 Save your receiver determination object.

3.4 Create a new interface determination and receiver agreement for your receiver:

Inbound Interface: ZBAPI_PO_CREATE

Interface Mapping: PO_out__ZBAPI_PO_CREATE

Receiver Agreement (Comm. Channel): XIWS_RFC_receiver

3.5 When you are finished, the configuration should look like the following. Make sure to activateall your objects.

Step 4 Test

4.1 To test this scenario we will use the simple HTTP client application provided to you.4.1.1 Open the HTTP client XIWS_httpClient.html4.1.2 The basic values have been prepopulated for you. Verify that they are correct:

ServerHost:

ServerPort:

Client:

4.1.3 The sender service, interface and namespace should match exactly the values inyour receiver determination object:

SenderService: XIWS_web_purchasing_[XX]


12/14

SenderInterface: PurchaseOrder_out

SenderNamespace: urn:xiworkshop:group[XX]:webapp

4.1.4 For quality of service (QoS) , enter BE for best effort. This will make themessage synchronous.

4.1.5 Leave the optional parameters empty, as we are not using a party.

4.1.6 For the Payload, we have provided you with a sample XML instance in the filePORequest_template.xml. Please make a copy of the file and edit it:

XML field Value

Header DocDate Todays date in format YYYYMMDD

Header Vendor - should match yourcondition for content-based routing

Item DeliveryDate Todays date + 1 week (YYYYMMDD)

Item Quantity 1

Item NetPrice 12

For the other elements, please keep the default values.

4.1.7 From the HTTP client you can either cut & paste the XML content manually, orupload the XML file

4.1.8 Once you send the request, examine the URL that was called. This is the URLcorresponding to the plain HTTP adapter of the Integration Server.

4.1.9 In the Result area you should see the response of the synchronous call.

4.2 In transaction SXMB_MONI, you should be able to see the request and responsemessages for your synchronous call. If any errors occurred, you can troubleshoot fromhere.

4.3 In the R/3 system, you can verify that the PO was created in transaction ME23.

Step 5 Advanced variant

Now we will repeat the exercise in asynchronous mode, thus making use of tRFC communication.Because the communication is asynchronous, the request is sent with QoS exactly once. TheBAPI response will not be returned back to XI and the emitting HTTP client application.

5.1 Adjust the objects in the Integration Repository:5.1.1 Copy your message interface PurchaseOrder_out to

PurchaseOrder_out_async (outbound, asynchronous).5.1.2 Copy your interface mapping PO_out__ZBAPI_PO_CREATE to

PO_out_async__ZBAPI_PO_CREATE. Change the source interface toPurchaseOrder_out_async. Notice that only a request mapping is required(POReq__ZBAPI_PO_CREATE_req).

5.1.3 Activate the new objects.

5.2 Adjust the objects in the Integration Directory5.2.1 Open the business service XIWS_web_purchasing_XX and assign the

outbound interface PurchaseOrder_out_async.5.2.2 Copy your receiver determination object to a new one where the sender interface

is PurchaseOrder_out_async. Make sure to add the new object to yourscenario. Notice that the receiver service and the condition remain the same.


13/14

5.2.3 Copy your interface determination object to a new one, where the senderinterface is PurchaseOrder_out_async. Make sure to add the new object to yourscenario.5.2.3.1 The inbound interface remains the same5.2.3.2 Assign the interface mapping PO_out_async__ZBAPI_PO_CREATE.

5.2.4 Refresh your receiver determination object. Notice that the receiver agreement

and communication channel remain the same. Activate all objects.

5.3 Now you can test the scenario asynchronously with the plain HTTP client.5.3.1 Make sure to change the following values:

QoS: EO (exactly once)

Sender Interface: PurchaseOrder_out_async5.3.2 All other values remain the same, so does the message payload5.3.3 When you submit your request, notice that there is no response coming back.

5.4 Examine your message in transaction SXMB_MONI.

5.5 Verify in the backend system that the PO was created.

5.6 Think about the pros and cons of utilizing asynchronous communication in this case. Theinstructor will discuss the topic.


14/14

Appendix: naming conventions and terminology

Exercise 3

Area Obj. type Object name Description

SLD n/a n/a No SLD objects

Int. Rep. NS urn:xiworkshop:groupXX[00..30]:webapp Namespace for web objectsXSD PurchaseOrderCombined Contains 2 message types

Msg.type PurchaseOrderRequest Derived from XSD

Msg.type PurchaseOrderResponse Derived from XSD

Msg.int. PurchaseOrder_out Outbound, synchronous

Msg.int. PurchaseOrder_out_async Outbound, asynchronous

XSLT POReq__Z_BAPI_PO_CREATE_req.xsl Request mapping

XSLT ZBAPI_PO_CREATE_resp__POResp.xsl Response mapping

Archive PurchaseOrder__Z_BAPI_PO_CREATE Archive for XSLT mappings

Int.map PO_out__Z_BAPI_PO_CREATE For synchronous case

Int.map. PO_out_async__Z_BAPI_PO_CREATE For asynchronous case

Context Vendor Context object

Int. Dir scenario xiworkshop_groupXX[00..30] Reuse scenario container

service XIWS_web_purchasing_XX Business service no party

R/3 RFC Z_BAPI_PO_CREATE RFC wrapper

Documents

SAP XI 3.0 EX3 - HTTP to RFC