Deep within SAP NetWeaver lies the service repository, where all services live. It's like a dormitory for services. The repository can hold thousands of services related to ERP and your business processes. mySAP ERP 2005 shipped with a few hundred services, and there will be hundreds more in early 2006. Because you just can't get enough services, even more will follow in years to come for ERP, mySAP CRM, mySAP SCM, and so on.

When you talk about getting an ERP solution, the discussion doesn't start with technology such as ESA and SAP NetWeaver. It starts by looking at your business objectives. From there, you need to define the business processes that support those objectives and then identify the services that support those processes.

To help you get from the business process to an individual service and even to the technical specification of that service (the so-called Web Service Description Language), SAP provides you with business scenario-driven industry solution maps (see Figure 7-1). These maps outline the processes in a solution (such as ERP or CRM) or the processes in an industry (such as chemicals or the public sector).

Here's an example. Say that your business needs better financial information about its customers. You want to create a simple Web page where the customer service representative can enter the customer's name and get a list of the current balances on the customer's account, all credit notes issued to that customer, payments received, and so on.

Figure 7-1. The mySAP ERP Solution Map.

Just where do you find the services to support this new application? Start with a solution map. This lays out all the business processes in an organization.

This example involves generic financials functionality, so the ERP Solution Map fits the bill. Figure 7-1 shows a solution map, which is created from within the Solution Composer.

Because you want financial information about your customer, you click the line labeled Financials. The solution map drills down to show the processes supported by the Financials functionality (see Figure 7-2).

Figure 7-2. The Financials functionality in mySAP ERP.

All the financial information about your customer would be in Financial Accounting, and more specifically, in the general ledger. Click the General Ledger link, and a list of all the services available is displayed (see Figure 7-3).

Figure 7-3. List of services for General Ledger.

In the list of services that are available under General Ledger, the following services that you need to complete your process are available

Deducing the functionality of the services from the way they're named is pretty simple. In fact, the naming conventions for services are critical because they help you find and use the services.

Naming services isn't quite like naming your bouncing baby girl. (What was Madonna's mother thinking?) On the contrary, the naming and design rules for ESA services are founded on a very solid rationale. With naming rules, you get

The first step in defining a service is to look at the business requirement that drives the service. In this example, if you want to see the outstanding balance of a customer, the name of the transaction is CustomerAccountCurrentBalanceQueryResponse.

The CustomerAccountCurrentBalance part of the service name is fairly easy to understand, but what does QueryResponse mean? For each service, the naming reflects not only what you get but also how the service is used. In this example, the service sends a query and requires a response; hence QueryResponse.

Other services may provide a notification or actually perform a function such as change or add a new order to the system, so the service name would reflect that function.

Here's another example of how this service naming works. A Customer Credit Fact Sheet presents all credit- and collection-relevant customer data to the user at a glance. The Credit Fact Sheet may be needed, for example, by people in roles such as Sales Manager, Credit Manager, or Collection Clerk. The Credit Fact Sheet requires information from a credit management application, as well as information from accounting (specifically payment behavior, payment history, and sales volume).

The name of this service is CustomerCreditFactSheetQueryResponse, which could be broken down into more specific services: DunningLevelCustomerCreditFactSheetQueryResponse (in which dunning equals payment history, for the nonfinancial among you) and SalesVolumeCustomerCreditFactSheetQueryResponse, for example.

What's handy about this naming convention is that it expresses things in business terms, not programming terms. That makes services easy to locate and call from the services repository, whether you're an IT person or a guy sitting at a desk. It's another example of the way that mySAP ERP helps everybody around the water cooler speak the same language.

Think of Web services as a flexible and configurable plug and socket for applications, just like the plug that you use to connect your computer to a wall outlet.

When one application wants to allow other applications to connect and access some of its functionality or data, it describes the way that its plug works by using a standard form called Web Service Description Language (WSDL). Other applications take a quick look at the description and then plug in.

After the connection is made, WSDL also describes commands that control the flow of information over the connection. The information moves back and forth as messages formatted in XML, a standard language that can describe almost any data format.

Like HTML and HTTP, Web services are based on a standard definition that is not controlled by any one company. That's one of the reasons that Web services became so popular so quickly. Another reason is that Web-service connections between applications are much cheaper to create and maintain than earlier approaches to making those same connections. Unlike some of those earlier methods, Web services are reusable, which means that one Web service can be used by any number of other applications. And, one application can provide many different Web services.

