This is a project scenario I had a chance to be part of which I would like to share with the community.
Our customer wanted some of their products (scenarios) integrated to SAP R/3 using EP and SAP XI and wanted the content to be certified “Powered by Netweaver” (basically a PBNW Certification project). The project decision was to showcase their product offerings to customers/vendors with SAP in the landscape, the business was not really interested in buying a licensed R/3 System just for the certification purpose, but still wanted to get their Product certified as PBNW.
We worked with the customer to come up with a solution of providing access to the hosted R/3 System in the target environment for the certification purpose. Though we thought that this would actually solve our problems.... On the contrary it just triggered a whole list of technical glitches during the build.. For a start, the hosted R/3 System was not available for direct access from the Client's XI(Lets call it XI-1) . While we were brainstorming an alternative, one of the Vendor's to our client offered the use of their own XI System(Lets call it XI-2) to be the access point for their R/3 System.This was achieved by opening ports of XI-2 for access from the Client's environment over the web. This didn’t really address all our concerns as the Client was not interested in sharing his integration content (understandable, it’s proprietary you see) development with the Vendor. Rather they wanted all the business logic to be built out in XI-1. This meant that we had to integrate both the XI servers such that the XI-2 would be just a medium to communicate to the R/3 hosted in the Target environment.
Now I guess I have the puzzled look out of all your faces as to how we completed the project using “
TWO XI SYSTEMS
”.... Well here we go....
h4. SOLUTION
Prerequisites:
Target Environment(XI-2)
1. Two Business Systems are required to be configured of type “Web As ABAP” in the SLD, one referring to the XI-1 and the other referring to the R/3 System in the Target Environment.
Client's Environment(XI-1)
1. One Business System is required to be configured of type 3rd party in SLD referring to EP.
2. One Business System is required to be configured of type “Web As ABAP” in the SLD, referring to XI-2.
Note:
SLD configurations required is not covered in detail.Developments and Configurations in Target Environment(XI-2):
The imported RFC was used as both the source and the target Message Types for request and response Mappings. It involved a one to one mapping with all the unused fields being disabled in both the request and the response mappings as shown below. (The reason for the same is given in the “Conclusion” section at the end of the Article). There were no transformations or BPMs involved in XI-2 as all the customizations were done in the Clients Environment.
The two adapters required to be configured in the Target Environment(XI-2) for our interfaces are:
1. Sender SOAP Adapter
2. Receiver RFC Adapter
The configurations of these Adapters remain pretty straight forward which we will see below.
Sender SOAP Adapter</b>
Receiver RFC Adapter</b>
Exposing the above interface developed in the Target Environment(XI-2) as a web service
The interface developed in the Target Environment(XI-2) was exposed as a web service so that it could be imported for development with required customization in the in the Client’s Environment. To expose the interface developed as a web service we follow the steps below.
The Integration Scenario’s developed in XI is ready to be exposed as a web service. A web service Client Tool (Ex: Altova XMLSPY) can be used to test the scenario.
1. Use the web service wizard to generate a WSDL file for the Integration Scenario.
This WSDL file is used as the target structure in the Client's XI System(XI-1).
Override the default URL with following while generating WSDL using web service wizard.
http://host:port/XISOAPAdapter/MessageServlet?channel=:Note: The above URL is used as the target URL in the receiver SOAP Adapter in the Client's XI(XI-1).</b>
2. Follow the steps in the wizard and specify the respective Sender interface and Sender Namespace of the Integration scenario. Click on finish and save a local copy of web service document for the respective Message Interfaces.(
This wsdl generated represents the target structure in the Client’s XI System (XI-1)
Developments and Configurations in Client's Environment(XI-1):
The WSDL generated by XI-2 is imported as an external definition in the XI-1 representing the target Message Type. An xsd provided was used as the source Message Type. The unused fields were disabled in both the request and the response mappings as shown below. (The reason for the same is given in the “Conclusion” section at the end of the Article). All transformations and BPMs involved were developed here to meet the Business requirements.
Sample Mapping:</b>
Unlike the one to one mappings in XI-2, the mappings in the Client’s XI are performed with the required transformation rules.
Sample BPM Design:</b>
The below BPM is to show that a number of BAPI calls were to be made to achieve a simple Business functionality. The only purpose that the BPM serves here is to make a series of BAPI calls which could have been easily avoided if the creation of a custom RFC's or proxies were allowed in the R/3 system in the target environment.
The two adapters required to be configured in the Client’s Environment(XI-1) for our interfaces are:
1. Sender SOAP Adapter
2. Receiver SOAP Adapter
The configurations of these Adapters remain pretty straight forward except for a few things we need to take care of.
Sender SOAP Adapter</b>
Receiver SOAP Adapter</b>
Exposing the above interface developed in the Client's XI System(XI-1) as a web service
The interface developed in the Client’s Environment(XI-1) was exposed as a web service so that it could be consumed by the Source Application System or Enterprise Portal to trigger the interface and send the request to XI-1. To expose the interface developed as a web service we follow the steps below.
The Integration Scenario’s developed in XI is ready to be exposed as a web service. A web service Client Tool (Ex: Altova XMLSPY) can be used to test the scenario.
1. Use the web service wizard to generate a WSDL file for the Integration Scenario. This WSDL file is used by the Source Application System or Enterprise Portal to trigger the interface and send the request to XI-1.
Override the default URL with following while generating WSDL using web service wizard.
http://host:port/XISOAPAdapter/MessageServlet?channel=:
2. Follow the steps in the wizard and specify the respective Sender interface and Sender Namespace of the Integration scenario. Click on finish and save a local copy of web service document for the respective Message Interfaces.
3. Open a web service client application (Ex: ALTOVA XML SPY) and Create a new SOAP Request. Select one of the WSDL Files that has been generated using the web service wizard at a time.
4.When clicked on Send request to server,the prompt for login details is seen. Give XISUPER and Password.
Issues Faced:
The unused fields in the request and the response mappings in XI-1 and XI-2 as we saw in the screen shots are disabled as this was the solution that helped us get across the “PL_TIMEOUT” error that we got. We have a 1: N mapping. Each of these “N” messages triggered a BAPI call. When the number of BAPI calls being made increased, we started getting the “PL_TIMEOUT” error, which after a lot of research we avoided by disabling all the unnecessary fields.
To note the fact when the same scenario was tried in our COE Server, where our XI could directly talk to our R/3, the same payload that gave us problems where making the required BAPI calls without any errors.
Conclusion:
In any B2B Scenario like the above which may ideally have 2 middlewares (In our case both the middleware in both the environments were XI), the structure in the target environment(XI-2) which is nothing but a RFC or IDoc structure can be easily exposed as a web service to be triggered from an external environment over the web.
Inspite of all the struggles we went through we made our day when the XI content that we developed was certified by SAP as Powered by Netweaver.
5 Comments
