This blog is regarding a synchronous scenario where we want to transfer bulk records from a database and push into SAP via a RFC and again get the response from SAP and update into the Database. But in SAP PI 7.1 we got an option to go with RFC Lookup to achieve this and to by-pass the BPM sync Async Bridge concept. But For Ex : we are having more number of DB inputs has to be given to the RFC as a request and getting back some Response and to update again into the Database. But speaking for large no of inputs, RFC lookup is not the feasible approach to get with, as these increases the Design complexity and huge time consuming process. So with the help of Request Response Beans,which can be configured in Module Tab of an sender JDBC Adapter will solves the problem to achieve a synchronous scenario without BPM and without RFC lookup.
But when I searched on SDN, I got a link but it’s for File to File with this RR Beans but that needs some additional explanation for other scenarios also, So in our case(DB TO DB), I had created a Receiver JDBC channel only for getting the value from Sender Adapter and post the response back into the DB. Hope this approach is a not a new one, but unexplained briefly in SDN, so I believe it will be useful for developers as a good synchronous approach in the JDBC TO RFC synchronous scenario, as I had implemented this approach successfully and went Live and satisfied lot of Business users .Also I had highlighted the issues which I had faced in my experience with this and included the remedies also for that.
Our scenario is as below :
Import the RFC into ur scenario and that has request and response parameters.
1) Create DT for source and target JDBC structure (DT_RRBEANS_S) & (DT_RRBEANS_T).
2) Create MT for source and target JDBC structure (MT_RRBEANS_S) & (MT_RRBEANS_T).
3) Create SI (SI_RRBEANS_S) for Sender O/B, Synchronous and import the above MT’s (request and response)
4) Create SI (SI_RRBEANS_T) for Receiver I/B, Synchronous and import the RFC request and response messages.
5) Create a OM ( OM _RRBEANS) and import the above Service Interface’s O/B and I/B in that and then We have to create Req and Response Mappings.
Request Mapping: (MM_RRBEANS_REQ)
The Source structure is Sender DB Structure and Target is RFC request fields.
Response Mapping: (MM_RRBEANS_RES)
The source structure is RFC response fields and Target is Receiver DB Structure.
Activate all ESR objects.
———————————-END OF ESR——————————————
1) Create a Configuration Scenario. CS_RRBEANS
2) Here I am creating a Business Service (BSER_RRBEANS) for Sender and using a Business system (BS_RRBEANS) for RFC RECEIVER.
3) Assign the Sender interface (SI_RRBEANS_S ) created above in the Business service.
4) Create a sender JDBC communication channel (CC_RRBEANS_JDBC_S).
5) Create the Receiver RFC communication channel (CC_RRBEANS_RFC_T)
6) Then Create Sender Agreement, Interface determination, Receiver Determination & Receiver Agreement.
Note: Here Sender channel represents the JDBC channel and Receiver channel represents the RFC Channel and not JDBC. But our scenario is JDBC to JDBC , so we are doing a JDBC to RFC interface ,then getting the response and posting into a Database with the help of another Receiver Virtual JDBC adapter configured with the help of REQUEST/RESPONSE BEANS in sender JDBC.
7) Now create a another Receiver JDBC communication channel (CC_RRBEANS_JDBC_T). and re-use the above Business service for this communication channel and assign the Receiver interface (SI_RRBEANS_T) in this Business service.
8) Request/Response Beans configurations in Sender JDBC channel :
Generally for any Sender JDBC adapter Module tab will be displayed as below screen shot.
Now in the Sender JDBC channel (CC_RRBEANS_JDBC_S), click on the Module Tab as below:
In the processing sequence “callSapAdapter” is the default Module name. So in additional to that we have to provide the two module names.
1) AF_Modules/RequestResponseBean Local Enterprise Bean 1
2) callSapAdapter Local Enterprise Bean 2
3) AF_Modules/ResponseOnewayBean Local Enterprise Bean 3 .
Note: Whatever module key used in the processing sequence should be given in the Module configuration. For convenience I had followed 1,2 and 3.
Also the adapter namespace is nothing but the SAP standard namespace which you can find in all communication channels.
But in the blogs explained already shown above doesn’t contains the adapterNamespace and adapterType as they are not mandatory, but PI throws a CPA cache error and some unidentified error if we miss out the above two parameters .So I got stuck here and unable to test this interface and after some time I came to know to include these two module names to overcome this issue. PFB Module config values for better understanding.
Here in our scenario :
Module Key Parameter Name Parameter Value
1 passThrough true
3 receiverChannel CC_RRBEANS_JDBC_T
3 receiverService BSER_RRBEANS
3 adapterNamespace http://sap.com/xi/XI/System( SAP Std Namespace)
3 adapterType JDBC (Based on scenario)
Note : So include all 5 Module names as specified with correct format as above, as all of them are case-sensitive. Even a single letter mistake leads to an error. In the parameter name, receiverChannel & receiverService are very important. Here I had taken the single Business service (BSER_RRBEANS) for both JDBC channels. Butwe can use different Services also.\
ID PART IS COMPLETED.
Now if we test the Interface and check in the sxmb_moni ,we will see two messages and in RWB we can able to see in the Audit Log as below.
From the above logs,we can able to see how our configured module parameters working in our interface and the significance of the Third Receiver JDBC channel which is getting the data and posting into the Database. Hope this approach will best suits for JDBC synchronous interfaces where more number of fields are involved in the sender.