TBIT44 - 2004-Q4 - A4 - Mapping, Adapters and BPM

© SAP AG <Course Number> Course Overview - 1

© SAP AG 2004

TADMBO Implementation&Operation II

THE BEST-RUN BUSINESSES RUN SAP

© SAP AG 2004

TBIT44Mapping, Adapters and BPM

2004/Q4

Material number: 50069570

©SAP AG TBIT44 0 - 1

SAP Exchange Infrastructure 3.0

TBIT44 Mapping/Adapters/BPM

©SAP AG TBIT44 0 - 2

© SAP AG 2004, TBIT44

Topics

Lecture topics

Mappings

Adapter

ccBPM

TBIT40 Exercise 0: Preparations Page 1 of 1

Exercise 0: Preparation Overview The purpose of this exercise is to create general objects in SLD, Repository, and Directory. In all exercise descriptions: ## is the placeholder for your group number. Exercise steps *Please note, as a general rule, all development and configuration objects are CASE-SENSITIVE. SLD

1. Logon to the SLD, e.g using transaction SLDHTMLGUI. 2. Create a Software Component Version (SWCV): in the Software Catalog under

Components create SWCV TBIT44_## for Product ATP (2004) from vendor SAP, version 1.0.

3. Maintain a usage dependency of your SWCV TBIT44_## to the following SWCVs:

- SELLSPAREPARTS, 1.0 of SAP - TBIT44, 2004 of SAP - TBIT44_BASE_COMP, 1.0 of SAP (dependency context: “Installation time”).

4. Add your SWCV to be used in the technical systems:

R/3 backend (Technical System Type: Web AS ABAP) XI system (Technical System Type: Web AS ABAP) TBIT44_FILE_SENDER (Technical System Type: Third-Party) TBIT44_JDBC_RECEIVER (Technical System Type: Third-Party) DMSCRM (Technical System Type: Third-Party) DMS_CRM (Technical System Type: Third-Party)

Navigate to the detail view on these technical systems, choose the product ATP (under “Installed Products”), select your SWCV and save. Integration Repository

5. Logon to the Integration Repository, e.g using transaction SXMB_IFR.

6. Import your SWCV TBIT44 _## via menu “Tools/Transfer from System Landscape Directory / Import Software Component Versions...”.

7. Create namespaces: create the following four namespaces in your SWCV: urn:sap-com:TBIT44:adapters:group## urn:sap-com:TBIT44:BPM:group## urn:sap-com:TBIT44:mapping:group## http://www.sap.com/xi/BPM/Spareparts (for the last namespace you will get a warning message because this namespace already exists in another SWCV, but you can create it.)

8. Save and activate your changes in Integration Repository.

Integration Directory

9. Logon to the Integration Directory, e.g using transaction SXMB_IFR.

10. Create a scenario: create the Scenario TBIT44_##.

11. Save and activate your changes in Integration Directory.

TBIT40 Part I: Mapping / Exercise 1 Page 1 of 1

Exercise 1: Message Mapping – Standard Functions Overview The purpose of this exercise is to design a Message Mapping using standard functions of the mapping tool. This exercise will test the understanding of using standard functions in Message Mapping. Prerequisites

Basic knowledge of XI 3.0 Message Mapping. Description The source is an XML document containing Contact1 information. The target is an XML document containing Customer1 information. Both can be found in your SWCV, under Basis Objects, in namespace urn:sap-com:TBIT44:mapping:common. Exercise steps *Please note, as a general rule, all development and configuration objects are CASE-SENSITIVE. There are many ways to achieve the desired result. The solution provided here is only 1 way, not the only way. Create a Message Mapping

1. In the Integration Repository, go into your SWCV TBIT44_## and your namespace urn:sap-com:TBIT44:mapping:group## (## is your group number) and create a new Message Mapping called ContactToCustomer1 between Contact1 as source message and Customer1 as target message.

2. The target element fullname should contain the concatenated content of title, firstname and custname, separated by a blank.

3. The first 10 digits of element contactID should be filled into element customerNo. 4. The six last digits of element contactID should be used to fill element birthday. Please

perform a date transfer so that birthday is of format yyyy/dd/MM. 5. Test the mapping (using the “Test” tab). You can use e.g. the following xml file for testing:

<?xml version="1.0" encoding="UTF-8"?> <ns0:Contact1 xmlns:ns0="urn:sap-com:TBIT44:mapping:common"> <title>Mr.</title> <custname>Smith</custname> <firstname>Paul</firstname> <contactID>0123456789-181170</contactID> </ns0:Contact1>

Possible solution /ns0:Customer/name/ firstname= /ns0:Contact/firstname /ns0:Customer/name/surname =/ns0:Contact/custname /ns0:Customer/name/fullname =concat ([delimeter= ]concat ([delimeter= ]/ns0:Contact/ title , /ns0:Contact/ firstname) , /ns0:Contact/custname ) /ns0:Customer/ birthday= DateTrans([iform=ddMMyy,oform=yyyy/dd/MM] substring([start=11,count=6] /ns0:Contact/contactID )) /ns0:Customer/ customerNo= substring([start=0,count=10] /ns0:Contact/contactID )


Exercise 2: Message Mapping – Mapping Template Overview The purpose of this exercise is to design a Message Mapping using existing mapping templates. This exercise will test the understanding of using mapping template in Message Mapping. Prerequisites

Basic knowledge of XI 3.0 Message Mapping. Description The source is an XML document containing Contact information. The target is an XML document containing Customer information. Within Contact, predefined data types of Name and Address are used. Within Customer, predefined data types of CustName and CustomerAddress are used. In a first step, two Mapping Templates based on these Data Types will be defined. Then the templates will be reused in a Message Mapping. (The objects can be found in your SWCV, under Basis Objects, in namespace urn:sap-com:TBIT44:mapping:common.) Exercise steps *Please note, as a general rule, all development and configuration objects are CASE-SENSITIVE. There are many ways to achieve the desired result. The solution provided here is only 1 way, not the only way. Create a Message Mapping

1. Logon to Integration Repository. 2. Go into SWCV TBIT44_## and your namespace

urn:sap-com:TBIT44:mapping:group##.

3. Create a mapping template. In Mapping Templates, create a template called NameToCustName, with the following mapping. The source and target are the data types of Name and CustName.

Please note that Mapping Templates are created using Data Types, not Message Types.


4. Create a second Mapping Template AddressToAddress applying a simple identity mapping (between the data type Adress and Adress).

5. Create a Message Mapping ContactToCustomer between Contact and Customer

(both Message Types).

6. Assign the Mapping Template as follow:

• Mark element Name in the source structure and element CustomerName in the target structure

• Right-click on element CustomerName and select “Show Suitable Templates”

• Select your mapping template NameToCustName.

7. Do the same for Address and CustomerAddress (using template AdressToAddress).

8. Check your mappings.

9. Test the mapping by using the “Test” tab.


Exercise 3: Message Mapping – Context Handling Overview The purpose of this exercise is to design a Message Mapping utilizing basic standard XI 3.0 functions. This exercise will test the understanding of context/queue processing of Message Mapping. Prerequisites

Basic knowledge of XI 3.0 Message Mapping. Description The source is an XML document containing material information. This document contains a material number and its description in multiple languages. The result of the mapping/transformation will contain the material number and the description of the material in English. Example source XML:

<?xml version="1.0" encoding="UTF-8"?> <ns0:MATERIAL xmlns:ns0="http://xi.com/mapping/exercise3"> <MATNO>4711</MATNO> <MATTEXT> <LANGKEY>DE</LANGKEY> <TEXT>Zahnpasta</TEXT> </MATTEXT> <MATTEXT> <LANGKEY>EN</LANGKEY> <TEXT>toothpaste</TEXT> </MATTEXT> <MATTEXT> <LANGKEY>FR</LANGKEY> <TEXT>dentifrice</TEXT> </MATTEXT> </ns0:MATERIAL>

Result of the mapping/transformation:

<?xml version="1.0" encoding="UTF-8"?> <ns0:ProductDefinition xmlns: ns0="http://xi.com/mapping/exercise3"> <RefNo>4710</RefNo> <Description>toothpaste</Description> </ns0:ProductDefinition>

Exercise steps *Please note, as a general rule, all development and configuration objects are CASE-SENSITIVE. There are many ways to achieve the desired result. The solution provided here is only 1 way, not the only way.


Create a Message Mapping

1. Logon to Integration Repository. 2. Go into your SWCV TBIT44_## and your namespace

urn:sap-com:TBIT44:mapping:group##.

3. Create a Message Mapping object named MATERIALToProductDefinition.

4. Use Message Type MATERIAL as source and ProductDefinition target structure.

5. To achieve the mapping requirement, we need to do the following: a. The MATNO from source is mapped to RefNo of target. b. Test the content of LANGKEY for the value of “EN”, for English. c. Assign the appropriate TEXT matching the LANGKEY to Description of the

target.

6. Create the following mappings in the Data Flow Editor:

Please note that all italicized source element name has context of “MATERIAL”.

Hint: for content check of LANGKEY, use text function equalsS

7. Test the mapping by using the “Test” tab. Create at least three different entries of node

MATTEXT using the duplicate subtree function. You can use the example for the source XML of the Description part of the exercise as role-model.


Exercise 4: User-defined functions – part I Overview The purpose of this exercise is to design a Message Mapping utilizing some basic techniques of using advanced user functions and to test the understanding of context/queue processing. Prerequisites Advanced knowledge of XI 3.0 Message Mapping. Basic knowledge of Java. Description The source is an XML document containing purchase order information. This document contains multiple orders. Each order has 1 header and multiple items information. The result of the mapping/transformation will contain a row for each item. Each row will contain the header information from the source, and the item information. This mapping might be used when we want to insert into a table the content of a purchase order from an IDoc. Each row in the table must contain both the header and detail information. For example, the source contains 2 orders. Each order has a header and 2 items. The result of the mapping/transformation must contain 4 rows for each of the items in the source. In addition, each of the rows will also contain the corresponding header information. Example source XML:

<?xml version="1.0" encoding="UTF-8"?> <PurchaseOrder> <Order> <Header> <Name>Smith</Name> <Address>123 Main St.</Address> </Header> <Item> <Material>100</Material> <Units>2</Units> <Price>100</Price> </Item> <Item> <Material>200</Material> <Units>1</Units> <Price>10</Price> </Item> </Order> <Order> <Header> <Name>Jones</Name> <Address>987 First Ave.</Address> </Header> <Item> <Material>101</Material> <Units>3</Units> <Price>50</Price> </Item> <Item> <Material>201</Material> <Units>4</Units> <Price>1000</Price> </Item> </Order> </PurchaseOrder>


Result of the mapping/transformation:

<?xml version="1.0" encoding="UTF-8"?> <resultset> <row> <name>Smith</name> <address>123 Main St.</address> <material>100</material> <units>2</units> <price>100</price> </row> <row> <name>Smith</name> <address>123 Main St.</address> <material>200</material> <units>1</units> <price>10</price> </row> <row> <name>Jones</name> <address>987 First Ave.</address> <material>101</material> <units>3</units> <price>50</price> </row> <row> <name>Jones</name> <address>987 First Ave.</address> <material>201</material> <units>4</units> <price>1000</price> </row> </resultset>

