SAP COMMUNITY NETWORK

Transcription

1 SAP Process Orchestration Makes System Technical Integration Transform into Business Integration (Including How SAP PI integrate with SAP BPM in SAP PO) Applies to: SAP Process Orchestration 7.31 and For more information, visit the SAP Process Orchestration SCN Homepage and latest SAP Process Orchestration Road Map. Summary SAP Process Orchestration (PO) combines the power of SAP Process Integration (PI), SAP Business Process Management (BPM) and SAP Business Rules Management (BRM) into one integrated offering. It provides tools to quickly automate and optimize business processes - from simple workflows to integrated processes that span applications, geographies, and organizational boundaries. Even in the future SAP Process Orchestration combine with SAP Operational Process Intelligence (OPInt) will enable intelligent business operations. So starting from SAP Process Orchestration, the new ONE Integration Solution came out. SAP Process Orchestration not only a composite system combine PI,BPM and BRM together, but also makes system technical integration transform into business integration from high level integration view. However it is not easy to understand this superior integration concept of SAP PO until you really implemented some complex integration scenario. In this article, I will present two scenario implementation with detail procedures as practice to let PI consultant adapt to PO consultant model and get the idea about how SAP PI integrate with SAP BPM in SAP PO from technical view. Note: The usage of the sub-brand "SAP NetWeaver" has been reevaluated and the SAP NetWeaver prefix will be dropped from most of the components. This will be publicly announced at SAPPHIRE NOW in June New names will be SAP Process Orchestration, SAP Process Integration, SAP Business Process Management, and SAP Business Rules Management. Author: Leon Li Company: SAP AGS, CHINA Created on: October 2014 Author Bio Leon Li is a SAP PI certified consultant and the member of the SAP NetWeaver Process Integration Team in SAP Active Global Support (AGS) CoE. Currently working on SAP Process Integration, SAP Process Orchestration and also SAP Manufacturing Integration and Intelligence (MII) areas as Integration Consultant SAP SE 1

2 Table of Content 1 Abstract Best Practice and Recommendation before Implementation Develop Environment Draw Business Requirement Flow (for scenario business requirement) Draw BPM Modeling Flow (for scenario using SAP PO) Draw Technical Message Flow (for scenario using SAP PI or SAP PO) iflow or ICO for PI integration scenario The sequence of implementation Practice 1: SOAP to File (simple scenario) Business Requirement Flow BPM Modeling Flow (if using PI integrate with BPM in PO model) Technical Message Flow (for scenario using SAP PI or SAP PO) SAP PI System Message Technical Integration SAP PO (PI integrate with BPM) System Message Technical Integration Service Interface with corresponding Message Type Used Operation Mapping with corresponding Message Mapping Used All Object in ESR Pure PI integration Scenario Model PI integrate with BPM in PO Model How to Send Testing Message to SAP BPM Practice 2: Get the price of the Subway tickets base on the numbers of stations (complex scenario) Business Requirement Description Business Requirement Flow BPM Modeling Flow (if using PI integrate with BPM in PO model) Technical Message Flow (for scenario using SAP PI or SAP PO) SAP PI System Message Technical Integration SAP PO (PI integrate with BPM) System Message Technical Integration Service Interface with corresponding Message Type Used Two JDBC Lookup Function Used Extended Receiver Determination/ Dynamic Routing and UDF used Pure PI integration Scenario Model PI integrate with BPM in PO Model Summery Reduce TCO due to an optimized architecture and simplified operations Become more efficient through process-driven integration Copyright SAP SE 2

3 1 Abstract SAP Process Orchestration (PO) combines the power of SAP Process Integration (PI), SAP Business Process Management (BPM) and SAP Business Rules Management (BRM) into one integrated offering. It provides tools to quickly automate and optimize business processes - from simple workflows to integrated processes that span applications, geographies, and organizational boundaries. Even in the future SAP Process Orchestration combine with SAP Operational Process Intelligence (OPInt) will enable intelligent business operations. So starting from SAP Process Orchestration, the new ONE Integration Solution came out. SAP Process Orchestration not only a system combine PI,BPM and BRM together, but also makes system technical integration transform into business integration from high level integration view. From below diagram you can clearly understand major milestones in SAP's IBO journey SAP SE 3

