JDBC to ECC "sync" - Scenario Design & Best Practice

[former_member440449]

Hi Gurus,

I have a concern on an existing interface in our PI 7.31 single stack version: there's an interface that has some data on a local database and that data need to go to ECC. When the data reachs ECC then ECC must response with the status of the processed information.

This is the way the interface works today in production:

• The sender JDBC channel of the first interface uses a SELECT * sentence to get all the records with null or blank status and send them to ECC in an asynchronous interface. The UPDATE sentence puts an "R" character in the status field so we know that that record was read so it can't be read again.
• The receiver channel of the first interface sends all these information to an abap proxy so ECC can start processing all the data.
• Once ECC finish its work, triggers an outbound message with all the records sent in the previous async interface through an abap proxy (second interface)
• There's a receiver JDBC channel in this second interface ready for doing an UPDATE on the same table with the corresponding status flag ("E" for error and "P" for processed successful)

This interface was made before I join the PI group of the company.

There are a few discussions where some people here are not convinced on the way this works as they used to found many registries on "R" (read) status that were never updated.

I need to propose a new design on this, as 2 async interfaces doesn't sound good for me too in the way that was created.

Can anyone please suggest alternatives on the scenario design different than the existing one using PI? Any idea will be very appreciated.

Thanks in advanced!

[former_member190293 · Accepted solution]

Hi Claudio!

According to your scenario, you could use async-sync bridge.

Get records from DB (JDBC async) -> PI -> Call Proxy (Sync) -> Response from Proxy Call (convert to Async) -> PI -> Update statuses in DB (JDBC async).

Take a look at this blog about generic async-sync bridge:

http://scn.sap.com/community/pi-and-soa-middleware/blog/2014/01/28/generic-pi-async-sync-bridge-conf...

Regards, Evgeniy.

[former_member440449]

Thanks both for your answers.

Actually I was thinking in a different design and let them know other alternatives (the async - sync bridge may be useful).

I am wondering if I can suggest them to stop using DataBase interfaces so they can migrate to another alternative or use the same but not in the same way.

Any other ideas are welcome

[iaki_vila]

Hi Claudio,

I am wondering if I can suggest them to stop using DataBase interfaces so they can migrate to another alternative or use the same but not in the same way.

You can suggest that hey do the insert in the table with a PL/SQL and to call a webservice (in PI). In Oracle for example is easy to do. In this way you would only need one scenario (sync SOAP - Proxy ECC) and they could do an error handling if any communication issue would happen.

In your current idea you don't control if any issue happens in PI or ECC and there is not response to update the flag to P or E, You would have the flag R eternally. I think this would be a weird issue, because in an stable environment this will not happen. May be you should have a second scenario to control this issue, resetting the flag, with an early morning jdbc(async)-RFC or Proxy (sync) - jdbc (async). In the RFC or proxy part you could check if in ECC any message came and to update this system accordingly.

Regards.

[Former Member]

Hi Claudio

From your post, I understand there are some gaps with R status. But the new design depends on  business demand : Is it a real time call or batch process : As both has different performance effects and business decision is always made either to be real time or batch process on basis of some scenarios.

If its real time then Evgeniy new design is the perfect to have without hindering the SAP PI server performance.

Else if business demands to have batch process and only worried about discrepancies in status then we can define additional flag in table which will have some intermediate status to show sets of records which were last processed  but status was not updated at all to R. These records can rescheduled to be sent along new fresh records in second run.