Exercise steps *Please note, as a general rule, all development and configuration objects, especially Java codes, in XI are CASE-SENSITIVE. There are many ways to achieve the desired result. The solution provided here is only 1 way, not the only way. Create a Message Mapping

1. Logon to Integration Repository and go into your SWCV TBIT44_## and your namespace urn:sap-com:TBIT44:mapping:group##.

2. Create a Message Mapping object named PO_to_resultset.

3. Insert message types PurchaseOrder as source and resultset as target (from Basis

objects, namespace urn:sap-com:TBIT44:mapping:common). 4. The result should look like the following:


5. To achieve the mapping requirement, we need to do the following: a. With each row in resultset, we need to assign the Header information from

PurchaseOrder. This need to be done for both Name and Address. b. The remainder elements in row can map directly from source to target.

6. Create the following Advanced User Function:

copyPerValue – There are 2 arguments. The 1st argument is the item, the 2nd argument is the Name or Address. In each context, for each occurrence of the item, the function will add the Name or Address to the target.




Enter the following data as an example.


The mapping result should be the following:


Bonus Exercises: I. To send a trace message to SXMB_MONI, use the Container object in either Simple or

Advanced user–function. Create a Simple user–function sendTraceInfo with 1 argument:

To use it, we can do the following mapping:

The testing tool will not be able to test the trace info being sent to the monitor. Only during runtime, the trace info will be sent to the monitor. In addition, the monitor’s trace level must be properly set to display it.

II. Control our own context changes in user–function.

In the exercise, we used the Node Function, SplitByValue, to insert context changes between the values. We can also perform this function within our own user–function. We can replace our user–function, copyPerValue, with another function, copyPerValueWithCC:

The mapping can be done as follow:


Exercise 5: User-defined functions – Part II Overview Purpose of this exercise: to design a Message Mapping utilizing advanced user functions along with the standard XI 3.0 functions; it will test the understanding of context/queue processing. Prerequisites Advanced knowledge of XI 3.0 Message Mapping. Basic knowledge of Java. Description The source is an XML document containing purchase order information. This document contains a single header with multiple detailed purchase orders. In each detailed purchase order, the supplier’s name is provided. There can be more than 1 detailed purchase order per supplier, and the number of suppliers is unknown. The detailed purchase orders are not grouped by supplier, in another word, it is not sorted by supplier name. The result of the mapping/transformation will contain an order for each supplier. Each supplier will contain the header information from the source, and all the detailed purchase orders belonging to the same supplier must be grouped within the order. For example, the source contains 2 suppliers and 4 detailed purchase orders. The 2nd and 3rd detailed purchase orders belong to companyA, and the 1st and 4th detailed purchase orders belong to companyB. The result of the mapping/transformation must contain 2 orders, each with a header. For companyA’s order, it must contain the 2nd and 3rd detailed purchase orders. For companyB’s order, it must contain the 1st and 4th detailed purchase orders. Example source XML:

<?xml version="1.0" encoding="UTF-8"?> <ns9:POCombined xmlns:ns9="http://sap.com/xi30/mapping/patterns"> <Header>

<Name>myName</Name> <Address>myAddress</Address>

</Header> <Detail>

<Supplier>OfficeMax</Supplier> <ProductID>11</ProductID> <Quantity>12</Quantity> <Price>13</Price>

</Detail> <Detail>

<Supplier>OfficeDepot</Supplier> <ProductID>21</ProductID> <Quantity>22</Quantity> <Price>23</Price>

</Detail> <Detail>

<Supplier>OfficeDepot</Supplier> <ProductID>31</ProductID> <Quantity>32</Quantity> <Price>33</Price>

</Detail> <Detail>

<Supplier>OfficeMax</Supplier> <ProductID>42</ProductID> <Quantity>42</Quantity> <Price>43</Price>

</Detail> </ns9:POCombined>


Result of the mapping/transformation: <?xml version="1.0" encoding="UTF-8"?> <ns9:POSplit xmlns:ns9="http://sap.com/xi30/mapping/patterns"> <Orders>

<Header> <toCompany>OfficeMax</toCompany> <custName>myName</custName> <custAddress>myAddress</custAddress>

</Header> <Items>

<productNo>11</productNo> <quantity>12</quantity> <price>13</price>

</Items> <Items>


</Items> </Orders> <Orders>

<Header> <toCompany>OfficeDepot</toCompany> <custName>myName</custName> <custAddress>myAddress</custAddress>

</Header> <Items>


</Items> <Items>


</Items> </Orders> </ns9:POSplit>

Exercise steps *Please note, as a general rule, all development and configuration objects, especially Java codes, in XI are CASE-SENSITIVE. There are many ways to achieve the desired result. The solution provided here is only 1 way, not the only way. Create a Message Mapping

1. Logon to Integration Repository and go into SWCV TBIT44_## and namespace urn:sap-com:TBIT44:mapping:group##.

2. Create a Message Mapping object called POCombinedToSplit.

3. Select Message Type POCombined as source structure and POSplit as target structure

(both from Basis objects, namespace urn:sap-com:TBIT44:mapping:common).


4. The result should look like the following:

5. To achieve the mapping requirement, we need to do the following: a. Determine the number of unique suppliers. This is how many Orders we must

create in the target. b. Assign the Header information to each of the Orders in the target. c. Determine the number items for each supplier. d. Assign the Detail information to the Items to the appropriate supplier in the target.

6. Create the following 4 Advanced User Functions:

getSuppliers – using Supplier as the input parameter, this function tests all the Supplier values and return only the unique ones.


assignItems – using Supplier as the input parameter, this function determines how many Items belongs to each Supplier and separate them with a ContextChange. In another word, for each Supplier, it create the number of Items element for it.

assignValue – using the number of unique Supplier as input, that same number of the value in the 2nd parameter will be added to the output. So, if there are 2 Suppliers, then the value in the 2nd parameter will be copied 2 times.


assignSupplier – this function is to assign the elements in Detail to the appropriate Items of a Supplier’s Order. It is used to rearrange/reorder the elements in Detail corresponding to how the Items are grouped together based on the Supplier.



Please note that all italicized source element name has context of “POCombined”.



Enter the following data as an example.

The result should be the following:

1

TBIT44: Mapping pattern

2

© SAP AG 2002, Title of Presentation, Speaker Name 2

Mapping Patterns

Mapping “patterns” are some of the common mapping requirements we found in the past which XSLT was used, because we did not think that Message Mapping provided the functionality

SummarizationSequence–Number GenerationDuplicating SubtreesTable / Value LookupsTree–Reversal

3


Summarization is when we try to consolidate detailed information into total/subtotals and counts.

The count and sum functions will act on the content of a context. Therefore, the context of the group to be summarized must be selected appropriately.

Example:

Mapping Patterns – Summarization (I)

Target: Total and count the order by each customer and a summary of all orders

Source: Order details containing customer, order numbers and order amount

4


Mapping Patterns – Summarization (II)

5


Mapping Patterns – Summarization (III)

Mapping Result:

6


Mapping Patterns – Sequence–Number Generation (I)

There are situations when sequence numbers had to be generated based on the number of occurrences of the source data. This is frequently used during mapping to SAP IDocs or BAPIs when item number, which is no available from the source, had to be entered.

Example:

Source: Order information.

Target: Two complex elements had to be populated from the source. Each one contains a sequence number which matches the position of the data in the source.

Sequence number to be generated.

7


Mapping Patterns – Sequence–Number Generation (II)

There are two ways the sequence number can be generated.

1. Use Advanced User–Defined function to generate the sequence number all at once.

2. Use Simple User–Defined function to generate the sequence number for each occurrence separately, keeping track of the sequence number value previously generated.

8


Mapping Patterns – Sequence–Number Generation (III)


The java function creates the sequence number all at once based on the number of elements in the source.

The sequence numbers are written to the ResultList object.

9


Mapping Patterns – Sequence–Number Generation (IV)


10


Mapping Patterns – Sequence–Number Generation (V)


Test Results:

11


Mapping Patterns – Sequence–Number Generation (VI)

2. Use Simple User–Defined function to generate the sequence number for each occurrence separately, keeping track of the sequence numbervalue previously generated.

The sequence number is stored in the container object. Each time it is retrieved, incremented and saved.

Note: There is no input required.

12


Mapping Patterns – Sequence–Number Generation (VII)


We cannot display the queue to examine the result of the mapping.

13


Mapping Patterns – Sequence–Number Generation (VIII)


14


Mapping Patterns – Duplicating Subtrees (I)

Even if elements are shown to occur more than once in the XML instance according to XML Schema Definition, they are only displayed once in the structure overview.

To assign source field(s) to multiple positions of an element in the target structure, the element or the entire subree can be duplicated (copied) using the context menu in the target structure.

Example:

Source: Accounting information with adjustment type and amount.

Target: Two CurrencyAmt’s are to be created. One is to credit one account. The other is to debit another account. The amount will either be positive or negative depending on the ADJTYPE.

15


Mapping Patterns – Duplicating Subtrees (II)

The subtree “CurrencyAmt” must be duplicated first. This will create 2 CurrencyAmt’s. One for credit, and one for debit.

16


Mapping Patterns – Duplicating Subtrees (III)

17


Mapping Patterns – Duplicating Subtrees (IV)

Mapping Results:

18


Mapping Patterns – Table/Value Lookup (I)

During mapping, a lookup is necessary in a different subtree structure of the XML document. This lookup process is easily accomplished using XSLT, since we can navigate the XML document using absolute or relative “path” specification. In Message Mapping, there is no facility to navigate the XML document.

In Message Mapping, we have to use the context of the different elements required for the lookup. A Java function will be needed to perform the comparisons. And, the matched values will have to be written to ResultList.

Example:

Source: Contains credit card information, with 2 subtrees. One is account information (including account number, cost center, sub–account, card type, etc.) The 2nd subtree contains detailed billing information (including account number, date, billing amount, etc.)

Target: Contains only detailed billing information, but with each billing record, the cost center, sub–account and card type from the account info record must also be included. The account number in the detail is used to do the lookup of the account information records.

19


Mapping Patterns – Table/Value Lookup (II)

Source: Target:

=

20


Mapping Patterns – Table/Value Lookup (III)Java Function:

The lookup’d value must be written to the ResultList.

21


Mapping Patterns – Table/Value Lookup (IV)

Mappings for all 3 elements are identical, except for the element names.

Contexts must be set a root level.

22


Mapping Patterns – Table/Value Lookup (V)

Mapping Results:

23


Mapping Patterns – Tree–Reversal (I) Below is a mapping scenario which reverses the parent and child nodes. A “reverse” summarizations is also performed.

Source document: Target document:

The products are to be sorted and totaled by prices with the ORDERID listed.

24


Mapping Patterns – Tree–Reversal (II)

The source document is organized by ORDERID, ITEM and price. The same product can occur in more than 1 orders.

The target document is summarized by product with a total price and listed within each product all the ORDERIDs. The same ORDERIDs can occur in more than 1 products.

The mapping needs to reverse the organization of the source document.

