side-stepping the labyrinth - project rescue for sap, soa...

Copyright © 2005 by Klee Associates, Inc.

www.SAPtips.com

Side-Stepping the Labyrinth: Finding Your Way

Through the New Service Oriented Enterprise – Part I

By Axel Angeli, logosworld.com, and Lynton Grice, Consultant Editor’s Note: Axel Angeli and Lynton Grice pair up again to bring you a thorough and compelling look at the SAP® NetWeaver™ stack utilized in a complex Enterprise Application Integration project. The first of two installments on this topic, this white paper presents an overview of the primary considerations in evaluating and selecting an EAI solution. The paper offers a generously detailed examination of using an EAI solution to maximize the value of your SAP investment while providing architectural flexibility. Axel and Lynton use this opportunity to weigh the pros and cons of SAP XI for EAI. Strategies outlined include SOA (Service Oriented Architecture) and ESB, along with numerous standards that will help ensure implementation success. If you’re giving thought to EAI in your enterprise, this paper is a “must read”.

"If you're not to be forgotten, when you're dead and rotten; write something worth reading, or do something worth the writing."

Benjamin Franklin

1 Introduction This paper will demonstrate how the individual components of the SAP NetWeaver stack fit into a complex enterprise-wide Enterprise Application Integration (EAI) and Electronic Data Interchange (EDI) scenario. From this perspective, the paper will highlight the key considerations to bear in mind when evaluating, selecting, and implementing an EAI solution. It furthermore explores how best to leverage existing investments to ensure maximum technology reuse and architectural flexibility. On this occasion, it will also weigh the pros and cons of investments into SAP XI for EAI orchestration.

The dynamic nature of business these days has forced many companies to reconsider how best they can utilize technology in order to become more agile in the marketplace. The huge amount of point-to-point connections and hard-coded interactions between systems can be crippling to any company wishing to support new and changing business requirements. The SAP NetWeaver stack has catapulted itself onto the integration scene and is proving its worth in the integration market.

However, if you take a closer look at the multitude of large-scale enterprises out there, you will notice that SAP often only forms part of the “integration puzzle”. Understanding a company’s integration scenarios and interfaces is one thing; selecting the right EAI integration platform to support its business operations, now and into the future, is another. To many, this may seem like “mission impossible”; for a large distributed enterprise, it is mission critical!

EAI is a hugely complex topic and encompasses a large variety of integration tools and products like Portals, Workflow, Business-to-Business (B2B) gateways, Message-Oriented Middleware (MOM), and many more. “Service-Oriented Architecture” (SOA) and its associated technologies and standards have slotted themselves nicely under the “EAI umbrella” and are allowing business processes and applications to be integrated like never before.

SAP has put its money on Web services and has strategically positioned SOA at the forefront of its SAP NetWeaver product suite. SAP's NetWeaver technology is indeed built upon its own version of SOA, called ESA (Enterprise Services Architecture).

At its Sapphire International Users Conference in Copenhagen in 2005, SAP CEO Henning Kagermann confirmed its steady course with the goal of making its architecture easier to integrate, and more flexible for customers: “People can combine the best process solutions they get from SAP with the process solutions they get from others and also some custom-built


www.SAPtips.com



software… Our Enterprise Services Architecture gives new flexibility and new power to change business processes on the fly without being blocked by inflexible IT systems.”

Just how well the integration market takes to this SOA is still to be seen. To make the whole EAI topic a little easier and less “mind-boggling” to understand, this paper has been broken up into two distinct, yet related, parts.

“Part I” will take you on a journey that will attempt to “demystify” and “sketch out” where we are in integration today, as well as how the SOA and its accompanying technologies will help a company streamline its business processes in the future.

“Part II” comes back to the focal point of the paper on how to go about analyzing and selecting an EAI solution. By the end of the paper, you will see why SOA was introduced first, how it fits into the bigger scheme of things, and why it is one of the key points to consider when evaluating an EAI solution.

1.1 The New World of SOA Those who regularly browse the SAP home page or read their publications, like the house publication SAPInfo, might have already realized what flag SAP has hoisted for their future strategy: the aforementioned Enterprise Service Architecture (ESA), their naming for what is also commonly known as the “Service Oriented Architecture” (SOA) for the “Service Oriented Enterprise”.

With SOA, we are talking about a new paradigm in application design in which we require every piece of software to expose its functionality in such a way, that the service it provides can be requested by a completely external program. Although SOA is mainly heard in the context of Web services, we are talking about an architecture that has actually been around for quite some time now. The most popular representative of its kind has been Microsoft Windows’ Object Link Enabling (OLE) technology, also known as Active/X.

This allows writing specialized add-ons on a different and remote platform that can be easily called from another machine. Imagine:

• that your purchase order transaction in SAP R/3 can look up book prices on an Amazon Web service, or flight availability and prices at AMADEUS’ eTravel.com service;

• that your warehouse management software can look up the material value of a batch from R/3 by calling the appropriate BAPI, while it retrieves the original, non-replicated quality certificate from the production line controller;

• that your customer’s R/3 system requests relevant delivery tracking data via the internet directly from your R/3 system’s handling unit in real-time.

• that you can inquire and control any kind of hardware device within the reach of your network (e.g., RS-232 devices like scales, thermometers and similar gauges; barcode and RFID scanners; key cards and waiter keys).

All this is possible, not in the future, but today. We call this Enterprise Application Integration (EAI) or the “Real-Time Enterprise”. The limitation that is implied by the word “enterprise” in EAI seems already a bit outdated, as the integration may well go beyond enterprise boundaries, as the example of real-time tracking in deliveries shows. So if this technology is available today, why isn’t everyone using it already? Why do many believe that EAI and the related Electronic Data Interchange (EDI) are a costly, time-consuming, and difficult task? The answer is mainly found in the simple fact that we are dealing with communication, and communication is not easy to


www.SAPtips.com



establish if you have to create cooperation between many departments (and in the case of EDI, many different, external companies).

The key to success lies here in the “so-called middleware software”. These are programs that take the role of an information broker between discretionary systems. The duty of the middleware is to provide a unique interface for all communication partners, allowing them to drop their messages like you drop a letter into a mailbox, in order for it to be delivered to the appropriate receiver. The middleware will, hence, implement algorithms for common tasks, and offer them as global services to all communication partners (like real-life public services offer their services to the households and citizens). While citizens ask for mail services, electricity, streets, police, schools, garbage collection, etc., the EAI communication partners look for electronic mail services, data archiving, encryption, firewalls, etc.

This is the idea behind the Service Oriented Enterprise and the reason why the middleware products will play an important role, like the nationwide mail service plays an important role in the real world. SAP is prepared for SOA in two ways: it has redesigned its ERP offering to be able to play a role in the SOA, and it also offers its own middleware product: SAP Exchange Infrastructure (XI). But you won’t need to have XI to do proper EAI with SAP, nor would you need SAP ERP to make good use of SAP XI.

SAP XI is one middleware product among several hundreds on the market, where more than ten manufacturers could be attributed as major players in the middleware arena. Competition is tough here, and to find the best middleware can be a very difficult and daunting task that may have dramatic consequences on the efficacy of the future EAI landscape. SAP XI, in its current release 3.0, is still a product in evolution. It has made rapid progress, but currently it is more in its “software lab stage”, where people can learn more about it so that it can be thoroughly prepared for the future.

