Develop a Real time Sync Consumer Web Service from SAP ECC
We have a requirement to build a Real time Syncronous Consumer Proxy in SAP ECC to be used in Order Capture in Real time. The Web Service will be provided by the Rule Engine.
The requirements are,
1. It should have very good performance. - Since this will be invoked for price calculations, real time at pricing procedure level
2. Good to have monitoring
3. Error handling mechanisms.
We are looking at the following options,
1. Direct Web Service from ECC.
2. RESTFul service
3. SAP PI as a broker (What options are available and its value)
The Rule Engine is expected to return the price at ~ 50 ms. So please let me know the best options that we can implement to cover the above requirements.
Thanks & Regards,
Jens Schwendemann replied
about your setup:
Who triggers communication (who ist the sender)? Which is the correct flow, 1 or 2? Please elaborate.
1. rule engine --> PI --> ECC?
2. ECC --> PI --> rule engine?
about chosing PI:
I cannot make statements whether PI would be your choice if performance is supreme you may consider your other options. Maybe some other SCN member may shed some light on how they behave performance like. You may, however lose some built-in PI features like monitoring / alerting / different mapping solutions and the like, if you go that way. Your milage may vary.
when PI is chosen, about ICO or AEX:
normally you already have a PI infrastructure, so you either have a PI dual stack or a PI single java stack installation. Which is it you have? Which version? If you're having an dual stack, ICO could be an option depending on version (available as of PI 7.1). If you have single java stack, everything is fine, already.
about Roadblocks / Impacts:
When quality of service "best effort" (synchronous) there is no blocking. That would be only the case when using QoS "exactyl once in order" (which is one of two async QoS, the other one being "exactly once"). If a message is erroneous, depending on your flow (see question in paragraph "about your setup") the sender will get the error and will have to deal with it. There's nothing PI could do about such erroneous messsages. That's ok, however. It's like when you surfing the web and reach a dead link. You (the sender) will get back an error message, that the side is not there and you can act accordingly (e.g. check if there were typos in the URL or just surf another page).