06wp02 Impl SAP From E2E Scenarios

8/10/2019 06wp02 Impl SAP From E2E Scenarios

1/22

WHITE PAPER:

IMPLEMENTING SAP FROM END TO END

BUSINESS PROCESS SCENARIOS


2/22

Table of Contents

ABSTRACT...................................................................................................................... 3

INTRODUCTION............................................................................................................. 3

BACKGROUND...............................................................................................................4

METHODOLOGY............................................................................................................ 7

COMPONENTS OF THE REFERENCE MODEL APPROACH TO IMPLEMENTING

COMPOSITE APPLICATIONS ...........................................................................8

THE REFERENCE MODEL APPROACH ................................................................... 14

CONCLUSIONS............................................................................................................ 20

RELATED PAPERS...................................................................................................... 20

REFERENCES ............................................................................................................... 21

END NOTES ..................................................................................................................22

Table of Figures

Figure 1: The center of the universe consequence of non-enterprise implementations............. 5

Figure 2: An end-to-end viewpoint required for true enterprise integration. In this approach,

IT supports the E2E business process. ................................................ ........................................ 6

Figure 3: A generic reference model for E2E order execution using the SCOR model for

organizing the business objects....................................... ..................................................... ....... 10

Figure 4: Example of a Place-Order Composite Application...............................................................13

Figure 5: Transitioning an E2E scenario from the ARIS Toolset into SAP NetWeaver for

execution ........................................... ............................................... ................................................ .....16

Figure 6: Object sharing across the enterprise is accommodated by the SAP Business

Process Platform.................................................................................................................................19


3/22


4/22

IMPLEMENTING SAP FROM END-TO-END BUSINESS

PROCESS SCENARIOS

Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 4

bounding of the composite process with a reference process that is first presented in

generic terms, and then translated (through object mappings or interface service

presentations) into a composite application that can be implemented across aheterogeneous system landscape.

BACKGROUND

Historically, organizations have evolved as circumstances have permitted. Product

demand, available resources, competition, partners and alliances, and management

style among a host of many other factors have influenced enterprise development.

These factors have similarly influenced the growth of the organizations information

systems that it has either developed or procured. For the most part, these systems

comprise a mix of applications that address particular requirements that are specificto a functional area (i.e. sales, customer support, etc). In effect, they have become

islands of automation. Enterprise Resource Planning (ERP) applications 1raised the

hope that an integrated solution2would address and resolve the integrity problems

that result from these disparate information systems. However, early generation ERP

implementations were limited constructs, and did not achieve the single source of

truth that managers sought. Indeed, the solutions offered within these enterprise

packages have in many cases been implemented in stove pipes; and have been

limited to supporting only specific and individual organizational functions that are

bound to the vertical solution. In the end, they increase, as opposed to reduce the

complexity of the information technology (IT) landscape; the promise made by the

business development teams.Neither has the perceived promise of these large and complex systems materialized

with the evolution of Enterprise Application Integration (EAI) solutions. Interoperable

systems have only enabled the passage of data, and little more, with the business

processes remaining trapped in the stovepipes. As such, a vast and heterogeneous

landscape of information systems has often come to characterize an organization. In

the center of theses interfaced systems stands a complex and expensive enterprise

application, which has become the center of corporate activity (see figure 1). With its

pre-defined and scripted business processes, the ERP system and its satellites enable

enterprise business processes. Processes within this domain are driven by the scope

of the ERP system, and they are typically not true end-to-end business processes.

Also, they are usually not fully integrated, nor do they enable an agile and innovativeprocess-centric organization. In short, the competitive advantage of ERP is often

compromised because organizations do not implement the solution as it was

intended to be implemented. As opposed to being implemented as an enterprise-

1See Gulledge, et al (2005) for background information on the basic concepts of ERP.

2Integration is a word that means different things to different people. Gulledge (2005) describes the usage context

for ERP systems. In this case, the authors are referring to Big I in the classification scheme proposed by Gulledge.


5/22


PROCESS SCENARIOS


wide solution, ERP is implemented as a sub-component of the enterprise, and in

some cases, even within an organizational stovepipe.

Sub-enterprise Scoping Diminishes

ERP Value Proposition

GCSS-Army

LMP

TC-AIMS II

LIDB

MC4

TMDE

J-CALS

OTHERS

BCS3FBCB2JC2

DFAS

Joint System

ARMY System

DoD System

Legend

FCS

BSM

DIMHRS

AllServicesMTS

OSMIS

AALPS

TAV

TLDD

IETM

