Developing Applications with Enterprise SOA

Martin Huvar, Timm Falter, Thomas Fiedler, Alexander Zubev

Developing Applications with Enterprise SOA

Bonn � Boston

ch00_FM_5133.indd 3ch00_FM_5133.indd 3 6/4/08 12:37:51 PM6/4/08 12:37:51 PM

http://www.sap-press.com

Contents at a Glance

1 Introduction to Enterprise Service-Oriented Architecture ................................................................. 13

2 The Building Blocks of SOA Middleware .................... 33

3 Model-Driven Business Process Development ........... 49

4 Components of SOA Middleware ............................... 67

5 Interaction Models for SOA Middleware .................... 103

6 Developing an Enterprise Service ............................... 143

7 Developing an Enterprise Service – Based Consumer Application .................................................................. 175

8 Confi guring an Enterprise Service–Based Scenario ..... 241

A Standards for Service-Oriented Architectures ............ 315

B The Authors ................................................................. 321


www.sappressbooks.com

7

Contents

1 Introduction to Enterprise Service-Oriented Architecture ................................................................. 13

1.1 About this Book ............................................................ 141.2 Defi nition of Enterprise SOA ........................................ 171.3 Enterprise SOA from the Perspective of Business

Processes ...................................................................... 191.3.1 The Challenges of Today’s Business World .......... 191.3.2 New Challenges in Attaining Company Goals ...... 211.3.3 Enterprise SOA: A New Architecture for New

Business Models ................................................. 221.4 Enterprise SOA: A Technical Perspective ....................... 28

1.4.1 Web Services: The Base of Enterprise SOA .......... 291.4.2 System Landscape and System Architecture in

Enterprise SOA ................................................... 301.4.3 SAP NetWeaver: Integration and Development

Platform ............................................................. 31

2 The Building Blocks of SOA Middleware ..................... 33

2.1 SOA Middleware for all Types of Applications ............... 342.2 Different Entry Points, One Integration Platform ........... 362.3 Building Blocks of SAP SOA Middleware ....................... 39

2.3.1 The Enterprise Services Repository ..................... 392.3.2 The Service Bus .................................................. 412.3.3 SOA Management .............................................. 44

2.4 Summary ..................................................................... 47

3 Model-Driven Business Process Development ........... 49

3.1 Specifi cation ................................................................. 503.1.1 Process Model .................................................... 523.1.2 Business Object Overview .................................. 523.1.3 Integration Scenario Model ................................ 533.1.4 Process Component Model ................................. 55



8

3.1.5 Process Component Interaction Model ............... 553.2 Design .......................................................................... 573.3 Implementation Phase .................................................. 613.4 Example of a Modeling Process ..................................... 62

3.4.1 Integration Scenario Model ................................ 633.4.2 Process Components .......................................... 643.4.3 Process Component Interaction Model ............... 65

4 Components of SOA Middleware ................................ 67

4.1 ES Repository ................................................................ 714.1.1 Enterprise Services Builder ................................. 724.1.2 Modeling Component ........................................ 754.1.3 Tools ................................................................. 774.1.4 Software Logistics ............................................... 78

4.2 Development Environment and Tools ............................ 804.3 Services Registry ........................................................... 85

4.3.1 The Services Registry: The “Yellow Pages” of a Service Landscape ............................................ 86

4.3.2 Architecture ....................................................... 894.3.3 Publish and search with the Services Registry ..... 92

4.4 Integration Server ......................................................... 99

5 Interaction Models for SOA Middleware .................... 103

5.1 Fundamental Paradigm and Processing Flow ................. 1035.1.1 Consumer Side ................................................... 1045.1.2 Provider Side ...................................................... 1055.1.3 Summary of the Processing Sequence ................. 1065.1.4 Runtime Properties During Interaction ............... 106

5.2 Asynchronous Scenarios ................................................ 1095.2.1 Confi guration of the Runtime Properties for

Asynchronous Scenarios ..................................... 1095.2.2 The Consumer Side in Asynchronous Processing ... 1105.2.3 The Provider Side in Asynchronous Processing .... 1125.2.4 Summary of the Steps for Asynchronous

Scenarios ............................................................ 1145.2.5 Sequencing through In-Order Processing ............ 115



9

5.2.6 SAP Sequencing ................................................. 1215.2.7 Avoiding Sequencing ......................................... 1275.2.8 Modeling the Behavior for Asynchronous

Scenarios ............................................................ 1305.3 Synchronous Scenarios .................................................. 130

5.3.1 Confi guring the Runtime Properties of Synchronous Scenarios ....................................... 131

5.3.2 Stateless Read .................................................... 1335.3.3 Tentative Update & Confi rm or Compensate

(TU&C/C) ........................................................... 1345.3.4 Stateful Write and Update .................................. 141

6 Developing an Enterprise Service ................................ 143

6.1 Modeling a Service Interface ......................................... 1466.1.1 Organizing the ES Repository Content ................ 1476.1.2 Modeling the Data Types .................................... 1506.1.3 Modeling a Service Interface .............................. 1526.1.4 Working with Change Lists ................................. 160

6.2 Service Implementation ................................................ 1626.2.1 Proxy Generation ................................................ 1626.2.2 Proxy Implementation ........................................ 166

6.3 Classifying and Publishing a Service ............................... 1686.3.1 Business Context as a Classifi cation Criterion ...... 1686.3.2 Publishing from the Provider System ................... 170

