PI ABAP Proxies versus RFC Web Services

[Former Member]

Hi All,

I've been having an interesting conversation with one of my colleagues who works with PI. We've been talking about a standardised approach to eSOA from an SAP development perspective and got onto a bit of a sticky subject which I'm hoping someone can add some clarity to...

Basically, we're trying to understand where the PI ABAP Proxies fit into the eSOA world. That is to say, we can create a web service which wraps around a function group, function module, BAPI, etc... We cannot as far as we are aware create a web service that wraps directly around an ABAP object. PI ABAP Proxies appear to be ABAP objects published as a pseudo web service for the sole consumption of PI.

So, taking a long term view with the aim of service enabling a backend system function, if we wanted to create a sales order change service for example, I'd take the RFC function module and create a web service around it and publish it to the ESR. If PI wanted to change a sales order would they use the same web service? We are led to believe they should create an ABAP proxy to access the backend functionality. This effectively gives us two possible service points which I don't think is correct.

Any thoughts or suggestions will be most welcome.

Gareth.

[Former Member · Accepted solution]

Hi All,

It seems to be an interesting conversation.

My view to the proxies and Web services is that both are used for different requirements.

PI works with both Java and ABAP stack. So, when using RFC or SOAP adapter, all the calls are routed through Java stack. To overcome this proxy concept was introduced, so that PI's ABAP stack can directly communicate with SAP ERP to increase the performance and avoid the delays due to Java stsck.

Underlying technology(ABAP and XML) for both Proxy and Web Service are same but proxy concept can only be used with ERP and PI where as Web Services are system, platform and technology independent.Web Services is standard way which is accepted gloabally to communicate and best used for loosely coupled architecture.

Now, with ESOA prespective. You can design Your Enterprise Services using ESR. Generate a proxy in Java or ABAP( to implement the enterprise service). Implement the web Service and finally register in service repository. Now your Enterprise Sevice( technically Web Service) is ready to use. Pi can communicate with Web Service. No need to connect through Proxy and you can call this Web Service directly using any technology.

Hope I am able to clear some of the points

Regarding the above posts, I agree with the points which you guya are discussing.

But we cannot say that Web Services are used only where user intervention required. It depends on one's need.

Definetely ESOA is a vision to make user's business service oriented. Everything is available in the form of services.

But if we look at the performace, defineltely ABAP proxies are better than Web SErvices( if we are using PI in between). If we are consuming directly( without using PI), then only Web Service is the choice.

Regards,

Piyush

[Former Member]

Thanks for all the comments everyone.

[Former Member]

imho it just reflects the two concurring design paradigms

• inside-out

• using the webservice wizard on WAS ABAP expose an existing function module to be used from outside; the semantics of the interface is often times very SAP specific and ABAP style, that means, it is hard to understand for any 3rd party application

• outside-in

• on PI design a webservice based on business semantics free of SAP and ABAP specifics; automatically create an ABAP proxy on WAS ABAP and tell some poore programmer 'here is your proxy and here comes the data, now save it to the system by coding the proxy appropriately'

having a closer look at he whole issue you'll see that the methods and created artifacts are easily interchangeable and or mixable, e.g. take a function module, generate a webservice, use the WSDL as a starting point for outside in development, design the service, throw away the original service, create a proxy and rather quickly make the proxy use the original function module.

my 2 cents,

anton

Edited by: Anton Wenzelhuemer on Aug 1, 2008 9:43 AM

[Former Member]

>

> imho it just reflects the two concurring design paradigms
> 
> * inside-out
> ** using the webservice wizard on WAS ABAP expose an existing function module to be used from outside; the semantics of the interface is often times very SAP specific and ABAP style, that means, it is hard to understand for any 3rd party application
> * outside-in
> ** on PI design a webservice based on business semantics free of SAP and ABAP specifics; automatically create an ABAP proxy on WAS ABAP and tell some poore programmer 'here is your proxy and here comes the data, now save it to the system by coding the proxy appropriately'
> 
> having a closer look at he whole issue you'll see that the methods and created artifacts are easily interchangeable and or mixable, e.g. take a function module, generate a webservice, use the WSDL as a starting point for outside in development, design the service, throw away the original service, create a proxy and rather quickly make the proxy use the original function module.
> 
> my 2 cents,
> anton
> 
> Edited by: Anton Wenzelhuemer on Aug 1, 2008 9:43 AM

