Lustratus Research Limited St David’s. 5 Elsfield Way, Oxford OX2 8EW, UK Tel: +44 (0)1865 559040 www.lustratusresearch.com

paper

SAP’s Approach to SOA-based Process Integration

white

Table of Contents

I. Executive summary 3

II. Introduction 4

i. SOA platform requirements 4

ii. Business process support 4

III. Overview of SAP’s SOA and process integration offerings 5

i. Current offerings 5

ii. SOA and process integration use cases 6

IV. Review of product capabilities 6

i. Basic requirements—SOA platform support 6

Ii. Basic requirements—Business process support 8

Iii. Basic requirements—Development tools 10

iv. Value-add considerations 11

V. Assessing SAP NetWeaver’s process integration capabilities 14

i. Assessment of basic support for SOA and process integration 14

Ii. Value-add differentiators 15

VI. 16 Summary

About Lustratus Research Lustratus Research Limited, founded in 2006, aims to deliver independent and unbiased analysis of global software technology trends for senior IT and business unit manage-ment, shedding light on the latest developments and best practices and interpreting them into business value and impact. Lustratus analysts include some of the top thought leaders in market segments such as service-oriented architecture (SOA) and business integration.

Lustratus offers a unique structure of materials, consisting of three categories—Insights, Reports and Research. The Insight offers concise analysis and opinion, while the Report offers more comprehensive breadth and depth. Research documents provide the results of practical investigations and experiences. Lustratus prides itself on bringing the techni-cal and business aspects of technology and best practices together, in order to clearly address the business impacts. Each Lustratus document is graded based on its techni-cal or business orientation, as a guide to readers.

Terms and Conditions © 2007—Lustratus Research Ltd.

Customers who have purchased this report individually or as part of a general access agreement, can freely copy and print this document for their internal use. Customers can also excerpt material from this document provided that they label the document as Pro-prietary and Confidential and add the following notice in the document: “Copyright © 2006 Lustratus Research. Used with the permission of the copyright holder”. Additional reproduction of this publication in any form without prior written permission is forbidden. For information on reproduction rights and allowed usage, email info@LustratusResearch.com.

While the information is based on best available resources, Lustratus Research Ltd dis-claims all warranties as to the accuracy, completeness or adequacy of such information. Lustratus Research Ltd shall have no liability for errors, omissions or in adequacies in the information contained herein or for interpretations thereof. Opinions reflect judgment at the time and are subject to change. All trademarks appearing in this report are trade-marks of their respective owners.

2

Executive summary For a number of years now, SAP has been building integration functionality into its suite of offerings through its SAP NetWeaver product line. The SAP Exchange Infrastructure (XI) product was the main focus for this activity. In 2005, however, SAP updated its offer-ings and brought all this functionality into NetWeaver, delivering one codebase that is capable of sustaining a range of functional capabilities, or usage types in SAP terms. A key usage type supported by NetWeaver is Process Integration.

SAP’s integration approach is designed with a number of key objectives in mind: • Deliver the full range of integration options within a single platform • Embrace and adopt industry standards wherever possible • Place a particular focus on providing added value for SAP application users

So, SAP NetWeaver supports application to application (A2A), business to business (B2B), process-based, consumer-based and service-oriented (SOA) integration models. Integration is all XML-based, with support for standards such as WSDL, UDDI, BPEL and JCA. And for users of the SAP suite of applications, there are a range of powerful options to speed up integration efforts and improve productivity, such as the provision of a library of process templates that can be used and customised as required rather than having to be built from scratch.

The SAP NetWeaver software is designed to be robust and scalable, offering an integra-tion solution for both SAP and non-SAP users that provides an ideal base for service-oriented architecture (SOA) projects and initiatives. The following table provides a quick summary of the strengths of the SOA and process integration capabilities offered by SAP NetWeaver, and the remaining challenges it faces.

Figure 1:- Summary of SAP NetWeaver strengths/challenges in the

area of SOA and process integration

Strengths Challenges

Enterprise Services Repository ♦ Breadth of information

♦ Design, configuration and runtime usage

Support for program-centric and human-related processes High-end support ♦ Powerful mapping option

♦ HA support

♦ Load balancing

♦ Different qualities of service

♦ End-to-end monitoring

Support for SAP-centric users ♦ Ready-to-run, customisable process templates Extensive B2B support Open, JCA-based adapter frame-work SAP Developer Network Market exposure and uptake

Limited range of fully integrated adapters Lack of a JMS-based integration backbone option Different tools for program-centric and human related processes Lack of integration to enterprise management frameworks Limited BAM functionality

3

SOA benefits Using SOA transforms IT assets into reusable, business-oriented components. This results in a range of business benefits. New projects can be developed more quickly, productively and relia-bly because of the higher level of reuse. IT systems become more closely aligned to busi-ness activities, enhancing op-erational visibility and improving business effectiveness. In short, businesses become more agile and efficient, with minimal busi-ness risk.

Process integration benefits Providing a visual linkage between business processes and the underlying IT compo-nents enables companies to rapidly automate and stream-line processes, building, changing and integrating them as required. The process integration technology makes this possible without the need for extensive coding, deliver-ing operational IT systems that can support an agile, flexible and adaptable busi-ness.