7 Developing an Enterprise Service – Based Consumer Application ................................................................... 175

7.1 Challenges in Developing a Consumer Application ........ 1757.2 SOA Middleware’s Solutions for these Challenges ......... 180

7.2.1 Services Registry ................................................. 1807.2.2 Service Group ..................................................... 1837.2.3 Dynamic Service Call .......................................... 187

7.3 Overview of the Development Process .......................... 1887.3.1 Discover and Import Services ............................. 189



10

7.3.2 Implement the Consumer ................................... 1897.3.3 Classify and Publish the Consumer Application ... 192

7.4 Developing a Consumer Application with SAP Development Tools ....................................................... 1937.4.1 Consumer Development in SAP NetWeaver

Developer Studio (JEE 5) .................................... 1987.4.2 Consumer Development in Web Dynpro for Java 2137.4.3 Consumer Development in ABAP ....................... 232

8 Confi guring an Enterprise Service–Based Scenario ..... 241

8.1 Overview of the Fundamental Concepts ........................ 2418.1.1 Goals of Confi guration in SOA Middleware ......... 2438.1.2 Requirements for SOA Middleware–Based

Confi guration ..................................................... 2448.2 Integrated Confi guration of a Scenario Using the SOA

Management Cockpit .................................................... 2538.2.1 The Confi guration Process on a Concept Level .... 2538.2.2 Confi guration Process: Example .......................... 275

8.3 Outlook: The Cross-System Confi guration of a Scenario 2908.3.1 Confi guration Process on a Conceptual Level ...... 2908.3.2 Confi guration Process: Example .......................... 304

Appendices

A Standards for Service-Oriented Architectures .......................... 315A.1 Standards for Design Time ............................................ 315

A.1.1 WS-MetadataExchange ...................................... 315A.1.2 Service Component Architecture ........................ 315

A.2 Confi guration and Management .................................... 315A.2.1 Web Service Reliable Messaging ......................... 315A.2.2 WS Addressing ................................................... 316

A.3 Generic XML and Communications Standards ............... 316A.3.1 Extensible Markup Language ............................... 316A.3.2 XML Schema ...................................................... 316A.3.3 SOAP ................................................................. 317A.3.4 MIME ................................................................. 317A.3.5 HTTP .................................................................. 318



11

A.3.6 WSDL ................................................................. 318A.3.7 Web Services ...................................................... 318A.3.8 Enterprise Services .............................................. 318

A.4 Security ........................................................................ 319A.4.1 WS-Security ....................................................... 319A.4.2 SAML ................................................................. 319

B The Authors ........................................................................... 321

Index ............................................................................................. 323



49

SAP ships the application platform in a number of different ver-sions, so as to best accommodate the requirements of large enter-prises, mid-sized companies, and small companies. This chapter offers you an overview of the approach used to model processes and services in each of the platform variants.

Model-Driven Business 3Process Development

A model-based development process is used to describe business pro-cesses on the business process platform. Modeling, naturally, has a cen-tral role in model-driven software development. Modeling makes the software development process more effective and more efficient and creates components that are suited for reuse. This chapter offers a brief introduction to the SOA development process, focusing on the role of process modeling and the different process model types.

The development of business applications can be divided into three phases: specification, design and implementation. This modeling process allows the complexities of a business process to be made transparent on different abstraction layers for different developer groups. Each of these phases has its own models and entities, which are closely interrelated, as shown in Figure 3.1.

In the specification phase, application requirements are mapped to busi-ness process models. The business process models contain process mod-els and process integration models to define a static view of process com-ponents, their internal structure, and the relationships between them. The main focus is on integration and service orchestration among pro-cess components, and less on specific business process functionality.

In the design phase, the details of the service interfaces are defined. The models from the specification phase form the basis for the design-time

Development phases

Specification

Design

178 BOOK.indb 49 6/5/08 10:01:32 AM


50

3 Model-Driven Business Process Development

entities. Here, the service models are created, which determine the ser-vice definitions, that is, the operations, parameters, and data types.

Specification phase

Design phase

Implementation phase

Business processintegrationscenarios

Service interfacemodels Global

Data types

Service providerProxy data types

Design objects are generated

Runtime objectsare generated

Relationships between Models and Entities in Each Development PhaseFigure3.1

In the implementation phase, the executable code is created. The services modeled in the design phase are turned into a platform-dependent rep-resentation. This step, known as proxy generation, creates the interfaces and implementation classes for the services. These generated entities are then enhanced with business and integration logic, which is normally programmed manually. The sections that follow explain the individual modeling phases in greater detail.

Specification3.1

The development cycle begins with the specification phase, in which requirements for the business applications are mapped to suitable mod-els. The specification phase starts with portfolio planning. Here, you identify the application requirements and functionalities that the soft-ware application will provide. Portfolio planning produces a list of appli-cation scenarios and a description of the functions to be implemented.

The results of portfolio planning are passed on to the technical process models. The following steps are performed:

Implementation

Mapping requirements

Technical process models

178 BOOK.indb 50 6/5/08 10:01:33 AM


51

Specification 3.1

Define the business processes on a non-technical level. EE

Result: Process model

Identify the function components needed by the integration scenario. EE

These are business objects, process components, and deployment units. Result: Business object overview

Define the interaction between the process components in the inte-EE