4 However it is not easy to understand this superior integration concept of SAP PO until you really implemented some complex integration scenario. In this article, I will present two scenario implementation with detail procedures as practice to let PI consultant adapt to PO consultant model and get idea about how SAP PI integrate with SAP BPM in SAP PO from technical view. Each scenario implemented by two different approaches. One is by pure PI integration scenario model, another one is by PI integrate with BPM in PO model. Practice 1 is quite simple, that is SOAP to File scenario. The purpose is to prove that every traditional PI integration scenario can also be implemented by PO (PI integrate with BPM) from pure technical view. Of course for simple scenario without business logic, it is no need to involve BPM. But for complex scenario, especially several different systems involved with specific business logic, using PO (PI integrate with BPM, PI handle technical system message processing and BPM handle business process management) significant advantages. So scenario 2 came out. Practice 2 is to simulate real life in Shanghai, China. The business logic of this scenario is to calculate the price of subway ticket base on the start station and end station, then send the price result to different price server (e.g. if the price of ticket is 4 RMB, then this price information send to SubwayAutoSystem_Price4) In this article, we call only using PI as pure PI integration scenario model; using PI integrate with BPM scenario as PI integrate with BPM in PO model SAP SE 4

5 2 Best Practice and Recommendation before Implementation 2.1 Develop Environment SAP NetWeaver Developer Studio as develop environment, it can be not only used to develop iflow for PI integration scenario but also used to develop process for BPM. It is necessary to keep Process Orchestration release equal to the NWDS release, or un-expectation may happened during deploy process into SAP Process Orchestration AS Java server. You can download different versions of NWDS via link: For example my environment is SAP Process Orchestration 7.40 SP07, so NWDS 7.31 SP12 should choose. (5 SP phases between 7.40 and 7.31) 2.2 Draw Business Requirement Flow (for scenario business requirement) If implemented by pure SAP PI, the scenario should be simple. However if SAP BPM involved, it is better to draw the business requirement flow to show what kinds of business data exchanged from what system. 2.3 Draw BPM Modeling Flow (for scenario using SAP PO) If implemented by SAP PO (PI and BPM), the scenario should be complex. It is better to draw the BPM Modeling draft flow base on the business requirement flow firstly. Then you can adjust it in NWDS. 2.4 Draw Technical Message Flow (for scenario using SAP PI or SAP PO) If implemented by SAP PO (PI and BPM), the scenario should be complex. With huge numbers of Service Interfaces involved with similar naming conversions may confuse you a lot. So it is better to draw the technical message flow with service interface and adapters. Then while you modeling BPM process in NWDS later, you can easy to find out which service interface will be used at each step. 2.5 iflow or ICO for PI integration scenario For PI scenario implementation, it is better to using iflow. Because it also can be implemented in NWDS and can show end to end flow diagram. However after you deploy iflow on SA PO, one ICO (Integration Configuration Object) will be generated automatically. So iflow and ICO are same basically, except you can see the end to end flow diagram in NWDS for ifow. In the document, I still using ICO to implement SAP PI integration scenario, but for naming I using iflow1, iflow2 to make description clear. 2.6 The sequence of implementation After we finished business requirement flow, BPM modeling flow and technical message flow, the whole scenario presented clearly. Then base on the service interface name and data type, we develop interfaces in ESR. After that, we should create iflow/ico for PI integration scenario, because from PI view, even you using BPM process, but this process have related PI message, and PI message have to come from one completed iflow/ico. So during PI integrate with BPM in PO model, we should treat BPM as business system/component just as normal system. While iflow/ico finished, we should assign send system and service interface in each steps in BPM process modeling. The most important thing is that: 1. For Start Event: It should assign BPM receiver/inbound interface (BPM received from PI) and using output mapping to assign PI message type/value into BPM local data object. 2. For Automated Activity: It should assign BPM send/outbound interface(bpm send to PI) and using input mapping to assign BPM local data object into PI message type/value to start the corresponding iflow/ico, also you can using output mapping to put this ifow/ico s receive message type/value into BPM local data object which may be used by next Automated Activity SAP SE 5