Introduction The purpose of this paper is to assess SAP’s current strategy and offerings for providing a service-oriented architecture (SOA) based platform for process integration. There are two distinct areas included in this assessment – the support for the service-oriented approach to component architecture, and process support to enable business process integration to be managed effectively. These areas will be assessed in terms of provision of basic functional requirements and value-add areas of potential differentiation.

SOA platform requirements In order to make the assessment, it is necessary to set the functional baselines against which the SAP offerings can be measured. On the SOA side, there is a range of function-ality that most people have come to expect of an SOA platform. The diagram below summarises the major functional categories.

Figure 2:- Generic components found in an SOA platform

The Registry is a repository for information about available services, such as functionality, location and invocation rules. The communications pipe is augmented by gateways and adapters to hook into specific source and target technologies, applications and environ-ments. Mediation services allow information to be transformed and enriched as it passes between components and services, and provide for the flow to be controlled and dy-namically modified based on business policies and rules. Development tools fall into two categories: those that support the SOA infrastructure itself, and those designed to help with the creation and deployment of the business services. Finally, the operational tools deal with management and governance needs such as controlling security, monitoring performance and resolving problems.

Apart from these functional areas, the SOA platform is also expected to support at least the key standards. In SOA terms these are:- • XML • Web Services • BPEL (for orchestration)

Business process support Service-oriented architecture makes individual pieces of business functionality available as reusable, loosely-coupled services. This makes SOA the ideal underpinning technol-ogy for business process integration and management. Processes consist of process steps, and these process steps can be represented by individual SOA services or or-chestrated combinations of them. Combining business process support with SOA yields an environment where processes can be defined and changed quickly, easily and effec-

Gateways and Adapters

Communications

SOA PlatformSOA Platform

BPM BAMApplications Management Portals

Business ServicesCustom PackagedExternal

TransformationOrchestrationAuditEnrichment

Operational Tools

Governance

Security

Management

Source:- Lustratuswww.LustratusResearch.com

Mediation services

Registry

DevelopmentTools

SOA Definitions & Deployment

Services Creation &

Deployment

4

What is SOA? SOA stands for service-oriented architecture, where IT programs and resources are encapsulated and made avail-able as business services, each enacting a discrete busi-ness function such as ‘Get Customer Details’. The ser-vices can then be used and reused as building blocks, assembled together into other business functions and proc-esses as required.

tively, without the need to make sweeping technical code changes.

There are a number of functions required for this business process support. These are • Process modeling and implementation • Process execution, supporting both program-to-program and human-oriented

activities • Process analysis These areas encompass both functionality and tools. The modeling refers to the ability to develop process flows graphically through flowcharts, and to assess the impact of the modeled behavior. Then the process flows need to be implemented and deployed for run-time execution. Flows are dynamically controlled, to enable business policies and rules to govern their execution, and finally some level of statistical reporting will be ex-pected to enable performance to be assessed.

Overview of SAP’s SOA and process integration offerings SAP has been providing an increasing level of support for integration needs over the past few years. The current offering, which is the main focus of this assessment, is SAP Net-Weaver, and in particular its Process Integration capability or ‘usage type’.

Current offerings SAP’s functionality to support SOA and process-based integration is part of its Net-Weaver family of offerings. NetWeaver 2004s, the latest version, implements a specific usage type for process integration. This is an upgraded combination of the old integra-tion offering, SAP NetWeaver Exchange Infrastructure (XI), together with the NetWeaver application server component. The diagram below shows the main functional compo-nents of NetWeaver involved in the process integration usage type.

Figure 3:- Components involved in the SAP NetWeaver process inte-

gration usage type

The Message Broker provides the basic integration infrastructure, while the Business Process Modeling and Management components handle business process needs, aug-mented by the Business Task Management component providing collaboration and hu-man-based workflow support. The Adapter Engine handles connectivity to a range of packaged and home-grown applications and technologies. The NetWeaver Partner Con-nectivity Kit (PCK) offers another environment for adapter execution, providing a light-weight, small-footprint version of the NetWeaver environment to act as an on-ramp to the wider NetWeaver implementation.

© SAP AG 2006, 2006 Friday Webinar Series/ 1

NetWeaver Process Integration (PI) Components

Suppliers

Business Partners

Auto-IDInfra-

structure

MessageBroker

Business Process

Management

Business Task

Management

Business Process Modeling

Trading Communities

PackagedApplications

LegacyApplications

mySAPApplications

Adapter Engine

• Technical• A2A• B2B

Partner Connectivity Kit

Key SOA functions An SOA offers a number of basic services:

• A common way to describe the interface to a component

• A registry of available com-ponents, their characteris-tics, locations etc

• Support for standard com-munication protocols such as SOAP and JMS

• Support for XML to provide standard, self-defining data formats

5

SOA and process integration use cases Before carrying out the assessment, it is worth reflecting on some of the use cases for NetWeaver’s process integration capabilities. It can be used in a wide variety of situa-tions, such as • Classical application integration (A2A) • Delivering service provisioning capabilities (SOA) • Business-to-business interactions • Operational collaboration and workflow • Program-level process modeling, integration and management • Provisioning of enterprise portals Some of these areas leverage additional functionality available in NetWeaver, such as the Enterprise Portal component. These use cases will be discussed in the later section on flexibility.