gration scenario. Result: Integration scenario model

Specify the communication details between the process components, EE

identify the enterprise services needed, and model the sequence of service calls. Result: Process component model and process component interaction model

Figure 3.2 shows the relations between these steps.

Portfolio Planning

Process flow model

Business object overview

Integration scenario model

Process component models

Select the integration scenariosDescribe the features and functions

Define the business processes on a non-technical level

Identify the function modules: • Business objects, • Process components, • Deployment units

Model the process components and their interactions

Identify and model services

Process component interaction modelsModel the service interactions

Overview of the Specification PhaseFigure3.2

178 BOOK.indb 51 6/5/08 10:01:33 AM


52


Process modeling in the specification phase is done via a top-down approach. The modeling begins with the rough modeling, which is described by the integration scenario model. From this model, two more detailed models are derived: the process component model and the pro-cess component interaction model.

However, before the integration scenario model is built, a software archi-tect defines the process model and the business object overview based on that. In the following sections, you will learn more about the indi-vidual steps in the specification phase.

Process Model3.1.1

After the portfolio has been planned, the first step is to build the process model. The aim of this model is to represent the process flow on the application level, that is, to abstract it from technical implementation details. The modeler defines the flow using standardized models, such as the Business Process Modeling Notation. Typically, the process flow is modeled using activities, control flows, and operators that determine the control flows (decisions, divisions, connections).

The example in Figure 3.3 shows the process flow for material order processing.

Business Object Overview3.1.2

Next, you define the business object overview. Here, you identify the basic building blocks that make up the business processes in the follow-ing order:

Business objectsEE

Process componentsEE

Deployment unitsEE

When the business object overview is complete, the next step is to define the interaction between the process components using the integration scenario model.

Top-down

Basic building blocks

178 BOOK.indb 52 6/5/08 10:01:33 AM


53

Specification 3.1

Activity Operator CompleteSales Order

Controlflow

Create/Change Sales Order

Check General Data

Completeness

CheckConsistency

Check Product Availability and Confirm

Cancel Sales Order

Request Product Availability Inform.

and ProvisionalReservation

Customer Requirement

Processing

Cancel Sales

Order

Request Invoicing

Request Cust. Product Requir.

Reservation and Fulfillment

Customer Invoice

Processing

Customer Requirement

Processing

Accounting Notify Accounting

Confirm Sales Order

Purchase Order

Processing at Customer

Change Sales Order Based on Customer

Invoice

Change Sales Order Based on

Product Availability Update

Change Sales Order Based on

Cust. Prod. Requir. Fulfillment Confirm.

Confirm Customer Invoice

Issue

Notify of Availability

ConfirmationUpdate

Confirm Product Customer

Requirement Fulfillment

Create Sales Order

Change Sales Order

Purchase Order Processing at Customer

Process Flow for Material Order ProcessingFigure3.3

Integration Scenario Model3.1.3

Process components group semantically related steps together. To flexibly group the business process platform entities, the semantically related process components are grouped into deployment units. This grouping is set up so that each deployment unit can be installed on a separate system. Thus, interaction between process components from different deployment units always takes place through the A2A enterprise service interaction. On the other hand, interactions within a process component are normally done by direct communication through method calls or function module calls.

Process components are self-contained and make up the reusable units in the business process architecture that are used in multiple integra-tion scenarios. The entities in a process component and the services it provides are represented graphically by a process component model. A process component is composed of one or more business objects and typically represents a self-contained functional area within a company,

Process components

Reusable units

178 BOOK.indb 53 6/5/08 10:01:34 AM


54


such as order requirements processing. Within process modeling, these process components are self-describing, reusable components that can be combined to describe different integration scenarios.

The interaction of all the process components in a business process is known as an integration scenario and is represented graphically by an inte-gration scenario model. Integration scenarios describe end-to-end busi-ness processes, which are composed of subprocesses defined through process components. The integration scenario model represents the highest level of abstraction in the design and implementation.

An integration scenario, as represented in Figure 3.4, describes a busi-ness scenario using the following three entities:

Deployment unitsEE

Process componentsEE

Interactions between process componentsEE

Processcomponent

Processcomponent

Processcomponent

Processcomponent

A2A Enterprise

service interaction

Directinteraction

B2B Enterprise

service interaction

Deployment unit

Deployment unit

Example of an Integration ScenarioFigure3.4

Interaction of components

178 BOOK.indb 54 6/5/08 10:01:34 AM


55

Specification 3.1

The interaction between two process components is represented in the integration scenario model as an arrow indicating the direction of the process flow. For communication beyond deployment unit and B2B, this interaction is refined through a dedicated model: the process component interaction model.

The integration scenario model is the entry point for a series of other more detailed models. On one hand, there is the process component model, which described the details of a process component. On the other hand is the process component interaction model that refines the cross-deployment unit and B2B communication.

Process Component Model3.1.4

A process component model provides details of the internal structure of a process component. It describes the business objects and the service interface operations of the consumer and the provider.

Process components can contain one or more business objects, but each business object belongs to exactly one process component. A business object represents a class of uniquely identifiable entities in business life, for example, sales order or business partner. An operation is the abstract description of a functionality or process provided through a service. Each operation is part of a service interface, which represents the group-ing of semantically related operations.

Processcomponent

Service Interface

OperationBusiness

objectProcess

component

Service Interface

Operation

Process Component ModelFigure3.5

