Interfacing to XI from Webdynpro

[Former Member]

I thought of sharing to the SDN community, details on the exercise i am currently involved in Wipro, as part of the Netweaver Competency Group. The objective of this exercise is to showcase the adapter and ccBPM capabilities of SAP XI3.0 using a business case. We decided to have a simple buyer/supplier cycle where in we had four role players, Org A(a brand manufacturer like Sony), Org B(a large retail organization like Circuit City/Best Buy), Org C(a pure manufacturing organization that takes in aggregated demand from ORGA) and Org D(an organization that caters to large manufacturers and accepts sub-contracting jobs).

I am not explaining in detail, the business case, because my intention here is to explain the solution approach proposed and to get that solution validated from the SDN comunity.The components from NetWeaver stack involved in this exercise are EP6(EP6 iViews will host webdynpro screens) and XI3.0(XI will serve as the facilitator/nerve centre). We came up with an approach where in we pool input data from Webdynpro pages(Quotation,Purchase Order, Sales Order screens). The pooled data from WebDynpros is then passed on to SAP XI 3.0 as XML documents. XI transforms the input XML data using transformation rules and then route them to the end systems(R/3 and SAP CRM 4.0 systems, in our case) based on predefined business rules(exploit ccBPM capabilities of SAP XI for content based routing, exception handling and alerting mechanisms).

The immediate challenge before us was to choose an interface to XI from Webdynpro.We came up with some options and then zeroed in on HTTP interfacing with XI, since most of our interfaces were synchronous and also we found the simplicity of using the HTTP interface more intriguing.Also we already had "JAXB parser" code snippets in place, so we could reuse it in this exercise.?

HTTP interfacing with XI

1. Role based access to WebdynPro screens(iViews on Ep6): We have four role players in our exercise. Org A(a brand manufacturer like Sony), Org B(a large retail organization like Circuit City/Best Buy), Org C(a pure manufacturing organization that takes in aggregated demand from ORGA) and Org D(cater to large manufacturers and accept sub-contracting jobs).
2. User input data from WebdynPro screens is passed on to XML parser(From the user input data, based on pre-defined XSD's, we build an XML document using JAXB parser).
3. The XML document is posted as HTTP payload to XI(HTTP sender adapter).
4. An intregration process(ccBPM) receives data from HTTP sender adapter
5. Based on the business rules defined in the integration process, the data is routed to RFC adapter endpoints
6. RFC adapter creates/updates business objects in R/3 and SAP CRM systems.
7. The response from end application system, in our case, SAP, is received in the integration process
8. The response collected in ccBPM integration process is sent back as HTTP payload(HTTPResponse object) back to Webdynpro
9. JAXB parser helper classes in Webdynpro help unmarshal the XML docuemnt
10. Build webdynpro response screen based on the data from XML document
11. The output of the process flow is shown in EP6 iViews.

The other options that occured during the high level design are below.

File Interfacing with XI:

Collect input data from webdynPros hosted in EP6 iViews -> transform input data to an XML document -> post XML document to an FTP server or write to a shared folder on the XI server as XML docuemtn -> collect XML data in XI using the FTP/File adapter -> use ccBPM(async-sync bridge mechanism)  -> create business objects in R/3 using RFC/IDOC adapters -> send response back to a webdynPro servlet listening on a particulatr URL via HTTP(HTTP receiver adapter) -> extract payload from HTTP in WebDynPro -> Unmarshal XML data in WebDynPro and display the response in the GUI.

JMS Interfacing with XI:

Collect input data from webdynPros hosted in EP6 iViews -> transform input data to an XML document -> pass XML data to helper classes that use JMS client libraries to post data to a JMS server(WebSphere MQ /Sonic MQ queue) -> collect data in XI using the JMS sender adapter -> use ccBPM(async-sync bridge mechanism, if required) for validation of business logic -> create business objects in R/3 using RFC/IDOC adapters -> send response back to a JMS queue using JMS receiver adapter -> helper classes in webdynpro listening on this queue will extract JMS payload and provide an XML to WebDynPro -> Unmarshal XML data in WebDynPro -> display the response in WebDynPro screens.

I am sure you will come back to me with a question. Why am i choosing a circuitous route routing data through XI, instead of using JCO from webdynpro and call the BAPI's and manipulate SAP Business Objects. Although there are no immediate advantages of using this approach, it does reveal the flexibility of interfacing to XI from outside world using universally accepted standards like HTTP/FTP/JMS.

I will write more about this as and when we make commendable progress in this exercise.