6 3 Practice 1: SOAP to File (simple scenario) 3.1 Business Requirement Flow SOAPUI system send Person message, then PI convert it into People message with very simple mapping for test purpose (filed to filed map and only add one more additional filed). To get this business requirement, it can be implemented by SAP PI or SAP PO (PI integrate with BPM). Of course if such scenario in real life, no need to using BPM, the purpose to using BPM here is to improve that normal PI scenario can transform/enhance into PI integrate with BPM in PO model and how to implement them. 3.2 BPM Modeling Flow (if using PI integrate with BPM in PO model) Two iflow/ ICO involved, 1 st iflow is from SOAPUI to BPM Start Event via PI, 2 nd iflow is from BPM Automated Activity to File via PI. MT_Person means Person message type in PI, Person means Local BPM Object Variant. The most important thing is that: IMPORTANT: In iflow, they are all PI message type (e.g. MT_Person/ MT_People) exchange via PI mapping. In BPM inside, Local BPM object variant (e.g. start event s Person/ Automated Activity s Person) exchange with PI message type via BPM mapping SAP SE 6

7 3.3 Technical Message Flow (for scenario using SAP PI or SAP PO) SAP PI System Message Technical Integration SAP PO (PI integrate with BPM) System Message Technical Integration 3.4 Service Interface with corresponding Message Type Used Please note that only 2 different date types involved. That are MT_Person and MT_People. To make them easy understand, for PI integrate with BPM in PO model, I add "UI" after original Person and People message type. MT_Person MT_Person Message Structure 1. Pure PI Scenario SI_Person_Async_Out SI_People_Async_In 2. PI integrate with BPM SI_PersonUI_Async_Out SI_PeopleUI_Async_In SI_PeopleUI_Async_Out SI_PeopleUI_Async_In 3.5 Operation Mapping with corresponding Message Mapping Used Only 2 Message Mapping involved. That are MM_Person2Person(MT_Person to MT_Person without change) and MM_Person2People(MT_Person to MT_People to add one additional filed) 2014 SAP SE 7

8 Operation Mapping Message Mappping 1.Pure PI integration Scenario None MM_Perso n2person 2.PI integrate with BPM Scenario OM_PersonUI2PersonU I 1.Pure PI integration Scenario OM_Person2People MM Pers on2people 2.PI integrate with BPM Scenario OM_PeopleUI2PeopleU I 3.6 All Object in ESR After all data type, message type, service interface, message mapping and operation mapping developed in the ESR SAP SE 8

9 Step Description Screenshot 3.7 Pure PI integration Scenario Model iflow in NWDS or ICO in Integration directory. Send Business Component - SOAPVirtual send Person h Message to PI via SOAP h Adapter, then PI convert it into jpeople Message to Receive Business Component - 1 SFSF Receiver via File Adapter Using WS Navigator to send testing message. Result SAP SE 9

10 Step Description Screenshot 3.8 PI integrate with BPM in PO Model Configure SOAP Adapter (based on XI) for BPM send channel and receive channel iflow 1: SOAPVirtual send PersonUI Message to PI via SOAP Adapter, then PI send it into BPM_PO7 without format change via SOAP/XI Adapter. SOAPUI->PI->BPM 2014 SAP SE 10

11 iflow2: BPM_PO7 send PersonUI Message to PI via SOAP/XI Adapter, then PI convert it into PeopleUI Message and received by SFSF Receiver via File Adapter Configuration Summary: Merge iflow1 and iflow2 into one CS 2014 SAP SE 11

12 3.8.5 Process in BPM: Go to NWDS to create Product and SC via Composite Explorer or create process standalone via Process Development Process in BPM: Then create Process with pool Process in BPM: 2014 SAP SE 12