We shall now sit in a chair on the other side of the stage in a conservative SAP R/3-centric IT department that has to decide on which middleware should be selected to best serve their needs.

1.2 What is EAI? Before we dig into deeper grounds of the Service Oriented Enterprise, we shall align our understanding of EAI first. EAI is a multi-dimensional matter on which there are actually several views. Most of the SAP-focused people will remember well the famous picture in many of the NetWeaver presentations that demonstrated the four main aspects of integration:

• People Integration

This applies to tools and utilities that are designed to work easier with the computer, and to make the computer more usable for collaboration of people. The leading applications in this sector are the individual portal solutions provided, like:

• SAP Enterprise Portal

• Websphere Portal

• Microsoft Sharepoint

• Knowledge Integration

This refers to all the software designed to consolidate, aggregate, or analyze distributed data sources, like the following application areas:

• Business Warehouse • SAP BW and SEM

• Master Data Management


www.SAPtips.com



• SAP MDM

• Production planning and forecast tools • APO

• Financial consolidation and balancing • Cross-company balancing • Bank analyzer

• Business Process Integration

This is the next step forward from the classical business workflow and is traditionally know by the term “automation”. Business processes, defined and running on completely independent computers, are sending their own data across the network and, hence, trigger subsequent activities.

• Common Execution Framework (Technical Integration)

The technical integration framework provides the low-level infrastructure that only allows the integration processes. The core components are:

• Virtual Machines • ABAP, WebAS, Virtual Machine, and Just-in-Time compiler • Java J2EE Runtime • Microsoft’s Microsoft.NET Framework

• Runtime libraries, like • ABAP function libraries • Java .JAR, and EAR archives • Microsoft Common Language Runtime

• Transport Protocol Framework for distributed computing • Providing interfaces to use protocols that a disparate application can understand • HTTP and SMTP • DCOM • CORBA


www.SAPtips.com



Figure 1: SAP Integration Cube

1.3 Typical SAP Landscape Nowadays, larger companies are not satisfied with one single SAP instance. A typical standard setup runs different instances for SD/MM, FI/CO, and the production-related tasks. It is also common to grant separate instances for each plant or subsidiary that implements special production processes; mainly to give them the ability to act within minutes, on their own, to meet local needs. Just as often, you find scenarios where a separate instance exists for historical reasons. In an era where companies are merged, spun-off, and taken over, just like any commodity, it is a daily situation that the new partners bring in their own IT. There won’t be great ambitions from management’s side to invest money into merging IT landscapes just for the sake of having a single, central instance.

Actually, enterprises have realized that it is much easier to setup and administer IT when the different business units run their own installation, independently. It appears that it is much easier to let everybody work with a system where they can widely do what they want, and they have one central instance in which to consolidate the results. (The alternative is having one big monster instance that tries to accommodate all the requirements and that requires every change to be coordinated beforehand between the impacted business units.) With the commodity attitude, it comes in handy when lines are kept autonomous, so that they can be sold, expanded, or shutdown at management’s sole discretion.

The majority of SAP customers out there need to support a mixture of complex EDI and EAI scenarios. EDI is the electronic exchange of business documents between business partners in the supply chain, and includes things like purchase orders, delivery notes, invoices, etc. An example of inter-organizational cooperation would typically be the interaction between an “original equipment manufacturer” and vendors in the supply chain. The “synergy” formed between the


www.SAPtips.com



business partners would either focus on achieving a common goal, or on allowing each participating party to reach their own goals (sort of the “I’ll scratch your back if you scratch my back” approach). Although EAI can be a massive topic to comprehend, it basically allows the seamless integration of applications within the enterprise.

Products like MQSeries and Tibco typically form the “messaging backbone” of a large corporation. Proprietary EDI solutions often work in conjunction with these “messaging products” to give a company the EDI capabilities they require. SAP NetWeaver tries to conquer its share in this market with the SAP Exchange Infrastructure (XI). The following is a “high-level” view of a typical SAP environment:

Figure 2: An Everyday EAI Scenario with Many SAP Instances

Although this solution may work, in essence it often needs to be carefully “massaged” to provide the right “specialized activities” and “standards-based interoperability” that a company needs to satisfy its “vertical-industry needs”. Take, for example, the pain often required to map an ANSI X12 message into an SAP standard IDoc. This can take from a few minutes to weeks, depending on your vendor choice. This can seriously hamper a company’s position in the market, as any inability to take advantage of “strategic business opportunities” (because of a slow interface implementation) can mean millions of dollars off the bottom line.

Another point to consider is the large array of skills needed to maintain such an SAP integration environment. Companies should have a long-term view of eventually having a “single way of


www.SAPtips.com



doing things”. It is becoming more and more clear that proprietary EAI and EDI solutions are becoming an integration dead-end! The lack of standard interfaces and product know-how is mostly concentrated on one single person, if at all. This makes changes awkward and costly, and finding cause of malfunction can be a business-critical exercise.

We need an EAI/EDI solution that is built on top of a modern standards-based architecture, not one that requires you to plug in another API or purchase the entire vendor stack of products, just to get something simple to work. In the next section we will take a step back, for a second, and try to illustrate where the real “business pain” lies in today’s integration environments.

2 Business Issues of Collaboration The value provided by a smooth running integration setup with your business partners and suppliers can be summed up as follows:

• Increased cooperation will open up new markets and will allow a company to take better advantage of strategic business opportunities.

• A reduction in costs is a classic advantage when business partners co-operate with each other.

• Decreased turnaround time to get a product to market. Partners are often able to perform their tasks in parallel, and therefore are able to reduce their development times.

Ideally all internal and external parties should be connected with each other in real-time, and messages should be exchanged without delay.

Latency and complexity can hit the company with a “double blow”. Let’s see some real life experiences to demonstrate just this.

Agile Reaction on Business Requirements In the first scenario picture, it’s Monday morning and a customer tells you that he needs to receive invoices electronically by Tuesday evening, otherwise he will change to another supplier. This happens more often than you may think, because the business has promised this a long while ago, and now the customer has finally decided to act, and has put pressure on. Now you have five SAP systems and one external converter. You want the process of extracting and sending the invoices to be as painless as possible, and have no desire to check each and every system, or to send the operator to specialized training in each system! The invoices should be able to be routed through one message broker, and go straight out to the customer. This all sounds easy, but if not set up correctly, can leave the operator still working at 4:00am on Tuesday morning, trying to scramble the customer’s request together!

Quick Reaction to New Business Opportunities In the second scenario picture, your company strikes a big deal with an overseas business partner who wishes to purchase and resell certain products of yours. However, they have been quite firm in stating that they want to be communicating electronically within a maximum of three weeks, or they will take their business elsewhere. Should the wrong integration product and/or process be in place, it will leave a manager extremely frustrated and angry that she is unable to respond quickly enough to market opportunities, and hence, probably lose the deal.

“Just in Time” Scenarios “Just-In-Time” (JIT), in the automotive production environment, is another good example.

