cancel
Showing results for 
Search instead for 
Did you mean: 

Develop a Real time Sync Consumer Web Service from SAP ECC

Former Member
0 Kudos

Hello Experts,

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,

Paul.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos


Hello,

So I would like to explore the option of Exposing Web service from PI instead of ECC. This seems to be

a solution where I could use monitoring capability if I am not wrong. Please let me know how to import my WSDL file in PI and directly consume it in my application. I do not want to use a Proxy since I am not sure if the Synchronous Proxy is a good solution from a queuing stand point. We should keep in mind I want to call the service from core Pricing module like Calculation routine. Performace is really the key here.

Please suggest.

Thanks & Regards,

Paul

JaySchwendemann
Active Contributor
0 Kudos

Honestly I don't fully understand your requirement yet. You say performance is key. This rule engine will be the sender, I suppose. And it will need real time data, right? So depending on your definition of real-time I would think that you will have to use a synchronous scenario because rule engine needs the price back from ECC.

--> So I don't see your need for async or queueing here. But maybe I'm missing the point

Then, when performance matters, you should really go for ICO or using PI AEX. The screenshot above mentioned Integration Server which is part of the "old" PI dual stack system. Crossing the stacks from java to ABAP and back significantly slows down performance.

--> What is your PI version? Have a look at single Stack PI (AEX) or at least integrated configuration to boost performance

Cheers

Former Member
0 Kudos

Wow, Thanks Jens. That was something I got confused with when I was going through the SAP Documentation.

Ok, Now that I can use ICO, can you let me know what all impacts / roadblocks we could have if we use a Synchronous Proxy at ECC and a Sync. SOAP call at the Rule engine. I am concerned with the 'Synchronous' way of exchanging messages on the ECC side using Proxy as I think, it could result in holding up the messages if 1 message is in 'Error' and has to be flushed out before other messages can be flow. We cannot let this happen in this scenario. Request you to please clarify what we have to watch out for in case of implementing a Sync. Proxy - Sync. SOAP scenario.

Thanks a Lot,

Paul.

JaySchwendemann
Active Contributor
0 Kudos

Hi Paul,

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).

Cheers

Jens

Former Member
0 Kudos

Thanks Jens.

That answers most of my questions.

The Scenario I was referrering to here is

SAP ECC <--> SAP PI <--> Rule Engine.

I think I can confortable use your inputs in creating thsi scenario. Thanks a lot for the inputs. Really appreciate it.

Thanks,

Paul.

Answers (2)

Answers (2)

baskar_gopalakrishnan2
Active Contributor
0 Kudos

Use PI as a broker instead of the option 1.  PI is a middleware tool and it helps for monitoring and debugging the web services much better.  One possible solution... Get Rule Engine wsdl and use it in both soap sender and soap receiver

Soap(sender) --> SOAP(Sync receiver)  Just one to one request mapping

Soap(receiver -response) --> Proxy (reciever response - ECC) response mapping

Former Member
0 Kudos


Hello Bhaskar,

Thanks for the response.

I have a few questions with regards to this build,

1. I will get 1 WSDL file from the Provider.

2. Should I create  a sync SI at ECC end which is a replica of the WSDL ?

Please clarify. How can I create a SOAP to SOAP when ECC is the Consumer ?

Thanks,

Paul.

JaySchwendemann
Active Contributor
0 Kudos

Following up on Former Member here:

I could think of the following:

Agree with the sender about the request and response message. That could very well already be developed and they provide you with a WSDL.

Use this WSDL to extract request and response XSDs (you don't need the operation / port part of the WSDL). PI can do that for you if you use external definitions.

Now things are getting a little vague as I did not do this before but I could imagine:

  • that you create inbound Interface on EEC side with same namespace as request / response messages from WSDL.
  • Assign those two messages (from external definition) to your service interace for Request and Response.
  • Create proxy on ECC side and fill in output structure as needed
  • no need for mapping in PI (I suppose)

HTH

Cheers Jens

baskar_gopalakrishnan2
Active Contributor
0 Kudos

Let me explain clearly.. I might want to use the following way.

You are trying to use async sync bridge without bpm

soap(async) -->  SOAP(sync ) -->  Soap adapter for proxy(async).   This is very similar to the case of file to RFC to File.

Here soap sender treated  as sender async  and  soap proxy as async receiver. 

You can configure soap adapter for proxy  using XI Protocol instead of choosing http protocol.  please search scn for configuring soap adpater for proxy. if your pi version is 7.11/7.3/7.31 you can do it.  In lower versions the above work flow is not possible.

Former Member
0 Kudos

Seems like you want the assurance of synchronous and the perfomance (non blocking nature) of async . Might I suggest you try an approach such as this one outlined by William