13 Import the interfaces which will be involved Note: BPM outbound interface need Service Group/reference. Because it need maintain BPM as sender with XI Adapter. No need for inbound BPM interface. It can be deleted later or deploy may failed SAP SE 13

14 3.8.8 Process in BPM: Import MT_Person and MT_People into pool, and rename them to treat Person and People data objects as BPM Local objects SAP SE 14

15 3.8.9 Process in BPM: Create service reference for start. Combine Service Interface to Trigger. And using output mapping to map PI message type MT_Person into BPM Local data object Person. Process in BPM: Create service reference for Automated. Combine Service Interface to it. BPM send out interface. And using input mapping to map BPM Local data object Person into PI message type MT_Person. This Automated should be iflow2, then assign BPM sender with BPM sender interface in Service reference. That means trigger this Automated 's iflow SAP SE 15

16 Process in BPM: Connect to End Event, process modeling finished 2014 SAP SE 16

17 Deploy BPM: Note: Process can be created in Composite Designer with under product. However it may cause addtional SC generated. some exception may happend while deploy. So process also can be created in process development under software component SAP SE 17

18 Testing: Using WS Navigator 2014 SAP SE 18

19 Result 3.9 How to Send Testing Message to SAP BPM As SAP BPM can accept XI, WS and RFC protocol, using following two approaches can send testing message to SAP BPM. 1. Any kinds of type messages. Sender Send message to PI, then using corresponding send adapter (e.g. SOAP, IDoc, JDBC) convert into PI-XML, then using SOAP adapter base on XI protocol send to BPM. In such mode, you can treat PI as a huge adapter support several message protocol into XI protocol then connect with BPM. In our above practice1, 1 st iflow is used for this purpose. SOAPUI send Person message type, then 1 st iflow transport it to BPM still with Person message type SAP SE 19

20 Publish 1 st iflow 1, then using WS navigator or SOAPUI send testing message to BPM. The WSDL is you can import it into WS navigator or SOAPUI to test SAP SE 20

21 2. Only Web Service message. While you deploy the process into PO successfully, you will find the BPM send interface as web service in NWA SOA. The WSDL is You can import it directly click Test button then jump into WS navigator or import it into SOAPUI to test SAP SE 21

22 From the test sender interface, we can see that following difference between two approaches. 1: SOAP->PI->BPM starting testing from point 1 (SI_PersonUI_Async_Out) 2: WS->PI->BPM starting testing from point 2 (SI_PersonUI_Async_In) From above simple demo practice, you can understand that the pure PI scenario model can implement by PI and BPM in PO model. But you may still have a question: Why or When should we input BPM in the PI scenarios? Then let me show you following complex scenario with practice 2, then you will get an idea SAP SE 22

23 4 Practice 2: Get the price of the Subway tickets base on the numbers of stations (complex scenario) 4.1 Business Requirement Description This is the really life in Shanghai, China, 1~3 stations cost 3 RMB; 4~10 stations cost 4 RMB; 11~17 stations cost 5 RMB etc. This practice scenario simulate one subway auto-system to deal with tickets price. Just take Shanghai Subway Line-2 as a sample. Subway map is Chinese, let me translate it into following English name. Line2 marked in green line. Station Chinese Name 中 山 公 园 江 苏 路 静 安 寺 Station English Name Zhongshan Park Jiangsu Road Jingan Temple 2014 SAP SE 23

