SAP AG.co in Will Give information of SAP related meterials Like SAP Platform and Operation,,SAP Security , SAP Enterprise Portal (EP), ,SAP Knowledge Management (KW), SAP Business Intelligence (BI), Exchange Infrastructure (XI),Application Server, Mobile (MI), Master Data Management MDM, Composit Appications Frame work,Web Dynpros,OOPABAP,Blog,Intergration Bulder, Integration Repository (IB),Integration Directory (ID).System Landscape Directory (SLD), And Adopter Configuration like File to File,File to JDBC, File to IDoc, File Content Convertion, RFC, HTTP,SOAP,XI Interview Questions,Xi Sertification Questions, and many more about SAP Netweaver Platform XI Training And Tutorial and XI interview Questions ..

SAP Exchange Infrastructure Tutorials

SAP XI Exercises BPM collect pattern

Exercise 6 – 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

•  Prepare interface objects.

•  in the Integration Repository, make sure that the objects from exercise 1 (File to IDoc) are present.

•  Copy Vendor_out to Vendor_out_collect. This will be the outbound interface used for vendor information in this exercise.

•  Business Processes only work with abstract interfaces. Create an abstract, asynchronous interface called CREMAS (based on single IDoc CREMAS03). This will be the input to the process.

•  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:

•  Export the XSD definition of the IDoc onto your desktop

•  Edit the XSD definition and make the following change:

< xsd:element name =" IDOC " type =" CREMAS.CREMAS03 "

minOccurs =" 1 " maxOccurs =" unbounded " />

•  Create an external definition object called CREMAS_package. Import the modified XSD.

•  Create an asynchronous abstract interface CREMAS_package (based on the object CREMAS_package from the previous step). This will be the output of the business process.

•  Copy the Interface mapping Vendor_CREMAS03 to Vendor_out__CREMAS03_abstract. This will be the mapping applied between the sender and the BPM (before entry into the BPM).

•  Source interface: Vendor_out_collect (outbound, asynchronous)

•  Target interface: CREMAS (abstract, asynchronous)

•  Message mapping: unchanged

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

•  Create a new message mapping CREMAS_multi__package.

•  Source message: CREMAS.CREMAS03 (original IDoc)

•  Target message: CREMAS03 (from external definition object CREMAS_package)

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

•  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

•  In the target message, disable the node “EDI_DC40”.

•  Assign the constant “1” to the target attribute “BEGIN”.

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

•  Test your mapping with multiple source messages

•  Create an interface mapping CREMAS_multi__package.

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

•  Create a context object called zipcode (type String).

•  In your abstract interface CREMAS 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

•  Create a Business Process object “CREMAS_collect_package”

•  Create container variables:

•  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)

•  Create the correlation object

•  Switch to the correlation List

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

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

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

•  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”)

•  Step name: “Loop3”

•  Condition: “counter <> 3” (Use the condition editor to fill the condition property.)

•  Receive step – this step will receive incoming IDocs and correlate based on zipcode

(“receive single IDoc and correlate”)

•  Step name: “Receive CREMAS”

•  Message: “CREMAS_single”

•  Start process: yes

•  Use Correlations: “zipcode”

•  Activate Correlations: “zipcode”.

•  zipcode à zip: CREMAS_single.zipcode (select your context object in the condition editor, for container CREMAS_single.)

Next

 Back to SAP XI Tutorials