In this scenario, the supplier will receive messages (for example: DELINS, DELJIT, etc.) indicating exactly what time and where the part(s) needs to be delivered. Any failure (and hence,


www.SAPtips.com



time delay) in this scenario, will result in parts not being delivered to the production line on time, and could potentially result in a production line stop.

Business Intelligence and Data Mining Lets move up to even higher-level management. This is where “Business Intelligence” proves invaluable and provides a company with the information it needs to strategically move to the next level. Let’s say you are a large SAP shop and have a couple R/3 systems scattered around the world: a new dimension product (like SRM), and perhaps some older legacy systems (that need to be integrated to allow management to get a global view of purchasing reports like “value of buy across purchasing organizations”, “total sales per buyer”, etc.). Failure to seamlessly integrate and orchestrate data and technologies correctly through the use of ALE, MQSeries, XI, etc, will leave management scratching their heads, wondering where all the money has gone!

Central Information Dashboards Along the same line as “business intelligence” is the need for management to have access to a “business process dashboard or cockpit” that gives them the ability to see and analyze a business process end-to-end, in real time. From this, they should be able to drill-down into the specific data they require, to make informed business decisions. Many vendors provide great “technical” monitoring tools, but fail to provide the much needed “business view” that managers are crying out for.

2.1 Cost Drivers for Communication So just how much is your current integration environment costing you? This is not only in terms of monetary value but also in terms of where it will put your company “strategically”.

In most complex EAI environments, it is extremely difficult to get an overall view of the whole implementation, because all the data is distributed across the various systems. This makes changes (after the initial implementation) a time-consuming and expensive task. This is where a “message broker/orchestration component” comes into play. Everything is routed through the message broker, and this ensures that all integration knowledge is safely wrapped in one central location.

Data Mapping As mentioned earlier, the amount of time it takes to get a message interface implemented can vary greatly, depending on your vendor choice. Take the scenario of mapping an ANSI X12 message to an IDoc. This can be a “semi-automated” process if you are able to use “standard mapping templates” from the vendor. If no “standard mapping template” is provided, you will either have to outsource the mapping, or create your own custom mapping/transformation, in a language like .NET or Java. This can add unwanted time and money to the picture. So much so that you could, for example, have an SD consultant just “sitting around”, waiting for new EDI messages to be mapped correctly. This can end up being be a very expensive exercise, and could even end up being a big chunk out of the total cost for a new EAI solution!

You want to streamline the integration process as much as possible—the fewer people involved, the better! And this should also be directly reflected in the integration software you choose—the fewer pieces that need to fit together, the better!

Geographical Differences One of the big problems with integrating business partners is if they are in other countries, with different time zones. Getting a timely response via email is very rare and leads to increased stress and frustration in setting up the integration scenario. You need to get all integration


www.SAPtips.com



participants seated face-to-face around a table. This will provide great value and will definitely save you money in the long run.

Skills as an Asset The costs in maintaining skills throughout the enterprise can add up quickly if you are talking about a complex environment with numerous different and proprietary technologies talking to each other.

In the end, the costing issues surrounding enterprise integration are far from clear-cut, and generally require extensive research and effort to come out with a true result. At least one thing is for sure: timely access to data will mean that new integration initiatives can be accomplished faster, and with fewer resources – full stop!!

2.2 Quality Drivers for Communication Deficits Human error is inevitable and can also lead to frustrating and time-consuming delays in getting an interface up and running.

Automation Is About Quality – Not Cost Savings The exclusive motivation for automation should be enhancing the quality provided by your IT group for the company. While saving investment in staff might be a temptation for management and those responsible for budgets, it must not become the striking argument to decide for or against collaboration and automation. To deliver better, quicker, and more reliable data and to allow a better control and judgment of the business processes are the true goals of automation. The staff you free up with a good and clever EAI solution need to be invested in improving and further developing your company. Those people are now freed from repetitive and boring tasks; however, the computer does not have the knowledge and instinct that is lodged in the brains of your people.

Streamlining Processes and Avoiding Redundancy A complex integration landscape goes hand-in-hand with a large number of processes and integration steps that need to be followed and configured just to get an interface up and running correctly. It comes as no surprise that, every so often, an IDoc may end up on the “dead letter queue” on MQSeries. This is often because some arbitrary configuration has been missed, and the IDoc does not know where to go, once it leaves SAP. In the end, it might have just been a small change to a UNIX configuration file that just needed a new partner added for a specific message type; but because the process involves so many people (and processing steps), the likelihood of something going wrong, at some point, is very high.

Conflicting Master Data Updates Imagine the situation where you have master data for an article. You are about to create a sales order for this article. Typically the article is locked during the sales process. If an IDoc suddenly arrives with a goods entry or a pick, the IDoc processing will run into error, because the material is enqueued (locked). A good middleware product should actually be able to first analyze the environment and predict any causes that may cause failure in processing (like in the case of the enqueue) of the material. Therefore, only if the canvas looks clean enough, should the middleware product submit the data for processing. In this case, we would expect the middleware to have a simple “settings parameter” for this message flow, one that says something like: “Lazy update: Wait until enqueues are released.”


www.SAPtips.com



Avoiding Lost Messages Losing messages? That’s unheard of, right? Not really. While the most basic feature of a message queue is to guarantee delivery of messages, the messages can be lost. This is especially important to understand, as many systems have no precautions or emergency plans to cope with the situation of messages “bouncing”, due to a non-available system.

That is known as the “postman scenario”, as the abstraction of the services provided here are identical with what is delivered by a mail service company. When you want to send a parcel over to someone in another town, you may send your driver to deliver it there. When the recipient is not available to take the parcel, your driver needs to apply some other strategy for delivery.

• He can take the parcel back, and drive over the next day, hoping that someone will be available to take it then.

This will cost him twice the time and fuel.

• He can try to leave it in front of the door, hoping that nobody will steal it.

Here he saves money and time, but delivery is not guaranteed.

• He can keep it in his car, for another time when he eventually is in the recipient’s area.

Here the delivery might be guaranteed, but delayed indefinitely.

• He can find a trusted friend in the town, to whom he hands over the parcel to try delivering again and again in regular intervals.

This allows guaranteed delivery, but you need to have the infrastructure (the friend) there.

These examples demonstrate some of the problems that need to be handled in a standard operating procedure when sending messages to an external recipient. They can be implemented individually, by everyone, or you can ask a central institution (like the post office) to provide all this as a service. So that is what middleware is all about: it is an electronic post office that intelligently and routinely handles message exchange.

A classic situation, where messages get lost easily, is in the simple sending of an HTTP or SMTP message. Of course, there will be a notification like the HTTP 404 message, but in most cases the sender will simply be incapable of handling it. With SMTP, it is even worse, as here the “mail not delivered notification” will only arrive asynchronously. This makes it even more difficult to associate the error message with the sent message, especially when one takes into account that the reply format may simply depend on the sender’s discretion.

