Skip to Content

The Architect’s World – Episode 18


In this blog, I will be sharing my experiences with a customer for whom I had conducted an ESA workshop last week just before TechEd. The earlier part of the discussion started off with discussions around creating and consuming web services using the Java and the ABAP stack and consuming webservices from these stacks. This led to an overview session on enterprise services and how it all starts making sense with XI as the enterprise services repository. Then came the moot point with questions such as “Am I ready”, “Are we making the right moves” and “How do we go forward from here with ESA.” Some of the snippets from this workshop, I believe, may be found useful by ESA Architects who perform a similar role as mine. I wish that this workshop was conducted post the TechEd, as I could have had so many new thought points to discuss in the workshop…….maybe, I would do it differently if I were to do it again…

With what starts off with a storyboard about an Organization A and its business partners forming an e-chain or an extended collaborative enterprise, moving the same with the SAP NetWeaver platform and providing a way forward with ESA for Organization A, helps put on perspective the ESA story. The road ahead looks like this from one perspective, before we start taking out systems:


The Layered approach to ESA with the storyboard:

The Enterprise backbone Layer: This is the layer which comprises the existing applications in the landscape – the business and technical systems. Organizations tend to look like this – with a host of custom/legacy and third party applications connected by a mesh of wires to perform include SCM, CRM, e-business, reporting and other transaction processing systems. These applications are best place to start. Again, an ESA trip would border on the esoteric. Implemented on a common web application server platform, 6.40 or above in the future, this layer includes the applications that does the business transaction processing as well as hosts the applications that runs on it.

The Enterprise services Layer : The ESA repository which is the collection of all enterprise services. The Enterprise Services Repository which will be the next move post the local UDDI server and the SE80 objects before that, will be the the design-time repository for the Enterprise Services Repository which would include business objects, service interfaces, process models, business scenarios, process and mapping objects – that is the Integration builder in XI as the repository. Needless to say, XI will be the central hub for all enterprise services which would contain the WSDL file for these interfaces made available for reuse. See below screenshot from the ABAP stack for publishing your web services options:

The Integration builder in XI, which is slated to be the Enterprise Service for creating and editing service objects, models, and interfaces contained in the ESR along with a repository browser to explore as what services lie within. This makes XI 3.0 initiatives the key to an ESA roadmap.

These services can be explored in this layer to be choreographed into composites with Guided procedures as module specific components to externalize a part of their interfaces in the form of service descriptions via the WSDL Thus, the enterprise service components would provide service realization at runtime using the functionality provided by their interfaces.

The Business process Layer: The composite applications will reside in this layer as logical bundles of functionality or sub-processes which would render operations at the ERP or xApps level as singular applications. Some may also call this as the “new layer for customization” to support the business processes. Along with the CAF framework, the layer would utilize the Visual Composer (next release when it is on WAS) and Web dynpros now to support the UI modeling and underlying architecture for EP to be the front face. EP becomes a lot more important as the skin of the future and in conjunction with the business logic, this becomes the UI or presentation layer.

The Integration Layer: XI forms the integration layer and also acts as the ESR. On one hand, This makes XI non-comparable to other EAI tools owing to this tight coupling within the SAP NetWeaver platform, deployed in WAS (ABAP+Java), using the SLD for communication with the landscape and providing this underlying orchestration of B2B and A2A for composites, on the other, tying up closely with ARIS for modeling via the Solution Manager to go a level deeper with ccBPM. With the orchestration of all these singular pieces forming the core or mySAP Business Suite on WAS 6.40, there is a need to tie up all organization-wide initiatives on the SAP NetWeaver platform to move ahead with ESA initiatives.

Enter Web Services:

As we saw from our storyboard example, the heterogeneous nature of any system landscape makes it practically impossible for an enterprise to implement all the necessary functions of a business process using one single application or one technology. Web services simplify this process. They enable you to combine functions in a single process, even if they are implemented across multiple applications. Web services are self-contained, modularized, executable entities that can be published, searched or accessed across networks & they are identified by urls. At the highest level – web service is application-to-application communication over the internet built with a view to facilitate EAI or B2Bi.

Just think about the way you, as Org. A, would send a purchase order to a supplier manually using DHL. DHL is the carrier which, in our situation, is HTTP. The DHL Flyer is your SOAP envelope. The Purchase Order Document inside the flyer, which is the payload, is your XML document. The Airway bill that describes the details of the shipment is your SOAP header. Since you can use only a DHL flyer to use the DHL network, & not a DHL flyer to send a document via DHL, it’s a binding. It’s the same binding you provide a SOAP message for communication over HTTP. The Hub & spoke infrastructure of DHL is similar to the messaging system of XI3.0 or any EAI application. And the Purchase Order acknowledgement sent back from your Supplier by DHL is your SOAP Response just as the Purchase Order you sent over to him was the SOAP request.

