5.1. Basics of ESA applicationsThe 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 structureService 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:
The service provider's main job is to provide services to service consumers. Service providers generally fall into three categories:
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 eventsCore 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 eventsIt 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. |