Serialization Issues A classic scenario is the exchange of IDocs between two SAP systems via RFC. If the receiving system is down, SAP (fortunately) has a mechanism to cope with this situation. All messages will be queued in the system and can be viewed in transaction SM58, as long as they are not successfully delivered. SM58 also allows releasing of the blocked RFC calls. This solution is a simple workaround, but it has its drawbacks. First, SM58 does not automatically retry sending. Second, if messages are queued in SM58 and the receiving system comes up again, newer messages might easily overtake the blocked ones, causing serious problems (if sequencing is important).

SAP also has a serialization mechanism, but this one simply guarantees that received IDocs are processed in order. It does not account for lost messages, because it has no general mechanism to check for the presence of the immediate predecessor.


www.SAPtips.com



Batch Job Orchestration Latency can also have a big impact on batch jobs. Picture the scenario where certain batch jobs may need to run AFTER IDocs have been processed. Any delay in getting the IDocs into SAP will therefore have detrimental effects on the job run, and will result in inaccurate results and inconsistencies. This means that the middleware needs to orchestrate the launch of the batch run as well.

There are many EDI converters that do not even have a mechanism to control the delivery of messages, and react accordingly. When several senders get implemented in your organization, every such sender would have to implement its own delivery control (which also requires thorough testing), a convenient monitoring dashboard, serialization checks, etc. These “integration silos”, and the associated effort needed to construct and maintain them, is any integration architect’s worst nightmare, and will eventually bring a company to its knees.

Monitoring and Redundant Task Drivers Probably the most expensive driver in an enterprise’s IT landscape is the development of algorithms, over and over again, on different platforms. Such common tasks include:

• Monitoring the flow of the messages:

We will discuss in more detail later, along with the dashboards, but it is evident that it would make more sense to have one central dashboard to monitor and control the flow of messages, instead of having one cockpit, developed for each individual ERP system.

• Finding the receiver of a message from its content:

If someone sends a sales order from an external source, it is the duty of the middleware to know which ERP system is the dedicated receiver. This usually means to look inside the message to find out important infrastructure information such as plant, sales organization, or company code that may help in determining which ERP system is the final receiver.

• Finding the recipient of a message from the recipient’s role designator:

Imagine a message is sent to the purchasing department. The queue should be the central place to tell which procurement manager is on duty today, taking care of recurring events like holidays, sick leave, and restructuring of departments.

• Sending alerts when messages fail:

The alert should be sensitive to the severity of the incident. Such an alert could be a simple message to the processing manager, up to sending an SMS message to the mobile phone of the IT administrator on duty.

The list of such common tasks can be probably extended to infinity. It is quite obvious that writing the software once, for all participants, reduces complexity and development costs dramatically. And it is not only the writing of the software that costs a lot, but also the maintenance and changing of it, including guaranteeing proper quality.

2.3 Cockpit and Dashboards We note a slight difference between a dashboard and a cockpit, although both terms are commonly used interchangeably. A dashboard, in our understanding, is a display and visualization tool only, while a cockpit is a dashboard that also incorporates the instruments to control the current machinery. So to compare it with an automobile, the dashboard is comparable to the instruments dashboard, while the cockpit is the dashboard, plus the pedals and armatures (light switches, choke, radio control, etc.).


www.SAPtips.com



Business Dashboards Managers aren’t interested in the technical details of how the systems are integrated in the backend; they just want to see results! That is where the business dashboards come into play. Dashboards are generally software tools that allow viewing, and visually embellishing consolidated and aggregated data in a central location. Graphical enhancements play an important role, and the basic purpose is to get a real-time view of the current operation of the whole enterprise, like a car’s dashboard displays the current parameters, such as speed and RPMs.

So what is a “business cockpit”? Well, a business cockpit basically provides managers with a set of “instruments and measures” that allow them to better gauge business-critical performance for the journey ahead. From a management point of view, the “business cockpit” should be able to:

1. Control and manage ongoing business operations

2. Allow them to respond quickly to business events as they occur

3. Give them the “big picture” as to how the business is running, at any particular point in time

4. Give them real-time analysis, so that they can see which processes are creating bottlenecks, etc. They may also want to drill-down into a single entity, to understand the complete status of its components.

Companies are, indeed, being forced to improve their monitoring of business processes and increase end-to-end business visibility. As mentioned in the previous section, the majority of EAI vendors out there state that their products provide great “monitoring and management” capabilities.

This all sounds great, but reality is yet far behind the theory. What these products are (more often than not) giving you is great “technical monitoring”, but not good “business process monitoring”. They’ll throw “buzz words” like “Business Activity Monitoring (BAM)” at you, but it’s not the “green light/red light” screens that you really want to see from a business point of view. It is important to realize that, in order to lower potential risk and optimize business processes, achieving “business visibility” means achieving good transaction monitoring. The problem with transaction monitoring is that transactions/messages often flow across multiple computing environments before completing the “transaction”. How do you get a “holistic view” across the entire business process that may span multiple software products and platforms? Figure 6 shows the minimum elements that a business cockpit should provide.


www.SAPtips.com



Figure 3: Example of a Business Monitoring Dashboard


www.SAPtips.com



The bottom line is that managers are interested in what business benefits and ROI an integration solution can provide. Although these are usually difficult to calculate and quantify, typical “EAI business requirements” can be rounded up as follows:

• Quick turnaround time in mapping and implementing new business scenarios

• Monitoring/Dashboard capabilities that give an end-to-end view of business processes

• Streamline the effort needed to set up communication with a business partner

• Simplify the integration landscape

• “Strategic platform” from which a company can satisfy all its current and future integration requirements

Technical Monitoring and Control Cockpits Most cockpits are loaded with gauges, meters, auto-refresh, and colorful designs that provide a helpful view of the business very similar to that provided by business dashboards. While this is also good for marketing technical monitoring tools, this is not the essence of a cockpit. Gauges are nice gimmicks, but to be honest, do they help? A good dashboard is a visual entry point into a combination of knowledge base and control panel, spanning across systems. The important features in a cockpit are the buttons and steering controls that allow driving the full equipment from a single location. It is not the dashboard, (the display of the instruments) that makes a good car. It is the gas, break pedals and the light switches that are the most important instruments in a car.

The cockpit needs to allow reprocessing of a message from any state, in a “de facto” debug mode (we call it in “slow motion”), while it displays the effects of the step-like input and output containers, sender and receiver paths (plus the possible alternatives), and a listing of all possible error events with a link into the knowledge base (that hints about causes and overcoming the failure).

The cockpit should provide a nice side-by-side display of the message, before and after transformation. The knowledge base should display recipes (Standard Operation Proc, SOP) on how to react when the message fails at this point, listing the common causes and consequences. If you get a message like “Error 51: could not determine sales org”, the cockpit should link you directly to a relevant entry in the knowledge base and, ideally, provide access to a search engine for you to search for solutions in general.

Figure 4 depicts the “technical monitoring” provided by Seeburger Business Integration Server (BIS).


www.SAPtips.com



Figure 4: Technical Monitoring Cockpit (from Seeburger BIS) The technical monitoring capabilities provided by Seeburger BIS are great, but we need another “business process monitor” that not only displays an “airplane type cockpit” with flashing lights, etc, but also one that allows an administrator to type in commands to query the systems in the landscape and get an appropriate and timely response

