Section 8.1. What is the Enterprise Services Repository?

8.1. What is the Enterprise Services Repository?

The Enterprise Services Repository is the design-time repository of service objects for ESA. What do we mean when we call the Enterprise Services Repository a design-time repository? This term refers to the process of designing services. There are essentially two methods for creating enterprise services: from the inside out and from the outside in (see Chapter 15 for detailed examples of these two methods). Inside a service is its implementation, the code itself. With inside-out development, you start with codethat is, existing application functionality. You then service-enable this functionality and turn it into a web service using a wizard. Inside-out development is straightforward; you take an existing function like a BAPI and turn it into a web service. It's helpful and easy, but not really anything new.

Outside-in development takes a process-oriented, model-driven approach. Instead of starting with the application, as in more traditional application development, you start with your business, examining your business processes from end to end. You focus on particular business processes that bring you the most value. You then model these business processes and map them to the services you need to bring them to life. You start from the outsideyour business needsand work your way in to the implementation.

This is where the Enterprise Services Repository comes in. To start with, you model data types and service interfaces in the Enterprise Services Repository. Because you're starting in the repository, you can reuse data types and interfaces that already exist. Having a central repository as a starting point enables orderly development, reuse, and enforcement of governance rules. Because you are doing your design work in the Enterprise Services Repository, and because everything you need for designing services is included in this central repository, the Enterprise Services Repository is a design-time repository. Let's qualify that a little. Everything you need for creating services might not be in this repository; you may want to import software components into the repository, for example. The point is that not only is the repository the central starting point for design, but also that it should be. If something you need is not in the repository, you model it there or import it into the repository. If everyone who is creating services works from the outside in, orderly development and reuse become the norm rather than the exception.

Figure 8-3 shows specification time, design time, and implementation time.

Figure 8-3. The Enterprise Services Repository in relationship to the development process

After modeling data types and service interfaces, you generate proxies in the Enterprise Services Repository, and the action moves to the implementation phase. The generated proxies are code skeletons that a developer will flesh out in the appropriate development environment, whether the ABAP Development Workbench or the SAP NetWeaver Developer Studio for Java (.NET support is coming as well). The Enterprise Services Repository is directly linked to these tools, so work flows seamlessly from one phase to the next. From implementation time, the service moves on to runtime. To be specific, the service is released to the SOAP^[*] runtime, which is part of the SAP NetWeaver Application Server (SAP NetWeaver AS). Note that the tools create all the necessary XML entities for you; you do not need to write XML yourself.

^[*] For details on web services standards such as SOAP, see Chapter 14.

Looking ahead, the Enterprise Services Repository is the design-time repository for ESA, and that won't change. One important change on the horizon, however, is the integration of the ARIS modeling tool into the Enterprise Services Repository. Today ARIS is available as a separate product, but its integration into the Enterprise Services Repository marks a step in which specification time also centers on the repository. We will discuss the integration of ARIS modeling and its implications for the Enterprise Services Repository in more detail later in this chapter.

8.1.1. What are the Enterprise Services Repository's roots?

To understand where the Enterprise Services Repository has come from, you need to understand SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI).

SAP NetWeaver XI plays an important role in development. Specifically, SAP NetWeaver XI helps with integration scenarios in which messages from different organizations, different XML vocabularies, or different systems are mapped to provide a robust integration that does not rely on custom development efforts.

SAP NetWeaver XI includes the Integration Repository, the Integration Builder, and the Integration Server. The Integration Server continues to act as an integration broker, brokering at runtime services that require more complicated integrations or mappings to translate between systems.

The Enterprise Services Repository is an evolution of the SAP NetWeaver XI Integration Repository. This means that the Enterprise Services Repository includes everything that was formerly in the SAP NetWeaver XI Integration Repository and a great deal more. All existing SAP NetWeaver XI business processes, interfaces, and data types are naturally part of the Enterprise Services Repository. The interface to the Enterprise Services Repository is through the Enterprise Services Builder, which is an evolution of the SAP NetWeaver XI Integration Builder.