Process Component Interaction Model3.1.5

The precise interaction of two process components is graphically repre-sented by a process component interaction model. Here, the modeling is restricted to the interactions that are implemented by services. Direct interactions between process components in the same deployment unit

Business objects

Connecting process components

178 BOOK.indb 55 6/5/08 10:01:34 AM


56


are not specified in detail within the model. The process component interaction model defines how the outbound interfaces of one process component are connected with the inbound interfaces of another com-ponent. Figure 3.6 illustrates this situation.

Message Type

Process component

Service interface

Operation

Businessobject

Service interface

Businessobject

Process componentinside company

Operation

Operation

Operation

Operation

Service interface

Service interface

Operation

Message Type

Message Type

Process Component Interaction ModelFigure3.6

Typically, the interaction between two process components contains sev-eral steps. For this reason, request-confirmation interaction models are often more complex than those described in Figure 3.6. In the figure, a request call is sent from one process component to another, followed by a confirmation call, which is sent in the opposite direction. It is impor-tant to note that this interaction model is not a request-response mes-sage exchange pattern in the sense of SOAP (see Chapter 5, Interaction Models for SOA Middleware). In this case, both calls, or messages, are defined as part of a single operation, and the response to the request is sent synchronously. In the request-confirmation interaction model, both calls are defined as separate, asynchronous operations belonging to two service interfaces, whose only relationship with each other is through the process component interaction model.

In this way, the process component interaction model is used to define relationships between service interfaces or operations that cannot be formulated on the SOAP or WSDL level but are nevertheless needed to fully describe process relationships.

178 BOOK.indb 56 6/5/08 10:01:35 AM


57

Design 3.2

The process component model and the process component interaction model essentially contain the same types of objects. To be more precise, the two models present two different views of the same data model:

The process component interaction model represents the EE connection-oriented view. It contains only parts of two related process compo-nents which are relevant for a specific interaction. It also contains the definition of the SOAP messages to be exchanged and the sequence of the service calls.

The process component model represents the EE structure-oriented view of the data. It contains all the business objects and all the service interfaces and operations that are called or provided within the pro-cess component.

As such, the process component model and the process component inter-action model are the connective links on the path from modeling to design. All the entities specified in these models have an equivalent in the design-time level. Both models are used to generate the correspond-ing design-time entities.

Design3.2

After the specification phase comes the design phase, where you define in detail how the individual business process components will look. This step is still on a very abstract model level.

In the design phase, the data structures are created from the business object models, and the service interfaces are defined. The data types and service operations are modeled independently of any particular pro-gramming language. These service operations handle the exchange of the business documents (described by their data types) that are processed within the process steps. Service operations are used primarily for A2A and B2B communication and are therefore based on open E-business standards. The underlying metamodel for service interfaces and data types is based on the World Wide Web Consortium (W3C) standards Web Services Description Language (WSDL) and XML Schema (XSD).

One model, two views

Creating data structures

178 BOOK.indb 57 6/5/08 10:01:35 AM


58


The quality of a service is determined to a significant extent by the data types used in it, as the data types have the greatest influence on how eas-ily a service can be implemented on the provider side and used by a con-sumer. The service interfaces are defined using global data types (GDTs). A GDT is a business world data type that is defined and consolidated throughout the SAP landscape and complies with established Internet and business standards or their extensions.

Data types are defined under strict guidelines in accordance with a uni-fied SAP modeling process (a governance process) that ensures that exist-ing types are reused and that new types are subject to certain rules. Nam-ing rules for data types comply with ISO11179, ensuring that the names of the data types and their elements correspond exactly to the semantic meaning. To increase reuse, SAP has defined GDTs that uniquely specify frequently reoccurring entities (such as currency and date). A mainstay of data modeling is ensuring the integrity of the data types among each other, which can be done by deriving them from a common object model. The individual data types needed for a particular scenario can then be obtained by aggregating the types from the business object model. A complex data type is created by using the object hierarchy to combine the fine-grained business object types into this course-grained type.

Semantic integration of components is an important unique selling point in competition with other software vendors. In addition to the tools and frameworks for this, SAP also ships the business content (process integration content) that is needed for communication between systems and their components. This content is designed in accordance with inter-national standards. This outside-in approach ensures that SAP (inside) speaks the language of the business world (outside). The basis for this is formed by an integrated business object model that describes the busi-ness-relevant concepts and relationships and is harmonized across indus-try and business sectors. The implementation of semantic integration across industry and business sectors is due, to a large extent, to the SAP normed data types.

Data types determine the types of unified elements in business objects or operations, which generally have a hierarchical structure. The types of their leaf elements are determined by GDTs, in accordance with the following principles:

Global data types

Governance process for data

types

Standardized interfaces based on

GDTs

Principles of typing

178 BOOK.indb 58 6/5/08 10:01:35 AM


59

Design 3.2

If the same semantic state occurs, then the type is always determined EE

by the same GDT.

The types of all leaf elements are determined by GDTs.EE

GDTs are based on a set of fundamental types, known as core component types (CCTs):

AmountEE Amount with a currency unit

BinaryObjectEE Data stream consisting of any binary characters

CodeEE Abbreviated representation of a value, a method, or a property

DateTimeEE Timestamp of a calendar

URIEE Unique digital address in the form of a uniform resource identifier

IdentifierEE Unique identifier of an object

