JDBC Receiver scenarios best practices part-1
One of my customers showcased me existing business process and he want to replace the same business process with SAP PI,the requirement is very simple like integrating SAP ECC and ORACLE data base system.
After analyzing the business process I came to know that to achieve my client requirement using SAP PI, I need to come up with innovative design standard because requirement demanded processing of 1.5 million JDBC messages per day and the operation on data base is JDBC insert.
Second challenge here is business process logic (mapping logic) and number of data base operations for every IDoc Eg: one contract IDoc needs to insert in 4 tables (Header, Line item, partner and DTN) but at minimum one contract IDocs is having nearly 54 messages (1 header, 6 line items, 42 partner records and 5 DTN records) and maximum 1400 messages.
Implementing mapping logic can be achieved using GUI functions, user defined functions and JAVA mapping. My Earlier projects involved very complex mapping logics so designed couple of standards to achieve current business process and it worked but only worry is will PI JDBC Adapters support processing of 1.5 million messages per day?
Do I need to recommend my customer to upgrade hard ware to support high volume?
Finally designed interface using multiple ways and compared the results but most of the design didn’t gave expected results eventually using one design we are able to process 1.5 +million messages without increasing hardware.
As part of this blog series I will cover JDBC receiver scenarios and will discuss different design approaches Pros and Cons.
This blog series covers below points,
1) 1) Comparing different JDBC receiver designs standard with Pros and Cons.
2) 2 )Processing high volume messages (Eg: 1.5 million message per day) using unique design.
3) 3) Implementing IDoc packaging in JDBC receiver scenarios and processing collected IDocs in one JDBC call.
4) 4) Maximum concurrency /Pool waiting time in JDBC receiver.
5) 5) Error handling in stored procedure design.