on 2016 Jun 13 10:15 PM
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:
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!
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:
Regards, Evgeniy.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
71 | |
10 | |
9 | |
7 | |
6 | |
6 | |
6 | |
5 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.