Here's how WSDL works with enterprise services on the nitty-gritty technical level. The pleasant surprise here is how relatively simple this all is, compared to previous application programming interfaces (APIs). That simplicity results from stating things in business parameters, rather than in programming code.

Take a look at a very simple example. Say you are creating a service that allows customers to check the availability of a seat on a plane. First, you need to define the input criteria; in this case, this is the input the system needs in order to check the availability of a seat. The name of the service follows the standard naming convention, so it is called FlightSeatAvailabilityQuery_In.

Using the integration builder tool of SAP NetWeaver (see Figure 7-4), you can easily define the overall service.

Figure 7-4. Defining the overall service.

Figure 7-5. Defining the input.

You input an airline ID, the connection ID (the flight number), and the date of the flight. The exact formats are defined in the Type column (see Figure 7-6).

All this is easy to define; the difficult part is to convert this into WSDL. Using the WSDL tab shown in Figure 7-7, you can automatically generate the WSDL.

Figure 7-6. The output data.

What becomes of this WSDL file? When someone wants to set up a system to use a service, he requests the WSDL file, which tells him the location of the service and the function calls, and how to access these calls. Then he uses the information in the WSDL file to form a SOAP (Simple Object Access Protocol) request to your computer.

WSDL is complex, and folks have developed numerous tools to create the WSDL files. Specifically, SAP has developed the integration builder tool of SAP NetWeaver to make the generation of this code as simple as possible.

Figure 7-7. The WSDL data.

Modeling means turning data sources, relationships, interface elements, and so on into visual objects and icons that you can move around a page. You can use modeling to manage the technical complexity underlying ERP functionality. Modeling describes what a program should do by defining relationships between simplified components, rather than piling up mounds of code. For a user-interface modeling system, for example, the components used for modeling might be buttons and text boxes. After the relationship between the components is described (or modeled), the description (called a model) is then used to generate the program.

This programming model has its very own goals, which are to

At its heart, this new programming model maximizes the amount of each program that is made up of reusable components, anticipates as many potential variables as possible, and provides a standard method for dealing with them. The result of such a model is a new kind of software that is far less costly to develop and far easier to change and maintain.

A few decades of experience have shown how applications should be constructed. The way different types of software work, including many user interface designs, is fairly similar in key ways: They follow certain patterns.

Programmers have recognized this and developed so-called software patterns that work in concert with models and frameworks. Patterns, models, and frameworks — what the heck are those? Don't worry: In the following sections, we explain it all.

Starting with a pattern

Another example would be the search pattern: In a section of your application window is an area for your input. This could be a simple text box like the one displayed on a Google Web page or a more form-like structure, such as the one you use when you book your flight to Hawaii. You click a Search button to get your search results. When you know how to operate one search engine, you know how to use them all.

Patterns are a win-win deal: They make a programmer's job easier because there is less code to write, and they make users happy because the users know what to do in many situations and what results to expect.

SAP developments tools, such as the Composite Application Framework (CAF) or Visual Composer, simplify your life by making heavy use of patterns, especially in the area of user interfaces. A developer selects a pattern, which does most of the work of creating the application, and then fills in the details of the kind of field that each record should contain and how the information should be displayed.

SAP allows developers to specify the behavior of an application by defining relationships between the elements. This means picking and choosing between high-level elements, such as roles or processes, and linking them to data. Then developers can link data to screens, and so on. (When we say high-level, we mean that these elements have a lot of functionality included in them already. This functionality is described and controlled by what is called metadata, which is a fancy way of saying data that describes what a program should do.)

The reason that this is called model-driven development is that the program is created by changing a description (metadata) of what the program should do. This metadata is used to generate the code that lies under the covers.

So how do patterns and models fit together? You can think of patterns as predefined models. If you look at the search pattern, you find that it has four elements: a UI (user interface) element for your input, a Search button, a data source that can be queried, and a UI list element where the results appear (also called output). The relationship between the four elements is predefined: When the button is clicked, the program gets the data from the input field(s) and sends it as a query to the data source, which returns a list of results that are handed over to the output element in the UI.

Simply put, SAP NetWeaver Visual Composer enables you to happily drag and drop objects that represent data sources and interface elements to create content for a portal. Assume you're a manager who wants a personal portal page that displays the monthly sales totals for each salesperson on your team. Using Visual Composer, you simply drag a portal page into your work-space (called the storyboard) from an interface elements list. Then you fill that storyboard with contents from the sales information database. You can build queries without knowing a whit of query language, simply by assembling icons and elements from various lists.