And if you go to & do an online track & trace of the shipment based on your AWB, you can track the status of your PO. And this is an RPC that you execute in the DHL systems. So, from an enterprise standpoint, you can expose the key functionality of your applications, legacy or otherwise, via web services in such a way that you can cover entire processes chains to encompass multiple applications & make them execute sound business logic which have a huge potential of reducing coding cost by bringing in a level of abstraction to the code logic & adding intelligence to your coding efforts. In short, Web Services with Intelligence built into them form Org. A’s Service Oriented Architecture.

Org. A has an internal Order processing system that is written in VB, once could use a Microsoft driven IDE (Visual Studio .Net to build web services.). If you are Borland driven, continue with the same and possibly extend the same with the IDE plug-in of “Together” for UME in the NDS. Bottomline is to expose all self-contained, modularized functions implemented as Enterprise JavaBean (stateless session Beans) or Java classes as Web services using the java stack or the same route with the ABAP stack with RFCs or BAPIs or XI message interfaces.

Let us use our DHL & Purchase Order example once again, but in the context of understanding the key elements of a web service.

1. Virtual Interface: – If Org. A decides to send Purchase Orders to two Suppliers – Supplier A & Supplier B, but would not prefer Supplier B to shared with all information, So one can & will create multiple Virtual Interfaces from the same end point. And in a virtual Interface, you define what parameters go in, what attributes are fixed, what’s not & other such information.

2. Web Service Definition: – Assume that Supplier B will have to ship out different quantities from two different locations – one in the US & the other in Mexico. For the Mexico location, you want to ensure additional security for your web service. You decide to that the access to your Web Service from Mexico is over SSL only & the authentication level is strong & would an X.509 client certificate. So, you can and will create multiple Web Service Definitions for the same Virtual Interface.

3. Web Service & web service configuration: – If you were to take the above example further, you can define many web services for the same web service definition. And Web services Configuration defines the property of a web service at runtime, so if you want to have many configurations for the same web service, it is also possible. The configurations define stuff like what design time features will apply to the web service during runtime. So, you can have many configurations for the same web service. And the web service is merely a container for the web service configurations.

WSDL, as stated earlier, provides us with the specification to describe a web service. You will note that there are two types of WSDLs here – One is the standard WSDL & the other is the SAP WSDL. The standard WSDL is provided for those clients who will use tools from other vendors to create clients. For SAP users, you have the SAP WSDL which is an extended WSDL which can be parsed using SAP tools like the SAP Proxy generator thus providing additional information about the web service. And it’s the tModel key which provides the metadata for the same. I have yet to explore the ESA preview system.

The Conceptual Model:

The SOA (Service Oriented Architecture) provides the theoretical model for all web services. Its a simple model that contains three entities – Service Requestor, Service provider, Service Registry. The service requestor is an application that requests a service from another application, but doesnt know where to look for it, so it goes to the Service registry & does a “Find”. The Service Registry provides the application & does a “Publish” to the Service Provider, who in turn does the “Bind” & sends the service to the requestor.

A hypothetical web service begins its life as an RFC-enabled Function Module in our case. This is easy with the WAS6.40 wizard. Once you generate the WSDL & the virtual interface for the web service, publishing the same in a registry & releasing it for SOAP Runtime, you would now publish the WSDL to a registry of our choice – say IBM – which is a public registry, or microsoft or SAP – all sync up by EOD. Else, keep it internal to Org.

ESA Repository – how XI:

The WSDL is written to UDDI specification. A potential consumer of the web service ends up finding the same in the Microsoft registry as all the public registries are synced up per UDDI standards. Org. B/Org. C/Org. D will now download a copy of the WSDL & create a client application, say in Visual Basic, that will call the proxies generated from the WSDL to call the service. After the bind operation is successful, he passes some parameters & waits for things to happen.

What actually happens in the SOAP runtime environment – that is the ABAP engine or the J2ee engine – The client software packages his request into a SOAP envelope & sends it to the our URL using HTTP(S). The ICM is listening & it receives the message & strips off the HTTP headers. It passes the SOAP message to the SOAP Engine. The SOAP engine – the J2ee or the ABAP engine, removes the headers and processes any directives that might appear in the header. Now it will call the SOAP despatcher program. The despatcher will call the methods in the web service as we have described in our case, execute the RFC or BAPI, adds on any SOAP headers that are needed, & send the response over HTTP to the Client. The Client program will convert the data into his data type & display the results on his screen per Org. B/C/D’s aplication.

To consume a web service, you would need to create a deployable or a standalone client proxy for the web service using the WSDL file as the basis. This is what we should expect out of the ESA preview system, which would provide you with the WSDLs. You would need to download the WSDL onto your server/local machine and generate proxies out of the same as below:


Notice, it asks you if you want to generate proxies from the XI respository, ie the Integration builder. This tells you as to how XI will be ESA respository. Now, imagine the power of XI if your interfaces are to be your WSDLS (which is the case) and warrant the use of specific systems and ccBPM, all built-in and you take these adapters/interfaces and export these as WSDL. Now if you build an application using this WSDL with any front-face, wouldn’t it be just awesome? And are web services not complementing EAI instead of competing? With the XI-mySAPERP combination, it is the orchestration that matters, and that is exactly what the role of an ESA Architect demands.