Monitoring in SAP XI and WebAS SAP XI uses the monitoring components of the SAP Web AS. These include the Process Monitoring Infrastructure (PMI), the Alert Framework, and the Computer Center Management System (CCMS). These allow you to have component, message, and performance monitoring. This still does not, however, provide the needed “cockpit” required by business users.

Regarding business activity monitoring, SAP’s strategy is leaning towards using the SEM and BW components instead. If they are properly orchestrated by an XI scenario, they can provide a de facto, real-time view on selected business activities and data aggregates. So, it is possible with the current toolset provided by SAP, but elegance would not be an attribute of it.

3 Terminology

Fighting Babylonian Cacophony EAI projects are communication projects. This means communication between computers, but also between people and between organizations. But there is still no commonly known and understood language and terminology. This is what makes EAI projects so delicate. Many


www.SAPtips.com



expressions go around without a clear understanding, and many terms are coined every day, just to disappear a few weeks later.

This Babylonia of terminology is a fate shared by every complex project (and which project isn’t complex?). The path to overcome it is just as old as science: be clear on terminology before starting a design. So we will abide by this virtue and start to sort the most common expressions used.

Message Oriented Middleware For computers to communicate with each other, the developer of the programs has to know about the protocol and the peculiarities of the communication partner. This leads to a simple estimate: if you have four software components that communicate, you have to maintain twelve (four times three; formula: n * (n-1)) communication channels. This can be avoided if every program communicates via an interpreter program, commonly called middleware. This middleware exposes an interface for every participating program, and reroutes the data to its final receiver. Hence, middleware allows every program to communicate in its native language only, and the hassle of protocol conversion is delegated entirely to the single software component, the middleware.

Middleware can do more than this. It can provide public services that are needed by all participating software, such as sending out information mail, watching over secure delivery, encrypting data sent over a channel, and more generalized triggering and monitoring of other workflow activity.

Communication between disparate systems is done through messages. Message-based communication is the opposite of imperative communication. The latter would have to know exactly the execution plan to trigger a certain action on the remote computer, while a message-driven communication puts the decision on the execution plan where it would naturally belong; the computer then executes the service. In addition to that, the executing computer can also decide whether to execute a command or not, and it can monitor the execution of every command, because monitoring is not done within the called service, but by the requester. Sophisticated, but very important tasks, are the mediation between the systems. This might include conflicts in locking data components or concurrent updates.

But all the theory about communication, messaging, message flow, and harmonizing the protocols is void unless there is something on the terminal points of a communication channel that performs a meaningful and useful action. The problem is, of course, not a lack of useful functionality of the participating software, but that this functionality is not easily (or not at all) accessible from an external requester. The software needs to expose its functionality as a public service. We need a “service oriented” architecture.

SOA - Service Oriented Architecture A SOA requires every participating software component within a network to expose its business functionality in a way that allows any action of a business process to be automated, and initiated from an external requester. SOA is also known as ESA - Enterprise Services Architecture.

The idea behind SOA is to break down the business functionality modeled in an ERP system to atomic entities that can be executed from anywhere.

What is the motivation? The purpose of an ERP system is to model certain business activities, like creating or changing a sales order, a delivery, some master data, etc. Traditionally those activities are proprietary tasks of the individual software. Think of the ways to create a sales order in SAP R/3. Before the introduction of BAPIs, you could help yourself by simulating the manual data entry via a screen through a batch input mechanism. Although this is a smart solution, it has its limitations.


www.SAPtips.com



Thinking of the SAP sales order transaction VA01, you may think of atomic activities like creating a header, sales items, delivery schedules, price items, variant configuration settings, etc. The idea is now to create small, mini transactions that allow changing those atomic entities, of course, with the possibilities to allow a proper rollback of those actions.

Such atomic entities are called “services”, and an ERP architecture that consequently implements a complete set of services for a business model is called an SOA.

The Web service architecture is quite simple actually; instead of the traditional 3-tier architecture, we now add in a 4th tier – the “Service Tier”. This is depicted in the diagram in Figure 5.

Figure 5: Four-tier Architecture of a Web Service Architecture Let’s take a quick look at a simple scenario of a client asking a “Loan Application Service” to determine whether a specific customer is “loan-worthy” or not.

Behind the scenes the “Loan Application Service” (written in .NET) accesses a “Credit Rating Service” (written in ABAP), to determine the client’s credit rating. Let’s take a look:


www.SAPtips.com



FUNCTION z_credit_rating.

*"---------------------------------------------

*"*"Local interface:

*" IMPORTING

*" REFERENCE(CUSTNO) TYPE STRING

*" EXPORTING

*" REFERENCE(CREDIT_OK) TYPE CHAR01

*"---------------------------------------------

DATA: profile TYPE REF TO zcl_credit_profile.

CREATE OBJECT profile

EXPORTING customer_number = custno.

CALL METHOD profile->check_credit_rating

IMPORTING

credit_ok = credit_ok.

ENDFUNCTION.

namespace LoanApplication {

public class LoanApplicationService :

System.Web.Services {

public LoanApplicationService {

Initialize( ) ;

}

[WebMethod]

public boolean ApplyForLoan (string custno) {

Loan l = new Loan ( );

return l.ApplyForLoan (new Client (custno));

}

}

}

Figure 6: A Simple Web Service Scenario

So we can immediately see that one of the big bonuses of using Web services is that you don’t need to worry about the implementation of the underlying service code. For all we know, any one orchestrated Web service scenario could involve languages like Java, C#, ABAP (and possibly many more). This allows you to utilize your current resources to their full potential, without having to necessarily re-skill in any particular area.


www.SAPtips.com



Although an SOA already defines an orderly way to produce open and collaborative systems, the degree of freedom to implement such architecture in reality is infinite. Just think of the possibilities to define a communication protocol to exchange the data between systems; imagine one being SAP R/3 and the other one Oracle or Microsoft EXCEL. To overcome these ambiguities, there are activities that define a common set of protocol standards for the communication between services. One such activity that builds ontology for Business Process Modeling is the open source movements around WSDL (Web Service Description Language) and BPML (Business Process Modeling Language BPMI.org).

To summarize, SOA is an architecture that exposes business functionality to external requesters. The Enterprise Service Architecture (ESA), SOA, and ESB are all pretty much aiming for the same goal. That goal is to deliver messages between systems, which in turn will provide for business services they can execute in a certain sequence and manner.

ESB-Enterprise Service Bus An ESB forms the backbone of an event-driven, highly-distributed enterprise. It provides the necessary fabric that connects a large number of applications under one “EAI umbrella”. The loosely coupled nature of the ESB promotes agility in the enterprise and allows IT staff to spend more time on the real business issues, rather than “hard-wiring” numerous applications together.

There are two different technologies to implement service architecture:

• Central orchestration

• Bus arbitration

There are star-like and bus-like network architectures. The central message queue architecture requires that all messages be sent to a central message hub (“the message queue”), that then decides how the message is routed and processed. Such central architecture allows monitoring and filtering every activity within the SOA. Typical representatives of such a star-like architecture are SAP XI or IBM Websphere/MQ.