24 南 京 西 路 人 民 广 场 南 京 东 路 陆 家 嘴 东 昌 路 世 纪 大 道 上 海 科 技 馆 世 纪 公 园 龙 阳 路 张 江 高 科 金 科 路 广 兰 路 West Nanjing Road Peoples Square East Nanjing Road Lujiazui Donchang Road Century Avenue Shanghai Science Technology Museum Century Park Longyang Road Zhangjiang Hight Technology Park Jinke Road Guanglan Road For example, If you take subway from West Nanjing Road to Jinke Road, this trip contain 9 stations, so the price of the ticket should be 4 RMB. While SubwayAutoSystem get the price result, it will send the price information to different price system. (e.g. if price is 4 RMB, the price information will send to SubwayAutoSystem_Price4, if price is 5 RMB, the price information will send to SubwayAutoSystem_Price5) Base on the above logic, the input and output of this scenario should be following: Test Data 2 Start Station: Zhangjiang Hight Technology Park Start Station: Zhongshan Park User Input Result End Station: Century Avenue "Welcome to take Line2, Your ticket price is 4 RMB" And the output information will send to one file folder named 4 元 收 费 处 End Station: LongyangRoad "Welcome to take Line2, Your ticket price is 5 RMB" And the output information will send to one file folder named 5 元 收 费 处 4.2 Business Requirement Flow 3 rd party system (SOAPUI) send station message (start station and end station), then PI convert it into price message (the price of this trip base on the number of stations), then put final price information to corresponding price system. To get this business requirement, it can implement by SAP PI or SAP PO (PI integrate with BPM). 1. If using pure PI integration scenario, this scenario will use two JDBC Lookup in one message mapping to get the price result base on the number of stations, UDF mapping and Enhanced Receiver Determination to send different price to corresponding different price system. 2. If using PI integration BPM scenario, this scenario will use two JDBC Lookups in two iflow s message mapping. And no need to using UDF mapping and Enhanced Receiver Determination, BPM will handle the receiver routing base on the price condition maintained in BRM. The purpose of this complex scenario is to improve that why and when it should implement by PI integrate with BPM model SAP SE 24

25 4.3 BPM Modeling Flow (if using PI integrate with BPM in PO model) Six iflow/ ICO involved, 1 st iflow is from SOAPUI to BPM start event via PI, 2 nd iflow is from BPM Automated Activity to get the delta number of stations via PI JDBC Lookup, 3 rd iflow is from BPM Automated Activity to get the ticket price base on the delta number of stations via another PI JDBC Lookup. Then base on the price condition in BRM, the price information will send to different price system via 4 th,5 th and 6 th iflow. MT_Station means station message type in PI, Station means Local BPM Object Variant. So do delta Number and Price. The most important thing is that: IMPORTANT: In iflow, they are all PI message type (e.g. MT_Station/ MT_deltaNumber/MT_Price/MT_FinalPriceInfo) exchange via PI mapping. In BPM inside, Local BPM object variant (e.g. start event s Station/ Automated Activity s deltanumber,price,finalpriceinfo) exchange with PI message type via BPM mapping. The reason to using temp file server is that, this scenario is asynchronous. However using JDBC Lookup get the result receive message in iflow2 and iflow3. To complete one iflow or ICO we have to fill Receiver System during configuration. So we using a temp file server to store those temp information which we do not needed. In the real scenario, it can be replaced by JDBC receiver channel instead of JDBC Lookup in mapping or RFC receiver, then we do not need temp file server. Another tricky point is that, even you input File Temp Server in iflow or ICO, you can choose the option If cannot find receiver, ignore in receiver tab. Then the temp file message will not go to temp file server SAP SE 25

26 4.4 Technical Message Flow (for scenario using SAP PI or SAP PO) SAP PI System Message Technical Integration SAP PO (PI integrate with BPM) System Message Technical Integration 4.5 Service Interface with corresponding Message Type Used Please note that only 2 different date types involved in pure PI integration scenario model. That are MT_Station and MT_FinalPriceInfo. However for PI integration BPM scenario model, there are 2 additional intermediate message types involved. That are MT_DeltaNumber and MT_Price. MT_Station MT_DeltaNumber MT_Price MT_FinalPriceInfo 1. Pure PI Scenario SI_UserInput_Out None None SI_FinalPrice_Info 2014 SAP SE 26

