developing applications with enterprise soa
TRANSCRIPT
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
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
ch00_FM_5133.indd 5ch00_FM_5133.indd 5 6/4/08 12:37:51 PM6/4/08 12:37:51 PM
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
ch00_FM_5133.indd 7ch00_FM_5133.indd 7 6/4/08 12:37:51 PM6/4/08 12:37:51 PM
www.sappressbooks.com
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
ch00_FM_5133.indd 8ch00_FM_5133.indd 8 6/4/08 12:37:51 PM6/4/08 12:37:51 PM
www.sappressbooks.com
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
ch00_FM_5133.indd 9ch00_FM_5133.indd 9 6/4/08 12:37:51 PM6/4/08 12:37:51 PM
www.sappressbooks.com
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
ch00_FM_5133.indd 10ch00_FM_5133.indd 10 6/4/08 12:37:51 PM6/4/08 12:37:51 PM
www.sappressbooks.com
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
ch00_FM_5133.indd 11ch00_FM_5133.indd 11 6/4/08 12:37:51 PM6/4/08 12:37:51 PM
www.sappressbooks.com
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
www.sappressbooks.com
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
www.sappressbooks.com
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
www.sappressbooks.com
52
3 Model-Driven Business Process Development
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
www.sappressbooks.com
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
www.sappressbooks.com
54
3 Model-Driven Business Process Development
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
www.sappressbooks.com
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
www.sappressbooks.com
56
3 Model-Driven Business Process Development
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
www.sappressbooks.com
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
www.sappressbooks.com
58
3 Model-Driven Business Process Development
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
www.sappressbooks.com
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
www.sappressbooks.com
60
3 Model-Driven Business Process Development
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
www.sappressbooks.com
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
www.sappressbooks.com
62
3 Model-Driven Business Process Development
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
www.sappressbooks.com
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
www.sappressbooks.com
64
3 Model-Driven Business Process Development
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
www.sappressbooks.com
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
www.sappressbooks.com
66
3 Model-Driven Business Process Development
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
www.sappressbooks.com
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
www.sappressbooks.com
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
www.sappressbooks.com
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
www.sappressbooks.com
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
www.sappressbooks.com
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
www.sappressbooks.com
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
www.sappressbooks.com
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
www.sappressbooks.com