Section 5.1. Basics of ESA applications

5.1. Basics of ESA applications

The questions in this section cover the basics of ESA applications to set the stage for the more detailed discussion of the ESA stack that follows. This chapter aims to create a clear understanding of the different ways that the ESA stack supports service consumers, such as composite applications, and the way in which ESA plays a slightly different role inside service providers, which should establish a solid foundation for more learning.

5.1.1. How are applications in ESA different from previous generations?

Figure 5-1 shows the key difference between traditional mainframe/client/server applications and the structure of applications in ESA. In ESA, applications no longer live inside one container in which every layer of the stack resides. Instead, some parts of the stack live in service consumers and other parts live in service providers. Composite applications are the most common service consumers, but the web services standards are so widely accepted and implemented that almost anything can consume a servicefor example, a spreadsheet, a portal page, or a mobile phone.

From the service consumer perspective, all that is required is knowledge of the interface of the services that are being consumed, an understanding of what that interface actually doesthat is, the semantics of the interfaceand the ability to invoke an enterprise service.

The Enterprise Services Repository is the design-time directory of information describing enterprise services interfaces that help people determine what services exist and how to use them. The Enterprise Services Inventory refers to the collection of enterprise services that SAP is initially building and providing to customers.

Figure 5-1. ESA application structure

Service consumers vary in complexity. The simplest service consumer could just be the user of one service, which would, despite its simplicity, still qualify as a composite application. Composite applications may then add complexity by doing any of the following things:

• Consuming many services.

• Creating new user interfaces (UIs) that take advantage of services for workflow, collaboration, analytics, data management, searching, mobile access, and others.

• Composing new services or business objects out of existing services for use inside the composite applications.

• Implementing new functionality by coordinating the invocation of services to perform some complex task. This is usually called service orchestration and can take place at the level of a composite application, inside a service, or inside a business object.

• Creating new services to be used by other composite applications.

• Creating new business objects that store new transactional and master data, thereby extending systems of record.

The service provider's main job is to provide services to service consumers. Service providers generally fall into three categories:

Existing enterprise applications

In this case, services will be built on top of the Enterprise Services Repository or other mySAP Business Suite solutions using languages such as Java and ABAP to create enterprise services out of APIs. Care must be taken to make sure that services created on top of existing enterprise applications don't have any side effects that may influence the behavior of the other users of the enterprise application.

New enterprise applications

In this case, enterprise applications will be created to be service providers. Most often this means that the enterprise application was created as a set of business objects that work together. Business objects, which were created to be reusable units of functionality, can easily support the creation of enterprise services. Patterns, which will be discussed later, make the transformation even easier.

Special-purpose functionality

In this case, some other functionalityperhaps the information from a system at another company, a radio frequency identification (RFID) reader, a sensor that shows the level of a tank, or an alert coming from an agent monitoring a vital KPIis made available as a service.

So the key characteristic to keep in mind about the structure of ESA applications is that a service consumer can use services from many providers and a provider can offer services to many consumers. At its best, this creates a situation in which functionality is "loosely coupled" so that parts can be assembled and reassembled to solve new problems.

5.1.2. How are services combined into applications in ESA?

Services represent reusable components, which in themselves are quite powerful, but alone are not enough to achieve the flexibility and rapid development that ESA must provide to create maximum business value. The way services are combined is fundamental to understanding the difference between ESA applications and those of previous generations.

Under ESA, services are combined with various mechanisms for service orchestration. The idea is that instead of using only Java or ABAP code to invoke services, get results, and process the data, tools for Business Process Management, workflow, and process orchestration would be used as much as possible. The more an application can be transformed from Java and ABAP code into process orchestration tools, the easier it will be to change the application. Such tools also increase the number of people who can participate in combining services to create applications. Tools such as SAP NetWeaver Visual Composer, Guided Procedures, and Cross Component Business Process Management (CCBPM) are examples of this technique.

In general, ESA tries to replace coding with modeling as much as possible. We will highlight this as we explain the different levels of the ESA stack.

5.1.3. Can an application be both a consumer and a provider of services?

Service consumers can create business objects that have new functionality coded in Java and ABAP, and can use other services or business objects. These new business objects can support the creation of new enterprise services that can be offered to other applications. In this way, a service consumer becomes a service provider as well. The idea sounds simple, but our understanding of the structure of ESA applications may be helped by walking through an example.

In one of the most popular composite applications, the blocked order list composite discussed in Chapter 11, it is possible to get a list of orders that are being blocked from completing because of credit limits or other issues. This composite was created to allow fast processing of orders that were blocked so that certain orders can be unblocked quickly in special situations. Let's say that a company had a $500,000 credit limit but was acquired by a much larger firm that was scaling up operations rapidly. The orders for that company might skyrocket before the new credit limit based on the credit quality of the new owner was approved. The blocked order composite allows the list of blocked orders to be examined, analyzed, and released for processing if justification can be found. So, how could this composite offer a service?

