Skip to Content
Jun 13, 2016 at 09:15 PM

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


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!