Exercise 6 Business Process Management Collect master records Overview In this exercise we continue to focus on the Business Process

ss 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 Prepare interface objects. 1.1.1 in the Integration Repository, make sure that the objects from exercise 1 (File to IDoc) are present. 1.1.2 Copy Vendor_out to Vendor_out_collect. This will be the outbound interface used for vendor information in this exercise. 1.1.3 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. 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 onto your desktop 1.1.4.2 Edit the XSD definition and make the following change: <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 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. 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) 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.6

1.1.7

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

1.1.10 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 2.1 2.2 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 2.3.1 2.3.2 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:

2.3

2.3.3 -

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 dragand-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.) Receive step 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 (select your context object in the condition editor, for container CREMAS_single.)

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 Create a new communication channel File_sender_collect for business system XIWS_Legacy_BS_[XX]. 3.1.1 Copy communication channel File_sender to File_sender_collect. 3.1.2 Change the source directory to D:/workshop/group[XX]/collect Create a business process object CREMAS_collect_package (under Service without Party). In this step import the business process created in the repository. 3.2.1 Use the wizard and select your business process. 3.2.2 Note the signature of the process (interfaces are listed under the sender and receiver tab) We will create 2 receiver determinations: file sender BPM and BPM IDoc receiver. 3.3.1 file sender BPM 3.3.1.1 Create the receiver determination from file sender to BPM with the following sender information: Service: XIWS_legacy_BS_[XX] Outbound Interface: Vendor_out_collect (urn:xiworkshop:group[XX]:legacy) 3.3.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 3.3.1.3 Notice that no receiver agreement or communication channel in necessary when BPM is used as a receiver

3.2

3.3

3.3.2

BPM IDoc receiver Sender service: CREMAS_collect_package Outbound interface: CREMAS_package Receiver service: <select the Business System for the R/3 client> Inbound interface: CREMAS.CREMAS03 Interface mapping: none

3.4

Create a receiver agreement for the IDoc receiver. It should point to the existing communication channel XIWS_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. * Note: in the current version of XI3.0 SP1, there are bugs in this particular area of the user interface. The instructor will give precise instructions on how to perform these steps. In the Header Mapping section, check Sender Service. From the drop-down list, select the original sender XIWS_legacy_BS_[XX].

3.5 3.6

Create a sender agreement for service XIWS_legacy_BS_XX and interface Vendor_out_collect. Select communication channel File_sender_collect. Activate all objects

Step 4 Test For convenience reasons, we will first use the plain HTTP client in order to send three separate XML messages successively 4.1 From the plain HTTP client, send the first XML message as follows: - Sender Service: XIWS_legacy_BS_[XX] - Sender Interface: Vendor_out_collect - Interface Namespace: urn:xiworkshop:groupXX:legacy - QoS: EO 4.2 As payload, please cut and paste the contents of the file Vendor[XX].xml used in a previous exercise.

Examine your message in transaction SXMB_MONI. Notice that the message was sent to the process engine, and that the status of the workflow is in process. 4.2.1 Drill down to the workflow details

4.2.2 4.2.3 4.2.4 4.3 4.4 4.5 4.6

Display the workflow log Display the technical details of the workflow log Display the graphical details of the workflow log

Send a second and a third message (using the same zipcode). 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. Check in the R/3 system that 3 IDocs were posted. (optional) Re-test using the sender file adapter and your folder \\<hostname>\workshop\group[XX]\collect .

Appendix: naming conventions and terminology Exercise 5 Area SLD Obj. type TS BS Log.Sys. SWC NS Data type Msg.type Msg.int. Ext.def. Msg.map Int.map Abs.int. Abs.int. BPM Context BPM Cont. Cont. Cont. Cont. Correl. Corr.cont. Msg.map Int. map Int. Dir scenario service Send c.c. service Rec. c.c. RFC dest IDoc Log.Sys. folder Object name XIWS_legacy_TS_XX[00..30] XIWS_legacy_BS_XX[00.30] WSXX[00..30] XI RIG US workshop [00..30] urn:xiworkshop:groupXX[00..30]:legacy Vendor_DT Address_DT Vendor Vendor_out_collect CREMAS_package Vendor_CREMAS03 Vendor_out_CREMAS03_abstract CREMAS CREMAS_package CREMAS_collect_package zipcode counter CREMAS_single CREMAS_multi CREMAS_package zipcode zip CREMAS_multi__package CREMAS_multi__package xiworkshop_groupXX[00..30] XIWS_legacy_BS_XX[00..30] File_sender CREMAS_collect_package_[XX] XIWS_IDoc_receiver SM59 dest + ALE port CREMAS.CREMAS03 WSXX[00..30] \\hostname\workshop\groupXX[00..30] Description Technical system for legacy app Business system for legacy app Logical system name for BS Individual SWC for exercises Namespace for legacy objects Vendor data type Nested DT Vendor message type Copy of Vendor_out Modified XSD for IDoc packages Message mapping Interface mapping Single IDoc (BPM input) Package of IDocs (BPM output) BPM object Context object for zip code Counter for received IDocs Individual IDoc Multiline IDoc IDoc package Correlate by zipcode Points to /CREMAS03/IDOC/E1LFA1M/PSTLZ Map multiline to package Interface mapping Common for all exercises Derived from BS (no party) Sender comm. Channel for BS Business Process Receiver c.c. for R/3 system. Vendor master data Same as above D:\workshop\groupXX[00..30]

Int. Rep.

Int. Serv. R/3 File sys