8.1.2. What are the advantages of the Enterprise Services Repository?

Having a central repository offers several distinct advantages, including:

• Orderly development

• Reuse

• Ease of development

• Model-driven development

• Service orchestration

Let's look at each advantage in more detail.

8.1.2.1. Orderly development

Having a central repository based on structured data makes development an orderly process rather than a free-for-all in which applications are developed only to solve a particular problem.

Consider how development has been done in the past. A developer looks at a problem and invents a way to solve it. There are nearly as many ways to solve problems as there are developers, so inevitably this method leads to a lack of uniformity and transparency. Reading another person's code can be tricky at best.

Development from the outside in is a more disciplined approach that promotes reuse. Starting with a central repository reinforces governance rules.

From a development perspective, there's another feature of the Enterprise Services Repository that isn't often noted. You can think of the Enterprise Services Repository as the mother of all development tools, ensuring orderly development. How does it do that? In addition to everything else we've discussed about the Enterprise Services Repository so far, the Enterprise Services Builder provides inherent support for software logistics features such as versioning, as well as a robust change management system. The repository includes an object history for each object it contains.

The Enterprise Services Repository helps companies promote governance such as adherence to standards like global data types, and it brings about uniformity. Looking ahead, the Enterprise Services Repository will include business objects, which are larger units of functionality. In brief, a business object is an identifiable business entity, such as a sales order or a purchase order. Business objects feature a certain uniformity in the types of operations they offer, including creating, deleting, and updating. This homogeneity in turn creates transparency. If everything is framed in the same way, a developer who has worked on one part of a system can easily work on another part. A future version of the Enterprise Services Repository will incorporate business objects as a key larger building block for enterprise services.

The Enterprise Services Repository is the centerpiece of ESA in an effort to shift from one-off solutions and brittle integrations to a robust SOA that provides business value and flexibility to change in response to market conditions without fear that making a change in one area will break integrations in other areas. An orderly approach ensures that development is disciplined and structured in ways that maximize business value.

8.1.2.2. Reuse

The presence of a central repository also enables reuse of its elements. When you are modeling, you can scan the repository to see if any elements can be reused or adapted. This in turn fosters orderly, robust, efficient development. And of course, it saves time as well.

In the Enterprise Services Repository, you can efficiently design services that reuse data types and even entire service interfaces. You can also ascertain what is missing and model the entities that you need to create.

By having all service objects available in a common repository, you can avoid reinventing the wheel and maximize reuse. All service interfaces are registered in the Enterprise Services Repository.

For example, consider a common feature that is typically handled through two completely different applications: taking an order. A business partner might send an order electronically, with essentially an application-to-application/business-to-business connection. For smaller partners, you might offer a self-service user interface (UI) or a telephone ordering system where employees in turn feed the data to a similar UI. Despite the similarity in the data exchanged, such applications are typically created as entirely different programming efforts. With the Enterprise Services Repository, a large portion of the process can reuse the same data types and service interfaces. When the process or data elements change, the reuse inherent in the repository ensures that the changes are minimal, and certainly duplication of effort is eliminated.

In addition to reuse, services can be adapted and repurposed. The repository makes it possible to see what is there and what you need to add, easily. And what you add becomes another part of the repository that someone else can reuse.

Because of the adherence to open standards, services created in other systems can also be reused by importing them into the repository; data types and service interfaces are created automatically when you do the import.

8.1.2.3. Ease of development

Let's focus for a moment on how the Enterprise Services Repository and related tools ease development by doing your work for you. Developing enterprise services involves the creation of XML files, including Web Services Description Language (WSDL) files. With the Enterprise Services Repository approach, all XML entities are generated for you; there is no need to write XML or even tweak it unless you want to. By abstracting this complexity, those involved in creating enterprise services can retain a business focus and not be caught up in these details unless there is a specific need to tweak the generated XML. Because ESA is solidly built on open standards, tools can generate XML for you without intervention. And as we will see in Chapter 15, flexibility is not hindered by this automatic generation. Four styles of WSDL are generated automatically, though one style, the document style, will be chosen most frequently to maximize interoperability. Further, model-driven development, as described next, involves generating proxies of services that once again ease development work by providing a starting point for implementation.