Based on that, the following needs to be done using the contexts/queues used by Message Mapping:

1. Get a list of all the products. Since the same product can be in multiple orders, we must eliminate the duplicates, and, then, sort them.

2. Sum the prices by product and assign those totals to the products in their sorted order.

3. Examine all the ORDERIDs and determine which ORDERIDs contain each of the products in the sorted list. Then, assign those ORDERIDs to the products.

25


Mapping Patterns – Tree–Reversal (III)

Three Java functions were written to:

1. Extract the products, eliminate duplicate names, and sort them in alphabetical order.

26


Mapping Patterns – Tree–Reversal (IV)

2. Total the prices and assign the total to the appropriate products.

27


Mapping Patterns – Tree–Reversal (V)

3. Retrieve all the orderids and assign them to the appropriate products.

Note:

“Cache Entire Queue” is checked.

When the product is being retrieved, the Context Change is skipped.

The Context Change is added to the ResultList.

28


Mapping Patterns – Tree–Reversal (VI)

Mapping for ITEM: To create the number of elements.

29


Mapping Patterns – Tree–Reversal (VII)

Mapping for the attribute NAME, which is the product name.

30


Mapping Patterns – Tree–Reversal (VIII)Display Queue for determining NAME:

31


Mapping Patterns – Tree–Reversal (IX)

Mapping to create the number of element for ORDERS_WHERE_ITEM_IS_FOUND.

32


Mapping Patterns – Tree–Reversal (X)

Mapping for the attribute TotalSalesFOrThisItem, which totals the prices by product name.

33


Mapping Patterns – Tree–Reversal (XI)

Display Queue for determining TotalSalesFOrThisItem:

34


Mapping Patterns – Tree–Reversal (XII)

Mapping for the element ORDERID, which will be listed by product name.

35


Mapping Patterns – Tree–Reversal (XIII)

Display Queue for determining ORDERID:

36


Mapping Patterns – Tree–Reversal (XIV)

Partial listing of the mapping results:

TBIT44 Adapters: CPA Cache 1

CPA Cache


© SAP AG 2004, TBIT44: Adapters: CPA Cache / 2

Learning Objectives

As a result of this unit, you will:

Understand the basics of CPA Cache, including:ConfigurationMonitoringTroubleshootingManual refresh



Cache overview

Integration Server

IntegrationEngine

BusinessProcess

EngineCacheTA: SXI_CACHE

•Delta•Full (only

on request)

IntegrationDirectory

Integration Builder

IntegrationRepository

Central AdapterEngine

Run

time

Acc

ess

•Business Processes•Mappings•Adaptermetadata

Cac

he U

pdat

eC

ache

Upd

ate

CacheJ2EE: CPACache

•Delta•Full via URL

SLD CacheBusiness systems

SLD CacheSoftware

componentsversions “Based

On”

Business systemSLD Cache “Own Business system”•Activate Changelist

•Import•Request Cache update again

•Business Process Configuration•Routing Rules•Collaboration Agreements•Collaboration Profiles

Local Adapter Engine

Adapter Framework

CacheJ2EE: CPACache

•Delta•Full via URL

SLD Cache “Own Business system”

Repository Cache

Adapter Meta data



CPA Cache in general

cache for Directory & Repository data (CPACache)

cache is filled during activation within directory(process described at the end of the document)

contains objects from directory

• services• parties• bindings (inbound/outbound; sender/receiver

agreements)• channels• adapter metadata• module configuration

used in adapter framework during runtime



CPA Cache – display content

data can be seen in the CPACache Monitor

(not accessible per default)

http://<host>:<J2EEport>/CPACache

Per default no user has access to the CPACache display tool

You get an “403 – Unauthorized” Error when trying to access the URL



CPA Cache – display content (2)

displays objects relevant for adapter framework during runtime

Shows all CPA Cache content objects

E.g. bindings (inbound/outbound) , channels , adapter metadata, services, parties, module configuration

Note: a binding corresponds to a sender or receiver agreement in the Integration Directory. The direction will be inbound (I) or outbound (O), respectively.



CPA Cache: Registration/Push vs. Pull

Registration/Push Mode(automatically or manual)

PULL-Mode (Delta or Full Refresh)http://<host>:<port>/CPACache/refresh?mode=delta|full

Integration Directory => Environment => Cache Notifications

The AE Java Cache will execute a full cache refresh, the first time the engine getsstarted

Pull-Mode: use XIDIRUSER



CPA Cache refresh

manual refresh via URL with user “XIDIRUSER”

http://<host>:<J2EEport>/CPACache/refresh?mode=full



CPA Cache refresh – in detail

AdapterEngine

Notificationhandler Notif Directory

ObjectRepository

ObjectChangelist

handler

Updaterunning

Get object ids

Get Object

Get object from repository

OK / OK with errorsGeneralstatus

Notiferror

Error Statusof single objects

RuntimeCache

Update

XIAFuser XIDIRuser

Directory RepositoryAdapter Engine

- after AE Runtime got the notification it starts the update asynchronously

- via JMS an update notification is written to the notification table

can be seen in Directory Environment Cache Notifications

- the update of CPACache is done using the user XIAFUSER

- the objects from repository (metadata) are accessed from directory using user

XIDIRUSER

- after update the success or failure is written to the notification table



SLD

CPA Cache - Registration

AE CPA Cache

1

Change in XI ID

2 54

3

Enables decentral AE with central configuration

Current Registration Mode (alternative: pull from Adapter Engine)

All parties are loaded; communication channel objects only for the related AE

Step 1: ID contacts SLD to find out which adapter engines are registered, and the URL where the trigger should be sent.

Step 2: ID sends a trigger to the respective adapter engines.

Step 3: adapter engine contacts the SLD to find out the address of the Integration Directory

Step 4: cache refresh occurs between the ID and the AE.

Step 5: Cache status and detailed problem description can be seen in the Integration directory: Environment => „Cache Notifications“ (positive and negative confirmations)



CPA Cache: Schema Upload

Information on available adapter schemas

Important for customer and partner solutions with the PCK; it is checked if thecacheType is „PCK“: then one can upload schema with

http://<host>:<port>/CPACache/schemaupload.jsp

This is not necessary for standard SAP (technical) adapters shipped with the PCK

It is planned for the future that partners deliver and deploy their metadata with thesda-file

TBIT44 Adapters: Messaging System 1

Messaging system


© SAP AG 2003, Title of Presentation, Speaker Name / 2

Learning Objectives

As a result of this unit, you will:

Understand the basics of the messaging system, including:

Messaging System overviewMessage flowImplementation of different adapters



Messaging system overview

XIIS

Adapter Engine

Module Processor

exitStructure conversion Other...

DBIB Directory

Store

API

CPA Cache

Receive/Send Queue

Scheduler retry/EO

Sequencer for EOIO

CPA Cache

SPI

Cache updateXML

Technical adapters

File/JDBC/JMS/ Mail

Other adapters without protocol handlerRFC/SOAP/3rd party

Adapter with protocol handler

RNIF/BC/CDIX

XI message

Protocol handler

ListenerBean

exit

MML/BC …message

XI message

XI message

XI message

XI “adapter”

Protocol handler

XI message

Configuration Configuration

PCK

AFW ListenerBean•Read agreements•Read channels

XI message

SPI

servletservlet

ConvertBean

(Adapter specific)

MML/BC …message

URL URL

Send via HTTP Send via HTTP



Message status in MDT - Prerequisites

Open Runtime Workbench (RWB)Select Message Monitoringselect adapter engine



Example

you can use a simple file sender / receiver scenario to test the display of status

Start (activate) the sender and receiver channel

Start (activate) only the sender channel, deactivate receiver channel

Start (activate) the receiver channel againpress button after selecting the message in “wait” mode

After stopping the receiver channel the message can not be delivered by the adapter engine

The status “Delivering” is shown only for a short period while trying to deliver the message

Status changes to “wait” when message can not be delivered



Status overview of messages in MDT

NDLVD

TBDL

HOLD

DLNG

WAIT

DLVD

FAIL

Worker thread

Delivery exception

Scheduler/ Admin action

successful

Recoverable exception

Max. retries exceeded

Admin action

EOIO, wait for other message

TBDL : ToBeDeLivered, can only be seen as long as no worker thread has started to process the message

DLNG: DeLiverNG

DLVD: DeLiVerD

HOLD: status if message waits for predecessors in EOIO mode

FAIL : a delivery exception occurred , no retry possible

WAIT:a recoverable exception occurred, retry possible, automatic retry by scheduler or manual retry by admin action

NotDeLiVereD: maximum retries to deliver the message exceeded, can be restarted by admin action

TBIT44 Adapters Ex1 RFC to WS Page1 of 14

TBIT44 – Adapters Ex. 1 – RFC to WebService Overview The purpose of this exercise is to implement a synchronous execution of a WebService using RFC from an R/3 system via XI. As a result of this exercise, you will become familiar with the basic sequence of steps to implement a simple interface with XI along with RFC sender adapter and SOAP receiver adapter. This exercise will also introduce you to browse, inspect and export WSDL for any remote enabled functions in a Web Application Server & import of WSDL documents into integration repository.

Prerequisites

Basic knowledge of XI architecture. Description In the R/3 system (Sender) a remote enabled function module call is executed passing the user name as a parameter. The call is sent to XI (Request message), which maps the data, and executes a web service. The details about the user are then retuned to the caller. XI again maps the data (Response message) to match the format of the sender function. For the purpose of this exercise, we will use client 821 of the XI system, to simulate a web service provider. All remote enabled function modules in Web Application Server (6.20 & above) are available as webservices & the WSDL (Web Service Description Language) documents are available in the Web service repository at: http://<host>:<port>/sap/bc/bsp/sap/webservicebrowser/search.html We will use the function module Z_BAPI_USER_GET_DETAIL, exposed as a web service from the client 821 of the XI server.

BAPI_USER_GET_DETAIL

SAP R/3 4.6C

Remote enabled function in SAP WebAS exposed as a Webservice

SOAP RFC

Z_BAPI_USER_GET_DETAIL


Exercise steps Step 1 – Preparation of the interfaces 1.1 Using your browser, open the following URL:

http://<host>:<port>/sap/bc/bsp/sap/webservicebrowser/search.html where <host> is the XI Server host, and <port> is the ICM port (can be obtained from transaction SMICM). Hint: you may start from the TBIT40 Tools home page, to be found on the Integration Builder start page (via SXB_IFR), under Additional Information -> Tools for TBIT44.

1.2 Find the standard BAPI “BAPI_USER_GET_DETAIL”. By clicking on the wsdl link the

WSDL is displayed in the browser. Save the WSDL locally as we will use this later to import it into the repository.

The webservice for BAPI_USER_GET_DETAIL will be invoked from R/3 system using an RFC. The input parameter for this webService is a user id (USERNAME) in the target system and it returns all the pertinent information about this userid. If an invalid Userid is entered, then a message “User xxxxx does not exist” is returned in table RETURN. 1.3 In the sender R/3 4.6C system (business system R3_BACKEND), you will create and

