exercise 3 - http client to (a)synchronous bapi

8/18/2019 Exercise 3 - HTTP Client to (a)Synchronous BAPI

1/13

1

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 the

XML Order DataBAPI

ZBAPI_PO_CREATE

SAPR/3 4.6C

Web Purchasing App licati on

HTTPRFC


2/13

2

Business Systems, defined in the System Landscape Directory, are used as sender or receiver inthe 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 a

different 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 s teps

Step 1 – System Landscape Directory (SLD)

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

Step 2 – Repository

2.1 Examine existing object: in the software component “TBIT40_BASE_COMP”, open thenode “imported objects”. Open the object ZBAPI_PO_CREATE and examine themetadata for the request and the response message.

2.2 Create a namespace: in your software component, create a new namespace“urn:tbit40:workshop:group##:webapp”. This will be the namespace for all objectsrelated to the web application.

2.3 Import the external schema definition for the custom XML interface

2.3.1 In your new namespace urn:tbit40:workshop:group##:webapp , under thenode “Interface Objects”, create a new object of type “External Definition”, called“PurchaseOrderCombined ”.

2.3.2 Select the following: Category: xsd Messages: From All Available Global Elements


3/13

3

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

Note: this file (like all following files) is available in your folder group## in case youdownloaded the TBIT40files.zip (from the TBIT40 Tools home page) and unzipped thecontent to your folder.

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 message interface object (synchronous, outbound) referencing the request andresponse messages.

2.4.1 Create a new outbound Message Interface object “PurchaseOrder_out ”(Outbound, Synchronous) in your new namespaceurn:tbit40:workshop:group##:webapp .

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


4/13

4

2.5 Import the XSLT archive containing request/response mapping into your new namespaceurn:tbit40:workshop:group##:webapp:

2.5.1 Inspect the following stylesheets,in your folder group## (e.g. with notepad): POReq__ZBAPI_PO_CREATE_req.xsl (request mapping) ZBAPI_PO_CREATE_resp__POResp.xsl (response mapping)

2.5.2 Create an “Imported Archive” object with name:PurchaseOrder_ZBAPI_PO_CREATE

2.5.3 Import the ZIP file (transforms_zip.zip) with the XSL mappings from your groupfolder group## by clicking on the import button in the Archive Program section.

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


5/13

5

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

(Attention: first switch type from message mapping to XSL!)

Response Mapping program: ZBAPI_PO_CREATE_resp__POResp (type: XSL).


6/13

6

2.7 Create an Context Object. “Context Objects” represent XPath expressions. It is avariable name which can be used to represent a complex (or long) element path in XML.This allows for readability, reusability, and minimizes errors during configuration.

2.7.1 Create a new “Context Object” with the name vendor.

2.7.2 Give the Context Object, vendor, the following attribute: Reference type: xsd:string


7/13


8/13

8

3.1.4 Save the Business Service.

(Note that for plain HTTP communication, no sender communication channel is required.)

3.2 Examine communication channel: for the target business system R3_BACKEND, the“Receiver Communication Channel” of type RFC has already been defined. Pleaselocate the target business system and examine the receiver communication channel oftype RFC, named ‘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_## Interface: PurchaseOrder_out

Namespace: urn:tbit40:workshop:group##:webapp

3.3.2 As receiver service, select the Business System for the backend R/3 system, i.e.

R3_BACKEND.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 field‘Condition’. You should now see the condition editor screen:


9/13

9

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: 320## (where ## is your groupnumber). Please check with the instructor.

3.3.3.5 Click ‘OK’ to exit the condition editor. The completed condition should looklike this (with ## as your group number):

3.3.4 Save your receiver determination object.


10/13

10

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): RFC_receiver

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

Step 4 – Test

4.1 To test this scenario we will use the simple HTTP client application provided to you.(You can open this web page from the TBIT40 Tools home page, where you found theTBIT40files.zip as well.)4.1.1 Open the HTTP client “XIWS_httpClient.html”4.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_## SenderInterface: PurchaseOrder_out SenderNamespace: urn:tbit40:workshop:group##: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 file

‘PORequest_template.xml’. Please make a copy of the file and edit it:


11/13

11

XML field ValueHeader DocDate Today’s date in format ‘YYYYMMDD’Header Vendor your vendor number 320##

(should match your condition for content-based routing)Item DeliveryDate Today’s date + 1 week (‘YYYYMMDD’)Item Quantity 1Item 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.Write down the purchase order number from the xml element, e.g.

4500013090.

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 byspecifying the purchase order number you wrote down in 4.1.9.

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 ’ and change Attributes to 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 to‘PurchaseOrder_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 Directory

5.2.1 Open the business service ‘XIWS_web_purchasing_##’ and assign theoutbound interface ‘PurchaseOrder_out_async ’.

5.2.2 Copy your receiver determination object‘|XIWS_web_purchasing_##|PurchaseOrder_out ’ to a new one where thesender interface is ‘PurchaseOrder_out_async ’. Make sure to add the newobject to your scenario. Notice that the receiver service and the condition remainthe same.


12/13


13/13

exercise 3 - http client to (a)synchronous bapi

Documents