Review of product capabili-ties The first step of the assessment process is to understand the product capabilities within SAP’s Netweaver-based solution, within the context of SOA and process integration needs. Once the salient features of the functionality are understood, it is then possible to make a general assessment. In order to make this assessment as useful as possible to end users considering SAP’s various SOA and process integration offerings, it will be arranged in four parts. The first, second and third parts look at how SAP’s plans stack up against the basic requirements for both SOA and process integration respectively. The combination of these three sections represents the fundamental level of functionality offered by all vendors of SOA and BPM solutions.

The fourth part will concentrate on value-add considerations. That is, those additional areas of functionality and characteristics that may prove to be differentiators, and which go to make the solution more attractive. If it is assumed that all serious vendors will be able to address the basic requirements, it will be the added value ones that will influence the purchasing decision.

Basic requirements – SOA platform support It is helpful to review SOA support and process support separately, as discussed at the start of this paper. The area of development tools, however, makes more sense when looked at in combination. The first section will deal with the SOA requirements.

Registry The registry is a key element of any successful SOA implementation. It has two extremely important purposes – to provide a repository where all information related to each service can be stored, and to provide the corresponding runtime information required during operational execution across the SOA.

The usage of the registry to record service information is key to one of the drivers for SOA adoption – increased levels of reuse. The problem is that developers are generally rather resistant to reuse, preferring instead to design and develop everything from scratch. If reuse is to succeed, it must be really easy for the programmer to review lists of available services, and quickly understand what the services do and whether they are relevant. If a service looks a good candidate for reuse, then additional information is re-quired to enable the programmer to understand how to invoke the service and receive the results, and any other relevant information such as security or quality of service re-quirements. In this case, the registry also provides a useful tool to implement corporate policies and procedures.

In runtime terms, the registry must be able to meet potentially high levels of demand efficiently, across the enterprise and beyond. This may well require federation and/or caching technologies. In some SOA registry tools, the development and runtime reposi-

What is process in-tegration? Process integration covers a wide range of process-based IT technologies that make it possi-ble to map between business process design and their under-lying IT components. Typically, business processes can be defined through graphical flow-charts, with IT services to repre-sent the sub-process steps.

A key capability of process integration is to enable the process to be integrated and automated across multiple platforms, technologies and even corporate entities.

6

tories are separated to make it easier to address the performance needs of the runtime component.

SAP NetWeaver, includes the SAP Enterprise Services (ES) Repository, a central reposi-tory where business services, business objects and business processes are stored, with their related metadata . The process integration support utilises the ES repository to hold all the information required to make an SOA run, and also to provide a fully compliant UDDI V3 registry for cataloguing services. SAP has elected to provide users with a single logical repository rather than deliver separate offerings for design-time and run-time needs. This approach minimises confusion for the user, while leaving SAP with the flexi-bility to implement whatever characteristics are required in the above roles under the covers.

The ES repository holds all sorts of information, such as • Index of available services (with associated WSDL etc) • XSD data types • Data mappings (eg to/from XML) • BPEL-based collaborative processes • Service endpoint definitions • Security settings • Documentation The last point is worth stressing. As well as specifying the information required for SOA and business process execution, the ES repository allows users to record documenta-tion on particular services. This is extremely useful when trying to encourage a higher degree of services reuse. It makes it much easier for developers to find and understand the appropriate services for their needs, making it less likely that the developer will write new function from scratch.

Communications, connectivity and mediation This is perhaps the best understood area of all aspects of integration. There have been many solutions, from message brokers to ESBs (Enterprise Service Bus). The main re-quirements are:- • Multi-platform, asynchronous, message-based connectivity • Connectivity with as many different environments, technologies and application

types as possible • A transformation/mapping service, to map data formats between target and

source components • Intelligent routing and orchestration, to allow dynamic determination of compo-

nent linkage and flow • Support for key integration standards such as XML and web services SAP NetWeaver’s process integration capabilities leverage the Integration Server func-tionality of SAP NetWeaver XI technology to deliver these capabilities. The essence of the SAP approach is to use XML messages for all internal activities. Messages entering the Integration Server domain must be transformed to an XML format on entry, using the provided transformation tools or adapters. During message processing between compo-nents, mediation services are provided, such as format mapping and intelligent routing. Note that SAP refers to the transformation of formats between XML and non-XML as ‘transformation’, while transformation of XML data between source and target require-ments is termed ‘mapping’.

Tools will be discussed in greater detail in the next section. Focusing on run-time func-tionality and processing, SAP calls the run-time instance the Integration Engine. The first point to note is that, in addition to handling XML messages, the Integration Engine has special support for handling SAP IDocs and RFCs. This is particularly useful for custom-ers that have already invested in these earlier integration forms, allowing them to be brought into the new Process Integration environment. Secondly, during message proc-essing the Integration Broker not only deals with mappings and intelligent routing, but it also provides for routing to multiple receivers and executing on pre-defined collaboration procedures. The support for multiple receivers gives SAP functionality similar to that offered by Publish / Subscribe implementations, although there is no explicit functionality for a user to subscribe to a particular class of information. But by combining event-driven

7

support with the support for multiple receivers, it would be possible to achieve Pub/Sub-like support. Apart from this, the collaborations capability offers the ability to agree such integration characteristics as security requirements between components.