use a remote enabled function module called Z_BAPI_USER_GET_DETAIL_## (where ## is your group number). Go to transaction SE37 and enter BAPI_USER_GET_DETAIL. Copy this function to Z_BAPI_USER_GET_DETAIL_## (## is your group number). Use function group ZATP. In change mode, go to the “source code” tab and delete all executable lines of code. As a result we have a function module with no implementation logic, but with the exact same signature as BAPI_USER_GET_DETAIL (compare screenshot below). Save and activate your changes.


Step 2 – Repository *Please note, as a general rule, all development and configuration objects in XI are CASE-SENSITIVE. 2.1 From the Integration Builder home page, launch the Integration Repository. Log in with

your user ID and password. 2.2 Please locate your Software Component (‘TBIT44_##’) and namespace

urn:sap-com:TBIT44:adapters:group## (## is your group number). 2.3 Open your SWCV and enable the import of RFC and IDoc interfaces from R/3, i.e. the

system you created your function module in. Specify the connection information to the backend R/3 system as provided by the instructor.


2.4 In the left-hand frame, under your SWCV, click on “Imported objects” and click on “Import

of SAP Objects.”

2.5 Log on to the Sender R/3 system (business system R3_BACKEND) and import the

signature of your function module ‘Z_BAPI_USER_GET_DETAIL_##’. You have now imported the metadata for the calling RFC. You may activate the imported objects now.

2.6 We will now import the web service metadata in the form of a WSDL file. In real-life this

file would be supplied by the web service provider. For the purpose of this exercise, we will use the WSDL file previously saved.

2.6.1 Under your namespace in the left frame (urn:sap-com:TBIT44:adapters:group##),

expand the node “Interface objects”. 2.6.2 Right click on External definitions and click on New. Create a new External

Definition called ws_bapi_user_get_detail. Import the WSDL file saved previously. Make sure the Category is WSDL.

2.6.3 Inspect the request and response messages generated.


2.7 Create a new message interface.

2.7.1 In the left frame, right-click on the node “Message Interface” and select “New”. 2.7.2 The name of the message interface will be “ws_user_display_in”.

2.7.3 Make your interface “inbound” and “synchronous”. The input message type should reference the BAPI_USER_GET_DETAILInput from the external definitions and output message type should reference BAPI_USER_GET_DETAILOutput, again from the external definitions. Save the object.

2.8 Create the message mappings for the request and response.

2.8.1 Create a message mapping called ‘user_display_request_map’. This maps the record structure of the Z_BAPI_USER_GET_DETAIL_## to the record structure of the web service request.


2.8.2 Source message should be the Z_BAPI_USER_GET_DETAIL_## imported previously (to be found under Imported Objects). Target message should be the BAPI_USER_GET_DETAILInput from the external WSDL definition (urn:sap-com:TBIT44:adapters:group##).

2.8.3 Since this is request mapping, we have to map only the USERNAME field. Save

the object after mapping is done.

2.8.4 Create another message mapping named “user_display_response_map”.

- Source message: BAPI_USER_GET_DETAILOutput from WSDL file. - Target message: Z_BAPI_USER_GET_DETAIL_##.Response

2.8.5 Since all structure names are same, we can make use of a mapping feature

where all fields and structures with identical names will get mapped automatically. To do this, highlight the top nodes as shown below, and click on

the icon at the top of the screen. All the nodes which have the same names will get automatically mapped. Save the object.


2.9 Now create an interface mapping.

2.9.1 Create a new interface mapping “user_display_in_map”.

2.9.2 Source interface: Z_BAPI_USER_GET_DETAIL_## (Imported Objects) Target interface: ‘ws_user_display_in’ (namespace urn:sap-com:TBIT44:adapters:group##). Make sure to pick the source and target interfaces from your own SWCV and namespace.

2.9.3 Hit the refresh button below to populate the Source and Target messages. Notice that there is a request and response tab. - Request message mapping: “user_display_request_map” - Response message mapping: “user_display_response_map”.

Save the object.

2.10 Finally, go to your change list and activate it. This concludes the steps required in

Integration Builder Design.


Step 3 – Directory 3.1 From the Integration Builder home page, select “Integration Directory”. 3.2 Create your own scenario if you don’t have one already (“TBIT44_##”). Please make

sure all the objects created below are added to this scenario. 3.3 Create a communication channel for the sender system:

3.3.1 The sender business system will be the R/3 system. Locate the business system ‘R3_BACKEND’ and assign it to your scenario.

3.3.2 Navigate to your scenario. Under the business system R3_BACKEND, create a communication channel called ‘RFC_sender_##’. A communication channel is essentially a physical connectivity to/from the application system. This is where the adapter configuration takes place.

3.3.3 Provide the following parameters: - Adapter Type: RFC - Sender - Transport protocol: RFC - Communication protocol: RFC (RFC-XML) - Adapter Engine : Integration Server

3.3.4 For the RFC Server Parameters, provide the following values:

- Application Server: <R/3 host name> - Application Server Service: <gateway service name> (usually sapgw00) - ProgramID: ID_##_TBIT44 (where ## is your group number).


For the metadata repository server, provide connectivity and logon information to the R/3 system as well. This is the system from which the RFC adapter will retrieve the metadata in order to convert the RFC call into XML.

3.4 Create a communication channel for the receiver system: 3.4.1 The receiver Business System will be ‘Training’, which represents client 821 of

the XI Server. Locate the Business System and assign it to your scenario. 3.4.2 In your scenario, under the Business System, create a new communication

channel ‘SOAP_receiver_##’. - Adapter Type: SOAP - Receiver


- Transport protocol: HTTP - Message protocol: SOAP 1.1 - Adapter Engine : Integration Server

3.4.3 Under the connection parameters, provide the following:

- Target URL: this should be the URL of the Web Service listener (see below). Make sure to specify client 821 at the end of the URL string.

- Provide a valid user-id and password for client 821 of the XI server (you may have to log in to the client via SAPGUI and change your password).

http://<host>:<ICM port>/sap/bc/soap/rfc/sap/BAPI_USER_GET_DETAIL?sap-client=821

3.5 Create a “Sender Agreement” object. This defines a binding between the sender

communication channel and the outbound interface. 3.5.1 On the left frame, right-click on the “sender Agreement” New. 3.5.2 Fill in the following values:

- Sender service: R3_BACKEND (BS for R/3 system) - Interface (namespace):

Z_BAPI_USER_GET_DETAIL_## (urn:sap-com:document:sap:rfc:functions)

- In the screen ‘edit sender agreement’, select your own communication

channel ‘RFC_sender_##’.

3.6 Create a Receiver Determination object. 3.6.1 Specify the following parameters:

- Sender Service: Sender Business system (‘R3_BACKEND’). - Sender interface: Z_BAPI_USER_GET_DETAIL_##

(in namespace urn:sap-com:document:sap:rfc:functions) - Receiver Service: Receiver Business system (‘Training’).


3.7 Create an “Interface Determination”: In the following steps, you will create an “Interface Determination” object. Now that we have defined a receiver for the message, we need to assign an inbound interface, and an interface mapping (if necessary).

3.7.1 Save your receiver determination object first. Then, in the area “Configuration

Overview for Receiver Determination” at the bottom of your screen, hit refresh.

3.7.2 In the column “Receiver (Partner/Service)” right-click on “Not Defined” and select “New Specific”, in order to create a new interface determination object.

3.7.3 You are now in the screen “Edit Interface Determination”. In the section “Configured inbound interfaces” select the following using F4 help and select the inbound interface and mapping that you have created in your own SWCV and namespace. When you are done, please save the Interface Determination object. - Inbound interface: ws_user_display_in

Namespace: urn:sap-com:TBIT44:adapters:group## - Interface mapping: user_display_in_map

Namespace: urn:sap-com:TBIT44:adapters:group## SWCV TBIT44_##

3.7.4 Go back to the main screen for your receiver determination. In the area

“Configuration Overview for Receiver Determination” at the bottom of the screen, hit “Refresh”.

3.7.5 In the column “Receiver Determination (Communication Channel)” right click on “Does not exist” and select “New Specific”. Here we have to create a receiver agreement. A receiver agreement defines a binding between the receiver communication channel and the inbound interface.


3.7.6 In the screen “Edit Receiver Agreement”, for the field “Receiver Communication Channel” use the input help (F4), and select your communication channel “SOAP_Receiver_##” (do not use Header Mapping).

3.7.7 Save the Receiver Agreement. 3.8 Go back to the main receiver determination screen and refresh. Your configuration is now

complete. Go to change lists and activate your objects. Step 4 – Testing 4.1 Log on to the sender system (R/3 backend, client 800)

. 4.2 Create an RFC Destination: you will need to create your own RFC destination pointing to the

registered program specified in the sender communication channel. 4.2.1 Create a new destination (‘TBIT44_DEST##’) of type T, using SM59. 4.2.2 Click on Registration button and provide the Program ID that was used in the creation

of the RFC communication channel. Note: the Program ID is case-sensitive and must match exactly what you specified in the sender RFC communication channel (‘ID_##_TBIT44’). After saving your destination, you may use button “Test connection” to see if the destination works well with the registered RFC communication channel.


4.3 Test the function module call. In the R/3 backend, start transaction SE37 and input

“Z_BAPI_USER_GET_DETAIL_##” for the Function Module name. Execute (F8).

4.4 As the RFC Target sys, provide your RFC destination (TBIT44_DEST##). Input any valid user id as USERNAME (the user must exist in client 821 of the XI system). Hit execute (F8).


4.5 Upon execution all the integration server steps will be carried out and a web service call using SOAP adapter should be made and the results will be displayed.

4.6 Inspection of payload: Log in to the integration server (XI client 800) and execute transaction SXMB_MONI to monitor the processed XML messages.

4.7 Fill in the sender values appropriately so that you are looking at the messages you have

processed, e.g. Sender Interface Name Z_BAPI_USER_GET_DETAIL_## for the request. 4.8 Inspect the request and the response message, in particular the payloads. 4.9 Further testing: what will happen if an invalid user id is provided?

TBIT44 Adapters Ex2 File to JDBC Page 1 of 10

TBIT44 – Adapters Ex. 2 – File to JDBC: Using Structure conversion and utilizing built-in EO processing in JDBC adapter Overview The purpose of this exercise is to implement an asynchronous scenario where a file adapter sends data in a comma delimited format; the file adapter performs structure conversion and converts contents of the file into XML format and sends to the integration engine. The data is then mapped to the jdbc XML SQL format and sent to the jdbc receiver. As a result of this exercise, you will become familiar with configuring a file adapter to perform structure conversion and mapping the data to XML SQL format. The exercise also takes advantage of the built in Exactly Once (EO) processing capabilities of the JDBC adapter.

Exactly Once Processing - Background

As in the other adapters, Exactly Once messages are handled by default using status information in the J2EE server. All adapter error statuses and program terminations initialized externally are also handled in this mode. However, this does not include external program terminations during a database commit. In this case, the status of message processing is unclear since it can only be changed once the database commit has been completed.

The receiver JDBC adapter has two persistence modes that enable Exactly Once processing:

Local

Database

In the past, with the J2SE Adapter Engine, Local meant that EO handling was file based (i.e. status information management was maintained within the local file system). This caused security concerns and was generally considered unsafe. In Database mode, message processing and status information management took place in the same database allowing the processing steps to have the same commit cycle and eliminating any doubt in EO handling.

With XI 3.0, since the J2EE Adapter Engine is deployed on top of the J2EE engine (which also has database persistence) the EO handling in Local mode is now also database based and in one database transaction with the message processing including the message persistence. This makes the Local mode EO handling just as reliable as Database mode EO handling. Note: Currently, the Database mode has not been implemented. It will be enabled for SP9. Prerequisites

Basic knowledge of XI architecture & databases. Description A table VendorMaster in the SQL server is created as shown: In this table we will store the vendor data.

File system

JDBC File


Exercise steps *Please note, as a general rule, all development and configuration objects in XI are CASE-SENSITIVE. Step 1 – SLD: Creating a technical system, business system and the software component version are not in scope for this exercise. Step 2 – Repository 2.1 Log on to the Integration Repository. 2.2 Examine existing data types: under the SWCV ‘TBIT44_BASE_COMP’ (or in your SWCV

under Basis Objects), namespace ‘urn:sap-com:TBIT44:adapters:common’, expand the node Data types. Please inspect the data types Vendor_file_DT & Vendor_SQL_DT. Please pay special attention to Vendor_SQL_DT. Data type Vendor_file_DT is used to describe the data sent by the file & Vendor_SQL_DT is used to describe the data in XML sql format. We will be using this format to write to the database using JDBC adapter.

2.3 Examine existing message types: Vendor_file and Vendor_SQL. 2.4 Create message interfaces: create 2 new message interfaces in your SWCV TBIT44_##

in your namespace urn:sap-com:TBIT44:adapters:group##: - Vendor_file_out_## (outbound asynchronous) using the message type Vendor_file. - Vendor_SQL_in_## (inbound asynchronous) using the message type Vendor_SQL.

Message interface: Vendor_file_out_##


Message interface: Vendor_SQL_in_##

2.5 Create a message mapping.

2.5.1 In the left frame right click on the node, message mappings under mapping objects and create a new message mapping called VendorFile_VendorSQL_##.

2.5.2 Set Vendor_file as source message type and Vendor_SQL as target message

type, both from namespace urn:sap-com:TBIT44:adapters:common. The message mapping shall map the data from the XML format converted from the file to the XML sql format the JDBC adapter accepts.

Drag the source fields to the target fields as shown. To map the attribute “action” , drop a constant and change the default value of the constant to “update_insert” and map the constant to action.


Be sure to map the root-level node of the target document to the root-level node of the source. Save the object. Be sure to understand the semantics of the target document. Where did the metadata come from?

2.6 Create an interface mapping VendorFile_VendorJDBC_##.

2.6.1 Create a new interface mapping VendorFile_VendorJDBC_## by right clicking on the interface mapping on the left frame.

2.6.2 As source interface, select Vendor_file_out_## from your SWC. For the target

interface, select Vendor_SQL_in_## message interface that was created earlier from your own namespace.

Hit the refresh button to populate the Source and Target messages. Associate the message mapping VendorFile_VendorSQL_##.

Save the object.

2.7 Finally, go to your change list and activate it. This concludes the steps required in

Integration Builder Design.


Step 3 – Directory 3.1 From the Integration Builder home page, select “Integration Directory”. 3.2 For this exercise you will re-use the scenario ‘TBIT44_##’. Create the scenario object if

you have not done so already in the previous exercise. Please make sure all the objects created below are added to your scenario. If it is not, you can do this from the “Objects” tab by navigating to the object, bringing up its context many and selecting “Add to Scenario…”. Select your scenario.

3.3 We have to create two communication channels. A communication channel is essentially a physical connection point to/from the application system. This is where the adapter configuration takes place. 3.3.1 The two business systems we are going to use are TBIT44_file_sender and

TBIT44_JDBC_receiver. Locate the business systems and assign them to your scenario.

3.3.2 Create a new Communication Channel for TBIT44_file_sender called

“file_sender_##”. Expand Service Without Party Business System TBIT44_file_sender. Right-click on Communication Channel and select “New…”. Name your Communication Channel file_sender_## and choose “Create”.

3.3.3 In the Edit Communication Channel screen, provide the following parameters:

Adapter Type: File Choose Sender Transport Protocol: File System (NFS) Message Protocol: File Content Conversion Adapter Engine : Integration Server

File System Access Parameters Source Directory* d:/usr/sap/trans/tmp/group## File Name* Vendor##.txt

Content conversion Parameters: • Document name: ‘Vendor_file’ • Document namespace: ‘urn:sap-com:TBIT44:adapters:common’ • Recordset Name: ‘Recordset’ • Recordset Namespace: (blank) • Recordset structure: Row,1 • Recordsets per message: * • Key field name: (blank) • Key field type: String (case-sensitive)


We will use the following advanced parameters for the content conversion:

Enter into the Row.fieldNames (case sensitive!) value the following: VendorNumber,LastName,SearchTerm,Currency,Street,City,Zip,Country Take a moment to compare this with the data type in the repository (Vendor_file_DT in namespace urn:sap-com:TBIT44:adapters:common). See how the document name and namespace and other values here are used in the datatype.

Note the large Poll Interval. For testing purposes, we want to set an unusually high interval to avoid inadvertent messages being sent continuously. While testing this scenario, sending of the file will be very deliberate by manually copying the test file into the source directory and reactivating the communication channel as described below in the testing section. 3.3.4 Create a new Communication Channel for business system

TBIT44_JDBC_receiver called JDBC_receiver_EO_## using the following parameters:

Adapter Type: JDBC Choose Receiver Transport Protocol: JDBC 2.0 Message Protocol: XML SQL Format Adapter Engine : Integration Server


JDBC Driver*: com.microsoft.jdbc.sqlserver.SQLServerDriver Connection*: jdbc:microsoft:sqlserver://iwdf5210.wdf.sap.corp:1433;DatabaseName=Northwind Double-check with the instructor that this is the database server which will be used for the class. The instructor will provide you a user id & password.

This is where you select the persistence mode for EO handling as described in Exactly Once Processing Background in the beginning of the exercise. As a reminder, Database mode is currently not implemented.

3.4 Next step is to create a “Sender Agreement” object. This defines a binding between the

sender communication channel and the outbound interface.

3.4.1 On the left frame, right-click on the “Sender Agreement” New. 3.4.2 Fill in the following values on the pop-up screen for the sender agreement and

click “Create”. Service: TBIT44_file_sender Interface: Vendor_file_out_## Namespace: urn:sap-com:TBIT44:adapters:group##

3.4.3 In the “Edit Sender Agreement” screen, enter “file_sender_XX” for Sender

Communication Channel and save.


3.5 Create a receiver determination object: 3.5.1 In the left frame, right-click on “Receiver Determination” New.

3.5.2 Specify the following parameters in the pop-up and click “Create”:

- Sender service: TBIT44_file_sender - Sender Interface: Vendor_file_out_## - Sender namespace: urn:sap-com:TBIT44:adapters:group##

3.5.3 For Configured Receivers, select Service TBIT44_JDBC_receiver and save. Remain on the Receiver Determination screen.

3.6 In the following steps, you will create an “Interface Determination” object. Now that we

have defined a receiver for the message, we need to assign an inbound interface, and an interface mapping (if necessary).

3.6.1 In the area “Configuration Overview for Receiver Determination” at the bottom of

your screen, hit refresh.

3.6.2 In the column “Receiver (Partner|Service)” right-click on “Not Defined” and select “New Specific”, in order to create a new Interface Determination object.

3.6.3 You are now in the screen “Edit Interface Determination”. In the section

“Configured Inbound Interfaces” select the following using F4 help. When you are done, please save the Interface Determination object.

Inbound Interface: Vendor_SQL_in_##

Interface Mapping: VendorFile_VendorSQL_##


3.7 Now we create a “Receiver Agreement” object. This defines a binding between the receiver communication channel and the inbound interface. This will allow you to assign a receiver communication channel to the receiver service/interface you have chosen. 3.7.1 On the screen ‘edit receiver determination’, in the area “Configuration Overview

for Receiver Determination” at the bottom of your screen, hit refresh.

3.7.2 From the screen ‘edit receiver determination’, under ‘Receiver Agreement’, right-click on “Does Not Exist” and choose ‘create new specific’.

3.7.3 Enter “JDBC_receiver_EO_##” for Receiver Communication Channel and save.

3.8 Go back to the previous Receiver Determination screen and click on the refresh button

within the Configuration Overview for Receiver Determination section at the bottom.

Your configuration should now be complete. Before you activate your objects, you will need to set up a file to be picked up. This will be explained in the next section.


Step 4 – Testing 4.1 You can download an example file from the TBIT44 Tools home page into your group

folder on the XI server drive. Examine the contents of the file Vendor##.txt (you may enter a name of your choice for easier find your result later). When the file is placed in the Source Directory of the sender file adapter (as specified in the Communication Channel ‘file_sender_##’), the file adapter will pick up the file and process it when the next polling cycle begins.

Hint: In order to reset the polling cycle of the inbound file adapter, you must go back to the Integration Directory and “reactivate” your communication channel ‘file_sender_##’ under the business system ‘TBIT44_file_sender’ (reactivate means: change anything, e.g. the description, save this and activate your changes). As soon as the file sender communication channel is activated and is replicated in the adapter engine cache, the polling cycle will start (this could take a few seconds).

4.2 Monitor your directory. The file should disappear after a few seconds. This means that it

was processed and then deleted by the adapter engine. 4.3 Log on to the XI Integration Server, choose monitoring Integration Engine monitoring

(or execute transaction SXMB_MONI). 4.4 Choose “Monitor for Processed XML Messages”. You can filter using different criteria, for

example by date and also by sender service (find your own business service name in the drop-down list). In the monitor, look for your message being sent to the JDBC adapter. Inspect the message for any errors.

4.5 In the Runtime workbench, under ‘Message monitoring’, select messages from

component ‘af.<SID>.<host>’ (this represents the central adapter engine.) Using the filter configuration, find your message ID in the list. Select your message, and click ‘Details’. From the details screen you can select ‘Audit Protocol’ for more information regarding the status of your message and the JDBC post.

4.6 To verify that the data is posted to the SQL server, you may start the NortwindRequest

from the TBIT44 Tools home page.

Sample Result: <?xml version="1.0" encoding="utf-8" ?> <ROOT>

<row Vendor_Number="301000" Last_Name="Smith Search_Term="John" Currency="USD" Street_Address="3421 Hillview" City="Palo Alto" Zip="94304" Country="US" />

</ROOT>

Exercise 1 – Business Process Management – Collect master records Overview In this exercise we continue to focus on the Business Process Management capabilities of XI 3.0. The goal is to implement a simple, stateful process. As a result of this exercise you will be able to model a “collect” pattern using BPM and apply it to IDoc communication. You will become familiar with the concept of correlation, and multi-mapping (N:1 mapping). Prerequisites

- Good understanding of basic XI features - Good understanding of basic BPM features

Description The requirement is to collect incoming vendor master records. The incoming messages arrive via the file adapter (or, for testing purposes, the plain HTTP adapter). After a certain number of messages are collected, they are bundled and mapped to a package of IDocs. This package of IDocs is then posted into the R/3 system via the IDoc adapter. The number of messages to be collected can be determined in one of three ways: a) a fixed number is explicitly specified (e.g. “collect 5 messages”) b) a relative or absolute time limit is set (e.g. “collect until 3PM” or “collect for 3 hours” c) messages are collected indefinitely, until a certain trigger (a specific interface type) is

received (e.g. “collect messages of type A UNTIL a message of type B arrives”). The standard BPM collect patterns are already predefined any new XI 3.0 installation. The focus here is on the customer requirement for XI to post IDocs into R/3 as packages and yet being able to handle each of them individually. For the purpose of this exercise we will implement option (a) above, for simplicity reasons. Options (b) and (c) can be implemented as optional exercises. In this exercise you will see that, when implementing BPM, the bulk of the work does not necessarily take place within the business process modeler itself. Preparing all the surrounding objects in the Repository and Directory may require just as much time and effort. Exercise steps Step 1 – Repository Prepare interface and mapping objects 1.1 Log on to the Integration Repository and prepare interface objects.

1.1.1 Examine existing objects: in the Integration Repository there is a namespace “urn:sap-com:atp:TBIT44:base” in the software component “TBIT44, 2004 of SAP”, which contains objects which are prepared for this exercise and needn’t be created manually.

1.1.2 Create the message interface Vendor_out_collect (outbound, asynchronous) in your namespace urn:sap-com:TBIT44:BPM:group## (it will be used for vendor information in this exercise). Reuse the Message Type “Vendor” from the “urn:sap-com:atp:TBIT44:base” as Output Message.

1.1.3 Business Processes only work with abstract interfaces. Create an abstract, asynchronous message interface called CREMAS in your namespace (based on single IDoc CREMAS03, which is located under “imported objects”). This will be the input to the process.

1.1.4 Examine the structure of the imported object “CREMAS.CREMAS03”. It can only be used as a single IDoc and not as a package. Therefore it cannot be used as-is for the target of the 1:N mapping and the output of the business process. We need to use a manual workaround to create a structure able to handle packages:

1.1.4.1 Export the XSD definition of the IDoc into your group folder

1.1.4.2 Edit the XSD definition with notepad and change the element name IDOC by adding parameters minOccurs and maxOccurs:

<xsd:element name="IDOC" type="CREMAS.CREMAS03" minOccurs="1" maxOccurs="unbounded" />

1.1.4.3 Create an external definition object called CREMAS_package. Import

the modified XSD.

1.1.5 Create an message interface CREMAS_package (based on the external definition CREMAS_package from the previous step) as abstract asynchronous message interface. This will be the output of the business process.

1.1.6 Create the Interface mapping Vendor_out_CREMAS03_abstract in your

namespace urn:sap-com:TBIT44:BPM:group##. This will be the mapping applied between the sender and the BPM (before entry into the BPM).

- Source interface: Vendor_out_collect (outbound, asynchronous) from your namespace urn:sap-com:TBIT44:BPM:group##.

- Target interface: CREMAS (abstract, asynchronous) from your namespace - Message mapping:

Select the existing Message Mapping Vendor_CREMAS03 from the urn:sap-com:atp:TBIT44:base namespace.

1.1.7 Now we will create a N:1 mapping (multi-mapping) which will be applied within

the BPM. The input is an array of individual IDocs, and the output is an IDoc package.

1.1.7.1 Create a new message mapping CREMAS_multi_package.

Source message: CREMAS.CREMAS03 (original IDoc) Target message: CREMAS03 (from external definition object

CREMAS_package – no drag&drop possible).

1.1.7.2 Goto the “Messages” tab and change the occurrence of the source message to “0..unbounded”. This defines the mapping as N:1 mapping.

1.1.7.3 Map the node “CREMAS03” from the source document to the structure “IDOC”. This indicates that the root of each source message should be mapped to an IDOC node in the target

1.1.7.4 In the target message, disable the node “EDI_DC40”. 1.1.7.5 Assign the constant “1” to the target attribute “BEGIN”. 1.1.7.6 The rest of the mapping can be completed automatically:

Highlight the nodes “E1LFA1M” in the source and target document

Click on the button (“map selected fields and substructures if names are identical”).

Verify that all fields were mapped correctly.

1.1.7.7 Test your mapping with multiple source messages

1.1.8 Create an interface mapping CREMAS_multi_package. All referenced objects

are part your namespace urn:sap-com:TBIT44:BPM:group## in your SWCV: Source interface: CREMAS (abstract) Target interface: CREMAS_package (abstract). Mapping program: CREMAS_multi_package (created above.)

For the source interface remember to change the Occurrence to “0..unbounded”, in order to match the message mapping.

1.1.9 Create a context object called zipcode (type String) in your namespace. 1.1.10 In your abstract message interface CREMAS (namespace urn:sap-

com:TBIT44:BPM:group##), associate the context object “zipcode” to field PSTLZ in segment E1LFA1M. We will use this as correlation id in BPM to correlate the messages.

Step 2 – BPM 2.1 Create a Business Process object “CREMAS_collect_package” in your namespace. 2.2 Create the following container variables

(with all references to your namespace urn:sap-com:TBIT44:BPM:group##): - counter (Category: Simple type; Type: XSD:Integer) - CREMAS_single (Category: Abstract interface; Type: CREMAS) - CREMAS_multi (Category: Abstract interface; Type: CREMAS; Multiline Checked) - CREMAS_package (Category: Abstract interface; Type: CREMAS_package)

2.3 Create the correlation object

2.3.1 Switch to the correlation List

2.3.2 Create a correlation object named “zipcode” and click on the details icon. This will display the correlation editor screen. Here more details about the correlation can be entered.

2.3.3 Specify the following:

- Correlation Container: enter the name “zip” (type xsd:string) - Involved messages: select “CREMAS” - Properties: assign your context object as the value for the correlation container “zip”.

You context object should appear in the condition editor.

2.3.4 The correlation editor screen should look as follow, after the correlation is defined:

2.4 Switch to the Graphical Definition mode and compose the business process flow by drag-

and-dropping each step into the desired location and filling out the parameters as specified below: - Loop step – this step will ensure that we will collect exactly 3 IDocs.

(“Loop 3 times”) o Step name: “Loop3” o Condition: “counter ≠ 3” (use the condition editor to fill the condition

property; “3” is a constant of type xsd:integer).

- Receive step (inside the Loop) – this step will receive incoming IDocs and correlate based on zipcode (“receive single IDoc and correlate”)

o Step name: “Receive CREMAS” o Message: “CREMAS_single” o Start process: yes o Use Correlations: “zipcode” o Activate Correlations: “zipcode”. o zipcode zip: CREMAS_single.zipcode (is assigned automatically).

- Container Operation step – this step will increase the loop counter (“counter = counter +1”).

o Step Name: “increment counter” o Target: “counter” (simple variable) o Operation: “Assign” o Expression: “counter” (simple variable) o Operator: “+” o Expression: “1” (constant – type xsd:integer)

- Container Operation step – this step will append the newly received IDoc to the list

of IDocs already collected. A multiline container is used for this purpose. (“Append CREMAS_single to CREMAS_multi”).

o Step Name: Append IDoc to list o Target: CREMAS_multi (Interface variable) o Operation: Append o Expression: CREMAS_single.

- Transformation step – this step occurs outside the loop. It will call the N:1 mapping

which will create the IDoc package. o Step Name: map IDocs to package o Interface mapping: CREMAS_multi_package o Source message: CREMAS_multi o Target message: CREMAS_package

- Send step – this step will send the package of IDoc to the R/3 system

o Step Name: Send CREMAS package o Mode: Asynchronous o Message: CREMAS_package o Acknowledgement: none o Receiver from: send context

The completed business process diagram should look like this:

2.5 Check the process (F7) and save. 2.6 Activate all Repository objects.

Step 3 – Directory 3.1 Log on to the Integration Directory and navigate to your scenario TBIT44_##. Create a

business process object CREMAS_collect_package## (under “Service without Party”). In this step import the business process created in the repository. 3.1.1 The wizard starts. Select your business process CREMAS_collect_package

from your namespace urn:sap-com:TBIT44:BPM:group##. Specify the name CREMAS_collect_package## and finish the wizard.

3.1.2 Open the created business process and note the signature of the process (interfaces are listed under the sender and receiver tab).

3.2 We will create 2 receiver determinations: DMS_CRM BPM and

BPM R3_BACKEND.

3.2.1 DMS_CRM BPM 3.2.1.1 Create the receiver determination from DMS_CRM to BPM with the

following sender information: Service: DMS_CRM Outbound Interface: Vendor_out_collect

(namespace urn:sap-com:TBIT44:BPM:group##)

3.2.1.2 Complete the receiver determination and interface determination as follows: Receiver service: CREMAS_collect_package## (your BPM object) Inbound interface: CREMAS Interface mapping: Vendor_out_CREMAS03_abstract

Make sure, that you are only using object from your namespace urn:sap-com:TBIT44:BPM:group## (## is your Group Number)

Notice that no receiver agreement or communication channel is necessary when BPM is used as a receiver

3.2.2 BPM R3_BACKEND

Sender service: CREMAS_collect_package## Outbound interface: CREMAS_package Receiver service: R3_BACKEND Inbound interface: CREMAS.CREMAS03 Interface mapping: none

3.3 If necessary, create a receiver agreement for the IDoc receiver. It should point to the existing communication channel IDoc_receiver.

Note that the IDoc adapter will lookup the logical system name of the sender from the SLD. In this case the sender of the message is the BPM process ‘CREMAS_collect_package##’. This would lead to an error at runtime since there is no corresponding entry in the SLD. The solution is to overwrite the sender service name using the header mapping functionality. - In the ‘Header Mapping’ section, check ‘Sender Service’. - From the drop-down list, select the original sender ‘DMS_CRM’.

3.4 Save and activate all objects.

Step 4 – Test For convenience reasons, we will test with the plain HTTP client in order to send three separate XML messages successively. You can start the plain HTTP client from the TBIT44 Tools home page, to be reached from the Integration Builder home page. 4.1 From the plain HTTP client, send the first XML message as follows:

- Sender Service: DMS_CRM - Sender Interface: Vendor_out_collect - Interface Namespace: urn:sap-com:TBIT44:BPM:group## - QoS: EO Replace ## with your group number. You may use 00099##001 as vendor number.

4.2 Examine your message in transaction SXMB_MONI. On the selection screen, use the

View Process. Notice that the message was sent to the process engine, and that the status of the workflow is ‘in process’ (in the message overview, select PE in column Outbound).

4.2.1 Drill down to the workflow details 4.2.2 Display the workflow log 4.2.3 Display the technical details of the workflow log

4.2.4 Display the graphical details of the workflow log 4.3 Send a second and a third message using the same zipcode (!).

You may use 00099##002 and 00099##002 as vendor number. 4.4 Notice that the process is now in state ‘COMPLETED’ and that a new message

containing the IDoc package was sent to the R/3 system.

4.5 Check in the R/3 system in transaction WE05 or BD87 that 3 IDocs were posted.

Maks sure, that you use Vendor Numbers, that are not already used in the Backendsystem: For Example use 00099##001, 00099##002,.. with ## = Group Number.

You can check in Transaction XK03, that your Vendors have been created.

Appendix: naming conventions and terminology Exercise 5

Area Obj. type Object name Description SLD BS DMS_CRM Business system for legacy app BS. R3_BACKEND Business system for R/3 Int. Rep. NS urn:sap-com:TBIT44:BPM:group## Namespace for legacy objects Data type Vendor_DT Vendor data type Address_DT Nested DT Msg.type Vendor Vendor message type Msg.int. Vendor_out_collect Copy of Vendor_out Ext.def. CREMAS_package Modified XSD for IDoc packages Msg.map Vendor_CREMAS03 Message mapping Int.map Vendor_out_CREMAS03_abstract Interface mapping Abs.int. CREMAS Single IDoc (BPM input) Abs.int. CREMAS_package Package of IDocs (BPM output) BPM CREMAS_collect_package BPM object Context zipcode Context object for zip code BPM Cont. counter Counter for received IDocs Cont. CREMAS_single Individual IDoc Cont. CREMAS_multi Multiline IDoc Cont. CREMAS_package IDoc package Correl. zipcode Correlate by zipcode Corr.cont. zip Points to

/CREMAS03/IDOC/E1LFA1M/PSTLZ Msg.map CREMAS_multi_package Map multiline to package Int. map CREMAS_multi_package Interface mapping Int. Dir scenario TBIT44_## Common for all exercises service DMS_CRM Derived from BS (no party) service CREMAS_collect_package## Business Process service R3_BACKEND Derived from BS. Int. Serv. RFC dest SM59 dest + ALE port R/3 IDoc CREMAS.CREMAS03 Vendor master data Log.Sys. DMS_CRM Same as above

TBIT44 BPM Exercise 2 1

TBIT44: BPM

Exercise 2:Sales Order Processing


Car dealers could use a non-SAP CRM system to order spare parts. The slideshows an overview of a system landscape for the procurement of spare parts fordifferent brands. The interfaces to the supplier systems are usually defined by the dealermanagement systems of the manufacturers. No-name products could be controlleddirectly by the dealer.

© SAP AG 2004, SAP NetWeaver Henrik Stotz 2

Use Case

ERP

Dealer Management System Supplier 1

CRM/Catalog

OrderFulfillment


ERPDealer

XI/BPM

CRM

Dea

ler M

anag

emen

t Sys

tem

Sup

plie

r2

Catalog

OrderSystem

OrderSystem

OtherSystem

OtherSystem

OtherSystem

OtherSystem

OtherSystem

EBP+„No-name“

Catalog

No-nameSupplier1

No-nameSupplier2

No-nameSupplier3

CRM

OtherSystem



ERP


Catalog/CRM

OrderFulfillment

ERPDealer

XI/BPM


•The CRM system sends data item-by-item in a given format.•The SAP system performs checks. •If the CRM system sends a new material, the material will be created in two clients.•A purchase order and a sales order are created.•The purchase order is sent to the supplier and the order confirmation sent by thesupplier is acknowledged.There is one excercise for each step.


Overview

Send items

Integration Process

1. Receive orderitems

2. Preparations

Preparations3. Create materialsif necessary

Create materials

4. Create purchase and sales order

Create purchase and sales order

5. Send purchase order to supplierand receive confirmation

Receive ordersend confirmation

CRM System Travel AgencySummer

AirlineGroup1AirlineGroup2


1. Receive order items2. Preparations3. Create materials4. Create purchase and sales order5. Send purchase order to supplier.


Integration Process

1 2 3

4 5


The business case for the complete process is a simplified selling of spare parts. The spare parts are selected in a non-SAP Catalog/CRM system, which is simulated in the exercises by a Web Dynpro user interface.


Web Dynpro User Interface


Since the non-SAP Catalog/CRM System sends the spare part items in individual messages, the process starts with a collect pattern. The order items are merged into a single message which is then used in exercise 2 where the preparations in the SD system are made.


Exercise 1: Receive Spare Part Items

Collect pattern:Items correlated by CustomerNoEnd condition:

after sending 3 items

Asynchronous Web Dynpro - XI Communication using SOAP Adapter


In this exercise, the “itemlist” is transformed to a “list”, which is sent synchronously to the business system Airline_Group_One. The response message contains the materials that must be created in the next exercise. This exercise also demonstrates exception handling for application and system errors. In case of an application exception, an alert is thrown, which can then be reviewed in the alert inbox.Use material 9999 to create an application exception that raises the alertMaterials 1000, 2000, 3000 will be always created if sent to the process


Exercise 2: Preparations

Transformation step

Synchronous send step

catches application and

system exceptions

Returns a list of materials that have

to be created

Application exception


In this exercise, the materials determined in the last exercise are created. This is done by combining a block in ParallelForEach mode with a block in ForEach mode, which loops over the list of receivers determined beforehand (broadcast pattern).


Exercise 3: Create Materials

Material1

Material2

System1System2

System1System2


In this exercise, the sales and purchase orders are created in parallel. If one fails, both orders are canceled. As an extension of this exercise, the creation of the purchase order part is enhanced by a manual compensation in case the creation of the purchase order fails. The exercise uses application and transport acknowledgments of send messages. Moreover, send contexts are used for routing purposes.If the Response Status field for the Purchase Order is ERROR, the process waits for one minute.If the error was corrected and a OK-Message has been raised manually theResponse Status field is set to OK. Thisindicates that the purchase order has been corrected manually. Thiscorrection can be done with report ZSK_STARTMESSAGE_OUT in client813 (!).If you don‘t run the report, no message is received and a timeout occuresafter one minute and the process is continued. In this case, the Response Status field for the Purchas Order remains on ERROR and both orders arecancelled in the next block.You can force the ERROR situation for the purchase order if CustomerNocontains a “Y“. To create an error in the SalesOrder, CustomerNo must contain a “Z“.If you don‘t compensate the purchase order “manually“ the process continues after one minute.


Exercise 4: Create Purchase and Sales Order

• Fork for parallel processing• Transport and application acknowledgments• Using send contexts• Correlation• Container operations• Switch• “Manual Exception Handling”




Purchase order errorcan be correctedin a given timeframeby starting the reportmanually

Report executed in time. Message sent to the process indicating the that purchase order is ok. The process PurchaseOrder status is updated.

“manual compensation”




If an error in the purchase order is not compensated “manually” (see last slide), the Purchase Order Status flag keeps the status ERROR for the process. If the timeout occurs, the process continues and runs into “automatic compensation”.

If either the purchase order OR the sales order run into an error, the “automatic compensation” branch cancels BOTH Orders, raises an alert, and then cancels the whole process

“Automatic compensation”


In this exercise, the purchase order is sent to the supplier. An order response is received and acknowledged.


Exercise 5: Send Purchase Order

• Purchase order is sent• Order confirmation is received• Order confirmation is acknowledged



Runtime Example: SXMB_MONI



Runtime Example: Workflow Log



Runtime Example: Graphical Workflow Log

Exercise 2 – Business Process Management – Purchase Order

Part 0: Overview

Prerequisites

- Good understanding of XI features - Good understanding of BPM features

Overview The business case for the complete process is a simplified selling of spare parts. The spare parts are selected in a non-SAP Catalog/CRM-System, which is in our exercises simulated by a Web Dynpro user interface. Since the non-SAP Catalog/CRM System sends the spare part items in individual messages, the process starts with a collect pattern (exercise Receive Order Items). In the Receive Order Items exercise the order items are merged into a single message which is then used in the Preparations exercise where the preparations in the SD system are done. The Preparations exercise consists of a synchronous call to the SD system to check whether missing materials have to be created. If so, the materials are created in the Create Materials exercise by looping through a list of missing materials and sending each material to the receivers, which are found using a receiver determination step (MM and SD system). In the Create Orders exercise, a sales order and a purchase order are created. The last exercise - Send Purchase Order to Supplier - covers the communication with the supplier who receives and confirms the purchase order. Exception handling is also part of the exercises. In order to focus on the modeling of the process we hide complexity. Therefore, we have simple message types and there are no mappings between process interfaces and the interfaces used by the business systems. In fact, we simulate the business objects (e.g. create Material, create Order) using ABAP proxies in the business systems, which are physically the clients 811 (Supplier), 812 (SD), 813 (MM) in the Integration Server box. Moreover, the Integration Directory configuration is preconfigured and so does not have to be done by the participants. The following graphics show the business scenario, which is separated in five exercises:

1. Receive Order Items 2. Preparations 3. Create Materials 4. Create Orders 5. Send Purchase Order to Supplier

At runtime, the following business systems are used: CRMCatalog DMSCRM SD System Airline_Group_One MM System Airline_Group_Two Supplier Travel_Agency_Summer

1. Receive Order Items

2. Preparations

3. Create Materials

4. Create Orders

5. Send Purchase Order to Supplier

A complete process, which creates two materials that are sent to two systems, produces the following messages (message selection in client 800 only) and Workflow logs:

Receive Order Items

Preparation

Create Materials

Create Orders

Send Purchase Order to Supplier

Exercise 2 BPM: Purchase Order

Exercise 1: Receive Order Items The aim of the exercise is to collect three incoming order items. The incoming messages arrive from the SOAP adapter. This is triggered by a Web Dynpro application.

Part 1 – Find your business process & check the environment Log on to the Integration Repository and navigate to your business process in SWCV SELLSPAREPARTS, namespace http://sap.com/xi/BPM/Spareparts. If you are in Group ##, your business process is SellSpareParts_0## (Process SellSpareParts_000 is reserved for the instructor). Do not open and edit your business process from within your SWCV TBIT44_## because that will lead to a modification instead of editing of the process. The exercise focuses on the Repository only, the necessary configuration in the Directory is already done and assumes the fixed names of business process (SellSpareParts_0##) and namespace (http://sap.com/xi/BPM/Spareparts). Your instructor will tell you if you should work on the existing object or create a new business process. The initial process consist of a container element item (abstract interface: item_abstract) and a receive step as Start Process, see below. In case you create a new business process, you have to delete the existing one first and you have to delete the business process in the Directory and import your new process as well!

Graphic 1: Find your business process

Initially, your process template only contains one receive step. If you run into trouble during the creation of the exercises, you can open the exercise solution in a second window for guidance. If you are not able to finish an exercise, you can delete your process and recopy it from the solution template. Make sure that you use exactly the same process name as before. For example, if you want to start with exercise 3, you can start by resetting your process from the Solution_2 process. Make sure that you activate the process.

your process

solution template

Graphic 2: Creating your exercise process based on the solution template

Part 2 – Test the initial state of your business process By executing this step you test the system environment.

1. Go to the TBIT44 Tools home page and select the url for BPM exercise 2. (http://<server>:<port>/webdynpro/dispatcher/local/OrderSparePartItem/OrderSparePartItem)

2. Enter the name of your business process in the Process Definition field. This is very important; otherwise you will send the data to a different process.

NOTE:

You might run into problems with endless running processes caused by the wrong process design. In this case, the workflow log shows an older protocol time stamp. To avoid interference with these process instances use a different Customer Number. 3. Click SendItem .

There is no confirmation on the web page.

4. Log on to the Integration Server (ABAP stack, client 800) and check in transaction SXMB_MONI whether you can see your SparePartItem message. The Receiver Service column must display the name of your process .

You may use the /SPAREPARTS layout for the list layout:

5. Check the Workflow log (refer to the screenshots below):

6. Select your process instance by calling transaction sxmb_moni_bpe. Enter the name of your process in the Service field on the selection screen, then choose Execute.

Double-click the process instance to open the Workflow log:

Use the transaction SXMB_MONI_BPE to find your process instances.

Double-click

Step 3 – Building the collect pattern

1. Delete the receive step in your scenario.

2. Insert the following block:

3. Define a container element counter (type xsd:integer):

4. Insert a loop (called ReceiveOrderItemLoop) with the condition “counter ≠ 3”: (“3” is xsd:integer)

5. Create a correlation CorrCustomer with Correlation Containter IDCust (xsd:string), involved message item_abstract, and Property “IDCust: Value CustomerNo”:

Make sure that in the XPath expression the Multiline check box (lower right corner) is deselected. This is necessary for all XPath expressions you create in correlations or if you use/activate a correlation in a send or a receive step.

6. Check that a container element item is already present in the process container:

7. Insert a receive step:

Name it ReceiveOrderItem and specify the following properties:

8. Define a container operation on the element counter:

9. Create a container multiline element itemlist:

10. Define a container operation called RecOrderItemSelect to append a single item from container element item to the list of items in container element itemlist:

(In the expression editor: make sure that the Multiline check box is deselected.)

11. Save and activate your process.

12. Send three items to your process by using the Web Dynpro user interface (i.e. submit three times after another):

13. Check the workflow log of your process. It should look as follows:

As you send three items with the same customer number they are collected by the process. After the third item, the condition becomes TRUE; therefore the loop is finished and the process is complete.

Exercise 2: Preparations In this exercise the “itemlist” is transformed to a “list”, which is send synchronously to the business system Airline_Group_One. The response message contains the materials which must be created in the next exercise. This exercise also demonstrates exception handling for application and system errors. In case of an application exception, an alert is thrown, which can then be reviewed in the alert inbox.

1. To collapse the ReceiveOrderItemBlock block you created in the first exercise, choose Collapse from the context menu:

2. Define a new block Preparation with two exceptions SystemError and ApplicationError:

3. Create a new container element list (category Abstract Interface, type list_abstract):

4. Insert a transformation step PrepTransformation using the interface mapping itemlist2list. The source message is itemlist, the target message is list:

5. Create a new container element preplist (category Abstract Interface, type list_abstract) which contains the result of the preparation call:

6. Insert a send step SendPreparation:

Set the mode of the send step to Synchronous. The send step uses the synchronous Interface prep_sync_abstract. The request message is list and the response message is preplist. For the Exception System Error enter SystemError, for the exception Application Fault enter ApplicationError. 7. Add two exception branches for the exception handlers SystemError and

ApplicationError by calling the context menu.

8. Add a control step PrepControlAppException into the exception handler for the exception ApplicationError:

Select the Throw Alert action and the PROCESS ALERT alert category. Enter an appropriate alert message (e.g. Preparation Checks group ‘’ failed).

9. In the exception handler branch for the SystemError exception, insert a control step PrepControlSysError to cancel the process.

10. Save and activate your process.

11. Send three line items to your process using the Web Dynpro user interface and check your process instance by calling transaction SXMB_MONI_BPE. The workflow log should look as follows:

12. Send again three line items to your process. Make sure that you send spare part number “9999”, which causes an application error, at least once:

The process catches the application error and triggers the alert defined in the process:

You can check whether the application error has been thrown by the receiver ABAP proxy by calling transaction SXMB_MONI:

If your user is registered for the Alert Category PROCESS ALERT and your user in client 800 has an email address assigned to it, you can review the alert in the alert inbox. The

alert inbox can be found in the Runtime Workbench, available e.g. from the Integration Builder home page. The subsciption to alerts can be done in the alert inbox as well.

13. The instructor will cut the connection between the Integration Server and the business system Airline_Group_One by manipulating the corresponding SM59 RFC destination:

If you now run your process, the system error exception is triggered and the control step in the corresponding exception branch cancels the process. Check this in the Workflow log:

You can check whether a system error was thrown by calling transaction SXMBI_MONI:

Make sure, that the RFC-Destination is working again before you proceed.

14. Run the process with the spare part numbers 2000, 3000, and 4000. Since the materials 1000, 2000, 3000 are always marked as missing in the system, the preparation check will return a message with the spare part numbers 2000 and 3000. To check this, call transaction SXMB_MONI and select any messages where the sender service is your process:

In this request message you should see all spare part items transferred to the preparation check:

If you select the message in transaction SXMB_MONI – the receiver service is your process SellSpareParts_0## and the receiver interface is prep_sync_abstract - you can check the preparation response.

In the response you can see which materials will be created in the next exercise:

Exercise 3: Create Materials In this exercise, the materials determined in the last exercise are created. This is done by combining a block in ParallelForEach mode with a block in ForEach mode which loops over the list of receivers determined beforehand (broadcast pattern).

1. Collapse the Preparation block and add a CreateMaterials block:

2. Insert a switch step to check if materials need to be created:

3. Create a multiline element prepitemlist in the CreateMaterials container, which is based

on the abstract interface item_abstract.

4. Insert a transformation step MaterialTransformation into branch1 of the switch step. The transformation is based on the interface mapping list2itemlist, the source message preplist and the target message prepitemlist.

5. After the transformation step, insert a block named SendMaterialsParallel:

6. Create an new container element prepitem in the container SendMaterialsParallel:

7. Set the mode of the SendMaterialsParallel block to ParForEach. For the Multiline Element property, select the container element prepitemlist. For the Current Line property, select the container element prepitem:

8. Create a multiline element Receivers (category Receiver) for the SendMaterialsParallel container:

9. Insert a receiver determination step ReceiverDetermination into the SendMaterialsParallel block. Select prepitem for the Message property,and Receivers for the Receivers property:

10. Create a correlation CorrMaterials as shown in the following graphic:

11. Insert a new block SystemBroadcastPerMaterial after the receiver determination step:

12. Create a container element Receiver (category Receiver):

13. For the SystemBroadcastPerMaterial block, set the ForEach mode. For the Multiline Element property select Receivers, for the Current Line property select Receiver, and for the correlation select CorrMaterials.

14. In this block insert the send step SendMaterial:

You may check (or change) the XPath expressions that are assigned automatically under CorrMaterials, but you don’t have to.

15. Create the container element create_matresp in the SystemBroadcastPerMaterial container:

16. Insert a receive step ReceiveCreateMatResp:

17. Save and check your process:

If no errors are found, activate your process and start testing.

18. Send the spare part numbers 2000, 3000 and 4000 to the process. The resulting Workflow log should look as follows:

Two materials (2000 and 3000) have been created and broadcasted to two systems each.

19. Carry out further tests.

Exercise 4: Create Orders In this exercise, the sales and purchase orders are created in parallel. If one fails, both orders are canceled. As an extension of this exercise, the creation of the purchase order part is enhanced by a manual compensation in case the creation of the purchase order fails. The exercise uses application and transport acknowledgments of send messages. Moreover, send contexts are used for routing purposes.

1. Collapse the Create Materials block and add a CreateSalesAndPurchaseOrdersBlock block.

2. Insert a fork step createparallel with two necessary branches:

3. Create the correlation CorrOrder:

4. Create a send step SendPO. Enter PurchaseOrder for the Send Context property. This

is important because the routing depends on this send context.

5. In the process container, create a container element po_resp.

6. Insert a receive step ReceivePO:

7. Create a container element status_po (type xsd:string):

8. Insert a container operation getPOstatus:

9. Insert a send step SendSO into the other branch:

10. Create a container element so_resp:

11. Insert a receive step ReceiveSO:

12. Create a container element status_so (type xsd:string):

13. Create a container operation getSOStatus:

14. Create a block AutomaticCompensation (still inside the block CreateSalesAndPurchaseOrderBlock, but next to block createparallel):

15. In this block, insert a switch CancelOrders:

16. Insert a send step Cancel_PO into branch1. Enter CancelPO for the Send Context property.

17. Insert a send step Cancel_SO into branch1. Enter CancelSO as the send context:

18. Insert a control step AlertCancelOrders, which raises an alert:

19. Insert a control step OrdersCanceled, which cancels the process:

20. Save, check and activate your process

21. Test your process: If you use a customer name containing a “Y”, the response message correlated to the CreatePurchaseOrderMessage from Airline_Group_2 indicates that an error occurred (this is not an application error in XI):

The same is true for the SalesOrder if you use a customer name containing a “Z”:

Check if your process works. If you use customer names without “Y” and “Z”, your Workflow log should look as follows:

If you use customer names with “Y” and/or “Z”, your Workflow log should look as follows:

Check the alert inbox:

22. Check the graphical Workflow log:

23. Check the transport and application acknowledgments in transaction SXMB_MONI:

Extension

1. Add a switch step check after the container operation getPOstatus:

2. Insert a block ManualCompensation into branch1 and define the exception TimeOut:

3. Add a deadline branch to this block:

4. Add a control step NoInteraction to this deadline branch, which triggers the TimeOut exception:

5. Add an exception branch to this block, which handles the TimeOut exception:

6. In the Manual Compensation branch, insert a control step POErrorControl, which triggers an alert with the alert message PurchaseOrder could not be created, Run Report SPAREPARTS_MANUALCOMPENSATION in client 813 within the next 60 seconds to compensate manually.

7. Insert a receive step ReceivePOAgain after the last control step:

8. Insert a container operation setPOStatus:

9. Save, check and activate your process.

10. Test the manual compensation step: a. Log on to client 813 and prepare to run the

SPAREPARTS_MANUALCOMPENSATION report. b. Run your process with a customer containing a “Y”. c. In the graphical Workflow log, check that the process reaches the

ReceivePOAgain step. d. Run the SPAREPARTS_MANUALCOMPENSATION report in client 813. e. Check that the orders are not cancelled due to the manual compensation (run the

report, which sends a message to the ReceivePOAgain step).

Process waiting manual compensation

for

Process manuallycompensated

Process withoutmanual compensation

Exercise 5: Send Purchase Order to Supplier In this exercise, the purchase order is sent to the supplier. An order response is received and acknowledged.

1. Collapse the CreateSalesAndPurchaseOrdersBlock block and add a SupplierCommunication block:

2. Insert a send step SendPO2Supplier. Enter Supplier for the Send Context property:

3. Create a container element po_confirmation:

4. Insert a receive step ReceiveOrderConfirmation:

5. Insert a send step SendAcknowledgement:

6. Save, check and activate your process.

7. Test the overall process:

Example with supplier communication

TBIT44 - 2004-Q4 - A4 - Mapping, Adapters and BPM

Documents

Transcript of TBIT44 - 2004-Q4 - A4 - Mapping, Adapters and BPM