cancel
Showing results for 
Search instead for 
Did you mean: 

More about ESA

Former Member
0 Kudos

I cannot understand if there is any difference between a BAPI that anybody can invoke through RFC/SOAP and a Enterprise Service.

There will be any loss of funtionality decoupling service and transaction in the traditional SAP GUI transaction? For example the data validation will be carried on in the service, therefore the chain/endchain for the data validation in the PAI couldn't be applied, and this could cause a loss of functionality.

Regards

Fabio Cerioni

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

ESA is something that not many fully realize the possibilities of. I certainly do not, but I'm trying, and I've bought into it.

First and foremost is the definition of an Enterprise Service. Most want to force an Enterprise Service to be a Web Service. I'm not convinced. Technically, an RFC, a Java Bean, a .Net component, these are all 'services', they perform a function and are callable by multiple applications. All can be exposed to the enterprise.

However, ESA is not just componentization. ESA is about the ability to extend applications and extend services with new functionality. ESA is about me being able to take your Java application and write a new front end in .Net for a new (internal) customer and not care that you used Java (and whether or not you're using RFCs behind that Java).

If you use a web service to expose SAP functionality, you're making it possible to purchase a new system, pull the old web service out, and put the new one in, and your applications that depend on the service are unaware. (The example of replacing SAP functionality is just an example, more realistically, as SAP core functionality expands, you may be looking to replace non SAP systems with new SAP functionality).

In a dream world, where you have enterprise services connected using an enterprise service security model (security for web services is often overlooked, because of the difficulty of it I believe), then your systems are independant of each other, your technologies can play nice together. They can all be removed and new technologies put in place without having to re-do your entire environment. The idea is to be reactive to changes in the business (recalling Shai's presentation on how IT is too slow to react to changes in the business).

I'm sorry to have strayed a lot, but I believe difference you are asking for depends heavily on the value proposition of the ESA.

Certainly there is a loss of fuctionality, and efficiency! Web Services are, in a sense, the common denominator as an API. We're taking the relatively archiac web technology and pushing its limits because of its openness.

These are challenges the ESA will continue to face. But it promises that the benefits gained from implementing it are far greater than the costs. We'll see. But I'm willing to bet the problems that we face with ESA will continue to be addressed, hopefully in non proprietary ways.

The question that we all face is how far do we push it? When is it right to make something into an open enterprise service and when do I use more efficient and functional APIs into a system? This is not an easy question to answer. It depends highly on each situation and environment. One problem arises from the fact that you cannot often foresee when you will gain value from creating an enterprise service.

Ah well, I apologize for such a long-winded response, it stems from being in a similar position... how far do I take this thing?... and not being sure, so I think about it a lot.