Three levels of QoS (Quality of Service) are supported – two asynchronous and one syn-chronous. In asynchronous mode, users can choose between exactly once delivery, where messages are sent once and only once, or the same with the additional require-ment of processing messages in the specified order. The synchronous option follows the traditional blocking model, where the sender waits until receiver confirmation.

Mapping of the XML data between source and target requirements is carried out through the use of Java mapping programs created with the Graphical Mapping Editor. Other mediation functions such as message logging and tracing are also supported.

Connectivity is provided through the use of an adapter framework based on JCA (Java Connector Architecture). As well as providing the vital support for web services, there are a range of other adapters provided directly by SAP, and many more through third party relationships with iWay for application adapters, and Seeburger for EDI ones. SAP-provided adapters include SAP RFC, SAP Business Connector, SOAP, JMS,,JDBC, email, FTP, HTTP and HTTPS. For those looking to build customised adapters, SAP offers built-in NetWeaver tools for this purpose. These tools are also available in the Part-ner Connectivity Kit, a lightweight small-footprint version of NetWeaver designed to pro-vide an outboard adapter environment to act as an on-ramp to the full NetWeaver envi-ronment. The PCK is often used by third parties wanting to build specialised adapters for particular applications or technologies. There are already more than 60 certified third party adapters available from 20 vendors.

Standards support is good, with specific adapters for such standards as MML, for Mar-ketPlaces, RosettaNet for the high tech industry and CIDX for the chemical industry.

Basic requirements – Business process support Fundamentally, the three key functions offered by BPM (Business Process Management) tools are modeling and implementation, execution and analysis.

Modeling and implementation The key to the modeling activities for most BPM tools is that the target audience for the modeling activity is often not particularly IT-skilled. BPM is all about integrating and man-aging operational steps across business processes, and offering an environment in which these processes can then be modeled and changed easily. But the driving force behind these activities is usually a business analyst, as opposed to an IT specialist, and so modeling support needs to be as accessible as possible to business people.

At the highest level, these business analysts generally start from an overall enterprise operating model, looking at the different aspects of the business and how each behaves. This defines the key business objects and how they interrelate, yielding the main proc-esses for the business. Within each process, the analyst then defines the required busi-ness objects and process steps to perform the process in accordance with corporate policies and initiatives. The idea behind BPM is that the IT layer underpinning business operations is related closely enough to the processes to allow process changes to be simply and easily reflected into IT operations.

The requirements on BPM modeling and implementation are therefore to enable use of business analyst tools such as process flowcharts, without in-depth technical knowl-edge, and then to map changes onto the IT layer. Process flow is governed by the basic process structure combined with business policies and rules. In addition, there is a need for both static and dynamic dimensions to this process flow control, where the dynamic part can make process flow decisions based on real-time circumstances and events.

SAP NetWeaver provides three approaches to modeling business processes, which all interlink. The Integration Builder tool has a process editor that is used to specify process flows in BPEL terms. ARIS business modeling tools are supported through the ARIS for SAP NetWeaver offering, with ARIS-generated BPEL flows being imported for use in Integration Builder. Task-based workflow specifications are carried out using the Work-flow Builder tool which is part of SAP Business Workflow. Flows built with Integration

8

Key process inte-gration functions • A graphical environment for

manipulating business proc-ess flowcharts

• Tools to analyse the impact of potential process changes

• Support for program-based and human-based workflows

• A run-time engine to imple-ment the process interac-tions

Builder can be driven from Workflow Builder, and the reverse is also true. All process definitions are stored in the Enterprise Services Repository.

The third-party relationship with ARIS satisfies the high-level BPM requirements. ARIS provides an environment for laying out the enterprise company value chain and associ-ated process architecture together with a wide range of modeling and simulations capa-bilities. ARIS-produced process flows can be then brought in to Integration Builder for further modification and enrichment. The process editor is a graphical tool, designed to be accessible for business analysts. In addition to specifying the process flows, events can be defined to support a more dynamic, event-driven form of process execution.

SAP NetWeaver makes extensive use of BPEL (Business Process Execution Language). BPEL is a standards-based language for defining message-based service orchestration, and has become accepted as the ‘norm’ in the marketplace. In general, the SAP proc-ess offerings provide pretty comprehensive execution facilities. • Serialisation forces process steps to execute in a particular order • Request / Response support includes time-out facilities to avoid hanging

threads • Multicast support can be used to broadcast messages to multiple receivers • Triggers are available, such as timer or payload related The Business Workflow Manager provides SAP’s human-oriented workflow support, where the business process integration involves people as well as programs. SAP covers all the basic requirements for a workflow manager. Essentially, using the graphical Work-flow Builder tool, operating units can be set up, and positions defined within them. User lists can then be browsed, with a drag-and-drop facility to assign users to positions. The flow is defined in graphical flowchart terms, describing how work moves from one user-position to another. There are front-end workplace clients for the native SAP environment (SAP Business Workplace) as well as Web, Microsoft Outlook and Lotus Notes environ-ments, although most client usage is through the universal work-list interface provided by the SAP Enterprise Portal. As mentioned earlier workflows built with the Workflow Builder tool can be used within the Integration Builder flows, and vice versa.

