In This Chapter
Understanding the concepts of the ESA-enabled ERP platform
Using Web services over HTTP
Figuring out business and technical protocols
Exploring the XI run-time
If you've read any of this book up to this point, you know that services sound like the best idea since indoor plumbing. They make you flexible, more productive, and more focused on your business than on the technological underpinnings.
But just in case you're the curious type who wants to know more about those technological doodads, this chapter looks a little more closely at how services work and what happens when you call one.
To use a service, such as "Cancel Order," you first have to call it. Calling a service, also referred to as invoking a service, brings it to life. This involves some highly technical stuff like run-time architecture, interaction semantics, transactional behavior, and sessions. (Don't worry: We try to make this discussion as painless as possible.)
Run-time has nothing to do with your morning jog. Run-time refers to all the things that go on when a system (in this case, SAP NetWeaver) is actually in operation. (This is in contrast to design-time, which refers to all the things that happen when a system is being designed and coded.)
To understand how Web services communicate, you need to understand protocols. A protocol is a set of rules for the communication of two entities. If the entities happen to be two people on the phone, the protocol involves greetings and introductions, followed by a bit of chitchat and topped off by goodbyes.
If the two entities are computers, it's not very different. The computers and the programs open a connection (greet and introduce each other), exchange some data (chitchat), and end the connection (say goodbye). Of course, instead of words and phrases, they use zeroes and ones to communicate.
Enterprise services are described and stored in SAP NetWeaver's XI service repository. At design-time, when the service is modeled and implemented, SAP NetWeaver generates a piece of code called a proxy. You can generate proxies in Java and ABAP. These proxies connect all that back-end functionality to the interface of the enterprise service.
As shown in Figure 8-1, when an application, a PDF form, or whatever invokes an enterprise service, the associated proxy is called. The invocation can be done through a Web service interface or via the XI run-time. We explain the inner workings of these two protocols and their differences later in the chapter.
You can take this one step further into the realm of the technical: Proxies parse the XML messages. To parse means to take the data out of the message in small chunks so a program can act on the information it provides. In an SAP system, this is done via an SAP proprietary interface called the Business Application Programming Interface (BAPI). The results of the calls are then translated back into XML by the proxy. (For the programmers out there who might be wondering, the back-end functionality is mostly written in ABAP, a programming language invented by SAP.)
All of these little interactions that go on when you invoke a service have their own behavior; these behaviors are also known as the interaction semantics of enterprise services. Interaction semantics come in two types: synchronous and asynchronous.
Protocols can exist on different levels and be either business or technical protocols. Here's how they differ:
A business protocol is between two business entities, for example, a seller and a buyer.
A technical protocol exists between two computers; for example, the protocol could be HTTP.
Interaction semantics can be applied to business protocols as well as technical ones. We take a closer look at the business protocols first.
Essentially, whenever you expect an immediate response to a request (for example, if you run a query for a set of data), you are using synchronous business semantics. When you don't expect an immediate response (for example, when you click the Submit button to send a purchase request for your boss to review), that's asynchronous.
The business process that an enterprise service is designed to handle is eventually executed over a technical protocol; this is where the two different semantic types come into play. So we start by looking at the interaction semantics of the technical protocol.
Web services use HTTP, which is a synchronous protocol. This means that a request and the response to that request are combined in the same interaction, as shown in Figure 8-2. You may be saying, "So what?" Well, the client process (or thread) is typically blocked while the service is being invoked. When the server is unavailable, the invocation fails.
Whether you realize it or not, you experience this frequently using your Web browser. For example, say that you want to book a hotel room online. You invoke (call) a service on the hotel-booking Web site. This service is invoked via HTTP. While the system "thinks" about your request, you can't do anything in your browser window, so you just sit there and wait or go get a soda (this is the client process being blocked while the service is invoked). After you have your soda and the server returns, one of three things happens:
Your booking is confirmed.
The room wasn't available on that date.
There was a technical problem, for example, the hotel reservation back-end system wasn't available or the connection to that system was down. In this case, you might see one of those dreaded error messages, as shown in Figure 8-3.
The first option is fine and dandy and lets you move on to other things. The second option requires that you choose another date or room type and repeat the process. The third option sends you back where you started to try the request again or wait until later when the system decides it wants to cooperate.
Enterprise services that are executed as Web services work the same way, except that, instead of a person calling the service, the program calls it.
But this brings up a major drawback of HTTP. What should the application, form, or whatever do when an enterprise service is called and something unexpected happens that leads to an error? If the programmer didn't build in a response, nothing happens. This is clearly a shortcoming of the protocol.
However, the simplicity of the protocol has its advantages: The programmer doesn't need to know anything about the server other than its URL and the XML message format, which you can easily obtain from the SAP NetWeaver XI service repository.
In contrast, the XI run-time uses an asynchronous interaction model based on message queuing. This is also known as store-and-forward. In our hotel booking example, if the third option occurs, it makes a huge difference if you're using asynchronous, store-and-forward semantics. With asynchronous semantics, you don't have to retry your request. The retry mechanism is baked right into the protocol (in this case, the XI run-time).
As shown in Figure 8-4, when a client sends a request, it places the request in a local queue. This queue attempts to send the request to the next XI hub (a hub is a program that connects an inbound queue with an outbound queue). The hub itself has both receiving and sending queues. If the hub is unavailable, the message stays in the receiving queue and the client process keeps trying to send the message to the hub.
What does all this mean? It means that in the asynchronous model, the client logic is not blocked after a request is sent to the queue. If the service isn't available, there simply is no impact on the client. This reliability comes at a performance price, however: Queuing and dequeuing take time.
Furthermore, you need some piece of code within the client. This code, known as the client-side proxy, handles the queuing and dequeuing. This creates some constraints when your client is a Web browser, PDF form, or anything written in a programming language other Java or ABAP.
Note
Web services are synchronous, and the XI run-time is asynchronous.
Enterprise services have both a technical and business protocol aspect that can get a little confusing, so bear with us. Enterprise services have business interaction semantics that are implemented by a technical protocol, which in turn has its own interaction semantics. Still with us?
Take a look at some examples for the business aspect of enterprise services:
"Get all purchase orders from yesterday for more than $100,000" is clearly synchronous. I make the request and expect to get a list of purchase orders immediately, not next week.
"Hire Joe Smith as director of Product Management" is clearly asynchronous because I don't expect to sit around at my computer while HR makes Joe an offer and processes a pile of paperwork, and he drives in to start work next Monday. What I really do is to kick off a complex process and feed in some initial data, such as name, starting date, compensation, and so on.
The interaction semantic of the business operation does not determine the interaction semantic of the underlying technical protocol. This means that a synchronous business operation can be executed over an asynchronous technical protocol and an asynchronous business operation can be executed over a synchronous technical protocol.
So now we have a couple of possibilities:
An enterprise service with synchronous interaction semantics, as shown in Figure 8-5, using a synchronous Web service or using the asynchronous XI run-time
An enterprise service with asynchronous interaction semantics, as shown in Figure 8-6, using a synchronous Web service or using the asynchronous XI run-time
Obviously, the most straightforward solution is to use synchronous technical protocols for synchronous business interactions and asynchronous technical protocols for asynchronous business interactions.
However, as we explained earlier, you can also implement synchronous business interaction semantics with an asynchronous technical protocol and vice versa. And you may have good reasons for doing that.
For example, you may have a set of enterprise services with synchronous as well as asynchronous business semantics, but with some client configurations, including HTML user interfaces and PDF forms, you have to use synchronous Web services. (Don't ask why. Just trust us on this one. You have no options.)
Understanding the differences helps you make the run-time decision that's right for your situation.
We'll start off with a few techie terms. A transaction is a single activity in a computer system, such as the act of entering a customer order. Enterprise services exhibit something called transactional behavior, reflecting the fact that a service is essentially a single business transaction. The behavior of transactions is referred to as the semantics of transactions. (Remember, semantics equals behavior.)
Transactions are defined by four properties referred to as ACID (Atomicity, Consistency, Isolation, and Durability). Transactional behavior is closely associated with the underlying database(s):
Atomicity refers to the ability of the transaction management system to guarantee that either all the tasks of a transaction are performed or none of them are.
For example, a transfer of funds can be completed or it can fail for a multitude of reasons, but atomicity guarantees that one account won't be debited if the other is not credited as well.
Consistency refers to the database being in a legal state when the transaction begins and when it ends. This means that a transaction can't break the rules, or integrity constraints, of the database.
For example, if an integrity constraint states that all accounts must have a positive balance, any transaction violating this rule is aborted.
Isolation refers to the ability of the application to make operations in a transaction appear isolated from all other operations. This means that no operation outside the transaction will ever see the data in an intermediate state.
For example, a bank manager can see the transferred funds credited to one account or the other, but those funds will never be credited to both simultaneously, even if she runs a query while the transfer is being processed.
Durability guarantees that after the user has been notified of a transaction's success, the transaction will persist, and not be undone. This means that it will survive system failure because the database system checks the integrity constraints and there's no need to abort the transaction. Typically, all transactions are written into a log that can be played back to re-create the system to its state right before the failure. A transaction is deemed committed only after it is safely entered into this log. For example, after the money is in your account, it stays there until you starting spending it.
The ERP enterprise services are mostly atomic transactions; this makes using them simple, as shown in Figure 8-7. You don't have to worry about ACID properties and special protocols: You just call the enterprise service and it is executed or not; if it's not executed, an exception is raised.
It's time for a few techie definitions (aren't you glad?). In computing terms, a session occurs when data is shared between a client and a server over some period of time and across interactions. A good example of a session is an electronic shopping cart. You put books or other goodies into and out of the cart until you eventually proceed to the checkout.
Stateless refers to a client/server system that does not share data between different interactions.
The process of managing a session is, quite logically, known as session management. When you use sessions, you have to make the session-management mechanisms known to the client so that the client can then be coded to make use of them. This makes the client side much more complex.
Similar to transactional behavior and the Web service protocol, the design principle for session management is "Keep it simple, stupid." If you have no sessions and all enterprise services are stateless, you are keeping things about as simple as you can, as shown in Figure 8-8.
Stateless is very simple, but it comes at a price: You have to send all the necessary data every time you invoke a service because nothing is kept on the server.
Security is a really important thing when you're running enterprise software. The topics of particular importance when you're calling enterprise services are
Authentication: Establishes the identity of the client and the server
Authorization: Controls access to data and functionality based on the identity of the client (and the parameters of the call)
Encryption: Scrambles the message so that nobody but the designated receiver can read it
The following sections describe how this trio works to keep your data secure.
You may use a few methods to identify yourself to others: your passport, driver's license, or green card. In the same way, there are many ways to establish the identity of the client of an enterprise service. The most common ones include certificates or the popular combo of user ID and password.
Most of us are familiar with user IDs and passwords because we spend half our lives typing them in (and the other half forgetting them). The interesting aspect in the context of enterprise services is that you're dealing with a client system, which is typically a third-party or composite application that has its own authentication systems. The client needs to be known to your ERP system. There are two ways of doing this:
Use the SAP NetWeaver single sign-on mechanism in the client application. SAP NetWeaver's single sign-on automatically maps an identity between different systems so you only have to log in once.
Map the client IDs and passwords to ERP identities. ERP identity is the enterprise service caller's identity.
Certificates are also known as X.509 certificates. (You can impress your IT guy by casually mentioning this someday.) You probably use certificates all the time. For example, when you deal with your bank over the Internet, certificates are flying around like mad because your bank uses (we hope!) HTTPS, the secure version of HTTP. When HTTPS shows up for the first time in the URL field of your browser, it establishes a secure session. In the process, the bank's server authenticates itself to your browser so that you can be assured that you are dealing with your bank and not with some con artist who is only pretending to be your bank.
X.509 certificates use a mechanism based on a combination of public and private keys that establishes the identity of an entity, such as the Internet server of your bank. They can also be used to authenticate clients. Certificates are issued by so-called certificate authorities, which are trusted entities such as Verisign that verify your identity before issuing a certificate.
Note
X.509 certificates are intrinsic components of HTTP's secure sibling, HTTPS. HTTPS mandates the use of certificates for authenticating servers and enables the use of certificates to establish client identities.
After you establish the identity of a caller with authentication, the ERP system has to figure out what the caller should be allowed to do and see. Enterprise services use ERP authorization mechanisms that provide the identity of the caller to the ERP system.
Roles, as we explain in Chapter 3, play an important part in providing access rights. They make an administrator's job much easier because the access rights are defined within polices for a specific role. The user gets the access rights along with his role. When a user changes roles in the company, simply assign the new role, and the access rights are instantly updated.
Tip
By decoupling users and access rights through roles, you also make the security audits for enterprise systems much easier and transparent. This is particularly important in the context of compliance with Sarbanes-Oxley and other regulations.
In your house, you may keep your neighbor from eavesdropping by shutting the windows and turning up the stereo. The two most common ways to secure messages that you send via a computer network from eavesdropping are to use virtual private networks (VPNs) or to establish secure communication channels over the public Internet. You are probably familiar with both approaches from your corporate e-mail and intranet access. Either you create a VPN connection via special software installed on your laptop (often involving a device that generates a random number that identifies you to your server), or you access your corporate e-mail by using an HTTPS connection to the Web that interfaces with your company's e-mail server.
Enterprise services work in a similar way. If someone calls your services from outside your corporate intranet, she may establish a VPN and become an extension of your intranet. Alternatively, she can use an ID and password or X.509 certificates in conjunction with HTTPS to invoke enterprise services. The client identity is established, and the messages are encrypted and sent over the public Internet.
Web-service run-time architecture (something of a mouthful, we grant you) is simply the way a Web service is designed to respond when you call that service. Web-service run-time involves a client and a server, which both use HTTP or HTTPS to exchange some XML-formatted message.
Figure 8-9 shows the Web-service run-time architecture for enterprise services. The server provides a Web service via an HTTP (or Web) server. The format of the input and output messages is defined in WSDL and can be found in the enterprise service repository. All a client needs to know is the URL and the XML format.
The beauty of all this is that the client can be written in any programming language, including Java, Perl, PHP, C/C++, or Visual Basic, and can be run on any operating system and hardware platform. This is the power of open standards and a keep-it-simple interaction model.
Take a look at how our two earlier examples, "Get all purchase orders from yesterday for more than $100,000" and "Hire Joe Smith as director of Product Management," get invoked as Web services.
"Get all purchase orders from yesterday for more than $100,000" is a straight Web service call that contains all the necessary input parameters and returns an XML message with the requested purchase orders.
"Hire Joe Smith as director of Product Management" is a Web service call that includes within the XML input message some essential parameters such as name, start date, compensation, and so on. The HTTP call returns and the output message acknowledges the kick-off of the hiring process.
The final piece of the services puzzle is the asynchronous XI run-time. The XI uses a different technical protocol than the synchronous Web service infrastructure.
Remember that the XI run-time uses message queues, which ensure that messages are delivered regardless of whether the server is available at the time of the invocation. That's a great feature, but, as with all great things, it comes at a price: You need to have a specific piece of code in your client. This code, known as the XI client-side proxy, is generated by XI at design-time when you build the service. XI can generate proxies in Java and ABAP.
Although this isn't a big deal, it makes some usage scenarios very hard to implement — and in some cases even impossible. For example, if the application that is trying to invoke enterprise services is written in C++ or PHP, a popular Internet scripting language, a proxy in Java or ABAP is of little use.
If you have a Java or ABAP client, you can make good use of the XI run-time. The client puts the message in the local queue. From there, the message is sent to the XI run-time and then on to the server, where it is received by the XI server-side proxy. A response travels the same path, but in reverse.
Figure 8-10 shows the XI run-time architecture for enterprise services.
Take our example services, "Get all purchase orders from yesterday for more than $100,000" and "Hire Joe Smith as director of Product Management," and you can see how they get invoked using the XI run-time.
"Get all purchase orders from yesterday for more than $100,000" is made up of a request and response. The request contains all the necessary input parameters and is sent from the client to the server. The response is another message that contains all the output parameters, also sent through the XI run-time. With the response, the server is the sender and the client the receiver.
"Hire Joe Smith as director of Product Management" is only a single message sent through the XI run-time from the client to the server. Given the reliability of the XI run-time, the client can rest assured that the server received the message and will act on it.