We had run into some setup related issues with the JRA way of invoking RFCs from the adapter modules , explained in my earlier weblog and an OSS was raised for the same. We had to come up with an alternative way for the same, till we received the response. I wish to share the approach we followed with the community here and have experts comment on the same with their views..
Note: I do not intend to compare the approaches here.Also, quite a few URLs are mentioned in this blog which just point to the help pages because those bits and pieces of information are not new to the community and I simply intend to highlight the way we have used all that in the XI context, to suit our requirements.
The following setup is required for this approach.
1. Expose the RFC as a web service - Off course, I need not explain this, it is very precisely documented at many places. Still, those who wish to have a look at the steps, the following tutor files in the Web Service eLearning Catalog would be of great help.
ABAP Web Service Creation Wizard in Web AS 6.40
ABAP Web Service Virtual Interface in Web AS 6.40
ABAP Web Service Definition in Web AS 6.40
ABAP Web Service Configuration in Web AS 6.40
2. Download the WSDL for the above web service from using transaction wsadmin.
3. Generate a web service deployable proxy from this WSDL - Refer help for more details. Note that since the call to the proxy will be made from the adapter module, which itself is a J2EE application , we go for deployable proxy. Check here to know more about the differences between standalone and deployable web service proxies.
4. Before deploying the deployable proxy, make sure to edit the logical port and set the security Authentication type as Basic. Having set this, deploy the EAR for the proxy on J2EE stack of XI.
5. In Visual administrator, specify the credentials for accessing the web service, i.e. the credentials with which you would otherwise access the RFC, with type as Basic Authentication.This has to be done for every logical port in your deployable proxy. Refer Configuring Security on a Deployable Proxy section of help.
6. Create your adapter module in NetWeaver Developer studio, and set references to the web service deployable proxy using the web service perspective. Do not forget to add an application type reference to the web service deployable proxy application in application-j2ee-engine.xml of the adapter module. Also as a best practice, retrieve the reference of the web service deployable proxy inside the create method of the adapter module. You don't need to do that again and again, so not to be done in process method. Precise details here.
7. Deploy the adapter module and you are ready with the total setup with this approach.
The best part with this approach , "as I felt" was
- No hard coding of credentials in the client code or no tweaky design to store the same with the client code is required.
- Access the proxy like your plain Java objects, after you are through with the initial lookup. You do not need to write any thing specific which otherwise is typically required for web service clients. The proxy takes care of the web service communication.
- Along with the credentials, few other properties of the deployable proxy destination can be modified at the runtime. Switching the property selection for the destination from default to Custom in Visual Administrator can do the trick.
- Most of the code, except the RFC(in case it is custom) and the adapter module, is auto generated and is bound to be error free and performance optimized.
Note : If you are stuck up with the JNDI lookup name of the Web service proxy from the client bean code(adapter module in our case, refer help link in step 6), you can ask your Basis team for the JNDI tree dump of the J2EE stack of XI. Visual administrator has a feature to export the tree structure in a file and you can easily refer to the name by which the proxy is bound in JNDI registry, as the pattern is a bit different in case of DC based setup.
