www.SAPAG.CO.IN | |||||||||||||||||||||||||||
COMPLETE SAP NETWEAVER TUTORIALSSITE | |||||||||||||||||||||||||||
|
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 async-sync Exercise 5 – Business Process Management – Async/Sync bridge Overview In this exercise we introduce the Business Process Management capabilities of XI 3.0. We will implement a stateless BPM pattern called an “asynchronous to synchronous bridge”. This is a common requirement from customers. It also addresses a former gap of XI 2.0. As a result of this exercise, you will become familiar with the business process engine and its monitoring features. You will have a better idea of how BPM allows you to mix asynchronous and synchronous messages. You will also be aware of the limitations in this area. Finally you will be able to revisit one of the previous scenarios with the inherent challenges of tRFC communication, and improve the message flow and error handling. This exercise will also introduce the usage of the receiver file adapter. <architecture diagram> <sequence diagram> Prerequisites Good knowledge of basic XI features. Good knowledge of RFC/tRFC concepts Basic knowledge of BPM architecture and concepts Description In the advanced variant of exercise 3, we issued an asynchronous HTTP call to XI, which in turn posted a BAPI call asynchronously, via tRFC. The main advantage is that the calling application does not have to wait for the synchronous response. Instead we rely on the quality of service offered by XI and tRFC technology. Overall this is a more efficient use of system resources, in both application systems and in the Integration Server. However, this does not come without challenges. Asynchronous BAPI calls do not provide a response, and tRFC is arguably difficult, if not impossible to monitor at the application level. Basically the only way to make sure that the BAPI call was successful is to check with transaction ME23 that the purchase order was actually posted. In order to improve the situation, one approach is to combine asynchronous and synchronous messages. From the calling side, the HTTP request arrives as an asynchronous document into XI. As a result, it is persisted immediately in XI and the calling application can move on. On the receiving end we would like to call the BAPI synchronously because the PO number will be immediately returned. This is referred to as an asynchronous-synchronous bridge, which is now possible with XI 3.0 and BPM. Then we would like to send this response, containing the PO number, asynchronously to an external legacy system. Finally, we will implement some error handling, such that if the BAPI call fails, an alert will be generated. The WebAS alert framework will be used for this purpose. Exercise steps We will first implement the basic asynchronous-synchronous bridge, then we will revisit the business process and build the error handling. Step 1 – Repository There are many objects to prepare in the Integration Repository, before we can build the BPM. Copy the interface PurchaseOrder_out_async to PurchaseOrder_out_async_BPM. This will be the outbound asynchronous interface used by the HTTP client to send the initial message. Copy the interface PurchaseOrder_out_async_BPM to abstract interface PurchaseOrder_async_abstract. This will be the input to the BPM. Copy the interface PurchaseOrder_out to abstract interface PurchaseOrder_sync_abstract. This will be the output of the BPM, representing the synchronous call. In this exercise, the mapping will be applied between the BPM and R/3. Copy the interface mapping PO_out__ZBAPI_PO_CREATE to PO_abs__ZBAPI_PO_CREATE: Source interface: PurchaseOrder_sync_abstract Target interface: ZBAPI_PO_CREATE (unchanged) Request mapping: POReq__ZBAPI_PO_CREATE_req (unchanged) Response mapping: ZBAPI_PO_CREATE_resp__POResp (unchanged) Create the abstract interface PurchaseOrderResp_async_abstract. This represents the output of the BPM containing the asynchronous PO response. abstract, asynchronous message type PurchaseOrderResponse Create the inbound interface PurchaseOrderResp_in_async. This will contain the final asynchronous response message to be accepted by the legacy application. inbound, asynchronous message type PurchaseOrderResponse Step 2 – BPM 2.1 Create a Business Process object: PO_async_sync Create the following containers: PO_req: abstract interface, type PurchaseOrder_async_abstract PO_resp: abstract interface, type PurchaseOrderResp_async_abstract Since the BPM is stateless, there is no correlation. Compose the business process flow by adding the following steps using drag-and-drop. For each step, complete the properties as specified below: Receive step – receive the asynchronous request and trigger the process Step Name: “Async PO request” Message: PO_req Start Process: yes Activate Correlations: none Send step – send the request asynchronously and receive a response. Note that, although the container objects refer to asynchronous abstract interfaces, they can be used as request and response message for the synchronous step (as long as the message types are identical). Step Name: “Sync PO request” Mode: Synchronous Synchronous Interface: PurchaseOrder_sync_abstract Request message: PO_req Response message: PO_resp Receiver from: Send Context Send step – send the response out asynchronously Step Name: “send response” Mode: Asynchronous Message: PO_resp Acknowledgement: none Receiver from: send context The completed business process flow should look like this: Check the business process (F7). Save and activate all objects. Step 3 – Directory We will have to create 3 different receiver determinations: HTTP client à BPM (async) BPM à R/3 (sync) BPM à Legacy (async) Install the BPM object as a service Create new service of type “business process”: XIWS_PO_async_sync_[XX] Assign your BPM object from the Repository: “PO_async_sync”. Notice the signature of the process under the tabs ‘sender' and ‘receiver'. Copy the existing receiver determination from exercise 3 (asynchronous): XIWS_web_purchasing_XX | PurchaseOrder_out_async. For the new object select the following: Sender service: XIWS_web_purchasing_XX (unchanged) Sender interface: PurchaseOrder_out_async_BPM Sender Namespace: urn:xiworkshop:groupXX:webapp Add to scenario: xiworkshop_group[XX] Change the receiver service to your BPM: ‘XIWS_PO_async_sync_[XX]' Select the inbound interface PurchaseOrder_async_abstract, no mapping. Notice that for BPM no receiver agreement or communication channel is necessary Create a new receiver determination from BPM to R/3: Sender service: XIWS_PO_async_sync_XX Sender interface: PurchaseOrder_sync_abstract Sender namespace: urn:xiworkshop:groupXX:webapp Receiver service: <select the business system for the R/3 client> Inbound interface: ZBAPI_PO_CREATE
|
|
|||||||||||||||||||||||||