IndicatorEE Binary code specifying a state (0/1 or true/false)

MeasureEE Physical measure with the unit

NumericEE Decimal value

QuantityEE Quantity with the unit

The CCTs were specified by the UN/CEFACT in the ebXML Framework and are based on the W3C XML Schema definition. The CCTs do not pos-sess any business semantics; they merely describe a structure. Only GDTs have business semantics.

In summary, GDTs have the following properties and benefits:

Core component type

Properties and benefits of GDTs

178 BOOK.indb 59 6/5/08 10:01:35 AM


60


They represent reusable data types that are used to define enterprise EE

services. Identical attributes in different service interfaces are always described by the same global data type or a derivative of it.

They are defined throughout all application areas and adhere to high EE

standards. This is guaranteed by the Governance Process for Business Content, which was developed by the SAP Process Integration Coun-cil and is monitored by them.

Their content is based on open business and industry standards, such EE

as RosettaNet.

They were developed in accordance with the modeling methodology EE

described in the international standards ISO 15000-5 and UN/CEFACT Core Component Types Specification (CCTS). This methodology, with its well-defined, controlled, semantics-oriented vocabulary and pre-defined XML Schema fragments, is specifically designed for building a consistent business data model.

Technically, GDTs are defined using the XML Schema.EE

This is the foundation for a consistent, non-technology-driven data type world, based on business-oriented semantics, throughout all SAP appli-cations and especially for service interfaces.

Figure 3.7 shows a metamodel summarizing the entities described in the sections on the specification and design phases.

..

*

1

*

1 1

*

* Specification entity (used in graphical models)

Deployment unit

Integrationscenario

Processcomponentinteraction

Service interface (inbound)

Business object Service interface(outbound)

Operation(inbound)

Data type Operation (outbound)

Processcomponent

1 ..*

1..*

1 ..* *

1 ..*

1..* 1..* 1..*

1..*1..*

0..1

1 ..*

1 ..*

1 ..*

leads to changes triggers uses

1..*

Metamodel of the Specification and Design EntitiesFigure3.7

178 BOOK.indb 60 6/5/08 10:01:35 AM


61

Implementation Phase 3.3

Implementation3.3 Phase

Up until this phase, we are still working on a very abstract modeling level. The actual mapping onto a runtime system and a programming language is done in the final phase, the implementation phase, in which the individual components are implemented.

In this phase, it is important that the transition from an abstraction phase to the next phase is done through an automatic generation process. Only in this way can consistency between the individual abstraction phases be achieved. After the services are modeled in the design phase, proxy generation occurs. In proxy generation, the metadata descriptions of the services and data types are used to create a representation, known as a proxy, in the ABAP development system or in the SAP NetWeaver Devel-oper Studio for Java (support for .NET proxies is planned for the future). In this phase, the metadata and programming language constructs for ABAP or Java, such as DDIC types, ABAP, or Java classes or interfaces, are created.

ABAP and Java developers only work with the corresponding proxies in their familiar development environment; they do not need to be con-cerned with the technical side of communication and of conversion to an XML document. A service is implemented by defining a method for each service operation defined in the ES Repository in the corresponding ABAP or Java class. A service is called using generated typed consumer proxies or generic interfaces in the infrastructure. In both cases, meth-ods are made available to execute the service operations defined in the ES Repository.

The infrastructure offers additional framework functionality in addition to proxy generation, such as transaction control, which can be used both to implement and to consume services. This functionality is a part of the SOA middleware programming model and is not described in the ES Repository. You can find a detailed description of service implementation in Chapter 6, Developing an Enterprise Service.

Mapping at runtime

Proxy generation

178 BOOK.indb 61 6/5/08 10:01:35 AM


62


Example of a Modeling Process3.4

We will now use a simple example to illustrate the entities and model types introduced in the previous sections. Figure 3.8 shows the inter-action of process components in a simple sales process integration scenario.

Buyer

Order creation Sales order processing

Vendor

B2B

A2AA2A

Invoice processing

Customer requirements

check

Interaction of Process ComponentsFigure3.8

This simplified integration scenario illustrates the process from ordering a product through processing the sales order, and invoicing. It involves the following steps:

1. A customer submits an order in his system. This involves business objects such as the sales order, the product, and the business partner.

When the order is completed, an electronic message is sent to the 2. vendor so the order can be processed. In the vendor’s system, a pro-cess component is started that creates a quote from the order. This takes place in the CRM deployment unit.

In this procedure, an availability check is first made to verify whether 3. the products are available in the quantity ordered.

If the check is positive, an order confirmation is sent to the buyer, and 4. invoicing is triggered.

The sections that follow will step through the modeling process for the vendor side of this process. We will not consider the buyer side, as we

Process steps

178 BOOK.indb 62 6/5/08 10:01:36 AM


63

Example of a Modeling Process 3.4

are working on the assumption that the purchase order is sent by an order application of another company. Consequently, this step is neither modeled nor implemented.

For this scenario, we identify four business objects: SalesOrder, Customer-Requirement, CustomerInvoiceRequest, and CustomerInvoice. These business objects are located in three process components, as shown in Figure 3.9.

It should also be possible for each process component to run in a sepa-rate system. For that reason, the process components are distributed over three deployment units.

Customer RelationshipManagement

SalesOrder

Sales Order Processing

Supply Chain Control

CustomerRequirement

Customer Requirement Processing

Customer Invoicing