The Proxy War:

The difference between a deployable and a standalone proxy is that – the web service client of the deployable proxy must be deployed on the J2ee engine. A standalone proxy can be deployed without a J2ee engine. Although both proxies have similar functions, there are some fundamental differences for you to decide which one to choose.

For a standalone proxy, a stub must be generated & the names & classnames of the transport bindings, protocols, & transports that are used must be provided. The big drawback here is – is ANY component is changed or modified, the stub can no longer be used & the whole proxy needs to be regenerated. On the other hand, with the deployable proxy, all information is either generated during deployment or is picked up during the runtime. So, the deployable proxies are protected from runtime changes to a certain extent. Once you have generated a proxy, you will now require a client application with bean or servlet that uses this proxy. With WAS 6.2 and above you can generate proxies for XI useage instead of using adapters. Word has it that perormance improves with proxies and it is best to avoid adapters. So, isnt proxies the way forward with XI? And if XI were to be your ESA respository, you could generate proxies from your enterprise services for your ccBPM?

The boundaries of Enterprise Services Architecture being the abstraction of business activities or events, modeled as enterprise services, from the actual functionality of enterprise applications to aggregating Web services into business-level enterprise services providing more meaningful building blocks for the task of automating enterprise-scale business scenarios. Enterprise services allow IT organizations to efficiently develop composite applications, defined as applications that compose functionality and information from existing systems to support new business processes or scenarios. All enterprise services communicate using Web services standards, can be described ina central repository, with this repository being XI. In a way, this becomes the classic differentiator for XI. Of course, you could skip the XI route and be happy with your UDDI server or external, as the case may be.

Enter Enterprise Services:

To move towards an Enterprise service Architecture, Org. A could consider based on these general steps:

Identification of the collaborative need, specification of the same with SAP NetWeaver and realization of services with mySAPERP (if you are on the same) or use workarounds with your existing landscape for your components and choreography of services.

Identification of the collaborative need: This process would need Org. A to look at taking a combination of a top-down, bottom-up, and cross-out of its key collaborative points that provide maximum pain today. This process decomposition and business-service modeling would enable Org. A to create and retain its focus around the identified ESA initiative and would get it the visibility that it requires. The top-down view would provide the business blueprint of business use cases, the bottom-up would provide the technical approach and the cross-out would provide the Solution Architect-approach to the same.


The top-down approach would provide the necessary decomposition of the business process into its impacting collaboration boundaries, functional areas and process-silos, with the flow of process at the highest level of abstraction going down a level deeper to expose the Enterprise service at an activity level. These use cases often are very good candidates for business services exposed at the edge of the enterprise, or for those used within the boundaries of the enterprise across lines of business.

So if you were pinning down the “Demand to Make” process and needed to nail down the process at an event level for web services, it would look something like this – just one step of Sales Order Scheduling. Now, Once you have identified your key process area for collaboration, you explode the process into granular details of sub-process and events. Once you have accomplished this, you know what enterprise and web service you need to accomplish your business cycle across your landcape.


In the bottom-up portion of the process or technical system analysis, existing systems would need to be analyzed and selected from a platform enablement perspective. Needless to say, this forms the core of your IT roadmap. The viable candidates for providing lower cost solutions to the implementation of underlying service functionality that supports the business process would now get attached to the overall objective of doing away with the systems you want out in the near future. In this process step, you will need to analyze and leverage the existing SAP objects or API’s of other systems, identify the transactions, and modules from the 3rd party/Best of Breed/legacy systems in your landscape

In the Cross-Out approach, the ESA Architect approach kicks-in with three key objectives, which I believe, is a must for the role. The specific areas that need to be covered are as below:

Bob’s gotta go:

Best-of-breed applications need to be taken out of the system. To align with the strategic roadmap that Org. A has, where SAP is sole platform, best of breed applications like Ariba Spend management Suite, BroadVision, LiveLink, SeeBeyond etc. would need to be shown the door. (I will take on case by case in my next few blogs to come as to how this can be achieved – starting with Sourcing and MRO procurement process)

Clean up the Attic:

Do the business consolidation within, the need to have legacy systems (political and technical) has to be analyzed and understood well. The approach taken on with the same could be to snuff these out in the long-run based on the steps an Architect helps decide today. (Consider a Sourcing engine or an Auction engine – Ill take this on in my next blog)

Clear out Charlotte’s Web:

Consider XI 3.0 as the ESA repository, not an EAI application. It is possible to bring about this paradigm shift to ensure that the EAI approach is taken away. (Ill take this on in one of my next blogs)

Outro: The Road ahead with ESA:

It is SAP’s agenda to push for an ESA roadmap. Organization A agrees to align with the same. But the way it can be done right can only be done right by a neutral third-party ESA/Solution Architect, who needs to remain at the grass-roots level to ensure that the correct processes and the right technology-combination used. The road to ESA definition cannot be an esoteric speel. Org. A realised the need for an ESA/Solution Architect to define the road ahead.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.