An in depth Look at enterprise SOA

Before logging in to the ESR and creating a service, let me explain the major building blocks of the Business Process Platform. After so many presentations during TechEd and other events this may be the last thing you want read, but I must consider readers that would like to understand these building blocks. Let me give you an architectural point of view and share some technical insights

Here is a recent image of the Business Process Platform

In SAP a Service Oriented Architecture is really a blueprint within which we focus on select business critical SOA principles and therefore Enterprise SOA. Examples of business critical principles include semantics, governance, and enterprise content

A Business Process Platform is the execution of such a blueprint or Enterprise SOA. In short, the BPP is the SAP NetWeaver Technology Platform plus Process Components. By SAP NetWeaver Technology Platform I mean all the integration capabilities, foundation, ESR, Registry, and Services. By Process Component, I mean all work done on ERP, PLM, SCM, SRM, and CRM to expose business functionality as services: a stable platform with five major components

Process Components

Those that have been in the SAP world for quite sometime will know that Process Components is a new term. Actually it is a very important term to understand. Let me give you a bit of background

During Sapphire 2005 it was officially announced that SAP would turn all of its back-end functionality into “enterprise services”. Process Components takes place behind the scenes before you ever use the famous “enterprise services”

I am sure you are familiar with the 1000+ enterprise services in the ESWorkplace, if not, I am sure you heard about them. Well, where do they come from, and how are they created? This is where Process Components play a role. For over two years a group of engineers and architects go through a major undertaking to identify “modular, independent, and reusable pieces of business functionality” from ERP, PLM, SRM, CRM, SCM. They are called “components” because they are small pieces of business functionality derived from SD, FI, LO, MM, etc

Once Process Components are identified they are eventually exposed to the outside world as “enterprise services”. An obvious question emerges, “If enterprise services are really the building blocks to create composites, why should I care about understanding what Process Components are? The answer to that question goes to the core of SOA. The process of turning backend functionality and exposing it as metadata (enterprise services), or service enablement, is certainly well received. However, a company that truly embraces SOA will have to address legacy software and other platforms where business functionality resides. Here is where Process Components play a key role. Companies trying to service enable non-SAP functionality will want to understand how SAP has accomplished the task. What criteria and tools did SAP follow to identify such Process Components? Companies will want to understand what modeling principles were used to guarantee reusability. Some companies may want to architect the interaction of SAP Process Components with their own, before creating any service. Creating a blueprint before jumping to service creation is the right approach, thus understanding Process Components is one of the first doors an Enterprise Service Architect will have to open upon executing SOA

Before services are implemented Process Components follow a strict provisioning and definition process. SAP calls such a process PIC. The SAP Modeling Methodology ensures that services follow namespace conventions, reusability and industry semantics such us Global Data Types. If you would like a better understanding of modeling principles used by SAP please refer to some of the TechED sessions. More workshops will be provided in the near future on this topic

Enterprise Service Definitions

Here there are three important topics to understand.

Enterprise Services

Structure

• Every enterprise service has two parts: (1) modeling and (2) definition. You can consider the service modeling to be the blueprint where process components are architected with business objects, service interfaces, operations, etc. The blueprint and service definition reside on the ESR and play a role only during design-time
• Every enterprise service has a “glue code”. Glue code (also called proxies or stubs) contains all the work done during the SAP Modeling Methodology. It contains GDT representations and is delivered with the Enterprise Service Bundles (see “Delivery” section)
• Every enterprise service has a “service implementation”. These are the BAPIS. This is what gets installed with with SAP ERP 6.0.

Meaning

• From a technical point of view every “enterprise service” is a web service. SAP is not adding any proprietary tag to the WSDL file or the communication protocol
• As described in the previous section, every enterprise service is only implemented after the SAP Modeling Methodology is finished
• Every enterprise services resides in the Enterprise Service Repository

Delivery

It did not make sense to deliver 1000+ enterprise services and a good luck wish for users to find the ones they need. Therefore:

• Enterprise services are grouped around business scenarios and such groups are called Enterprise Service Bundles
• Enterprise Services Bundles are delivered as part of the enhancement packages
• Discover, share, test-drive and develop enterprise services with the Enterprise Service Workplace and the Enterprise Service Wiki, both available in SDN
• The discovery system is a great way to get everything in a box; ESBundles, SAP NetWeaver, SAP ERP 6.0 and many composites

Enterprise Service Repository

If you are familiar with PI (formerly known as XI) you may be confused about where the ESR starts and PI ends. If you are not familiar with PI then you’ve probably never seen the ESR and if you have, someone pointed out that what you were looking at was XI. Either way, I understand the confusion. Let me give you a bit of background

The Enterprise Service Repository is the evolution of what it was known as the Integration Repository in XI. Now the Integration Repository is called the ESR and XI is called PI. Using the Integration Repository as foundation for the ESR made a lot of sense since many of the capabilities were already there: metadata storage, defining message types, data types, operations, etc.

Most important, the ESR is where the enterprise services reside. This is the place where these services get model and defined. The two venues to get the ESR, either through PI or CE close the loop to provide and end-to-end solution from modeling to enabling provisioning and consumption tasks. You will get a clear picture of how these services get created in part two of the blog series

Enterprise Service Registry

A little known fact is that SAP also provides a Registry. Very often overview material clearly describes the role of the ESR, but says little or nothing about the Registry

The Registry gives visibility to the ESR. Through the Registry, providers and consumers can publish and discover services. As you will see in this blog series Java and ABAP development tools are already integrated with the Registry and ESR. Capabilities from the Registry, such as classifications, facilitate tools like Visual Composer and Web Dynpro to define advance search criteria. ABAP back-end systems can now publish enterprise services and set endpoints

Now you know that the ESR is the starting point to create a service. What next? Let me explain the role of the Composition Environment

Composition Environment

I believe that since TechED 2003 various stakeholders, including myself, have been describing a recommended approach to service enable. We call it the outside-in approach. Basically such an approach recommends that developers and engineers focus on the definition of services before beginning implementation. In 2003, and even before that, we had capabilities in XI to define Message Interfaces and do provisioning in ABAP. Today, we can model and define a service in the ESR. With the Composition Environment we can do all the provisioning and consumption activities in Java. Therefore, with the ESR, Composition Environment and ABAP Workbench, we have an end-to-end enterprise SOA infrastructure for both stacks

This is why the Composition Environment is a complete enterprise SOA development infrastructure. Capabilities in the Composition Environment such us the ESR Browser allow the generation of Java proxies. Business functionality can be implemented using EJBs and security configurations can be set. Service publication and testing is also available. Furthermore during consumption, Web Dynpro or Visual Composer can create a client application running on Interactive Adobe forms, Flash or Web Dynpro

This blog series will not only touch on all the provisioning and consumption activities that are possible with the ESR and the Composition Environment, but it will also show how the same tasks are possible in ABAP

Now that I have described Process Components, Service definition and the Composition Environment, let me summarize all the end-to-end activities that will be described in this blog series. I will use the outside-in approach and describe them from a technical perspective. Keep in mind that these steps are possible in ABAP and Java and describe only design-time activities

Provisioning

• Define a Service: Model and define a Service with the ESR of PI or the ESR of CE
Generate Proxies. Find the service interface or WSDL from the ESR and generate proxies
• Implement: Write the BAPIS in ABAP or EJBs in Java
• Publish. Once business functionality is implemented a Web Service is created and publish to the Enterprise Service Registry

Consumption

• Discover: Discover the WSDL file with Visual Composer or Web Dynpro
• Implement: Write the client code. Give it a UI
• Deploy and Configure: Deploy client application to the engine and configure web services (if needed)
• Run.

Finally let me write a few words on the Integration Platform. I will be brief to limit coverage of topics outside this blog series

Integration Platform

The Integration Platform describes all NetWeaver capabilities around SOA. There are many that play key roles. If you have read some of the most recent blogs on BI you know that many of the NetWeaver capabilities are also exposed as web services. Such service enablement of NetWeaver complements all ESOA activities. As part of the Integration Platform you will also discover the key enterprise SOA initiatives around PI and BAM and BPM. We will cover some of these in this blog series