Customer Invoicing

CustomerInvoice Request

CustomerInvoice

Components for the Vendor SideFigure3.9

Integration Scenario Model3.4.1

When the business object overview has been completed, the next step is to use the integration scenario model to define the interaction between the process components. The scenario Sell from Stock is shown in Figure 3.10.

Business objects

178 BOOK.indb 63 6/5/08 10:01:36 AM


64


Supply Chain Control

Customer Invoicing

Customer RelationshipManagement

Purchase OrderProcessing(Customer)

Sales OrderProcessing

CustomerRequirementProcessing

Customer Invoicing

Interaction between the Process ComponentsFigure3.10

In this example, the interactions needed in the vendor’s system are implemented through asynchronous services between the process com-ponents. It is assumed here that the individual process components are defined in different deployment units and may potentially be installed in different systems.

Process Components3.4.2

Figure 3.11 shows the process component model for the SalesOrder Pro-cessing process component.

SalesOrder

SalesOrderProcessing

InvoiceIssuedIn

Changed Order basedon Invoice

InvoicingOut

RequestInvoicing

Process Component Model for the SalesOrderProcessing Process Figure3.11Component

178 BOOK.indb 64 6/5/08 10:01:37 AM


65

Example of a Modeling Process 3.4

The graphic shows an example of the entities in a process component model. In the center of the diagram, the SalesOrder business object is shown. This is the central object in the sales process. From this object, the process of generating the invoice is triggered. This process kicks in after the sales order has been correctly saved in the system. This process step is implemented through the service interface InvoicingOut with the RequestInvoicing operation, which is shown at the top-right of the dia-gram. Another interface in the SalesOrderProcessing process component is the inbound interface for invoice creation. This interface can be used to notify the invoicing part of sales processing that the invoice has been created for the sales order. The interface is also described as a service interface with an operation.

Process Component Interaction Model3.4.3

Following on from that example, Figure 3.12 shows the process compo-nent interaction model for the SalesOrderProcessing and InvoiceProcessing process components.

SalesOrder

SalesOrderProcessing

InvoiceIssuedIn

Changed Order basedon Invoice

InvoicingOut

RequestInvoicing

InvoiceRequest

InvoiceProcessing

InvoiceIssuedOut

Confirm Invoice

InvoicingIn

Maintain InvoiceInvoiceRequest

InvoiceConfirmation

Invoice

Process Component Interaction Model for SalesOrderProcessing and Figure3.12InvoiceProcessing

On the left of the diagram is the SalesOrderProcessing process compo-nent with the SalesOrder business object and the two service interfaces InvoicingOut and InvoiceIssuedIn. Also, in this graphic the interactions are modeled with the InvoiceProcessing process component. There are

178 BOOK.indb 65 6/5/08 10:01:37 AM


66


two process steps: the asynchronous interaction InvoiceRequest, which is located between the SalesOrderProcessing and InvoiceProcessing process components. The graphic also shows some internal details about the process components, particularly the SalesOrder business object within the SalesOrderProcessing component, which initiates communication to invoicing, and the consumer service interface InvoicingIssuedOut, which contains the consumer operation RequestInvoicingIn, used for communi-cation. The same types of entities are used on the provider side, that is, the process component InvoiceProcessing. The service interface InvoicingIn with the operation Maintain Invoice makes up the inbound interface of the process component. When it is called, this interface generates an invoice request (the business object InvoiceRequest) by calling opera-tions in the business logic. The next internal process step is to create an invoice from the invoice request. When the invoice has been created, communication changes direction. The confirmation process for the Sale-sOrder process component is called through the service operation Con-firm Invoice in the service interface InvoicingIssuedOut.

This causes the business document InvoiceConfirmation to be sent to the process component SalesOrderProcessing, where is it processed within the service operation Change Order based on Invoice in the service inter-face InvoiceIssuedIn. At the same time, the business object SalesOrder is modified by adding the invoice information. This last step in the process chain completes the process of order creation.

178 BOOK.indb 66 6/5/08 10:01:37 AM


323

A

ABAP objects, 166ABAP proxy objects, 81ABAP Workbench, 68, 81, 162, 233Amount, 59Application

release, 283, 308Application administrator, 243, 244, 254, 268, 291, 298, 300Applications

release, 268, 298ARIS Toolset, 72Asynchronous operation, 157Asynchronous scenario, 109, 167

all steps, 114consumer side, 112modeling, 130provider side, 113

Authentication, 247, 248, 276Automatic configuration, 231

B

Best-of-breed, 19BinaryObject, 59Blocking the caller, 110Business context, 94, 178, 201, 218

restricting, 210Business object, 52, 55, 249

assign, 169Business object overview, 51Business processes, 19Business Process Modeling Notation, 52Business process platform, 49

C

Caller blocking, 107, 131

CCTS, 150Change lists, 79, 160Change management, 45Change scenarios, 87, 273, 302Code, 59Commit, 135, 141Commit handling, 108, 110, 132Communication

asynchronous, 157synchronous, 158

Communication infrastructure, 41Compensate, 135, 137, 140Compensate operation, 159Component context, 228Composite application, 34, 47, 68, 182, 203, 221, 231, 238

simplified creation, 37Compound service, 57Configuration

application, 254, 291automatic, 243mass, 243process, 253, 275, 290, 304