27 2. PI integrate with BPM MT_Station MT_DeltaNumber MT_Price MT_FinalPriceInfo SI_UserInput_UI_Out SI_UserInput_UI_In SI_Input_UI_Out SI_DeltaNumber_In SI_Price_In SI_DeltaNumber_Out SI_Price_Out SI_FinalPriceInfo _In 4.6 Two JDBC Lookup Function Used There are 2 JDBC Lookup Function used. The first one is input station information (start station and end station), the result JDBC Lookup should be the number tag of stations. Then using subtract function to get delta numbers of stations between. The second one is input delta number of stations, the result JDBC Lookup should be corresponding price. Following 2 DB table used, the first one is store station name with corresponding Tag_Number, the second one is store station Tag_Delta with corresponding price. The mapping test result as following, input start station: Jingke Road and end station Longyang Road which contain 1 station. So the result is Price = 3 人 民 币 RMB with other constant statement information. 4.7 Extended Receiver Determination/ Dynamic Routing and UDF used The extended receiver determination or so-called Enhanced receiver determination used for deciding the receiver system during mapping. The receiver condition in Standard Receiver Determination tab in ICO can also send the message to the specifcal receiver. However the condition can only select from send/source message fileld (e.g. send message contain one fileld with loaction information) SAP SE 27

28 So if some logic should be performed on source message, then the result to be conditaion. In such model, the receiver condition cannot get the goal. Just in this practice, we have to calculate price from source station information, then using price as condition to dynamic routing receiver. Because we may have serval receiver more than 2, so no standard function in mapping can used. I develop following simple UDF. While input 3, the output will be SubwayAutoSystem_Price 3 which one receiver system name; if input 4, the output will be SubwayAutoSystem_Price 4 and so on. The final receiver determination mapping as following: The receiver determination mapping test as following: Input start station: Jinke Road, end station: Jinke Road. It contain no station, but should be treat as one station. The price is 3 RMB, so the receiver system should be SubwayAutoSystem_Price SAP SE 28

29 Step Description Screenshot 4.8 Pure PI integration Scenario Model Extended Receiver Determination Input receiver hdetermination operation hmapping j Input 3 receivers SAP SE 29

30 4.8.2 Input JDBC Lookup import parameter( JDBC Channel Name) Input 3 receivers Input real business message mapping Input 3 receiver channels Testing result 1: 金 科 路 to 世 纪 大 道 /4 人 民 币 / 票 据 信 息 放 置 到 4 元 收 2014 SAP SE 30

31 费 处 Jinke Road to Century Avenue, it contained 4 stations. So the price should be 4 RMB. And the final price result should be send to SubwayAutoSystem_Price4 Using Message Version, you can see the message before mapping and after mapping Testing result 2: 中 山 公 园 to 广 兰 路 /5 人 民 币 / 票 据 信 息 放 置 到 5 元 收 费 处 Zhongshan Park to Guanglan Road, it contained 13 stations. So the price should be 5RMB. And the final price result should be send to SubwayAutoSystem_Price SAP SE 31

32 Step Description Screenshot 4.9 PI integrate with BPM in PO Model Process Modeling in BPM Same steps as Practice 1. 5 Summery Practice 1 improve that traditional PI integration Scenario can be transfer/ enhance into PI integration BPM model in PO model. You can treat PI as a huge adapter support several message protocols into XI protocol connect with BPM. Practice 2 improve that in complex scenario especially several systems involved, even some business logic can implement by pure PI integration scenario, but it may put heavy load in PI which is design for system message exchange not business process management. So with PI integrate with BPM in PO model, it release the business logic out from PI into BPM which is design for business process management. At this moment, we can understand that with SAP Process Orchestration, it makes system technical integration transform into business integration from high level integration view. 5.1 Reduce TCO due to an optimized architecture and simplified operations 2014 SAP SE 32

33 5.2 Become more efficient through process-driven integration 2014 SAP SE 33

34 Copyright 2014 SAP SE SE or an SAP SE affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE and its affiliated companies ( SAP SE Group ) for informational purposes only, without representation or warranty of any kind, and SAP SE Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP SE and other SAP SE products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries. Please see for additional trademark information and notices SAP SE 34