8.1.2.4. Model-driven development

Having a central repository enables a new approach to application development: model-driven development, in which you start with business processes rather than with application code. The central repository grounds these models in reality, tying them to service objects and data types in the repository.

One of the fundamental principles of ESA is that you start with business processes and create strategic services that will support these processes. As we will see later in this chapter, in the section "What is the Enterprise Services Inventory?," you can move from solution maps and drill down to individual services in the repository. This is ultimately a description of the outside-in approach: starting with business processes and moving in toward the fine-grained details of implementation.

Today when creating services from the outside in, you model data types and service interfaces in the repository. In the future, the Enterprise Services Repository will incorporate ARIS models, allowing more specification work to occur in the repository as well. (As mentioned earlier, ARIS is available today as a separate product.)

8.1.2.5. Service orchestration

The Enterprise Services Repository also plays an important role in service orchestration. The Enterprise Services Repository represents a central modeling layer, which guides implementation from high-level business models right down to callable enterprise services. No matter whether you are reusing services or business objects from SAP applications, those created by a third party, or your own custom development, the repository acts as a central hub for coordinating all of these activities and ensuring uniform development, order, and efficiency.

8.1.3. What tools do you use to access the Enterprise Services Repository?

You use the Enterprise Services Repository directly through the Enterprise Services Builder. The Enterprise Services Builder provides a variety of editors for working with different repository objects. Repository objects are related to various open standards (for example, service interfaces use WSDL). The System Landscape Directory serves as a central information repository for your system landscape. A system landscape consists of a number of software and hardware components that depend on each other with regard to installation, software updates, and demands on interfaces. Software component versions can be imported into the Enterprise Services Repository from the System Landscape Directory (see Figure 8-4).

Figure 8-4. The Enterprise Services Repository's role in composition

The Enterprise Services Builder is the tool for creating and editing service objects, models, and interfaces contained in the Enterprise Services Repository. While the Enterprise Services Builder is the tool for interacting with the Enterprise Services Repository for both creating and composing services, sometimes developers need to see what is in the Enterprise Services Repository from their development environments. The Enterprise Services Browser provides a window into the Enterprise Services Repository from development tools such as the ABAP Development Workbench and SAP NetWeaver Developer Studio.

Using the Enterprise Services Browser, you can browse the objects in the Enterprise Services Repository and generate proxies for them. The WSDL descriptions of these objects are then retrieved from the Enterprise Services Repository and form the basis for generated proxies for those objects. Although the Enterprise Services Repository can be accessed in this way through the Enterprise Services Browser, in order to create or modify objects in the repository, you launch the Enterprise Services Builder.

8.1.4. If the Enterprise Services Repository is at the heart of ESA, don't less technical people use it, too?

Modeling data types and creating service interfaces is typically the province of developers. That's why you will find detailed descriptions of these processes in Chapter 15. As we have described throughout this book, ESA allows a much broader group of people to consume enterprise services, compose new applications using enterprise services, and even create new enterprise services. We've mentioned how developers and programmers use the Enterprise Services Repository through the Enterprise Services Builder. Figure 8-4 shows all the touchpoints that leverage the Enterprise Services Repository. Users interact with the repository through a variety of interface types, as shown at the top of this figure. These interfaces are constructed by business analysts using a variety of tools, including SAP NetWeaver Visual Composer. The repository also plays a role in the orchestration of business processes and in analytics. We've already highlighted the role of the Enterprise Services Repository in service creation and composition.