Execution The execution area of BPM is relatively straightforward. The process and flow definitions are extracted from the repository where they were stored at design time, and a run-time engine now controls the behaviour of the underlying IT implementation according to the process specifications. Any necessary calculations at the various flow decision points are carried out in order to determine the appropriate next step. The run-time engine also has the responsibility for managing state, to ensure that consistency can be maintained in the event of a failure or some other disruption.

In the SAP implementation, execution is controlled through the process flows, integra-tions and collaborations specified in the Enterprise Services Repository. The run-time engine carrying out this activity is called the Integration Engine. Using this engine, flows can be decomposed into multiple paths and then be recomposed again. Steps may be serialised, to force in-order execution, or could be carried out in parallel where the proc-ess definition allows this. Messages can similarly be split or merged. Triggering is sup-ported, so processes can be started on the occurrence of some event. In terms of flow control decisions, the normal range of choices is available such as Wait and Loop. Gen-erally, SAP has broad support for most process integration needs.

It is important to understand that the Integration Engine runs within a SAP application server environment, and can therefore benefit from a lot of the functionality already in place in the application server, such as availability, recovery and dispatching support. So, for example, the SAP Web Dispatcher can load balance activities across a cluster of web servers, for performance, scalability and availability purposes.

Analysis Full impact analysis, using simulation techniques, can be done through the OEMed ARIS for SAP NetWeaver business modeling tool. Within the SAP products themselves, there are various facilities for analysis. Event occurrences and other technical tracking can be carried out through the SAP Runtime Workbench, while the process integration compo-

9

nent also interoperates with SAP CCMS for more general monitoring support.

Through use of the event management piece, SAP NetWeaver can deliver a level of Busi-ness Activity Monitoring (BAM). Essentially, any SAP process can generate an alert. In SOA and process integration terms, events can be defined and recorded in the Enter-prise Services Repository. These events are effectively triggers. When the event occurs, the SAP Event Manager filters the event according to the event specifications, and then routes the event as an XML message to trigger the required tasks and processes. So, for example, an event might be the raising of a purchase order. The filter checks to see if the PO is for a value greater than a specified amount, say $1M, and if so it then triggers a supervisory approval process.

But these events can now be monitored, with reporting going to the SAP Portal. It is this capability that enables users to implement a BAM solution, monitoring these business-related events and interpreting them into meaningful milestone measurements as re-quired.

Basic requirements – Development tools Development tools are best reviewed in a combined fashion, taking into account both SOA and wider process integration needs. The primary development tool is the SAP Integration Builder. This rich Java client has two distinct views – one for dealing with the design-time information and the other to handle configuration information. In SAP terms, the Enterprise Services Repository combines a repository for design-time and a directory for configuration, so Integration Builder has ‘repository’ and ‘directory’ views.

Within these different views, Integration Builder offers a number of specialised editors for working with the different categories of information making up the overall SOA and proc-ess integration environment. The following picture describes the editors and functional areas for the design-time (repository) view.

Figure 4:- Design-time view of the Integration Builder environment

The process editor is the main vehicle for building the process flows, described using BPEL. Any BPEL created through the use of the ARIS enterprise modeling environment can be used, and new BPEL can be created. The mapping editor deals with the defini-tion of any mapping activities required, such as moving data formats into and out of XML. The condition editor allows events to be specified to support the event-driven func-tionality. Finally the interface editor handles the message and data types and formats.

10

Similarly, the facilities offered within the configuration (directory) view are depicted below.

Figure 5:- Configuration view of the Integration Builder environment

This is the tool for defining such information as routing rules, collaboration agreements and partner profiles. Integration Builder offers both straight editors and also wizards to make the configuration task easier.

The other relevant development tool is the SAP Workflow Builder, part of the SAP Busi-ness Workflow component. This is the tool that is used to construct task-oriented work-flows to address the human-centric element of process integration and management. Although this tool is separate to the Integration Builder, it is possible to drive a BPEL flow created with Integration Builder from a Workflow Builder process specification, and vice versa. In addition, because workflow and other integration processing is carried out within the same run-time environment, information can be shared between workflow and general integration activities.

Value-add considerations These are the factors relating to SAP’s SOA-based process integration platform that can be regarded as going beyond the basic requirements, adding potential differentiators and more value to the solution. As in the two previous sections of the assessment, these will be dealt with in a selection of different categories.

Manageability and governance In terms of monitoring, the main tool for the process integration usage case of SAP Net-Weaver is the Runtime Workbench. The workbench provides four main features:- • Message monitoring • Component monitoring • Performance analysis • Message alerting The message monitoring feature enables message tracking end-to-end, encompassing the integration engine itself and the adapters used to move information into and out of the engine. Message logs can be reviewed and analysed, with drill-down facilities for additional detail. Component analysis integrates directly to the central SAP system moni-toring facility, CCMS. It checks to ensure that the different runtime components that de-liver the NetWeaver functionality are all present and working properly, with any error situations being reflected to CCMS. The performance analysis feature covers processing of such performance statistics as message throughput and latency. Information can be aggregated and filtered based on a range of factors such as time intervals or message attributes. The message alerting component allows alerts to be delivered to the required recipient, such as through email or SMS.

The Runtime Workbench provides the facility of mapping the monitored information to the process definitions contained in the Enterprise Services Repository, putting it into an end-to-end business context. This makes it possible to provide information in a more