A bus-like architecture follows a more democratic philosophy. Messages are all put on a commuting belt, the bus that is connected to every computer. A service running on one of those computers can now decide whether it is interested in processing the message. That does not discriminate the advantages of a central message hub: one of the services attached to the bus will be the traditional message queue arbiter that monitors and mediates all messages, and delivers messages to computers that do not have their own service monitor to pick messages from the bus.

In practical terms, the main difference between central and bus architecture is that the bus architecture implements a publicly available message repository that can be accessed by any participating software (of the whole service orchestra). An integration broker tends to be more or less “specialized”, while an ESB provides a more generalized, standard-based infrastructure. A product like SAP XI is more suited to an “individual project”, where the high cost can be justified by its support for vertical industry processes. An ESB, on the other hand, provides a moderately “cheap”, open infrastructure that ensures compliance to any number of different environments and technologies. In a more narrow meaning, the ESB is associated by the technology proposed by Sonic Software, who coined the expression initially.

All Web service work follows the same two-step process: first you publish, and then you orchestrate. Publishing a Web service means taking an existing system and exposing it as a service. Orchestrating is when you compose multiple Web services into an end-to-end process flow. The industry standard BPEL (Business Process Execution Language) provides the glue that coordinates the execution of a Web service process flow.

C



WSDL – Web Service Description Language This is an XML-based formal language that describes the syntax of an interface exposed by a specific Web service. It tells the caller what the technical name of the service is, what parameters are available, and how they are defined. A WSDL delivers a template for the XML document that is acceptable for calling the service, and defines the setup of the subsequent action that handles the received request.

UDDI – Universal Discovery, Description, and Integration When a software producer finally produces an excellent business service and creates a WSDL for it, it is of no worth at all, if this information does not reach a potential consumer. It is like if you produced the best bicycle wheels in the world but nobody could find your shop. In that case, you might advertise in the yellow pages, so the rest of the world would know that you are selling bicycle wheels. And this is just what UDDI is about. It is a universal directory, just like the yellow pages for businesses, that lists all publicly accessible Web services, along with their proper WSDL.

BPML - Business Process Modeling Language The BPML is an approach to describe business processes by means of a harmonized XML syntax. The BPML is used to catalog each business process and its associated Web service. Every business process in BPML implements Web services through “request” activities and corresponding “response” activities.

F

BBsocttos

SWsp

<?xml version="1.0" ?>

- <bpml:package targetNamespace="http://www.bpmi.org/2002/BPML/instance" xmlns:bpml="http://www.bpmi.org/2002/BPML/process" xmlns:inst="http://www.bpmi.org/2002/BPML/instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<bpml:property name="branch" type="xsd:positiveInteger" />

<bpml:property name="current" type="xsd:anyType" />

<bpml:property name="endTime" type="xsd:dateTime" fixed="true" />

<bpml:property name="fault" type="xsd:QName" fixed="true" />

<bpml:property name="identifier" type="inst:instance" fixed="true" />

<bpml:property name="iteration" type="xsd:positiveInteger" />

opyright © 2005 by Klee Associates, Inc. www.SAPtips.com

igure 7: Example of a BPML Document

PEL – Business Process Execution Language PEL stands for “Business Process Execution Language”. This language was created to tandardize the integration logic and process automation between Web services. BPEL uses ther Web service standards (e.g., WSDL and SOAP) for interface description and ommunication. BPEL describes both the inbound and outbound process interfaces in WSDL, so hat they can easily integrate into other processes or applications. This has the added advantage hat the consumer of a process is able to “inspect” and “invoke” the BPEL process, just like any ther Web service. It is also important to note that BPEL allows processes to interact ynchronously and asynchronously.

o why do we want to orchestrate Web services? Well, the answer to that is quite simply that eb services are rapidly being adopted as a common integration fabric, and this means that

ervices, both internal and external to a company, can easily be incorporated into one, seamless rocess. This opens up great potential for very “innovative” and flexible business processes and

http://xml.coverpages.org/BPML-2002-instance-bpml.txt


www.SAPtips.com



opportunities. Furthermore, the loose coupling and “run-time discovery” of Web services has allowed us to move one step closer to true real-time business process modeling and execution. This is a great improvement over the somewhat “brittle” solutions used by some proprietary EAI solutions in the past.

EDI - Electronic Data Exchange EDI refers to exchanging electronic documents across company boundaries. The idea behind it is simple. The sender creates a document in a format that can be received by the computer in a foreign company, and processed automatically there. It is not the dream of the real-time enterprise that drove the EDI movement, but the prospect of the paper-free office. There are numerous standards around this concept; the best-known ones are EDIFACT, in Europe, and ANSI X.12, in North America.

EDI is often mistakenly understood as a synonym for the common EDI standard EDIFACT, which only defines the formats and requirements of a document for electronic data exchange. Those utterly academic and unnecessarily complicated formats defined by EDIFACT or ANSI.X12 contribute strongly to the negative reputation that builds the aura of EDI as being complicated, elusive, and consequently expensive.

EDI in SAP solutions is supported by Intermediate Documents (IDocs), which are standardized descriptions of the structure of a business document (such as an invoice or sales order). In the SAP world, a conversion is needed between these IDocs and corresponding EDI messages. For this reason, many EDI software vendors have become certified by SAP to provide mapping, status tracking, and conversion of IDocs into EDI standards.

Despite the numerous advantages of using EDI, it has its reverse side. Currently the use of EDI systems is restricted to large organizations due to its high implementation costs.

The Internet, with all its open standards (particularly XML), has given the smaller to medium sized companies the ability to use EDI as well. “Internet-EDI” uses Internet services to transport EDI messages. These would include, for example, protocols like HTTP, FTP, and SMTP. The use of open standards provides platform independence, which allows for a significant reduction in investment costs.

4 Getting a Feeling for the Technology For those who are more interested in the nuts and bolts that keep the machinery running, we shall discuss a bit deeper how the core standards of Web service orchestration actually work.

4.1 A Deeper View on WSDL In SAP Web AS, you can get the WSDL definition document for a service by calling: http://jupiter.winproxy:8080/sap/bc/soap/wsdl11?services=BAPI_BANK_GETDETAIL&sap-client=000

This example calls the WSDL for the BAPI BAPI_BANK_GETDETAIL. A list of all Web services implemented can be obtained by calling: http://jupiter.winproxy:8080/sap/bc/bsp/sap/WebServiceBrowser

Figure 8 gives an example of the SAP integrated Web service repository that allows retrieving the WSDL information for a Web service within Web AS. Figure 9 shows an example of a WSDL document for a Web service as returned from the SAP WSDL browser.

http://jupiter.winproxy:8080/sap/bc/soap/wsdl11?services=BAPI_BANK_GETDETAIL&sap-client=000



www.SAPtips.com



Figure 8: The SAP WebAS Web Service Browser The service is actually executed in SAP Web AS by sending the XML template that corresponds to this WSDL to the Web AS SOAP gateway that listens at the following URI: http://jupiter.winproxy:8080/sap/bc/soap/rfc


www.SAPtips.com



Figure 9: WSDL for the BAPI_BANK_GETDETAIL


www.SAPtips.com



The WSDL syntax appears confusing at first glance, but it is indeed well structured. There are basically five sections in the document:

1. <types> … </types>

2. <message> … </message>

3. <portType> … </portType>

4. <binding> … </binding>

5. <service> … </service>

The main trick in reading the document is to parse it backwards, from the bottom top.

- <service name="BAPI_BANK_GETDETAILService">

<documentation>SAP Service BAPI_BANK_GETDETAIL via SOAP</documentation>

- <port name="BAPI_BANK_GETDETAILPortType" binding="s0:BAPI_BANK_GETDETAILBinding">

<soap:address location="http://jupiter.winproxy:8080/sap/bc/soap/rfc" />

</port>

</service>

The service section tells us how the service is called and where we need to send the request. For the standard ABAP Web AS, the URL is always: http://jupiter.winproxy:8080/sap/bc/soap/rfc

+ <binding name="BAPI_BANK_GETDETAILBinding" type="s0:BAPI_BANK_GETDETAILPortType">

This tells us that the service is made from messages that are defined in a “port definition” called BAPI_BANK_GETDETAILPortType.

- <portType name="BAPI_BANK_GETDETAILPortType">

- <operation name="BAPI_BANK_GETDETAIL">

<input message="s0:BAPI_BANK_GETDETAILInput" />

<output message="s0:BAPI_BANK_GETDETAILOutput" />

</operation>

</portType>

The port type simply lists the messages that are to be exchanged for the service.







www.SAPtips.com



- <message name="BAPI_BANK_GETDETAILInput">

<part name="parameters" element="s0:BAPI_BANK_GETDETAIL" />

</message>

- <message name="BAPI_BANK_GETDETAILOutput">

<part name="parameters" element="s0:BAPI_BANK_GETDETAIL.Response" />

</message>

The messages are defined individually. A message can theoretically consist of many parts, but, in practice, there will be one inbound and one outbound message only. So it is the case with the BAPI call. For the sake of cleanliness and readability, the message section does not define the structure of the message, but references a type definition.

Figure 10 shows the reference for the input message: BAPI_BANK_GETDETAILInput points to a type definition BAPI_BANK_GETDETAIL while BAPI_BANK_GETDETAILOutput points to a type definition BAPI_BANK_GETDETAIL.Response. The URI of the SAP Web service, where we send the request document to, is actually a BSP extension. You can easily see what is behind it by browsing the SICF transaction and locating the specified URL. You’ll find that it actually executes the BSP extension class CL_HTTP_EXT_SOAPHANDLER_RFC.

Figure 10: Locating the SOAP Processor in Web AS ICF (Transaction SICF)

4.2 BPEL in a Nutshell Once you have created and deployed your Web services, what’s the next step? For many developers, it will entail orchestrating these services into composite applications and business processes. BPEL has emerged onto the scene and is providing developers and architects with the “glue” they require to get their services talking together in one seamless business process, while all the time helping maintain the focus towards a true service-oriented architecture.

For example, let’s say in your SAP environment you have some processes flowing among your SRM, R/3, and some other legacy CRM system. Now getting these processes somewhat “seamless” and “agile” can be quite a tricky task. This is especially true if you are locked into some propriety software that you need to dig deeply into, just to change some arbitrary logic




www.SAPtips.com



needed to alter a business process. The development, testing, and deployment effort required to change these applications often makes process changes and integration a very costly and complex exercise. Figure 11 depicts a “proprietary integration scenario” among three systems.

Figure 11: BPEL Flow Model

Many EAI and “Business Process Management” (BPM) tools extract this embedded process logic and process automation logic into a new layer of software tool. These products provide users with a new level of abstraction, which moves integration and process tasks away from the underlying applications, making these applications (and associated business processes) easier to change, manage, and optimize.

The following depicts how the BPEL engine (in a product like SAP XI, for example) could be used to seamlessly integrate and “choreograph” a set of services to streamline one or more business processes across multiple systems.

Figure 12: Workflow Driven by a BPEL Engine


www.SAPtips.com



But we are not only limited to applications that are internal to your organization. The mere fact that Web services are based on open technologies and standards allows you to easily integrate applications and services with your business partners, customers, and suppliers. The diagram in Figure 13 illustrates just this, and shows a business process that not only links internal applications, but also allows external communication with suppliers (and others) as well.

Figure 13: Web Services Orchestration through BPEL

Let us now move away from the diagrams and into a practical BPEL example. Figure 14 depicts a basic purchase order approval scenario.


www.SAPtips.com



Figure 14: Abstract Flow of a Message-Based Communication

In the above diagram, “Business A” sends “Business B” purchase order information and triggers an internal “order approval” BPEL process. The process performs the following tasks:

• A “credit check” Web service is called to ensure that the customer is “credit worthy”

• Should the customer be “credit worthy”, the process then calls a “check inventory” Web service to ensure that “Business B” can fulfill the customer’s request

From a technical perspective, we would like to have a basic tool that enables “Business B” to easily model and orchestrate the Web services needed in the “order approval” process. There are many products out there like Seeburger Business Integration Server (BIS) and SAP XI that have


www.SAPtips.com



great built-in BPEL support and enable developers and architects alike to orchestrate Web service scenarios in a simple way. Another great tool is “ActiveWebflow Professional” by 1Active Endpoints, Inc. This Eclipse based product provides great “drag & drop” functionality that allows complex business process scenarios to be developed, simulated, and deployed very quickly. Figure 15 shows a very scaled down view of what “Business B’s” BPEL process would typically look like (developed in “ActiveWebflow Professional”).

Figure15: “Order Approval” BPEL Process Developed in “ActiveWebflow Professional”

1 "Active Endpoints is the leading independent provider of BPEL solutions for ISVs, IT organizations, and service providers. Their market-proven products deliver unrivaled platform breadth and the most flexible, open architecture available today.www.active-endpoints.com "

http://www.active-endpoints.com/


www.SAPtips.com



The above BPEL process consists of a number of files that includes the following:

• A WSDL file that describes business operations that are invoked to carry out the activities of the BPEL process (e.g., SOAP bindings to Web services, etc)

• A BPEL file that describes a series of process flows, partner links, and their interactions, etc.

• A PDD file (“deployment descriptor”) that describes the relationship between the partner links defined in the BPEL file and the implementation required to interact with actual partner endpoints

• A BPR file (“business process archive”) is required in order to deploy the BPEL process to a server (e.g., Tomcat)

The following piece of code is the BPEL code generated by “ActiveWebflow Professional” when orchestrating the above “order approval” Web service scenario. It may look complex at first, but this XML based syntax soon becomes very easy to follow and understand.

www.SAPtips.com



<?xml version="1.0" encoding="UTF-8"?>



<process name="order_approval_process" suppressJoinFailure="yes" targetNamespace="http://order_approval_process" xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:ns1="http://orderapproval.org/wsdl/orderapproval" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<partnerLinks>

<partnerLink myRole="orderApprovalService" name="orderApprovalServiceLinkType" partnerLinkType="ns1:orderApprovalServiceLinkType"/>

<partnerLink name="creditCheckServiceLinkType" partnerLinkType="ns1:creditCheckServiceLinkType" partnerRole="creditCheckService"/>