The role of the Enterprise Services Repository in all these areas will become clearer as you read further in this book. This chapter marks the beginning of a deeper dive into the full implications of consuming and composing services, tasks that are the province of business experts. Chapters 9 and 10 will delve into specifics about consuming services, including a discussion of Project Mendocino, which uses service consumption to provide robust integration of SAP application functionality through Microsoft Office. Chapters 11 through 13 provide important details about how business analysts can use existing services to compose new applications, through the SAP Composite Application Framework (CAF) at the center of Figure 8-4. We don't want to steal the thunder from those critical chapters here, but rather to show you visually that all of these approaches to service consumption, composition, and creation are ultimately tied back into the Enterprise Services Repository.

8.1.5. What is in the Enterprise Services Repository?

Now it's time look at the contents of the Enterprise Services Repository in more detail. Figure 8-5 provides an overview of what is in the Enterprise Services Repository, including service objects, integration objects, and process models.

Let's look at each element in a bit more detail.

Figure 8-5. What's in the Enterprise Services Repository

8.1.5.1. Data types

Data types are the lowest-level element from which we construct services. Data types are used in business objects and they are used in interfaces. They are very basic building blocks.

How did the focus on standardizing data types for reuse come about? Like many companies, SAP discovered over time that the definition of a given data type in one software module might differ from a similar data type in another module. In an effort to standardize both internally and externally and therefore achieve greater interoperability, SAP chose to adopt the UN/CEFACT standard for global data types. This international semantic standard ensures maximum reusability and ease of integration. As a result, developers can't just create data types on a whim. Instead, creating a data type is subject to a governance process, where standards personnel work to figure out whether the proposed addition is redundant with other data types. (For more details on ESA governance, see Chapter 17.)

The use of global data types ensures standardization and interoperability. To describe global data types, another open standard is used: XML Schema Definition (XSD). XSD allows for cardinality, default values, and facets. Data types can be nested. They can be created using the data type editor or imported from XSD documents. They can also be exported from the repository as XSD documents.

8.1.5.2. Message types

Message types are XML entities that describe the messages the service will send over the wire. Message types are the design-time representation of the messages that are exchanged at runtime.

8.1.5.3. Operations

You can think of an operation as what the service does. Operations are the specific actions that the service can perform at runtime. An operation can be synchronous or asynchronous. A synchronous message waits or blocks until it receives a response (a telephone call is synchronous, as an example). An asynchronous message is sent and may receive no response at all (an email message is asynchronous). More germane to ESA, you can think of an order sent from a business partner electronically as an asynchronous message.

8.1.5.4. Service interfaces

Service interfaces are the metadata description of messages and operations used at runtime.

Currently, service interfaces have one operation per service. In an upcoming version of the Enterprise Services Repository, they will offer multiple operations per service.

Service interfaces have a direction attribute that defines them as outbound, inbound, or abstract (a category used for business processes or canonical interfaces).

A service interface represents a large part of what makes up a WSDL document (it will get its binding and address data at runtime). As such, the service interface is completely independent of the language in which the service is implemented and the platform on which it runs.

The WSDL for a service interface is shown in Figure 8-6. The exported WSDL document can be published either to a Universal Description, Discovery, and Integration (UDDI) server (whether to a public UDDI server on the Internet or to a private UDDI server running on SAP NetWeaver AS) or exchanged with partners in another way (such as HTTPS or encrypted email).

Figure 8-6. A service interface in a WSDL document

8.1.5.5. Integration objects

We mentioned that the Enterprise Services Repository has evolved from the SAP NetWeaver XI Integration Repository. The presence of integration objects and mappings in the Enterprise Services Repository relates to its ongoing role in helping facilitate flexible integrations among business partners. The Enterprise Services Repository aids in creating integration scenarios, mapping from the data types used by one business partner to another and automating translations between two systems or two XML vocabularies, such as RosettaNet, an XML standard for the high-tech industry.

Mappings are among the integration objects used in integration scenarios. Message mappings transform the sender message to the form of the receiver message. You can create message mappings using a graphical mapping editor (which generates Java code), using Java programs, ABAP Objects classes, or XSLT stylesheets. Interface mappings register a pair of interfaces for use in an integration scenario and specify the message mappings to be used at runtime.