Process integration and visibility Process integration enables business processes to be aligned more closely with the IT components that underpin them, and this yields a greater degree of visibility of IT-based operations in a business con-text.

The result is more accurate business performance measure-ments and more operational control and governance.

11

accessible format, such as showing a graphical representation of a process flow, and where the flows are operating smoothly or backing up.

Other manageability and governance support is provided by the information provided in the Enterprise Services Repository. For example, versioning is controlled through the information recorded here, together with business policy factors such as security require-ments and usage authorisations.

Scalability, reliability and performance As might be expected, the SAP solution scores highly in the area of scalability, reliability and performance. SAP has had considerable experience in these factors through its mySAP Business Suite, which is often used in a mission-critical environment.

On the scalability front, SAP leverages the Web Dispatcher provided as part of its Appli-cation Server to provide the ability to use multiple different engines and threads. The dispatcher can drive multiple application server instances, and carry out load-balancing across them. This provides for scalability in the processing power sense, but also en-ables processes to be executed in parallel where the defined process flow allows. Of course, if certain process steps have to run in order, then SAP provides a serialisation capability to enforce this.

Also on the scalability side, SAP’s solution is not forced to rely on XSLT for data map-ping. XSLT is a standard, and as such is supported by most SOA and integration solu-tions, but it has a number of drawbacks. One is that XSLT performance is generally weak in high-volume environments, and the other is that it is not equipped to deal with more complex or specialised transformation/mapping requirements. SAP NetWeaver uses Java mapping programs, created through the graphical mapping editor, to handle map-ping needs as efficiently as possible. Existing XSLT mapping definitions can be imported if required. On the question of transformations, although NetWeaver provides functional-ity in this area, SAP offers the SAP Conversion Agent based on Itemfield’s transformation engine to address more complex transformation needs.

Service reliability is protected by a range of availability features. The dispatching function means that most of the integration tasks, such as mapping and flow control, can be architected using redundant systems or at least with a switchover capability. The Enter-prise Service Repository, a key potential single point of failure, is preserved through the use of both caching and redundancy to preserve its availability. Even the Integration En-gine itself can run in multiple copies. In the rare cases where a single point of failure does exist, such as the Application Gateway used as a security shield when deploying a busi-ness-to-business solution, HA hardware-based solutions such as clustering are sup-ported.

Performance in terms of throughput is aided by the multi-tasking, multi-threading archi-tecture. In response-time terms, performance is assisted by the provision of different classes of service for the underlying SOA framework. These also contribute to better reliability and scalability. The two asynchronous options are exactly once message deliv-ery, and exactly once in order - that is, serialised. The SAP approach to exactly once delivery is to send messages until they are acknowledged as having been received by the recipient. Received messages are checked for duplicates, which are discarded. For the serialised version, message identifications are checked to ensure the correct order is maintained. The synchronous option involves a blocking model, where the sender waits for a response, or a time-out.

Flexibility SAP NetWeaver supports a range of different SOA and process integration use cases. For instance, as can be seen from the above discussions on SOA, it is perfectly possible to use the NetWeaver software to enable a service-oriented architecture. Web services created outside of NetWeaver can be imported into the Enterprise Services Repository, and legacy or home-grown applications can be brought into the SOA through the use of the SAP and third party adapters. In a similar fashion, classical application integration can also be carried out with SAP NetWeaver support.

An important use case covered by the SAP solution is that of collaborative, human-oriented workflow support. As discussed in the previous sections, the SAP Business

12

Workflow software provides the facilities needed to operate task lists, manage user roles and progress work-items through the desired process. The one drawback in the SAP solution is that different tools are used to build the human-oriented workflows and the program-centric BPM ones, although objects defined in either can be used in the other.

Business-to-business integration is another area of value-add flexibility offered by the SAP NetWeaver process integration capabilities. SAP obviously has to have a good un-derstanding of the requirements of different industries to deliver an effective mySAP Busi-ness Suite to the market as a whole. It has leveraged this knowledgebase to build in a range of facilities designed to enable safe and secure integration between business part-ners. So, for example, it supports a wide range of EDI standards through its partnership with Seeburger. It also has specific partner profiling capabilities, where information about partners can be built and stored in the Enterprise Services Repository, and an Applica-tion Gateway is provided to sit at the perimeter of the enterprise, to protect integrity and security from exposure to the outside world.

Another area of flexibility is provided by interoperability with other SAP components. So, for example, the Business Intelligence component can be used to add value to the BAM and associated analysis capabilities already discussed.

Usability and productivity For existing mySAP Business Suite users in particular, SAP NetWeaver’s process integra-tion capabilities score highly for added value in the area of usability and productivity.

Clearly, one of the challenges for SAP application users is that a number of business processes are at least partly contained within the SAP applications themselves. This presents a problem for companies looking to move down the BPM route on a more widespread basis. How can the processes embedded within the SAP applications be interlinked with other processes outside of SAP’s domain? The answer lies in the SAP Solution Maps, sometimes called Business Maps. These Solution Maps describe the processes being executed by the applications, including the solution variants such as industry vertical differences.