Configuration API, 183Configuration framework, 69, 255, 296, 299, 300Configuration framework API, 297Configuration of a scenario, 241Configuration scenrio, 68Configuring services, 145Confirm, 135, 137, 140Confirm operation, 159Consistency check, 77Consumer

implement, 188, 189implementing, 204, 238

Consumer applicationclassify, 188, 192, 203classifying, 221, 238deploy, 208developing, 175, 193

Index

178 BOOK.indb 323 6/5/08 10:02:57 AM


324

Index

developing in Java, 198development in ABAP, 232development in WD Java, 213finding, 231publish, 192

Consumer proxy, 104, 191class, 185interface, 190

Context, 181business, 94, 178define, 201defining, 218restricting, 210specifying, 236

Context-sensitive actions, 164Contract, 135

breach, 136Core Component Types (CCT), 59Core Component Types Specification (CCTS), 60Core data types, 150Coupling

synchronous, 130

D

Data binding, 227Data exchange

modeling, 227Data type editor, 76Data types, 57, 143

aggregated, 151core, 150global, 40integrity, 58metamodel, 152modeling, 58, 150

DateTime, 59Declaring dependencies, 148Delta values, 128Deployment unit, 52, 54, 249, 258, 292

assign, 168Design, 49, 57Design-time entities, 50

Destinationlogical, 184, 194, 210, 235, 297

Development component (DC), 199Development environment, 80Development process, 188

model-based, 49Development repository, 67Development tools, 28, 80Documentation, 78, 197Document style, 153Domain, 294, 305

adding systems, 295Dynamic invocation interface (DII), 187Dynamic proxy call, 185Dynamic service call, 187

E

ebXML Framework, 59Enterprise Application Archive, 200Enterprise Application Integration (EAI), 20Enterprise service-oriented architecture, 13, 33

definition, 17, 19Enterprise services, 18, 318

classify, 168developing, 143development process, 144metamodel, 154modeling, 144publish, 171

Enterprise Services Browser, 73, 74creating objects, 149SE80, 163

Enterprise Services Builder, 67, 72Enterprise Services Repository (ES Repository), 39, 46, 67, 71, 143, 149

functions, 72modeling services, 144model types, 75organizing content, 147

ERP Core Component (ECC), 194ERP Foundation, 194ES Repository object, 164

mapping to ABAP objects, 166

178 BOOK.indb 324 6/5/08 10:02:57 AM


325

Index

Exactly once, 108ExactlyOnceInOrder, 108, 115, 177Extensible Markup Language (XML), 316Extension application, 34

F

Factory, 192, 205Fault message, 156Flexibility, 20

G

Global data types, 40, 58benefits, 59

Goalstechnical, 266

Governance process, 58Grid layout, 222Guaranteed Delivery, 315

H

Heterogeneity, 19, 20Hypertext Transfer Protocol (HTTP), 318

I

Identifier, 59Implementation, 49, 50, 61Inbound plug, 224Incorrect configuration

consequences, 177Indicator, 59Initialization phase, 254, 256, 275, 291, 304Initializing the system landscape, 241InOrder, 177In-Order processing, 115, 121In-Order sequencing, 118, 119, 120Integrated publication, 98

Integration scenario model, 51, 54, 63, 75Integration server, 99Interaction models, 15Interaction pattern, 42Interface pattern, 157Invalidating calls, 122, 123ISO 11179, 58ISO 15000-5, 60

L

Lifecycle status, 181Locking objects , 161Logical destination, 184, 258, 292, 297

creating, 235defining, 210find, 194

Logical metadata, 183Logical provider, 185, 189, 191

M

Mass configuration, 243Measure, 59Message Exchange Pattern (MEP), 107, 109, 131Message type, 156Metadata, 190, 246

logical, 183service definition, 247

MIME, 317Model-driven development, 222Modeling, 15

Component, 75Object, 39

Model object, 229Model types, 75Model View Controller, 213, 215Modular functionality, 28Multipurpose Internet Mail Extensions (MIME), 317

178 BOOK.indb 325 6/5/08 10:02:57 AM


326

Index

N

Namespaces, 148Navigation, 224Notification, 42Notification mechanism, 245Numeric, 59

O

OASIS, 319Object history, 78Open technology, 28Operations, 143

asynchronous, 157synchronous, 158

Operations pattern, 157Outbound plug, 224

P

Packaged integration, 37Parameters, 143Physical system, 255, 259, 291

publish, 261Platform application, 34Plug, 224Portfolio planning, 50Print, 78Process component, 52, 53, 54, 62, 64, 249

assign, 168interaction model, 51, 55, 65, 75model,51, 55, 75, 76

Process integration model, 49Process model, 49, 51, 52Product, 147Profile

change, 274, 303Provider

classified, 209logical, 185, 189

Provider group, 268, 299Provider proxy, 104

Provider side, 15publication, 261register, 257, 259

Provider systemfinding, 208

Proxy, 61Proxy call

dynamic, 185Proxy definition, 185, 233Proxy editor, 82, 164Proxy generation, 50, 61, 80, 162

JEE 5, 205mapping rules, 190object status, 163

Proxy implementation, 166Proxy instance

creating, 239Proxy object

naming conventions, 165statuses, 163

Publicationautomatic, 260from the administration environment, 98from the ES Repository, 98integrated, 98in the Services Registry, 99manual, 260

Publishingmonitoring, 173

Publishing job, 171configure, 172