8.1.5.6. Process models

As mentioned earlier, dynamic process models will be added to an upcoming release of the Enterprise Services Repository with the integration of the ARIS modeling tool. ARIS models further enable a top-down or outside-in approach to development. Once ARIS is integrated into the repository, you will be able to use this tool to create high-level ARIS models that drill down into more detailed process models.

What are some of the benefits of visual modeling? For one, models make development easier and prototyping faster. They expand the audience of people who can participate in the development process, allowing business analysts, whose expertise lies in the area of business processes, to help create these models instead of having to leave all of the development to "code jockeys." These models are dynamic; they drill down to more detailed integration models that in turn drill down into services. Unlike static models, they do not get out of sync over time; changes are reflected in the model, so the model can be used for creating a test plan as well as for documentation and training. Additionally, since the models are dynamic, working with them is a fluid process. You can import and export models as needed. You can pull in an ARIS model as a starting point, then drill down and see what services are affected. This process is as iterative and fluid as you need it to be.

Further, once ARIS is incorporated into the Enterprise Services Repository, it will include SAP-specific content. If your process follows that of the SAP software, you have a good starting point with these reference models; you need only model areas where your process takes a different turn.

While the integration of ARIS modeling into the Enterprise Services Repository is a future focus, modeling is still the basis of the design-time process in the Enterprise Services Repository today; you model service objects as you create enterprise services from the outside in, as described in Chapter 15. Those who are also interested in visual modeling may want to start taking immediate advantage of ARIS modeling, which is available today as a standalone tool.

8.1.5.7. Business objects

Another important element that is coming in a future release of the Enterprise Services Repository is business objects . In brief, a business object is an identifiable business entity. Business objects are conceptually clear to businesspeople as logical units, such as a customer or a sales order. What is clear in the mind of business experts has been less clear in software in the past. Business objects follow a consistent structure and have logical relationships with other business objects (a purchase order is associated with a customer, for example). Like a purchase order, a business object has subelements known as business object nodes. Business objects reuse existing data types. Business objects can be used in predictable ways to ensure orderly development and generate enterprise services that are guaranteed to perform basic functions such as modifying a purchase order, creating a purchase order, or deleting a purchase order. Because business objects are strategic building blocks, the creation of new business objects must be subject to a governance process (governance in ESA is the topic of Chapter 17).

All entities in the repository link together in a hierarchy, and you can navigate through the repository to find just the element you need for any given task. Further, the availability of a common repository enables smooth and consistent development, all the way from high-level graphical process models to services and right down to the definition of global data types.

8.1.6. What is the role of namespaces in the Enterprise Services Repository?

Given that the Enterprise Services Repository serves as a common repository for all service objects, how can we ensure that two objects are not duplicated? After all, we could certainly have multiple objects with the same name. How can we prevent naming collisions?

To ensure that each object in the repository has a unique name, objects are named through a combination of component version, namespace, and name. Namespaces ensure that when a component is named, it can definitively point to a single entity. Each object in the Enterprise Services Repository is uniquely identified by the triple of software component version, namespace, and name. During the modeling process for data types and service interfaces, we supply a namespace to prevent any naming collisions.

To be registered in the repository, a software component version must exist in the System Landscape Directory. The software component version then becomes an object in the Enterprise Services Repository that can be edited (if it is configured to be editable, that is).

For each software component version, we specify whether its Remote Function Calls (RFCs) and IDOCs can be imported. Since accessing these entities entails logging in to a remote system, credentials must be supplied if this access is permitted.

For each software component version, multiple namespaces can be defined. This allows development objects to be segregated into different areas. These namespaces are defined by either a URI or a URN, according to the W3C's XML Namespaces specification.

Now that we've looked at the Enterprise Services Repository and what it contains, we will direct our attention to the "content" that SAP provides for the repository: the some 500 services that comprise the Enterprise Services Inventory.