Even if you're programming-phobic — say a business consultant, analyst, process expert, or writer of a For Dummies book — you can use SAP NetWeaver Visual Composer to make a diagram of just what you want a page to do. Then this clever application not only presents the content, but also creates iViews (reusable and configurable portions of a page in a portal) that come ready to be deployed. In a nutshell, SAP NetWeaver Visual Composer is about as easy as sketching out what you want on a napkin and getting it delivered to your desktop in minutes.

One of the chief benefits of this approach is that it dramatically reduces the amount of time that the IT department has to spend on content assembly and maintenance. Instead, this is left to the business experts. While these folks may not know the first thing about how to code, they completely understand the business process they're trying to model.

Have you ever tried to buy something online and had something about your order that was really weird? Maybe you wanted the standard size but in an nonstandard color? Suddenly, the whole ordering process fell apart. That's because you asked the system to make an exception to all the preprogrammed guidelines somebody fed into it.

Traditionally, in technology-land, exceptions to a routine procedure you've predefined are hard to handle. ESA and SAP modeling tools, however, make exception handling much easier.

Here's an example. Say you ordered something within the Procure2Pay business process. When the package arrives, you open it, only to find that somebody shipped you the Jx-HHG69 rather than the Jx-HKG67. The next step in the system may be to submit the invoice, but you need to do something exceptional, namely, return the package and adjust the record in the system.

In the past, this would involve getting on the phone to somebody in purchasing, shipping, or accounting — or all three. With ESA and modeling tools, you can handle it all by putting together your own solution (which is referred to as WrongPackage2ReturnDelivery).

Using Visual Composer, you can

Microsoft is committed to open standards, just as SAP is. Microsoft has made some of its products open-source so that they can cozy right up to Web services. This makes several Microsoft products a perfect match for ESA-enabled ERP.

How Microsoft opened the door to open-source

Microsoft has made Office products open through something called IBF (Information Bridge Framework). A framework, in object-oriented developer-speak, is simply a reusable design structure that you can use to make building applications easier. The main goal of IBF is to make users of Office products more productive, which it does by allowing Office to consume (or use) Web services.

SAP provides Web services through its ESA-enabled ERP; IBF is what allows Office products to connect with ERP functions.

Mendocino closes the loop

Mendocino is a set of employee and manager self-service applications that connect Office and ERP. To help you understand how it works, here are some ways you might use Mendocino in your business:

All the Office programs can be integrated with your enterprise applications and data. You can customize the Microsoft Research pane so that it is specific to your ERP-related data, for example. All Office applications have easy connectivity with e-mail to exchange documents. You can deliver business analytics through Excel and smart documents in Word.

Figure 7-8. Taking a peek at Project Mendocino.

Some folks use something called Unified Modeling Language (UML) as a general-purpose modeling language. It's the one-size-fits-all approach. But SAP chose to go with domain-specific languages expressed in eXtensible Markup Language (XML) to support various forms of automation. Domain-specific languages have built-in assumptions about the context of your application. For example, SAP models business applications, but other folks model computer games or telephone networks. Domain-specific languages are smarter. As a consequence, they offer a faster, less expensive, and more reliable approach to application development.

SAP uses domain-specific languages as the basis of its modeling tool, Visual Composer. The purpose of this is to model business applications powered by enterprise services.

Adobe is another technology giant committed to open standards through Web services. This means that it's easy to use interactive PDF forms in the world of service-enabled ERP.

Specifically, SAP has integrated Adobe Interactive PDF forms into SAP NetWeaver. An application such as mySAP ERP HCM can use these electronic forms to submit requests and handle reporting. With Adobe Interactive PDF forms, you can stay in complete compliance with all the requirements established for paper forms. Electronic forms are easy to back up for recordkeeping, and you can e-mail them or use them from mobile devices.

Using these interactive forms, financial-services providers, for example, can easily create interactive loan applications complete with customer names and addresses, and even include mortgage rates based on the customer's credit score and geographic region. Applicants complete the forms at their convenience and return them. The digital forms then automatically update the enterprise's application with new information. This avoids costly and often error-prone manual data entry.

Using these virtual forms, your enterprise can get more efficient and reduce the total cost of SAP ownership. That's because you can leverage business-critical information in extended forms-based processes to

Any development tool and programming language that can understand Web services can be used with ESA-enabled ERP. Of course, this means that your programmer won't get the full benefits provided by the SAP NetWeaver tools, but he can use the tool that's familiar and easy to use.

Tools from Microsoft, IBM, BEA, Borland, and Eclipse and programming languages including Java, C/C++, Visual Basic, C#, Python, PHP, and PERL are just some examples of this handy interoperability.