Another source of productivity improvements is the SAP Developer Network (SDN). SAP has established a community base for all people involved in Netweaver activities, includ-ing end users, systems integrators, implementers and partners. The SDN resources provide forums, bulletin boards and a wide array of technical documentation and content for browsing and reviewing.

SAP offers an SDN-hosted tool, the Enterprise Services Workplace, for browsing and working with these Solution Maps. Using the tool, the user can work through the embed-ded processes, drill down as required, and upload relevant processes to ARIS. Now the user can innovate on top of the SAP-provided process, using ARIS to model the new, composite application, produce a BPEL representation and merge it into the Integration Builder environment where further enrichment can take place before deployment. This functionality therefore provides an excellent way for users to build on their existing invest-ments in SAP applications, and bring those applications into the new BPM environment, in a usable and productive fashion.

In general, the process integration tools are graphical in nature. Integration Builder does offer two distinct views, design time and configuration time, and this role-based ap-proach makes it easier for users to only have to deal with the bits they understand.

Standards adoption SAP’s approach to standards is to consider them very much from the user’s perspective, as opposed to market movement. So, it does not tend to jump onto every latest stan-dard as a marketing exercise, but instead likes to be clear in its own mind about the value and applicability of the standard to its customers.

At the lowest level, SAP NetWeaver is built around XML. XPATH, XSLT, SOAP, WSDL and UDDI are also supported to ensure that message transmission, processing and web services are all covered. SAP is also active in the BPEL area, offering BPEL views of process execution flows as required, although in common with many other vendors it has added its own enhancements to satisfy those requirements not addressed by the current BPEL specifications. In the area of security, SAP has also adopted WS-Security

13

and the WS-I Basic Security Profile.

On top of this, there are a number of standards-related areas where SAP is currently active, either evaluating standards for potential adoption or working to produce stan-dards where none exist today. For example, SAP is working with IBM on BPEL4People, an extension of BPEL to deal with the needs of human-oriented process integration, and is also evaluating BPMN. It is also involved with the SCA and SDO initiatives as part of its work to support composite applications.

Market factors One of the problems for companies looking to invest in SOA and process integration tools is that many of the vendors have limited market exposure today. In contrast, SAP has had significant success with NetWeaver in general and the Process Integration com-ponent in particular. As 2006 draws to a close, SAP is claiming more than 6,800 Net-Weaver deployments, with at least 500 ‘powered by NetWeaver’ partner offerings and 10,000 trained consultants. So the NetWeaver platform has had significant opportunity to benefit from this level of customer exposure, assuring a high degree of customer input and quality.

But the process integration usage case has also achieved significant penetration, with 2,200 installations across 1,600 enterprises, 700 of which are in production. These are highly creditable figures, putting SAP NetWeaver’s process integration solution in the leading group of SOA and process offerings in the marketplace. Admittedly, most, if not all, these users will be SAP application package customers, but the net effect on soft-ware quality and capability of this exposure will still be highly beneficial.

Assessing SAP NetWeaver’s process integration capabili-ties The review of the functionality provided by SAP NetWeaver for process integration was carried out in terms of its basic level of support for SOA and process integration, and then its value-add differentiators. The assessment will take the same approach.

Assessment of basic support for SOA and process inte-gration As far as basic support for SOA and process integration goes, the SAP solution appears to tick all the boxes. The Enterprise Services Repository provides all the necessary func-tionality to fulfil registry needs, and handles both registry and repository requirements in one package. Web services created outside of the SAP NetWeaver infrastructure can be imported into the ES Repository. It supports browsing, analysis and selection of existing services, and unlike some of the competition it also allows the user to put additional user-specific information into the various entries such as documentation, explaining the use of the service and making it more likely the service will end up being reused.

Overall, SAP offers strong functionality in the area of communications, connectivity and mediation. The use of Java mapping programs, rather than XSLT, and the provision of the SAP Conversion Agent gives users a lot of extra power, flexibility, scalability and per-formance. Reliance on a third party for most of the application environment adapters may be a bit of an exposure, but this is actually the way that most vendors address con-nectivity needs today.

The three levels of QoS offer more flexibility. In particular, many competitors do not offer the ‘exactly once, in specified order’ class of service. This is very useful in more complex process flows. On the migration/coexistence front, SAP has been careful to include sup-port for previous technologies such as SAP IDoc and RFC. This will be very important to existing SAP users who have already invested in these technologies.

14

Currently SAP’s overall Integration Server implementation is based on the classical mes-sage broker architecture, sometimes called hub-and-spoke. A number of competitors use the ESB approach instead, which is very popular at the moment. ESBs are based on distributed rather than centralised intelligence, removing the need for a large investment in the ‘hub’ upfront and providing a greater degree of architectural flexibility, in a true, peer-to-peer sense. Broker vendors will point out that a multi-hub solution can be imple-mented, which will deliver some of the characteristics of an ESB, but this is still a little unwieldy. In addition, ESB solutions are starting to allow the use of any JMS-based mes-saging engine, giving users the flexibility to standardise on one messaging solution for all corporate needs. Although the SAP solution can interoperate with other messaging tech-nologies, it cannot use them internally as its messaging backbone. SAP would do well to introduce an ESB option with this substitutable flexibility, in much the same way as IBM has done, although SAP has recently been discussing its proposed Enterprise Services Infrastructure initiative which should address at least some of the issues.