Hi Anton,

Thanks for this. I guess my outstanding issue is how we make the decision to either create a proxy from PI or create a web service in ECC - at the start of realisation it may be possible to say a particular service is only relevant to PI and hence a proxy is logical but then 6 months down the line it becomes apparent that the same service may be useful to a portal for instance.

One of our other frustrations is that the Proxy generator creates nice ABAP objects with a method, whilst we can't do the same going out of SAP - ie. we can't create a web service based on an existing class and method. Ok it is easy to encapsulate the object/method in a function module and then web service - it just seems a bit silly to have this extra layer, especially when it makes more sense to code purely in ABAP objects these days.

As you've suggested, I think it boils down to making the actual service level code re-usable in such a way that it can be encapsulated both in a Proxy and a Web Service as needed - if they can both use the same base level object then even better, as support and long term maintenance is improved and the logic is consistent. Taking a lot of the CRM functionality as an example, I think we end up with function groups and modules built which simply encapsulate the relevant classes and methods for a given operation. Logically, for future custom objects we would follow the same approach and add a call to the function either via a proxy or a web service.

Thanks,

Gareth.

[Former Member]

>

> One of our other frustrations is that the Proxy generator creates nice ABAP objects with a method, whilst we can't do the same going out of SAP - ie. we can't create a web service based on an existing class and method.  Ok it is easy to encapsulate the object/method in a function module and then web service - it just seems a bit silly to have this extra layer, especially when it makes more sense to code purely in ABAP objects these days.

Although you find it annoying this makes well sense from a purist view. The problem is that the granularity/organisational principles of your object oriented application parts are not necessarily the same as for business objects exposed as webservices. it is about semantics, system boundaries and stuff like that. imho, an ABAP object representing some business object is designed to work well and be understood within the application whereas a webservice offering some functions on the same business object is to be designed to work well and to be understood by the world . so, there is no 1:1 translation from class (object) to service and therefore it is a good idea not to suggest there were such a relation by allowing to create services from (any) class.

the other way it is possible to create an object oriented proxy because this results in a functional class not representing an application object but the service designed 'outside'. To embed this into your app you have to do all kinds of stuff to yield a semantic mediation from the general service to the concrete class.

my 2 cents,

anton

[Former Member]

Hi Gareth,

Following is my comment on your queries:

- we're trying to understand where the PI ABAP Proxies fit into the eSOA world

> PI ABAP proxies are also one of the building block of eSOA and specially useful in point to point communication where no user intervention required. proxies and webservices are not competing each other but complimenting each other. Proxies allow backend to process information which is received via interfaces from ABAP systems and very useful in case of point to point communication. They are similar to webservices in ABAP world.

- if we wanted to create a sales order change service for example, I'd take the RFC function module and create a web service around it and publish it to the ESR. If PI wanted to change a sales order would they use the same web service? We are led to believe they should create an ABAP proxy to access the backend functionality

> there is no need to create proxy if webservice is already available.

I hope I am able to clarify few points. More questions on this topics are welcome.

Regards,

Gourav Khare

[Former Member]

>

> > PI ABAP proxies are also one of the building block of eSOA and specially useful in point to point communication where no user intervention required. proxies and webservices are not competing each other but complimenting each other. Proxies allow backend to process information which is received via interfaces from ABAP systems and very useful in case of point to point communication. They are similar to webservices in ABAP world.
> 
> there is no need to create proxy if webservice is already available. 

Hi Gourav,

Thanks for your answers. So essentially the ABAP proxies will sit alongside any web services, specifically designed to handle interfaces which do not require manual input? So in the example of changing a sales order, if we developed an Enterprise Portal application for instance which needed to maintain sales orders we would create and publish the change web service. If there was a requirement to also change sales orders via a PI interface then we would use the same web service. If, on the other hand, there was no requirement to manually maintain sales orders via a UI but we still needed to update them via an interface then we would just create the PI proxy.

I guess the complication would be on a large project where a PI proxy is created early on in realisation and then later on down the road it is decided we need to develop a manual method of performing the same functionality. In this case, we would have a PI proxy already working but would need to create a web service to achieve the same functionality. In this case, should we stop using the proxy and shift all calls to the web service or should we have both used in parallel and run the risk of them becoming different in functionality?

Thanks,

Gareth.