Webdynpro for ABAP versus Enterprise Services

[Former Member]

Hi,

With ECC 6.0 the WebDynpro for ABAP will be available. After converting my well-known ABAP-dynpro screens to WebDynpro I will have the possibility to expose all R/3 functionality from within the portal.

Two years from now the Enterprise Services will be there. What will be the reason(s) for using enterprise services instead of WebDynpro for abap to make R/3 functionality available in the portal? I think at the end both functionalities can co-exist but what are the criteria to use one or both methods?

Greetings Theo

[Former Member]

David,

Thanks for your reply. With your reply in my mind I would give a customer the following roadmap for ESA-implementation:

1. Model your existing business processes included how they are implemented now.

3. From these pick out the processes that will not be changed in the near future (for instance 'hard-core' financial processes or HR-payroll-processes: mainly secundary processes). Keep these implementations as they are (probably including point-to-point interfaces)

4. Pick out the processes that will probably change in the future (mainly primary processes). Expose these processes gradually as services, even if they are completely implemented in SAP at this moment. When the time comes you can decide if the existing services are sufficient or need to be replaced by different services with different implementations.

5. Expose by default new processes as services.

Is this a reasonable roadmap/methodology?

Greetings Theo

[Former Member]

This is not a bad road map at all. But there is no one single good answer in IT. other considerations might be.

-1- users that need a light and easy instead of a complete GUI with a menu that contains many features they beter not know of (it's common that not all TCodes are fully customized)This is especialy the case for mobile users, etc.

-2- users that use many other applications and should be provided with a quick and easy SAP-applet. For instance customer service in the organisation I'm in at this moment only needs SAp to retrieve the actual "amount due". Every thing els is supported by other systems. For the time being this service need is supported by a RFC-call to SAP. Standard services whould have saved on the developing efforts.

-3- possibility to make a clear distinction between application logic that can reside with the user (purchasing variant that checks whether the total is not above 10.000 Euro, etc is user related, not strickly aplication related. It should also be maintained by his direct superior) SAP and the service desk could then be releaved of a lot of operational work that should reside in the business.

-4- And so on, you'll come up with more....

[Former Member]

There will always be processes that are covered by SAP alone in conjunction with processes that will be covered by multiple system. This is what I understand from ESA's methodology:

1. design the processes

2. invoke the appopriate services to support these processes. The implementation of the services is defined in the service itself.

Should I use this methodology for all processes, even if I know some of them will be entirely covered within SAP?

Greetings Theo

[Former Member]

Well, if SAP applications provide your end-users the required UIs and functions to perform some of your processes end-to-end, I don't see any reasons why you would create another layer unless the end-user totally refuses to use SAP screens or for some other reasons.

[Former Member]

Theo,

We should not implement ESA just for the sake of it. If your business process is entirely done in one single application system, why do you want build another layer on top of it.

Unless your business process cuts across multiple technical implementations it does not make any sense to build layers.

Regards,

Ravi

[Former Member]

Ravikumar,

Of course you should not introduce another layer when it's not neccesary. What I'm trying to figure out, is the methodology to use when some business processes are run in a single system in conjunction with business processes going over multiple systems (both types will will be used simultaniously in most organisations). I these cases I would prefer using one overall methodology i.e. ESA. Do I make a point or is this something I should discuss at he bar -:)?

[david_sonnenschein]

Theo,

This is not a discussion relegated to the bar...

First the short methodology is correct... Id the processes, expose major entry points as Services, orchestrate, publish Service Desc, endpoints, etc., repeat...

The real question remaining is, if I believe my entire process is incorporated with a single SAP system why would I expose Services (and add the additional layer)?

I agree with the comment where if a process completely executes in a single environment there is no need to change its strategy and force it to be an orchestrated set of Service interactions. That is not inconsistent with providing Service interfaces along the process so that it can be composed into other processes either not yet in place or requiring cross-system interaction. ESA is not saying "break open the container and make every little piece operate as Enterprise Services", instead it guides us to Service enable components so that others can consume them in a standard way, regardless of implementation / execution environment.

As we think about leveraging ESA for the benefit of our businesses (our enterprise and the ecosystem of business partners and customers) we have to acknowledge that we do not and will not know where every step of a busines process will execute throughout time. There may be tremendous value in executing part of a process that could be performed in that same SAP system in a completely different environment. The main benefit of Service enabling is business agility for a reasonable cost. I would argue that at least the main entry and exit points to major processes should have Service interfaces, followed by a more comprehensive assessment of internal process steps - looking for opportunities.

The other side of the equation is determining what additional consumers of the process could be found if major parts of the process exposed Service interfaces. To say, "my process executes inside this one system, so I should not expose it as a set of Services", ignores the potential benefit of other systems being able to incorporate that process in their execution (or parts of a process). As we expose more, well defined Services that represent aspects of enterprise business processes we create an environment where there is low cost, opportunistic integration based on standards.

Or put more briefly, make sure to execute your business process in an efficent computing manner, but do not let that constraint limit your thinking when it comes to Services. They are two different (yet related) issues. Services simply give us another way to leverage an asset we already have. Make the asset available and if it has value to the organization, it will be consumed.

Hope that helps...

David

[Former Member]

Andre,

Thanks for you quick reply. The criteria you mentioned have to do with money, time etc. For a lot of customers the transition from C/S to SOA (ESA) will have a lot to do with your criteria.

So the roadmap could be as follows:

1. Make R/3 accessible by the portal using f.i webdynpro for Abap

2. Then for agility's sake the CAF should be introduced from where Enterprise/Composite Services can be selected/created and from where orchestrations can be developed.

Does this little roadmap makes sense?

Greetings Theo

[Former Member]

Regarding your first post, You are right if you are talking about SAP system alone. However when we talk about ESA, we usually consider multiple systems that come into play for a single business process. So, we need to take a look at this from a business stand point and not from a specific application stand point.

Regarding your second post, Making R/3 accessible using ABAP Dynpros - You need to look what is that you want to build using this. Most of the standard transactions - SAP gives the dynpro's anyway. So, if we are talking about custom functionality being built using ABAP Dynpros that should be fine. However, we need to make sure this dynpro's can interact with other services exposed by non-SAP systems as well.

If NOT, where is the ESA coming into play?

Regards,

Ravi

[Former Member]

Absolutely correct. co-existence will be the reality fro years to come. Fundamentally or conceptually, you would want to design applications that are flexible and agile to be able to address ever changing business process requirements. Therefore you would want to go the Enterprise Services and Composite Applications road. Now from a pragmatical standpoint, dealing with each individual situation and reality (skillset, timeline, budget...), taping into R3 directly might be the way to go in a lot of cases.