Figure 1: The center of the universe consequence of non-enterprise implementations

As noted above, frequently enterprise system implementations produce a state of

affairs where the ERP solution becomes the center of the universe. When ERP is

implemented in this way, it is just another system that must be managed across a

complex technology landscape; and business processes that depend on this system

are bounded by its stovepiped scope. This is a common problem. Fortunately, the

Center of the Universe paradigm is being replaced by new enterprise solutions that

support an end-to-end composite application framework.

The business environment has become increasingly competitive, and will no longer

tolerate those enterprises that do not posses the inherent agility within their businessprocesses to respond to the demands of the environment. Enterprises have extended

and networked across functional and/or geographical boundaries, and in doing so,

have sought competitive advantage in areas regardless of where these value-added

activities may be found. A true enterprise management approach demands an end-

to-end viewpoint (see figure 2) that flows unimpeded across the constraints imposed

by information system. Hence, where Okrent and Vokura (2004) focus on those

processes that fall within system boundaries, we focus on those that flow inside and


6/22


PROCESS SCENARIOS


outside. End-to-end business process management is the viewpoint that provides

transparency to identify cost reductions, efficacies, opportunities, new practices, and

other related benefits. In this model, IT supports a corporate strategy and embeddedbusiness processes, it does not dictate them. This result is in direct opposition to the

Center of the Universe model where all business processes are constrained by the

interfaces across system components as in Figure 1.

ERPERPCRMCRM

End-to-End Business Process ScenarioEnd-to-End Business Process Scenario

InquiryInquiry

Process

Flow Process

sequence

Time

CreateCreate

quotationquotation

SalesSales

staffstaff

Accep tAccept

orderorder

CustomerCustomer

managementmanagement

CreateCreate

shipping listshipping list

ClerkClerk

WriteWrite

invoiceinvoice

GroupGroup

leaderleader

CheckCheck

paymentpayment

ClerkClerk

LegacyLegacy

ServiceService WrapperWrapperServiceService

OrderOrder ShippingShipping

listlist InvoiceInvoice PaymentPayment

receivedreceivedQuotationQuotation

Figure 2: An end-to-end viewpoint required for true enterprise integration.

In this approach, IT supports the E2E business process.

In the real world scenario of figure 2, there are also very real constraints. It was

previously stated that many organizations already depend on a universe of disparate

systems, and they already have deeply ingrained corporate practices that are tied to

their existing systems. Improving upon these business processes may appear to be a

daunting, if not impossible, task. Many organizations have already gone down this

path before, and many only achieved a limited return on their investment. Further,

end-to-end processes themselves can be vast and extraordinarily complex.

Identifying, let alone enabling an accurate end-to-end business process, is difficult.

The question is then, how does an organization implement an end-to-end process

across a complex heterogeneous IT landscape?


7/22


PROCESS SCENARIOS


METHODOLOGY

We demonstrate an E2E implementation approach using a reference scenario - E2EOrder Execution - a critical business process for most enterprises. This process

begins with the receipt of an order that triggers an order execution process and

terminates with an output that is delivered to the customer. We show how our

general reference model evolves into a customer specific reference model, is

aligned with application solutions, is enabled by data, tested, and executed. There

are many possibilities for demonstrating the concept, so we focus on one type of

composite application, a process that is comprised of both SAP and non-SAP

components3. Table 1 presents the general steps that define the methodology.

Step escription

1. Develop a business architecture.

2. Develop or procure a generic E2E reference scenario.

3. Align the reference scenario with the target organization, creating a customer-specific

reference model.

4. Determine which segments of the process will be scoped within SAP, and which

segments will reside in other applications. This is accomplished using a known

commercial approach, such as ARIS4.

5. For the SAP segments, map (or replace) the company-specific objects with objects

from SAP using NetWeaver.

6. For the non-SAP components, wrap the interfaces so that the functionality provided

by the system may be instantiated as an enterprise service5.

7. Synchronize the complete customer specific model with SAP Solution Manager.

8. Bind the data to the services using the capabilities of the SAP Web Application Server6.

9. Test the E2E composite application.

Table 1: Steps in a Reference Model Approach to Implementing Composite Applications

3See Wood (2004) for the definition of a Composite Application within the context of SAP and non-SAP

components.4

This approach is quite complicated, and is comprised of a complete architecture-driven methodology. Information

on the approach can be found at http://www.ids-scheer.de/.5It is also possible to evolve this step through traditional Enterprise Application Integration (EAI) techniques, but we