Process integration support is reasonably good in the SAP solution. The partnership with ARIS ensures the user has access to industry-leading enterprise and business modeling tools, although in the current SAP NetWeaver product the join between the two vendor offerings seems a little cumbersome. SAP would probably benefit from a tighter integra-tion of the two products, and indeed it is working with IDS Scheer to achieve this. The ARIS linkage enables SAP to offer powerful impact analysis facilities, and the fact that mySAP Business Suite process flows can be extracted and imported to the ARIS envi-ronment offers a great deal of value to the overall process integration scenario for exist-ing SAP customers.

The support for events and triggers, together with other process integration requirements such as time-based facilities, means that the SAP NetWeaver process integration offering is pretty comprehensive in its functional coverage. Perhaps the only other drawback is the lack of support for UML.

On the tools side, Integration Builder offers the dual view facility for dealing with design or configuration needs. This is an attractive, role-based approach to functional presentation, helping to personalise the view for specific needs. The tool is graphical, although there are quite a lot of menu-based data collection screens. It seems perfectly adequate, how-ever. The SAP solution supports both program-centric, production-based process inte-gration and the human-oriented workflow variety, which is a strong factor in SAP’s favour compared to a number of competitors, but it is somewhat unfortunate that the develop-ment environment for the workflow flavour, Workflow Builder, is a different tool. It would be more appealing to have all process integration development available within a single environment.

Value-add differentiators So SAP NetWeaver satisfies the basic requirements for any SOA and process integration solution. But it also benefits from a range of added value characteristics, which could be differentiators in any purchasing decision.

The Runtime Workbench is a useful tool for keeping an eye on what is happening with the end-to-end process, and it interoperates with the SAP systems management tool, CCMS. This provides a reasonably good level of monitoring support, although it is some-what SAP-specific. To broaden the appeal, SAP needs to make Runtime Workbench alerts interoperate with other management frameworks, perhaps through the use of an SNMP agent.

The Enterprise Services Repository has been well thought out. Functionality is compre-hensive, and the ability to put user installation-specific information into the records is a very useful feature. If a user employs the repository properly, it can not only improve the overall effectiveness of the SOA and process integration implementations, but it can also assist in enforcing required levels of governance.

SAP offers a number of high-end features in its SOA and process support, such as sup-port for clustering, the ability to architect redundant and standby instances of runtime components and the Web Dispatcher functionality to enable load balancing and im-proved efficiency. The range of classes of service provided include exactly once delivery of messages, an essential feature for many high-end environments, and the added sup-

15

port for forcing messages to be processed in order is also beneficial in some cases.

Perhaps the one high-end area where the SAP solution is weakest, however, is Business Activity Monitoring (BAM). Although there is some basic BAM functionality in the current offerings, it is still a long way from market-leading BAM solutions. Mechanisms for dis-playing activity information are rather primitive, and there are no direct pattern-analysis or predictive facilities to enable users to not just see problems but to anticipate them and take avoiding action.

Many competitive SOA offerings limit transformation support to XSLT-based mappings. This can be a big problem for larger customers, or companies with specific and some-times complex mapping requirements. SAP’s Java program-based approach to mapping should be much more efficient, providing a clear differentiation from purely XSLT-based options.

For SAP customers, there are, of course, many competitive differentiators. The SAP solution support RFC and IDoc, for a start. But it is the ability to utilise the Solution Maps, bringing existing package-embedded processes into the process integration environ-ment, that offers the most benefit to existing SAP environments. This enables a much higher degree of process enrichment and value creation. Also, the creation of the SAP Developers Network promises to generate a significant and growing body of knowledge about SAP’s SOA and process initiatives.

Finally, the extensive take-up of the SAP NetWeaver’s process integration solution pro-vides a great deal of assurance about product quality and functionality, especially com-pared to many other SOA and process vendors where customer experience may be extremely limited.

Summary SAP has drawn a lot of threads together to produce SAP NetWeaver’s process integra-tion facilities. It is moving to a single approach for integration, superseding the older IDoc and RFC mechanisms, and it has placed this solution into an SOA context. On top of this, it has delivered process integration support, spanning both program and human-centric workflow needs. Although the initial focus was on providing existing users ways to leverage and maximise their investments in SAP packages, the technology has suffi-cient functionality to now stand in its own right as a sound basis for SOA and process integration needs. At a purely functional level, it has good support for the mostly non-SAP environment as well as the more heavily SAP-oriented one.

Naturally, in these relatively early days the picture is not perfect. SAP still seems to strug-gle to wrench its vision away from internally focused thinking focused on its own pack-age-based world, but it is continuing to provide impetus and investment to its drive to move its solution to a more generalised market. However, it is not the few functional weaknesses that will be the most difficult hurdle for SAP to overcome if it is to widen the appeal of its SOA and process integration tools. It is the market perception that SAP is first and foremost a package vendor, and that all its tools are designed for use with those packages. Unless SAP decides to address this issue, the NetWeaver process integration capabilities will always be seen as relevant only for users that have largely adopted my-SAP Business Suite as their mainstream application environment.

16

Lustratus Research Limited St David’s. 5 Elsfield Way, Oxford OX2 8EW, UK Tel: +44 (0)1865 559040 www.lustratusresearch.com

Ref SC/LR/71149827/V1.00