One natural candidate would be a service to search the blocked order list for the presence of a blocked order for a particular customer ID. This service could then be used on the dashboard for the sales representatives to alert them if any orders were being blocked. They would then be aware of the situation and could help take action to remedy the blocked order if any action was warranted.

Now, if such a service were created for reuse, it would first have to be run through SAP's process for creating, designing, and approving services that would be added to the Enterprise Services Inventory and be described in the Enterprise Services Repository so that it could be used by SAP's development tools. The Enterprise Services Repository, Enterprise Services Inventory, and development tools are described in later chapters.

5.1.4. How does ESA work with event-driven architectures?

ESA, like all forms of service-oriented architecture (SOA), works on a request/response paradigm. Nothing happens until a service consumer invokes a servicethat is, makes a request and then waits for the response. While it is theoretically possible that a service could accept a request and always return nothing, most of the time service consumers wait for the service to respond with some sort of information.

Event-driven architectures (EDAs) work completely differently. In an EDA, something happens to start a chain of events. The paradigm is not request/response but fire and forget. The event occurs, some other software system or some person is notified about it, and then all sorts of things could happen. One event could lead to one event or many other events being triggered. Many programs could be listening for the same event. An event could lead to a task being put on someone's worklist. An event could start a composite application that could help a user do the work of reacting to the event. Events could notify systems that were monitoring a business.

SOA and EDA are appropriate architectures for creating software systems that model and automate business activity. SAP has long used events all over the mySAP Business Suite, and now that ESA is transforming how software is structured and created, it is clear that both EDA and SOA will work together. But how?

To understand how EDA and SOA interact, we will delve deeper into how SAP has implemented events and how new forms of architecture and systems are being constructed on top of basic mechanisms.

5.1.4.1. Core events and business events

Core events are technical in nature and do not really carry much information with them. A core event indicates that a business object has changed its state, and nothing more. For example, Purchase Order Saved is a typical core event. What does it signify? That a purchase order was saved. This purchase order could be new or it could be an existing purchase order that has been changed. More than 2,000 such core events are defined across the business objects of the mySAP Business Suite.

Business events are built on core events. As Figure 5-2 shows, business events start with a core event, but then more information is added to them. The core event, Purchase Order Saved, might become a business event that has the name of the customer, the amount of the purchase order, the product being purchased, and so on. What is stored in a business event is determined by how it is going to be used. In the future, there will be even more types of business events. Business Intelligence events, Knowledge Management events, Database events, and many more types of events are possible.

Figure 5-2. Core events and business events

It is easy to imagine the many different things you could do with business events. For example, if a business event indicating a new customer was created, a business event could trigger the creation of a task to evaluate that customer's credit quality and set a credit limit, a process that could be supported by a composite application. A task is not an event; it is a unit of work performed by a person. Tasks are one important way that ESA will interact with EDA. Composite applications built using ESA will be used to process tasks that are created from core or business events. For example, a composite application created to process a task might have functionality to understand exactly what the task is, inspect and analyze the context, and then take action to properly complete the task. It is also possible that composite apps will monitor business events or analyze information gathered about business events, or wait to be triggered by business events.

SAP plans to implement a form of Business Activity Monitoring (BAM) called Milestone Monitoring, BAM is a general concept that covers many capabilities for automated performance monitoring, such as creating alerts based on KPIs and using events to create a sophisticated model of a business. Milestone Monitoring is a type of BAM in which key business processes are tracked by the SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI) Business Process Management capabilities for modeling processes. This use of Business Process Management creates a long-running monitor out of a capability frequently used to manage long-running transactions. Business events and alerts are generated when certain thresholds are reached, and then Business Process Management can monitor how long various parts of a process take and can determine whether milestones are met on time. As part of the tracking, metrics about process performance are gathered and delivered into SAP NetWeaver Business Intelligence (SAP NetWeaver BI) for analysis.

For example, monitoring of a Customer Relationship Management (CRM) process might work as follows. When a lead is created, a business event causes a timer in Business Process Management to be set. If a business event indicating an appropriate response to the lead is not generated within, say, two days, an alert is sent to the responsible sales representative. If four days go by, the alert might go to the sales rep's manager. All the while, when people do respond within these thresholds, the actions taken and the results are sent to SAP NetWeaver BI for further analysis.

Milestone Monitoring is just one way that events can be put to good use. Many others are on the way that involve not just monitoring, but also automated responses to business events.

In the long run, EDA and ESA will likely work together in common patterns that will become, in effect, a new integrated architecture. In the short term, it is clear that in certain cases, the fire and forget paradigm allows even more decoupling than the request/response paradigm and that flexibility will be put to interesting uses.