Publish/subscribe, 42

Q

Quantity, 59

R

Reconciliation, 122, 123, 130Release

application, 254information, 16status, 78

178 BOOK.indb 326 6/5/08 10:02:57 AM


327

Index

Reliable communication, 42, 108, 110, 132, 241Reliable messaging, 121Representation term, 151Request-confirmation interaction model, 56Request/reply, 42Request-response message exchange pattern, 56Rollback, 135, 142RPC style, 153Runtime properties, 106

asynchronous scenarios, 109synchronous scenarios, 131

S

SAML, 319SAP Developer Network (SDN), 16SAP NetWeaver, 29, 31SAP NetWeaver Composition Environment (CE), 35, 181SAP NetWeaver Developer Studio, 68, 198, 216, 231SAP NetWeaver Exchange Infrastructure (XI), 67SAP NetWeaver JEE 5.0, 193SAP NetWeaver Process Integration (PI), 47, 100SAP Process Integration Council (PIC), 60SAP sequencing, 121, 167SAP xApps, 36SCA, 315Scenario

configuration phases, 242configuring, 241correct configuration, 178release, 268, 298

SE80, 163, 233Search functionality, 77Security, 45, 319Security Assertion Markup Language (SAML), 319Separation of concerns, 128

Sequence, 115continue processing in new, 126restart, 122, 126

Sequence context, 120minimize, 127

Sequencing, 114, 115, 167, 177avoiding, 127consumer side, 116limitations, 121provider side, 118SAP, 121

Serviceassigning, 219classify, 246classifying, 249describe, 246documentation, 197find, 175importing, 211, 217include, 189including, 200search, 189, 199, 216, 233select, 189

Service bundling, 184Service bus, 39, 41, 46Service call, 240

consumer side, 105dynamic, 187including, 230provider side, 106static, 187

Service Component Architecture (SCA), 315Service configuration, 69

description, 250Service consumer

configure, 247, 270, 300description, 251

Service definition, 67, 144components, 247publishing, 95

Service endpoint, 245, 259, 269, 291, 300

publishing, 96Service group, 183, 192, 193, 220, 251, 258, 269, 292, 299

classification, 186

178 BOOK.indb 327 6/5/08 10:02:57 AM


328

Index

components, 184create, 202creating, 235extended support, 209editor, 212, 236

Service group objectcreating, 238

Service implementation, 162Service interaction, 103Service interface, 39

modeling, 146, 152, 155stateless, 134

Service interface editor, 155Service interface object editor, 76Service metadata, 18, 196

documentation, 196Service model

publish, 144publishing, 92

Service name, 181Service operation, 152Service-oriented architecture (SOA), 17Service providers

configure, 269, 299Service proxy, 103Service reference, 185, 237Service side, 15

registration, 293Service search, 188Services, 17

finding, 180grouping, 178search, 181

Services Registry, 40, 67, 68, 85, 143, 180, 244, 255, 296, 299, 300

API, 90architecture, 89publish, 92search, 92

Services Registry Library, 91Servlet, 198

implementing, 206Session, 141Session handling, 108, 110, 132Single sign-on, 307SOA backbone, 36, 37SOA by evolution, 22

SOA development process, 49SOA management, 39, 44, 46SOA Management Cockpit, 253, 255, 296, 299, 300SOA middleware, 14, 47

building blocks, 39components, 70

SOAP, 317SOAP protocols, 167Software availability, 16Software component (SC), 147, 199, 249, 258, 292

assign, 168local, 147version, 147SLD-based, 147

Software logistics, 78Specification, 49, 50Standard context, 227Stateful write, 133, 141Stateful write/update, 160Stateless read, 133, 158Static service call, 187Status change

binary, 129SWC editor, 148Synchronous scenario, 131System

physical, 255, 259, 261, 291publishing, 96

System administrator, 243, 254, 262, 291, 294, 303System configuration

technical, 254, 262, 278, 291, 294, 305

System Landscape Directory (SLD), 147

T

Tasks of the application administrator, 241Tasks of the technical administrator, 241Technical system configuration, 254, 262, 291, 294Tentative update, 135, 140

178 BOOK.indb 328 6/5/08 10:02:58 AM


329

Index

Tentative update and confirm or compensate (TU&C/C), 131, 133, 134Tentative update operation, 159Transactionality, 107, 109, 131Transport security, 247TU&C/C, 168TU&C/C service interface, 159Two-phase commit, 134

U

UDDI best practice for WSDL, 89UDDI entities, 89UDDI registry, 242UI elements

creating, 229UN/CEFACT, 59Update, 141URI, 59User interaction, 225User interface

modeling, 222

V

Version management, 73Visual Composer (VC), 68

W

Web Dynpro, 193Java, 213

Web Dynpro Foundation, 188Web modules, 200Web Service Reliable Messaging (WS-RM), 315Web services, 29Web Services Description Language (WSDL), 318Where-used list, 77Window editor, 222WS addressing, 316WSDL, 318WSDL Wizard, 211WS-MetadataExchange, 315WS-Policy, 94, 250, 286, 310WS-Reliable Messaging (WS-RM), 111, 112, 248, 315WS-Security, 319

X

XML, 316XML Schema (XSD), 316XSD, 316XSD data types, 83

178 BOOK.indb 329 6/5/08 10:02:58 AM


Documents

Developing Applications with Enterprise SOA