<partnerLink name="inventoryCheckServiceLinkType" partnerLinkType="ns1:inventoryCheckServiceLinkType" partnerRole="inventoryCheckService"/>

</partnerLinks>

<variables>

<variable messageType="ns1:orderApprovalRequestMessage" name="orderApprovalRequestMessage"/>

<variable messageType="ns1:responseMessage" name="responseMessage"/>

<variable messageType="ns1:customerMessage" name="customerMessage"/>

<variable messageType="ns1:inventoryMessage" name="inventoryMessage"/>

</variables>

<flow>

<links>

<link name="receive-to-assign"/>

<link name="check-credit-to-failure"/>

<link name="check-credit-to-success"/>

<link name="check-inventory-to-reply"/>

<link name="assign-to-check-credit"/>

</links>

<receive createInstance="yes" name="ReceiveOrder" operation="request" partnerLink="orderApprovalServiceLinkType" portType="ns1:orderApprovalServicePT" variable="orderApprovalRequestMessage">

<source linkName="receive-to-assign"/>

</receive>

<reply name="OrderApprovalResponse" operation="request" partnerLink="orderApprovalServiceLinkType" portType="ns1:orderApprovalServicePT" variable="responseMessage">

<target linkName="check-credit-to-failure"/>

<target linkName="check-inventory-to-reply"/>

</reply>


www.SAPtips.com



<invoke inputVariable="customerMessage" name="CheckCustomerCreditRating" operation="getCreditRating" outputVariable="responseMessage" partnerLink="creditCheckServiceLinkType" portType="ns1:creditCheckServicePT">

<target linkName="assign-to-check-credit"/>

<source linkName="check-credit-to-failure" transitionCondition="bpws:getVariableData('responseMessage', 'response') != 'good'"/>

<source linkName="check-credit-to-success"/>

</invoke>

<invoke inputVariable="inventoryMessage" name="CheckInventory" operation="checkInventory" outputVariable="responseMessage" partnerLink="inventoryCheckServiceLinkType" portType="ns1:inventoryCheckServicePT">

<target linkName="check-credit-to-success"/>

<source linkName="check-inventory-to-reply"/>

</invoke>

<assign name="AssignVariables">

<target linkName="receive-to-assign"/>

<source linkName="assign-to-check-credit"/>

<copy>

<from part="customerNo" variable="orderApprovalRequestMessage"/>

<to part="customerNo" variable="customerMessage"/>

</copy>

<copy>

<from part="materialNo" variable="orderApprovalRequestMessage"/>

<to part="materialNo" variable="inventoryMessage"/>

</copy>

<copy>

<from part="qty" variable="orderApprovalRequestMessage"/>

<to part="qty" variable="inventoryMessage"/>

</copy>

</assign>

</flow>

</process>

Calling a BPEL process like the one described above is very easy. As a basic example, the following piece of Java code triggers the deployed “order approval” BPEL process, passing it the three required fields (“customer no”, “material no”, “qty”), and returns a result to the console.


www.SAPtips.com



import javax.xml.rpc.ParameterMode;

public class OrderApprovalServiceTestClient {

public static void main(String[] args) {

String result = null;

Service service = new Service();

Call call = (Call)service.createCall();

String urlString = "http://jupiter:8080/active-bpel/services/orderApprovalService";

call.setTargetEndpointAddress(new java.net.URL(urlString));

call.setOperationName("request");

call.addParameter("customerNo", org.apache.axis.Constants.XSD_STRING, ParameterMode.IN);

call.addParameter("materialNo", org.apache.axis.Constants.XSD_STRING, ParameterMode.IN);

call.addParameter("qty", org.apache.axis.Constants.XSD_INTEGER, ParameterMode.IN);

call.setReturnType(org.apache.axis.Constants.XSD_STRING); try {

result = (String)call.invoke(new Object[]{"CUST_1", "MATNR_1", new Integer("8")});

}catch (Exception e) {

result = "unexpected exception seen: " + e.toString();

}

System.out.println(result);

}

In practical terms, such a BPEL execution plan would define sequences like those outlined in the this list (as well as depicted in Figure 16):


www.SAPtips.com



1. The BPEL process reads some data from a start service.

2. The data is converted into an XML document according the WSDL of the next request.

3. The received data is converted into some internal format.

4. Steps 2-3 may be repeated until all steps are done.

Figure 16: A Basic Flow Orchestrated by BPEL The point is that the master systems interpret a BPEL flow sequence and call the services appropriately, while converting the data received (and sent) from and to external partners.


www.SAPtips.com



Conclusion to Part I By now, you should have a good idea of what EAI is really all about, as well as what potential and innovative integration scenarios are possible for the future. We learned that there are architectural strategies, like SOA and ESB, and new upcoming standards like WSDL, BPML, and BPEL, to allow a practical implementation of such a standard. The very essence of the modern Service Oriented Enterprise (and its related techniques) lies in the openness of the participating systems, which is tightly related to its compliance to standards.

NetWeaver is following this path, although it is still in its infancy. In Part II of our series, we shall check how far SAP is along this path in comparison with direct competitors, taking into account all the new standards and design perspectives. We will review what the critical issues really are within a mature Enterprise Integration Architecture. So in Part II, we shall focus on providing readers with practical questions and aspects to consider when sitting down and trying to decide on an EAI solution that will support their SAP environment now, and into the future.

Axel Angeli, logosworld.com. Axel is a senior SAP and EAI advisor and principal of logosworld.com, a German-based enterprise specializing in coaching SAP and EAI project teams and advising IT management on implementation issues. Axel has been in the IT business since 1984, and throughout his career, he has always worked with cutting edge technologies. Axel's SAP experience stems from the good old R/2 days, and he is an expert on SAP’s NetWeaver technology and any kind of ABAP development. A speaker of several languages, Axel specializes in coaching and leading large multi-national teams on complex projects with heterogeneous platforms and international rollouts. Known for his intensive and successful trouble-shooting experience, Axel has been nicknamed by his colleagues as the “Red Adair” of SAP projects. He is the author of the best-selling tutorial “The SAP R/3 Guide to EDI, IDocs, ALE and Interfaces.” Lynton Grice is an application developer contracted to one of the big automotive companies in South Africa. He has a passion for programming and new technologies and takes care of SAP Portal development as well as other SAP EAI requirements. Coming from a typical Java school, he is now just as familiar with ABAP. Lynton’s email address is [email protected]

The information in our publications and on our Website is the copyrighted work of Klee Associates, Inc. and is owned by Klee Associates, Inc. NO WARRANTY: This documentation is delivered as is, and Klee Associates, Inc. makes no warranty as to its accuracy or use. Any use of this documentation is at the risk of the user. Although we make every good faith effort to ensure accuracy, this document may include technical or other inaccuracies or typographical errors. Klee Associates, Inc. reserves the right to make changes without prior notice. NO AFFILIATION: Klee Associates, Inc. and this publication are not affiliated with or endorsed by SAP AG. SAP AG software referenced on this site is furnished under license agreements between SAP AG and its customers and can be used only within the terms of such agreements. SAP AG and mySAP are registered trademarks of SAP AG. All other company and product names used herein may be trademarks or registered trademarks of their respective owners.