We create a PI adapter module that calls a ABAP function module to process the messages payload. The function module must accept the message payload and encoding and return the resulting payload and an error text if an error ocurred.
The module uses the java resource architecture (JRA) to call the RFC runtime. This eases transport of the PI communication channel because no module parameters have to be changed in the different stages. Also credentials for RFC connection can be maintained using NWA.
Why do we need to call ABAP from the module processor?
At a customer site we are dealing with an Idoc to Idoc scenario where one system creates Idocs and dumps the textual representation of the Idoc into a flat file. Starting from PI 7.11 a module is available to convert Idoc flat files to Idoc xml, see . As no backport of this solution was available for PI 7.10 we decided to create an ABAP mapping to do the job as there are standard ABAP functions to do this kind of conversion.
Later we realized we need enhanced receiver determination for dynamically adressing different target systems. However enhanced receiver determination requires that the payload of the actual message is xml which was not the case for our Idoc scenario. So we created an adapter module to call a ABAP function module which in turn called the ABAP mapping. This way we got xml before we enter receiver determination.
It turns out that our module is quite generic. It uses the SAP Java Resource Adapter (SAP JRA) to call the RFC module. The parameters of the module are given but its name is configurable as module parameter. The host it runs on as well as the credentials are configured for the JRA connection factory in the Netweaver Administrator.
What is the advantage of JRA?
JRA does all the resource handling for you. This way you avoid common pitfalls like memory leaks due to resources that are not freed correctly. User and password for the RFC call can be maintained using the NWA and not as module parameter. Module parameters can be transported without change as long as the connection factory is maintained in all the landscapes using the same name.
How to use the module
|JNDINameOfJRAConnectionFactory||Name of the JRA connection factory configured e.g. deployedAdapters/CBFC_JRC_CF/nonGlobalTx/CBFC_JRC_CF|
|NameOfRfc||Name of the RFC function module that is to be called e.g. CBFC_FLAT_IDOC_2_XML|
|Encoding||The encoding will be passed one to one to the called ABAP function module e.g. 1100|
Example configuration might look like this
Parameters of the ABAP function module
The ABAP function module will have a defined signature. Apart from the message payload we decided to pass the encoding to do a conversion within the module if necessary. Also we added an export parameter for passing error information. The module will exit gracefully if it encounters non empty error message. The error text will be shown in the adapter log.
|SOURCE||Import||XSTRING||Bytestream of the message payload|
|ENCODING||Import||STRING||Either empty (binary) or encoding|
|RESULT||Export||XSTRING||Bytestream of the message payload|
|ERROR||Export||STRING||Error text. If error text != null Module will finish with exception|
A typical implementation might look like this (This is only a wrapper module that calls our former ABAP mapping. It does the encoding conversion and error handling)
How to setup the connection factory for use of JRA?
It is discribed in detail in . For our example it will look like
 How to Use User-Module for Conversion of IDoc Messages Between Flat and XML Formats, How to Use User-Module for Conversion of IDoc Messages Between Flat and XML Formats
 SAP Java Resource Adapter (SAP JRA), http://help.sap.com/saphelp_nwpi71/helpdata/EN/6f/1bd5caa85b11d6b28500508b5d5211/frameset.htm