focus on the service-oriented approach for this baseline example.6While we have not explored all possibilities, it should be possible to execute some sequence of these steps by

alternative means, with the orchestration falling in third party non-SAP products, such as those from Digital Harbor

(http://www.digitalharbor.com/)


8/22


PROCESS SCENARIOS


Table 1 describes a new paradigm for implementing enterprise solutions. Notice thatthe focus is not on the configuration of ERP modules, but on business processes.

Also note that there is no requirement that all business processes fall inside the

enterprise integration domain; i.e., inside of a single enterprise solution providers

product offering. In fact, we specifically consider in our example the case where

some components are external to SAP. The main point is that the reference scenario

and the company-specific reference model, which ensures a true business process

orientation (as opposed to an interfaced family of systems) drives the

implementation. Throughout, we focus on SAP and non-SAP composite applications,

but a similar approach would be used with Oracle, or the product of any vendor that

permits the orchestration of business processes from enterprise services7.

COMPONENTS OF THE REFERENCE MODEL APPROACH TO

IMPLEMENTING COMPOSITE APPLICATIONS

We acknowledge that we use terms that may not be familiar to readers who are

unaware of the new enterprise system paradigm. The following sections provide an

overview of the key components that are critical to the understanding of the

reference model approach to orchestrating enterprise services.

Reference Models

When it comes to successful Business Process Management (BPM), it is important tounderstand and be aware of three main items: (i) the business processes that are to

be managed; (ii) how these processes compare against best practices, and (iii) how

these processes can be implemented in supporting IT systems that are available to

the organization. Gaining an understanding of these items is where reference models

can assist. In the scope of this paper, the term reference model is used to refer to any

model that represents an overview of a particular business process regardless of

the level of detail of the model8.

Generally, reference models will either focus on a business process, or how it can be

implemented in a specific IT environment. The former will typically be based on

research into existing implementations. Here, a generic process will be applicable to

most organizations, regardless of the particular IT environment. The latter is typicallybased on an existing and proven implementation of a business process within a

specific IT environment for a specific organization. It may or may not be applicable to

7Wood (2004) provides a management overview of enterprise services.

8In general, a reference model could apply to any view of an architecture, such as data, organization, function, etc.

We focus on the business process view, since that is the most important for implementing ERP solutions.


9/22


PROCESS SCENARIOS


other organizations, largely due to potential differences in the IT environment9. Both

can however present a starting point against which an organizations existing

processes can be compared and built upon to arrive at a to-be model of a newprocess.

The benefit of a generic reference model is that it will be applicable to many

organizations and will easily allow an organization to compare its own processes

against the model. As these generic reference models are not based on a particular

IT implementation, they should be considered with caution. What may look good in a

generic reference model may not be able to be implemented in the organizations IT

environment, or it may be costly to implement. Apart from not necessarily being

based on best practices, non-generic reference models also need to be considered

with caution for a similar reason: they pre-suppose a particular IT environment. What

may appear to be slight changes in the IT environment can result in costly changes

to the actual implementation of the business process.

A generic business process (reference) model illustrates the business entities and

their relationships. It is not tied to the technologies or standards of the IT landscape;

rather it depicts the general method of executing a business process. The detail that

is specific to the needs of an organization will be added as required so that it can be

used to implement a targeted business concept. Even in establishing a generic

model, it is often useful to use a frame of reference to assist in the overall

development of the business flow, the various business activities and their

relationships. To that end, a blueprint, or an architecture that helps to guide the

layout of the generic process is also recommended. Any such appropriate

overarching mechanism will be adequate. For example, the Supply Chain Council has

released a reference model that visualizes a supply chain as different areas of intra

and inter-company activities. This Supply Chain Operations Reference Model (SCOR)

has served as a useful mechanism in building our generic order execution model (see

figure 3). For the reference model using the new SAP implementation paradigm, SAP

will provide Business Process Snippets, or short business processes that may be

modeled as components of larger aggregated business processes that are

documented in the SAP Business Process Platform. These process snippets are

referenced for usage in the Enterprise Services Repository (ESR), which is a type of

super UDDI10reference repository that identifies all the required objects that are

available to assist in implementing the new SAP paradigm.

9A discussion of some of the organizational and management issues associated with these types of misalignments is

provided by Clemmons and Simon (2001). Additional misalignment issues are presented by Ho, et al. (2004).10

Universal Description, Discovery, and Integration (UDDI) is an industry initiative to create a platform-independent,

open framework for describing Web services, discovering businesses, and integrating business services using the

Internet. More information about UDDI may be found at http://www.uddi.org/.


10/22


11/22


PROCESS SCENARIOS


absorption of BPML. As of this date, BPML is the standard that is supported by all of

the major enterprise systems vendors, including Oracle and SAP.

Service Wrappers

One of the principal challenges typically encountered when building an enterprise

application is accommodating pre-existing (also referred to as legacy) systems and

their associated data. Because it is usually infeasible to implement an entire E2E

enterprise application due to cost and time constraints, enterprise implementations

are usually blends of new and existing systems. Wrappers (also referred to as

adapters) serve as a bridge between different applications and enable the

construction of an enterprise architecture composed of different systems. Web-

based wrappers are software tools that interpret information delivered from an

external business application (on the Web) and translate it into a structure which is

compatible with the master application (Mecella and Pernici, 2001). In practice, aservice wrapper would collect data presented on a Web page through HTML (Hyper-

Text Markup Language) and translate it into the more structured XML, (eXtensible

Markup Language). Once translated into XML, the information can be presented to

other applications that can parse the particular XML flavor in which the data was

stored. In this way, customer data from one business application can be

automatically passed to another application.

Web Services

There is a growing array of software methods, standards, and tools being developed

to enable the development of blended enterprise applications. A key element of

these tools is their adherence to industry-wide standards. Web-based protocols, suchas XML, SOAP11, WDSL12and UDDI, can be used to allow disparate systems to

communicate. Utilizing such protocols and standards, Web services allow different

applications to interact with each other (without human interaction and regardless of

the applications development platform).

An E2E solution links internal and external business applications, systems, and staff

so that they can respond to dynamic business conditions. In the enterprise systems

literature, such linking is known as a composite application (see below). To

effectively support end-to-end processes, an organization must identify how Web

services are used to choreograph activities within a business process, how business

processes are represented as Web services, and also which business partners

perform what parts of the actual business process (Leymann, 2001). Identifying thesekey components will facilitate the integrated solution needed to support Web service

11The Simple Object Access Protocol (SOAP) is a lightweight protocol for exchanging information in a decentralized

and distributed environment. This XML-based protocol is typically used with HTTP. SOAP is a key component for

accessing and invoking a Web service.12

Web Services Description Language (WSDL) is a specification for describing Web services as a set of end points

operating on messages.


12/22


PROCESS SCENARIOS


activities. These Web services are orchestrated in accordance with a service-oriented

architecture.

Service Oriented Architecture

In order for composite applications to work in concert, enterprises must implement a

Service-Oriented Architecture (SOA). A service-oriented architecture is a modular

architectural framework that enables Web services and legacy components to

interact seamlessly. When an organization needs to create a new business process to

facilitate interaction with suppliers, customers, subsidiaries, or partners, the SOA

allows quick adjustment of components and creation of new virtual applications.

Business requirements can thus be met more easily and programming efforts and

costs are minimized. Mergers and acquisitions, strategic alliances, portfolio

management, new product rollouts, or supply chain management can be eased using

service-oriented architectures. (Hurwitz, 2003)

With a SOA, a business process involving two or more business partners can be

realized by composing Web services offered by the individual business partners

while taking into account the constraints and requirements defined for each

participating Web service in a hierarchical scenario (Leymann, 2001). The top-level

process in a hierarchical scenario does not have to be owned by an individual

business partner because the standard-based rules are defined in a "virtual

enterprise." Though Web services have held out great promise for integrating

business partners, their true potential remains to be tapped. That is clearly the plan

for next generation enterprise system implementations.

Composite Applications

In todays rapidly evolving business world, companies must be able to quickly adapt

and change their business practices (and in turn their underlying business processes)

to retain competitive advantage. However, organizations typically possess a host of

complex interfaced applications, many of which are from different vendors.

Consequently, even minor changes to a business process may require timely and

costly modifications to the IT environment. Replacing any or all of these systems may

not be possible as significant investments have already been made in these existing

solutions.

Composite applications provide a means to address this challenge. The goal of

composite applications is to preserve the existing software infrastructure by reusingexisting business services, or defining new services around existing functions

(Waloszek, 2005).


13/22


PROCESS SCENARIOS


Taken from Seebeyond.com. (2005). Composite Applications and Service-Oriented Architectures.

Figure 4: Example of a Place-Order Composite Application

Figure 4 represents an organization, which employs existing systems to create acomposite application called Place Order. Four layers are shown: the existing

systems, business services, assembly and orchestration, and composite applications

layers. The existing systems layer contains several heterogeneous systems found in

different parts of the enterprise. Objects must be selected, transformed into common

object models, and then integrated into one or more business services. Services like

Create customer or Determine product availability are defined in the business

services layer. These services are part of a service-oriented architecture and are

reusable across the enterprise. The business process is defined and executed in the

assembly and orchestration layer, also called the process layer. The composite

application is now ready for presentation to the user, who is in turn ready to enter

customers order into the system for execution.

Enterprise Services Architecture

This section provides the foundation for bringing all of the previous concepts into a

framework for supporting an enterprise solution. Earlier solutions based on EAI

typically used interfaces to enable communication among disparate systems. Today,

leading businesses are in the early stages of implementing service-oriented

application servers the technology of choice to connect disparate systems. The

application server manages the services that are orchestrated as business processes,


14/22


PROCESS SCENARIOS


and binds the data from relational or object-relations sources to the services.

Therefore, it provides the ability to create and maintain the integration logic in a

flexible and efficient manner, sharing objects across disparate system components.However, the challenge has been how to plan, build, maintain, and utilize application

server integration for real business cases. By "real business cases" we mean those

that cut across an organization's internal and external boundaries. Realizing the need

for E2E real business scenarios, SAP has defined a Business Process Platform as a

core enabler of its Enterprise Services Architecture (ESA). The ESA, SAPs response

to the SOA, takes Web services standards and services-oriented architecture

principles and extends them to meet the business solution needs of the extended

enterprise. The concepts are summarized by van de Loo (2005).

With the Enterprise Services Architecture, a composite application can use

enterprise services to automate the flow of information from application to

application. This orchestration is accomplished using a new concept from SAP that is

known as the Composite Application Framework. Enabling the flow of business

processes across internal business units and external customers provides disparate

systems the ability to interact globally and in real time, in order to orchestrate,

oversee and operate complex internal and external business processes such as order

execution.

THE REFERENCE MODEL APPROACH

For purposes of our illustration, we present a medium size manufacturing business

that offers a family of products with variants, as well as customized orders. Thebusiness has a dynamic supply chain and a customer relationship process that

continues to mature. The business environment within which the company operates

is customer oriented, fast paced, and demands attention to achieving competitive

advantage. The company struggles with establishing a broad perspective of its

business processes that span the entire enterprise. Specifically, it cannot fully

articulate what its value added activities are, both internally and externally with its

partners and suppliers. Furthermore, it has had only limited success in capturing

benefits of collaboration and innovation resident in its own employees. Finally, its IT

environment is complex and heterogeneous. It includes components of the mySAP

business suite, but also interfaces with non-SAP applications needed by its internal

organization, partnerships, alliances, and customers.Given this assumed background, the company needs to become more agile and

responsive to not only rapidly evolving business opportunities, but also to an

increasingly demanding customer base. Therefore, the company cannot be

constrained by its own systems, interfaces, business processes, or by any incapacity

to fully leverage its enterprise wide capabilities. Hence, the company needs to know

(i) what its processes are, (ii) how the processes can be integrated and improved,

and (iii) how new processes can be created to address changing business demands.


15/22


PROCESS SCENARIOS


Please note, that we are referring to business processes that extend from the start to

the end of an enterprise wide activity, rather than processes that are bound in

functional departments or stand-alone information systems.

The first step in this undertaking is establishing an overarching blueprint a high-

level architecture. Included in this architecture are the different views of the

company (i.e. systems, organization, processes, etc). The business process map of

the enterprise describes the companys overarching business process strategy and

will help to illuminate the value added (process) chains in the enterprise. It models

the company view of what business scenarios are desired. In other words, it is the

company reference architecture that allows management to illuminate, and focus on

a business process orientation as opposed to disjointed functional activities driven

by its interfaced family of information systems.

Once the architecture is established, the focus turns to the key business scenariosthat have been illuminated by the business blueprint. We have noted that the order

execution business process is fundamental to this enterprise, and we shall use this

scenario to illustrate its development into a company specific reference process.

After developing the architecture, the company must now layout an entire end-to-

end product ordering process. Developing an E2E order business process of this

magnitude requires particular attention to detail. To start this process, a generic

reference model greatly facilitates this effort. Although it is not specific to the

company, it assists in revealing the general landscape of the operations. At this point,

it is nothing more than a conceptualization of a basic E2E scenario from which a

company specific model can be developed.

Technology can support this modeling effort. Thus, it is important to note therequirement for an effective and automated tool that supports the development and

subsequent management of the process. As the order execution business process is

being designed, the final results must be documented and implemented in the

company regardless of complexity. All of these initial steps can be accomplished by

using an automated modeling toolset such as ARIS13. ARIS can be employed as a

stand-alone product, and through a bi-directional interface, an E2E scenario can be

synchronized with the SAP Solution Manager14that is itself a component of the SAP

NetWeaver. Besides creating models using ARIS, another option is to use reference

models (i.e., process scenarios that exist in the SAP Solution Manager, which is also a

part of NetWeaver). These pre-designed models describe a business process, and

can be customized for use, and imported into ARIS. It is important to note here thatsophisticated modeling tools will assist in developing, configuring, and implementing

the E2E process. The complete process is presented in Figure 5.

13ARIS stands for Architecture of Integrated Information Systems. Additional information about ARIS may be found

at http://www.ids-scheer.com/.14

For those not familiar with the SAP Solution Manager, see Gulledge and Simon (2005).


16/22


17/22


PROCESS SCENARIOS


into a solution. To that end, we must communicate the execution process through

the various applications and legacy systems.

As noted earlier, integrated systems are fundamental to passing processes related

information between applications. Although application programming interfaces

(APIs) allow different enterprise applications to communicate with each other, the

business process logic in these applications is never passed between them. In other

words, the data is sent without any understanding of the process. The passing of

relevant and accurate data, let alone the integrity of the process is problematic.

NetWeaver provides a solution to address the data and process integration problem.

We discuss NetWeaver as a solution for implementing our extended order process in

SAP and non-SAP enterprise applications (as well as legacy systems) for those who

wish to pursue these options.

NetWeaver is a SAP compilation of products that are presented as an integratedtechnology stack. NetWeaver allows for the development, modeling and

implementation of business processes that retain integrated data bound to

enterprise services, as they are executed across the enterprise. Within NetWeaver is

a component known as the Exchange Infrastructure (XI). XI has a number of

integration components to define, map, configure, describe and store the execution

process, its associated message formats, and how it will interface with other

applications. Once the order execution process is developed in ARIS, and mapped to

the business process objects in the Solution Manager, process execution is managed

through the XI as indicated in Figure 5. The integration builder component of XI is

used to build and map one message format to another for use among the various

application systems. The process is then configured for execution; i.e., this is where

the definitions for the routing of information occur.

Using our order execution example, information received in the customer order may

be relevant to several different parts of the organization, such as accounting,

manufacturing, or delivery. Appropriate routing of this information is stored in the

(XI) directory. This directory also adds additional configuration-specific information

needed for execution. If non-SAP applications are contained within the IT landscape,

SAP NetWeaver has the ability to use other industry-specific standards for

communicating business processes across the enterprise. As an example, different

messages from external customer orders can be mapped to internal SAP message

structures. In this way, when the order is received it is communicated accurately

within SAP components. Descriptions of the various messages and processes (bothby SAP and those from its partners and customers) are kept and drawn from the

integration repository. Through these configuration activities, our model becomes

customer specific.

It is the application server that performs the tasks involved in controlling the

execution process, binding data, and exchanging its XML-based services among

other connected systems. A key component in the server is the adapter framework

that enables different applications outside of XI to communicate. Adapters (recall our


18/22


PROCESS SCENARIOS


discussion of wrappers) are used for applications within SAP, messaging systems

(e.g., SOAP), and other industry standards (e.g., RosettaNet), and non-SAP

applications (e.g., Oracle). So, if a partner in the order execution supply chain uses anon-XML format, then an adapter (that is built or procured) will enable a connection

to the XI.

How the order execution process is communicated and navigated through SAP and

non-SAP solutions is managed in the SAP Solution Manager (also a part of

NetWeaver), which manages the implementation and provides configuration

management control over those objects that are shared across the enterprise. As the

to-be execution process is configured, the complete development lifecycle is

managed within the SAP Solution Manager. Here, the order execution process

becomes testable and executable.

The SAP Web Application Server (SAP Web AS) is fundamental to both NetWeaverand the ESA approach to Web services. As the name suggests, SAP Web AS is a

server that communicates through the IP protocol. This is important to the final

development of our solution, which can now be extended as a service. Recall that the

ESA is a new paradigm for implementing enterprise solutions. The focus is not on

modules or applications, but on business processes themselves; and the business

processes need no longer be constrained to a single ERP domain. Rather, the

architecture is what enables an organization to extend its infrastructure on to the

Web and throughout the enterprise.

For example, the execution order may necessitate a special service from one of the

companys external partners (be it financial, manufacturing, or otherwise) this is

possible because NetWeaver runs on the SAP Web AS, and as long as outsideproviders follow the standards, external services may be stored for sharing inside the

SAP Enterprise Services Repository. This is critical to our process as it can now

operate end-to-end, and it truly operates across the geographical and functional

boundaries of the extended enterprise. Furthermore, new and composite solutions

can be either developed or created through re-used lower level business processes

and objects. The concept of sharing and reusable components as presented by van

de Loo (2005) is reproduced in Figure 6.


19/22


PROCESS SCENARIOS


Models are a Key Element of the Platform

ISV

components

SAP

non-platform

components

Legacy/

3rd Party

Legacy/

3rd Party

EnterpriseServices

Repository

Process ComponentsProcess Components

OEM

platform

components

Business Suite

SAP Composite Apps

(incl. UI & analytics)

ISV / CustomerComposite Apps

(incl. UI & analytics)

Legacy/Partner

Services

Services

Events

Process snippets

Object models

Roles

UI patterns

The platform contains one consistent set of models

Contributed by any component

Used by any component

Slide taken from Kaj van de Loo, The SAP Business Process Platform, presentation at Burt on Group Catalyst, 2005

Figure 6: Object sharing across the enterprise is accommodatedby the SAP Business Process Platform

Although it may not be readily apparent, Figure 6 is key to understanding the value

proposition for the Enterprise Services Architecture and Service Oriented

Architecture as a general concept. The value of service orientation follows from re-

use. In this case, the re-use is from the sharing of services across the enterprise.

Hence, if service oriented enterprise solutions are implemented in stovepipes, and

the objects are not shared, the value proposition evaporates, just as it does with

traditional highly interfaced enterprise solutions.


20/22


PROCESS SCENARIOS


CONCLUSIONS

We have shown, using a generic reference scenario and model, how management

can ensure a true business process orientation across a heterogeneous information

system landscape. This is in contrast to current approaches that interface existing or

new families of systems to achieve an implied process flow that is bound by the

nature of the interfaces. We accomplished this by bounding a composite process

with a reference process that is first presented in generic terms. The scenario is then

translated (through object mappings or interface service presentations) into an E2E

solution that can be implemented in a heterogeneous system landscape in the SAP

Solution Manager.

The intent of the methodology is to facilitate a companys understanding and

capacity to design integrated E2E business solutions using new technologies. The

E2E solution extends the functionality of an organizations systems in a complex

enterprise wide IT environment while remaining true to the real world business

processes that must be executed to obtain competitive advantage. The powerful,

new technologies used to develop these processes are rapidly emerging. Against the

backdrop of these new capabilities, novel applications can be modeled, automated,

implemented, and executed to achieve competitive advantage.

RELATED PAPERS

This and White Papers on other related topics can be downloaded from

http://www.eiisolutions.net/


21/22


PROCESS SCENARIOS


REFERENCES

Author Unknown (2001), mySAP Technology for Open eBusiness Integration, SAP White Paper,

Retrieved April, 2005 from [http://www.sap.com/solutions/netweaver/pdf/overview.pdf/]

Author Unknown (2005), iWay Universal Adapter Framework for SAP NetWeaver, iWay Software,

Retrieved April, 2005 from

[http://www.iwaysoftware.com/pdf/tech_brief/TechBrief_SAPNETweaver.pdf].

Author Unknown (2004), SAP XI 3.0 Adapter Framework. SAP AG, Retrieved April, 2005 from

[https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/xi/3.0/SA

P%20Exchange%20Infrastructure%203.0%20-

%20Adapter%20Framework%20Overview_0_.pdf].

Author Unknown (2005), ARIS for SAP NetWeaver: The Business Process Design Solution for SAP

NetWeaver. IDS Scheer AG. Retrieved April 2005 from [http://www.ids-

scheer.com/international/english/products/aris_implementation_platform/31291].

Chou, D. et al. (2004), Model-driven Business Process Integration and Management: A Case Study with

the Bank SinoPac Regional Service Platform.

[http://www.research.ibm.com/journal/rd/485/zhu.html]

Clemmons, S. and S.J. Simon (2001), Control and Coordination in Global ERP Configuration, Business

Process Management Journal, 7 (3), pp. 205-215.

Eisenberg, R. (2004), Open for Business, Retrieved April, 2005 from

[http://www.intelligententerprise.com/showArticle.jhtml?articleID=19502159/].

Enterprise Services Architecture - An Introduction (2004), Walldorf, Germany: SAP AG.

Fotis, R. (2003). SAP Exchange Infrastructure: An Overview of SAP Integration Technology, SAP AG,

Retrieved April, 2005 from [http://www.sap.co.il/ppts/Rico%C2%B4s%20XI%20Overview.pdf].

Gulledge, Thomas and Georg Simon (2005), The Evolution of SAP Implementation Environments: ACase Study from a Complex Public Sector Organization, Industrial Management & Data

Systems, 105 (6), pp. 714-736.

Gulledge, T.R., R.A. Sommer, and J.P. Vincent (2005), An Introduction to Basic Enterprise Resource

Planning Concepts, International Journal of Management & Enterprise Development, 2 (2), pp.

204-218.

Gulledge, Thomas (2005), What is Integration? Forthcoming in Industrial Management & Data

Systems.

Ho, C.F., W.H. Wu, and Y.M. Tai (2004), Strategies for the Adaptation of ERP Systems, Industrial

Management & Data Systems, 104 (3), pp. 234-251.

Hofreiter, B. and Huemer, C. (2004), Transforming UMM Business Collaboration Models to BPEL, Lecture

Notes in Computer Science, 3292, pp. 507-519.

Hurwitz, Judith (2003), Composite Applications: Leveraging Assets for New Business Models. CIO

Online, Retrieved April, 2005 from [http://www2.cio.com/analyst/report1726.html].

Jorns, C. Fit for SAP NetWeaver? Use the Potentials of Integrated and Innovative Processes in the Best

Way, IDS Scheer AG, Retrieved April, 2005 from [http://www.ids-scheer.com]

Leymann, F, Roller, D and Schmidt T. (2001), Web Services and Business Process Management.

[http://www.research.ibm.com/journal/sj/412/leymann.html]

Mecella, M. and Pernici, B. (2001), Designing Wrapper Components for e-services in Integrating

Heterogeneous Systems, The International Journal on Very Large Data Bases, vol. 10 (1), pp 2-15.


22/22


PROCESS SCENARIOS

C i h 2008 i i All i h d 22

Medaille, P. (2004), Using SAP XI to Integrate Heterogeneous Landscapes. SAP Labs, Retrieved April,

2005 from

[https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/xi/Use%20SAP%20XI%20to%20Integrate%20Heterogeneous%20Landscapes.pdf].

Okrent, M. and R. Vokurka (2004), Process Mapping in Successful ERP Implementations, Industrial

Management & Data Systems, 104 (8), pp. 637-643.

Schmitz, D. Lakemeyer, G. Gans, G. and Jarke, M. (2004), Using BPEL Process Descriptions for Building

Up Strategic Models of Inter-Organizational Networks. Lecture Notes in Computer Science, pp.

520-532.

Seebeyond.com (2005), Composite Applications and Service-Oriented Architectures, Retrieved April,

2005 from [http://www.seebeyond.com/resource/index.asp].

Volmering, T. and Scholz, T. (2004), A Shared Language for Business and IT, SAP AG, Retrieved April,

2005 from

[http://www.sap.info/index.php4?ACTION=noframe&url=http://www.sap.info/public/en/catego

ry.php4/Category-28943c61b1e60d84b/page/7/article/Article-1304740f658013176e/en/articleStatistic/].

van de Loo, K. (2005), The SAP Business Process Platform, Presentation at the Burton Group Catalyst

Conference, 13 July, San Diego, California.

Volmering, T. et al. (2004). BPM in Practice: Modeling Business Processes. SAP AG. Retrieved April,

2005 from [https:/.../documents/a1-8-4/ BPM251%20-

%20BPM%20in%20Practice%20Modelling%20Business%20Processes.pdf].

Waloszek, Gerd. (2005), Crossing Boundaries with Composite Applications, SAP Design Guild Online,

Retrieved April, 2005 from [http://www.sapdesignguild.org/editions/edition7/intro_article.asp].

Woods, D. and Word, J. (2004), SAP NetWeaver for Dummies. Wiley Publishing Inc.

END NOTES

Hofreiter, B. and Huemer, C. (2004) Lecture Notes in Computer Science, 3292, 507-519.

Mecella, M. and Pernici, B. (2001) The VLDB Journal The International Journal on Very Large Data Bases,

10, 2-15.

Schmitz, D., Lakemeyer, G., Gans, G. and Jarke, M. (2004) Lecture Notes in Computer Science, 3292,

520-532.

Date post:	02-Jun-2018
Category:	Documents
Upload:	aminab1
View:	234 times
Download:	0 times

06wp02 Impl SAP From E2E Scenarios

Documents