Thomas Pohl and Markus Peter
Developing Enterprise Services for SAP®
Bonn � Boston
291 Book.indb 3 6/8/09 11:20:01 AM
Contents at a Glance
PArT I Modeling of Enterprise Services
1 Basic Modeling Principles for Enterprise Services .......... 21
2 Modeling A2X Services ................................................. 73
3 Process Integration and Integration Scenarios ............... 115
PArT II Development of Enterprise Services
4 Enterprise Services Repository ...................................... 129
5 Technical Principles and Standards for Services ............. 145
6 Development of Enterprise Services in ABAP ................ 167
7 Development of Enterprise Services in Java ................... 233
PArT III Sample Implementations for Enterprise Services
8 Sample Implementations of Enterprise Services in ABAP ........................................................................ 251
9 Sample Implementations for Service Consumers ........... 311
Appendices
A Literature ...................................................................... 383
B The Authors .................................................................. 385
291 Book.indb 5 6/8/09 11:20:01 AM
7
Contents
Introduction ......................................................................................... 13
PArT I Modeling of Enterprise Services
1 Basic Modeling Principles for Enterprise Services ...... 21
1.1 Service-Oriented Architectures .......................................... 241.1.1 Characteristics of Service-Oriented Architectures .... 251.1.2 SOA for Enterprise Software — Open Questions .... 271.1.3 SOA for Enterprise Software — The SAP Approach ... 29
1.2 Enterprise Services ............................................................ 311.2.1 Derivation from the Enterprise Model .................... 321.2.2 Role of the Global Data Types ................................ 351.2.3 From BAPIs to Web Services to Enterprise Services ... 36
1.3 A2X, A2A, and B2B Services ............................................. 401.3.1 A2X Services .......................................................... 401.3.2 A2A Services .......................................................... 421.3.3 B2B Services .......................................................... 44
1.4 Enterprise Services Metamodel ......................................... 441.4.1 Process Components .............................................. 451.4.2 Business Objects .................................................... 471.4.3 Service Operations ................................................. 501.4.4 Service Interfaces ................................................... 511.4.5 Deployment Units .................................................. 521.4.6 Communication Patterns and Message Categories ... 531.4.7 Interface Pattern — Patterns of Related Interfaces ... 581.4.8 Conclusion ............................................................. 63
1.5 Enterprise Services Repository and Registry ....................... 631.5.1 Road to a Custom SAP Enterprise Services
Repository ............................................................. 641.5.2 Enterprise Services Builder — A Brief Overview ...... 651.5.3 Models of the SAP Applications and
Enterprise Services ................................................. 681.6 Summary .......................................................................... 72
2 Modeling A2X Services ................................................ 73
2.1 Modeling the Metamodel Entities ..................................... 742.1.1 Application Case for Analyses ................................. 74
291 Book.indb 7 6/8/09 11:20:01 AM
8
Contents
2.1.2 Preparations in the Enterprise Services Repository ... 752.1.3 Identification of the Business Objects ..................... 762.1.4 Layout of the Process Components and
Deployment Units .................................................. 792.1.5 Creation of the Architecture Model ........................ 812.1.6 Conclusion ............................................................. 90
2.2 Consistent Signatures and Their Significance ..................... 902.3 Modeling of Business Objects ........................................... 92
2.3.1 Structure of the Integrated Business Object Model ... 932.3.2 Business Object Properties ..................................... 972.3.3 SAP Global Data Types and Core Data Types .......... 1042.3.4 Completing the Business Object Modeling ............. 106
2.4 Derivation of the Enterprise Services Signatures ................ 1072.4.1 Business Document and Business Document
Object ................................................................... 1072.4.2 Derivation of the Business Document Object
Structure ................................................................ 1092.4.3 Construction of the Business Document Object
Structure ................................................................ 1112.5 Summary .......................................................................... 114
3 Process Integration and Integration Scenarios ........... 115
3.1 Integration Scenario Models ............................................. 1163.1.1 Presenting Integration Scenario Models ................. 1173.1.2 Creating Integration Scenario Models ..................... 119
3.2 Process Components Interaction Models ........................... 1223.2.1 A2A and B2B Services in Contrast to A2X Services ... 1233.2.2 Creating Process Components Interaction Models ... 124
3.3 Integration Scenario Catalog ............................................. 1243.4 Summary .......................................................................... 125
PArT II Development of Enterprise Services
4 Enterprise Services repository .................................... 129
4.1 Structure of the Enterprise Services Repository Content .... 1304.2 Overview of the Required Design Objects ......................... 131
4.2.1 Service Interfaces ................................................... 1314.2.2 Message Types ....................................................... 1344.2.3 Data Types ............................................................. 1344.2.4 Fault Message Types .............................................. 1394.2.5 Class Model ........................................................... 140
291 Book.indb 8 6/8/09 11:20:01 AM
9
Contents
4.3 Identifying Industry-Specific Fields .................................... 1414.4 Namespaces in the Enterprise Services Repository ............. 1414.5 Naming Conventions for Design Objects in the
Enterprise Services Repository ........................................... 1424.6 Summary .......................................................................... 144
5 Technical Principles and Standards for Services .......... 145
5.1 Web Services .................................................................... 1465.2 Extensible Markup Language ............................................. 147
5.2.1 Structure of an XML Document .............................. 1475.2.2 Example of an XML Document ............................... 1485.2.3 Namespaces ........................................................... 1495.2.4 Processing Instruction ............................................ 1495.2.5 Syntactic and Semantic Correctness ........................ 149
5.3 XML Schema Definition .................................................... 1505.3.1 Primitive Data Types .............................................. 1505.3.2 Value Space, Lexical Space, Facet ........................... 1505.3.3 Derived Data Type ................................................. 1515.3.4 Simple Data Types .................................................. 1515.3.5 Complex Data Types ............................................... 153
5.4 Web Services Description Language .................................. 1555.4.1 Structure of a WSDL Document ............................. 1555.4.2 Definitions ............................................................. 1575.4.3 Data Types ............................................................. 1575.4.4 Message ................................................................ 1575.4.5 Port Type ............................................................... 1585.4.6 Binding .................................................................. 1595.4.7 Service ................................................................... 160
5.5 SOAP ................................................................................ 1605.6 Additional W3C Standards ................................................ 161
5.6.1 XML Parser ............................................................ 1615.6.2 Extensible Stylesheet Language for Transformation ... 1625.6.3 XML Path Language ............................................... 164
5.7 Summary .......................................................................... 165
6 Development of Enterprise Services in ABAP ............. 167
6.1 Background and Basic Properties ....................................... 1676.1.1 Decoupling ............................................................ 1686.1.2 Model-Based Development .................................... 1686.1.3 Transactional Behavior ........................................... 1686.1.4 Stateless and Stateful Communication .................... 1686.1.5 Unidirectional and Bidirectional Communication .... 169
291 Book.indb 9 6/8/09 11:20:01 AM
10
Contents
6.1.6 Synchronous and Asynchronous Communication .... 1696.1.7 Inbound and Outbound Operations and
Service Interfaces ................................................... 1706.1.8 Communication Patterns ........................................ 1716.1.9 Quality of Service ................................................... 1796.1.10 Reliable Messaging ................................................ 180
6.2 Generating Proxies in the Backend System ........................ 1826.2.1 ABAP Provider Proxy .............................................. 1836.2.2 ABAP Consumer Proxy ........................................... 184
6.3 ABAP Proxy Runtime and Configuration ............................ 1866.3.1 Overview of Message Processing at Runtime .......... 1876.3.2 Configuration of Provider Proxies ........................... 1906.3.3 Configuration of Consumer Proxies ........................ 1926.3.4 Configuration of the Message Processing via the
Integration Server .................................................. 1946.3.5 Serialization and Deserialization ............................. 195
6.4 Implementation of Inbound Service Interfaces .................. 1976.4.1 General Implementation Considerations ................. 1976.4.2 Basic Programming Model of Enterprise Services .... 1986.4.3 Implementation of Change Services ........................ 2026.4.4 Code Lists .............................................................. 2106.4.5 Reliable Messaging ................................................ 2146.4.6 Extension Concept ................................................. 2176.4.7 Error Handling ....................................................... 2186.4.8 Industry-Specific Extensions ................................... 2206.4.9 Mass Data Services ................................................ 224
6.5 Testing Services in the Web Services Navigator .................. 2256.6 Evaluating Services in the Enterprise Services Workplace ... 2266.7 Publishing Services to the Services Registry ....................... 227
6.7.1 Structuring Services in the Services Registry ........... 2286.7.2 Consuming Web Services in the Services Registry ... 2306.7.3 Publishing Services to the Services Registry ............ 231
6.8 Summary .......................................................................... 231
7 Development of Enterprise Services in Java ................ 233
7.1 Inside-Out Implementation ............................................... 2347.2 Outside-In Implementation ............................................... 234
7.2.1 Prerequisites .......................................................... 2357.2.2 Importing a WSDL Document ................................ 2357.2.3 Proxy Generation ................................................... 2397.2.4 Displaying the Generated Web Service Artifacts ..... 241
7.3 Configuration of Web Services at Design Time .................. 2427.3.1 Configuration of the Authentication Level .............. 242
291 Book.indb 10 6/8/09 11:20:01 AM
11
Contents
7.3.2 Configuration of the Transport Guarantee ............... 2437.3.3 Configuration of Web Services
Reliable Messaging (WS-RM) ................................. 2447.3.4 Configuration of Stateful Communication ............... 2447.3.5 Implementation of the JavaBean Skeleton .............. 244
7.4 Configuration of Java Web Services with the SAP NetWeaver Administrator .......................................... 244
7.5 Publication of Services from SAP NetWeaver Administrator .................................................................... 245
7.6 Testing Services in the Web Services Navigator .................. 2477.7 Summary .......................................................................... 247
PArT III Sample Implementations for Enterprise Services
8 Sample Implementations of Enterprise Services in ABAP ........................................................................ 251
8.1 Overview of the Implementation Project ........................... 2518.2 Preparations in Enterprise Services Repository ................... 2538.3 Preparations in the ABAP System ...................................... 2568.4 Patterns for the Design of Service Implementations ........... 2598.5 Reserving, Booking, and Canceling a Flight ....................... 262
8.5.1 Specifications of Services ........................................ 2628.5.2 Implementing the Service Interface Proxy Classes ... 2658.5.3 Template for Service Implementation Classes ......... 2678.5.4 Completing the Create Flight Sales Order Service
Implementation Class ............................................. 2698.5.5 Helper Classes ........................................................ 2728.5.6 Completing the Confirm and Cancel Services .......... 274
8.6 Service for Reading a Flight Sales Order ............................ 2788.6.1 Specifying the Read Flight Sales Order Service ........ 2788.6.2 Read Flight Sales Order Service
Implementation Class ............................................. 2798.7 Input Help Services ........................................................... 284
8.7.1 Implementing the Find Flight Customer Service ..... 2858.7.2 Implementing the Find Flight Service ..................... 2918.7.3 Input Helps for the Core Data Types of the
Code Type .............................................................. 2968.8 Service for Checking the Availability of a Flight ................. 2998.9 Changes to Flight Sales Orders .......................................... 3008.10 Testing the Service Implementations ................................. 3078.11 Summary .......................................................................... 309
291 Book.indb 11 6/8/09 11:20:01 AM
12
Contents
9 Sample Implementations for Service Consumers ........ 311
9.1 Development of a Consumer Application in ABAP ............ 3129.1.1 Sample Application ................................................ 3129.1.2 Framework of the Reservation Report .................... 3149.1.3 Filling the List Boxes for the Airport and
Booking Class ......................................................... 3169.1.4 Determining the Flights ......................................... 3209.1.5 Interactive Display of the Flights with an
ABAP List Viewer ................................................... 3239.1.6 Calling the Availability Check ................................. 3279.1.7 Service Call for Reserving a Flight ........................... 3289.1.8 Conclusion ............................................................. 332
9.2 Application Development with SAP NetWeaver Composition Environment ................................................. 3329.2.1 SAP NetWeaver Visual Composer ........................... 3339.2.2 Web Dynpro Java ................................................... 343
9.3 Application Development with Eclipse .............................. 3569.3.1 Eclipse ................................................................... 3579.3.2 JSP Sample Application .......................................... 3599.3.3 Generating a Dynamic Web Project in the
Eclipse IDE ............................................................. 3599.3.4 Importing the WSDL Document ............................. 3609.3.5 Creating the JavaServer Page .................................. 3629.3.6 Editing the Deployment Descriptor ........................ 3639.3.7 FlightDemoServlet Servlet ...................................... 3649.3.8 Implementing the FlightDemoBean JavaBean ......... 3679.3.9 Result .................................................................... 370
9.4 Application Development with Microsoft .NET ................. 3719.4.1 Generating the Consumer Proxy ............................. 3729.4.2 Creating the Consumer Application ........................ 3749.4.3 Result .................................................................... 381
9.5 Summary .......................................................................... 382
Appendices ........................................................................ 383
A Literature ............................................................................... 383B The Authors ........................................................................... 385
Index ............................................................................................ 387
291 Book.indb 12 6/8/09 11:20:02 AM
167
Enterprise services are standardized in multiple ways. The model-specific and design-specific principles for a uniform definition of services and the technical standards for the message transfer have already been discussed. Furthermore, services have a com-mon programming model to ensure a standardized behavior at runtime. This is illustrated in this chapter.
Development of Enterprise 6Services in ABAP
The previous chapters explained how to model enterprise services and specify them in a standardized format in Enterprise Services Repository (ES Repository). This chapter details the rules according to which the ser-vices are developed in ABAP.
The implementation is based on proxies that are generated from the meta-data of the services. A common architecture ensures that the services behave in a uniform and consistent manner at runtime. This chapter analyzes this architecture in detail. First of all, however, it describes some of the basic properties of an enterprise service, which are essential to understanding the subsequent descriptions. Instead of the term “enterprise services,” this chapter also uses “Web services” or “services” depending on whether it is referring to the overall concept, the technical implementation, or the functionality itself.
To keep the description as simple and clear as possible, this chapter refers to the current release of SAP Business Suite or SAP NetWeaver Process Inte-gration 7.1 EhP1, even though the functions deployed here have already been available in earlier releases.
Background and Basic Properties6.1
SOA is different from conventional programming models for business applications in many respects. The differences are indicated in the devel-opment process of business applications but also in the way the applica-tions communicate with each other at runtime and their integration with
291 Book.indb 167 6/8/09 11:20:53 AM
168
6 Development of Enterprise Services in ABAP
each other. This chapter discusses the special features of a service-based architecture and its benefits in more detail.
Decoupling6.1.1
A reason for using enterprise services is the decoupling of the applications by means of intermediate services. Consumer and provider can commu-nicate with each other without any restrictions on the platform on which they are implemented. For example, a Java EE-based business application can access services that are implemented in ABAP. This is enabled by the standardization of the technology that is used, which is at a very advanced level today. Consumer and provider communicate with each other via an open protocol (SOAP) and use standardized interface information only that can be published in a Services Registry. Therefore, technical decoupling allows reusing services on different platforms.
Model-Based Development6.1.2
Metadata assumes a significant role in the development of enterprise ser-vices. It defines the contract between the consumer and the provider at the technical level. The consumer uses the metadata to determine the format of the messages and further information that it requires to call the service from its application. For the provider, the metadata is the default data that it has to implement. Consumer and provider can generate the framework or skeletons of the required development objects using the metadata.
Transactional Behavior6.1.3
Enterprise services are required to always leave the database in a consistent status. Calling additional services to ensure data consistency should not be necessary. Instead, each service call transforms the database from one con-sistent status into another consistent status.
Stateless and Stateful Communication6.1.4
Basically, enterprise service can be either stateless or stateful. In this con-text, stateful means that specific context information is stored in the pro-vider over multiple subsequent calls for the current interaction with a consumer.
The context can be provided at several levels:
At the level of the technical communication via a stateful protocolEE
At the service level by combining subsequent calls of the same con-EE
sumer in a session (e.g., by exchanging a session ID)
SOAP
Metadata
Data consistency
291 Book.indb 168 6/8/09 11:20:53 AM
169
Background and Basic Properties 6.1
At the application level which, in turn, has to provide the correspond-EE
ing mechanisms
All enterprise services delivered in SAP Business Suite are stateless. The following sections also use stateless enterprise services without explicitly mentioning this every time.
Unidirectional and Bidirectional Communication6.1.5
Services can communicate with each other in unidirectional and bidirec-tional ways. Unidirectional means that the initiator of the communication sends a message to a receiver. For the bidirectional communication, it is additionally required that the receiver of the message also sends a response message to the sender.
Typical scenarios for a unidirectional communication are messages of an application that indicate the result of a process. However, in most cases, a bidirectional communication is required because the initiator is interested in the result of its message.
Synchronous and Asynchronous 6.1.6 Communication
The synchronous communication and the asynchronous communication are two generally different modes for exchanging information:
EE Synchronous communication Synchronous communication is generally bidirectional because it requires a communication channel between the initiator of the mes-sage and the receiver through which the response message can also be directly sent to the initiator. You can compare the synchronous com-munication with a telephone call where the caller submits a request message to the receiver (e.g., “Book the flight with the number LH454 from Frankfurt to San Francisco on May 1, 2009”), and the receiver directly confirms or rejects this request. The initiator doesn’t proceed with processing until it has received a response from the receiver.
This behavior, which characterizes the synchronous communication, is also referred to as blocking because it deploys critical system resources exclusively, such as database blocks or communication channels.
EE Asynchronous communication At first glance, the asynchronous communication is unidirectional. However, this doesn’t mean that no response can be sent. You can compare it with a communication by email. In this case, the initiator sends an electronic message to the receiver. The receiver may send a
Messages
Communication channel
Blocking
Not blocking
291 Book.indb 169 6/8/09 11:20:53 AM
170
6 Development of Enterprise Services in ABAP
response later on but doesn’t have to. The major benefit of the asyn-chronous communication is that the initiator can continue processing without blocking system resources until it receives a response.
Therefore, applications that are based on asynchronous communica-tion feature a more efficient scaling than those that use synchronous communication. Generally, when the input sets increase, the resource requirements of an asynchronous application increase considerably less than the resource requirements of a synchronous application. Of course, this requires that the response message is not needed immedi-ately. Another advantage over synchronous communication is that the receiver doesn’t have to be available when the initiator sends the mes-sage.
Everybody knows from real life that phone calls may not be answered, or lines may be busy. On the other hand, asynchronous communica-tion sets considerably higher demands on the technical infrastructure, which has to correlate the response message with the request message and send it to the corresponding receiver. Additionally, special mecha-nisms are required to manage the errors that occur.
Inbound and Outbound Operations and Service Interfaces6.1.7
An inbound operation is an operation of an inbound service interface. Analogous, an outbound operation is an operation of an outbound ser-vice interface. The proxy object that is generated from an inbound (out-bound) service interface is also referred to as inbound (outbound) proxy. An inbound operation receives messages from a sender, and an outbound operation sends messages to a receiver.
An outbound operation is used by a calling application for the following reasons:
The system is supposed to send a request message to a provider. In EE
this case, a service of the provider is called. The call is made from a consumer application in a consumer proxy. A confirmation is princi-pally expected.
Another application is to be informed about a process. In this case, a EE
message is transferred to the other application. A confirmation is not expected.
EE The service provider implements the inbound operation. It contains the functions that are provided to the consumers as services (in the sense of technical services). The functions are implemented in a pro-vider proxy.
Availability of the receiver
Error handling
Service provider
291 Book.indb 170 6/8/09 11:20:53 AM
171
Background and Basic Properties 6.1
Figure 6.1 illustrates the relationship between the consumer application and the provider application as well as between the consumer proxy and the provider proxy.
Consumer ApplicationConsumer Proxy
(Outbound)
Provider ApplicationProvider Proxy
(Inbound)
Calls
Relationship Between Consumer and Provider ProxyFigure6.1
Communication Patterns6.1.8
Analogous to the interpersonal communication where you distinguish between the different types of communication, such as monolog, dialog, and discussion, you can classify the communication between applications according to various criteria. The service-based communication differenti-ates between the following communication patterns, which are character-ized from the perspective of the implementation here:
EE Request/confirmation pattern This pattern is characterized by the fact that the calling program requests an activity from the provider (e.g., creating or changing a business object), and the provider confirms the activity after the exe-cution.
Query/response patternEE Here, a query is sent to the provider (e.g., which business objects belong to my organizational unit?) and answered in a response mes-sage by the provider.
EE Notification pattern A message is sent to a receiver. However, no response is expected. The calling program assumes that the receiver processes the message accordingly so that the business process can be completed consis-tently.
Information patternEE Like in the notification pattern, a message is sent to a receiver in this pattern; however, no expectations are linked to the processing of the message. The receiver can take note of the message anytime, and the further processing is completely left up to it.
In contrast to the first two patterns, the notification and information pat-terns involve a unidirectional communication, which can be modeled via
Bidirectional
Unidirectional
291 Book.indb 171 6/8/09 11:20:53 AM
172
6 Development of Enterprise Services in ABAP
asynchronous outbound service interfaces. The request/confirmation pat-tern and query/response pattern are bidirectional and can be either syn-chronous or asynchronous.
The following sections describe these patterns from the development per-spective and also explain the differences between synchronous and asyn-chronous communication.
Synchronous request/Confirmation Pattern
The process of the request/confirmation pattern is defined as follows (see Figure 6.2):
The consumer application sends a request message to the provider 1.
application by calling the corresponding method of the outbound proxy.
This causes the corresponding method of the inbound proxy to be 2.
called on the provider side, which implements the desired business logic.
The result of the call (the return parameters) is immediately trans-3.
ferred to the calling application.
After the call has been executed, the application can proceed with 4.
processing.
ProviderInbound Proxy
ConsumerOutbound Proxy
Send Confirmation
Send Request
Business Logic
Sequence Diagram for the Synchronous Request/Confirmation PatternFigure6.2
291 Book.indb 172 6/8/09 11:20:54 AM
173
Background and Basic Properties 6.1
In ES Repository, a synchronous request/confi rmation pattern is mapped by an inbound service interface, which contains a synchronous operation with the following messages:
RequestEE
ResponseEE
FaultEE
Figure 6.3 shows an example of such a service interface.
Example of a Synchronous Service Interface in the Enterprise Services Figure6.3Repository
Asynchronous request/Confi rmation Pattern
The asynchronous request/confi rmation pattern differs from the synchro-nous pattern in that consumer and provider communicate asynchronously with each other. The benefi t of the asynchronous communication is that the processing of the messages can be decoupled, which results in a higher throughput.
However, for the runtime, the problem is now to send the response mes-sage to the original calling program. Basically, there are two options for delivering the messages. The following discusses fi rst the direct commu-nication between the consumer and provider, which is also referred to as point-to-point communication (P2P) and then the communication via a broker .
Higher throughput
Point-to-point communication
291 Book.indb 173 6/8/09 11:20:55 AM
174
6 Development of Enterprise Services in ABAP
Direct (P2P) Communication
The process of the asynchronous request/confirmation pattern for a direct communication between the consumer and provider is as follows (and in a sequence diagram in Figure 6.4):
The consumer sends a request message to the provider. For this pur-1.
pose, it calls the corresponding method of the outbound proxy in its application.
This causes the corresponding method of the inbound proxy to be 2.
called on the provider side.
In the implementation of the inbound proxy, the desired business 3.
logic is executed.
After the business logic has been executed, an outbound proxy of the 4.
provider application is called.
The outbound proxy sends the confirmation message to the calling 5.
application.
ConsumerOutbound Proxy
ProviderInbound Proxy
ConsumerInbound Proxy
ProviderOutbound Proxy
Send Request Message
Business Logic
Generate Outbound Proxy
Send Confirmation
Sequence Diagram for the Asynchronous Request/Confirmation Pattern Figure6.4(P2P)
291 Book.indb 174 6/8/09 11:20:55 AM
175
Background and Basic Properties 6.1
The consumer receives the message in the inbound proxy provided 6.
for this purpose.
This communication requires that the provider remembers the address information of the consumer until it has delivered the response message to the consumer. This example also illustrates that inbound and outbound proxies can be called on both the consumer and the provider side.
Communication via an Integration Broker
Another communication option is that the consumer and provider applica-tion communicate with each other via an integration broker. The process is as follows (and is shown in the sequence diagram in Figure 6.5):
The consumer sends a request to the broker. For this purpose, it calls 1.
the corresponding method of the outbound proxy in its application.
The broker determines the desired provider and forwards the request 2.
to the corresponding provider.
Integration Broker
ProviderOutbound Proxy
ConsumerInbound Proxy
ProviderInbound Proxy
ConsumerOutbound Proxy
Business Logic
Generate Outbound Proxy
Send Request Message
Forward Request Message
Send Confirmation Message
Forward Confirmation Message
Sequence Diagram for the Asynchronous Request/Confirmation Pattern Figure6.5with an Integration Broker
291 Book.indb 175 6/8/09 11:20:55 AM
176
6 Development of Enterprise Services in ABAP
The provider calls the desired business logic.3.
The provider instances its outbound proxy for the response.4.
The outbound proxy sends the confi rmation message to the broker.5.
The broker receives the confi rmation message, determines the receiv-6.
er, and forwards the message to the receiver.
The consumer receives the confi rmation message in the inbound 7.
proxy provided for this purpose.
Service Interface in Enterprise Services repository
The asynchronous request/confi rmation pattern is mapped by two service interfaces in ES Repository. The inbound service interface contains an asyn-chronous operation for the request, and the corresponding outbound ser-vice interface contains an asynchronous operation for the confi rmation message. The operation for the inbound service interface additionally con-tains a fault message.
Figure 6.6 shows an example of an outbound service interface, and Figure 6.7 shows an example of an inbound service interface. Together, they map the asynchronous request/confi rmation pattern.
Example of an Asynchronous Outbound Service Interface in ES RepositoryFigure6.6
291 Book.indb 176 6/8/09 11:20:56 AM
177
Background and Basic Properties 6.1
Example of an Asynchronous Inbound Service Interface in Enterprise Figure6.7Services Repository
Notifi cation Pattern
The process of the notifi cation pattern is defi ned as follows:
The application triggers the sending of the message to a receiver.1.
The receiver receives and processes the message.2.
The receipt and processing of the message are required to complete 3. the business process consistently.
The notifi cation pattern is mapped by an outbound stateless service inter-face in ES Repository. It contains an asynchronous operation in the Request role. Figure 6.8 shows an example.
Example of a Notifi cation PatternFigure6.8
291 Book.indb 177 6/8/09 11:20:57 AM
178
6 Development of Enterprise Services in ABAP
Information Pattern
The information pattern process is as follows:
The application triggers the sending of the message to a receiver.1.
The receiver receives the message and can process it.2.
In contrast to the notifi cation pattern, the processing of the message 3. on the receiver side is not required to complete the business process consistently. The optional receiver may trigger follow-up actions.
Analogous to the notifi cation pattern, the information pattern is mapped by an outbound stateless service interface. It contains an asynchronous operation in the Request role. Figure 6.9 shows an example.
Example of an Information PatternFigure6.9
TU&C/C Pattern (Tentative Update & Confi rm/Compensation)
In business applications, a process is often fi rst preliminarily executed before it is ultimately processed. An example of this is a reservation, which blocks specifi c resources from further access for a certain period of time (e.g., items from a warehouse) before the actual booking takes place. Between the reservation and the booking, the reservation can still be changed several times.
For the example of the fl ight sales order, the airline would be obliged to not assign the seat otherwise (for a certain period of time) in case of a res-
291 Book.indb 178 6/8/09 11:20:58 AM
179
Background and Basic Properties 6.1
ervation. Within this period, you can still change the reservation several times. Only when the airline receives a confirmation from the sold-to party does the provider, that is, the airline, implement a hard booking. However, the sold-to party might also cancel the reservation. In this case, the airline would make the seat available to other sold-to parties again.
Technically, this is a protocol, which can be mapped by the TU&C/C pat-tern. The following steps are performed:
1. The consumer calls a service on the provider side via a synchronous tentative update operation. But this service doesn’t ultimately execute the process. Instead it marks the changes as preliminary. The changes are visible for other consumers; that is, no isolation in the sense of an SQL transaction isolation is given here.
2. During the process, this requirement can still be changed several times. The calling program uses a transaction ID to establish a refer-ence to the process.
Finally, the calling program lets the service provider know whether 3. the process is supposed to be ultimately executed or to be canceled. For this purpose, it calls an asynchronous confirm or compensation operation.
Prerequisites for this protocol are the guaranteed processing of messages at the technical level and the fulfillment of a specific contract between consumer and provider at the semantic level. The contract obligates the consumer to always send a confirm or compensation message at the end of the processing and the provider to process these messages accurately. The fulfillment of the contract must also be ensured in the case of technical problems (e.g., when the provider system fails).
In ES Repository, a TU&C/C pattern is mapped by a specific service interface that contains at least one synchronous operation and two asynchronous operations. Because service interfaces of this type are not SAP NetWeaver XI 3.0-compatible, this pattern is not yet used in SAP Business Suite.
Quality of Service6.1.9
The quality of service (QoS) is a critical attribute of a communication ser-vice that describes the reliability of messaging. In the context of Web ser-vices, you distinguish between the different quality requirements described in the following:
SQL transaction isolation
Transaction ID
Reliable messaging
291 Book.indb 179 6/8/09 11:20:58 AM
180
6 Development of Enterprise Services in ABAP
Best EffortEE Best Effort refers to a QoS that ensures that the accumulating messages are transferred in the best and fastest possible way. However, the net-work doesn’t guarantee that the messages are delivered.
Mail is delivered according to this principle, for example: The mail-man does his best to deliver the letter. It is still possible that letters are delivered with delay or get lost.
Standard SOAP also doesn’t guarantee reliable messaging and doesn’t include mechanisms to secure the communication against lost mes-sages or multiple deliveries of the same message.
At Most OnceEE At Most Once guarantees that the same message is delivered to the receiver at most once. It is not allowed to deliver the same message several times. It may happen that not all messages are delivered.
At Least OnceEE At Least Once guarantees that each message is delivered to the receiver at least once or that an error message is generated. It may happen that a message is delivered several times.
Exactly OnceEE Exactly Once guarantees that each message is delivered exactly once or that an error message is generated if this is impossible.
In OrderEE In Order guarantees that the messages are delivered in the sequence in which they were sent.
Exactly Once In OrderEE Exactly Once In Order is a combination from Exactly Once and In Order and refers to a QoS that ensures that the receiver receives the messages exactly once and in the sequence in which they were sent.
reliable Messaging6.1.10
For business applications, it is considerably important that messages are delivered reliably. In this context, the basic requirement is the delivery of messages with the Exactly Once QoS. Because SOAP doesn’t provide any information on the delivery guarantee, you need additional utilities or stan-dards to achieve this goal.
SAP Idempotency Framework
291 Book.indb 180 6/8/09 11:20:58 AM
181
Background and Basic Properties 6.1
For synchronous services, the application can achieve the Exactly Once quality level by using the Idempotency Framework (IDP), which is a compo-nent of SAP NetWeaver. Section 6.4.5, Reliable Messaging, discusses the underlying programming model in more detail. In the case of asynchronous services, the procedure depends on whether the delivery is implemented via a broker (SAP NetWeaver PI Integration Server) or via P2P. These cases are described in greater detail in the following sections.
reliable Messaging When Using the PI Integration Server
The SAP NetWeaver XI 3.0 protocol for exchanging messages, which is used when the SAP NetWeaver PI Integration Server is deployed, already contains the required mechanisms to deliver the messages at the Exactly Once quality level.
reliable Messaging for P2P Communication
To also enable reliable messaging without using the infrastructure of SAP NetWeaver PI, SAP NetWeaver supports the open standard, Web Services Reliable Messaging (WS-RM). WS-RM is a protocol that can be used to pro-vide the Exactly Once or even Exactly Once In Order QoS.
For this purpose, the WS-RM protocol uses sequences. Within a sequence, the messages are numbered in ascending order, starting with 1, so that the receiver can determine whether a message hasn’t been delivered and in which sequence the messages were sent.
Figure 6.10 shows a typical WS-RM scenario. The consumer (Endpoint A) first sends a request for the creation of a sequence to the provider (End-point B). The provider then confirms this request by returning an identi-fier for this sequence. Referring to this sequence, the consumer now sends three messages, which are numbered sequentially, starting with 1 (Mes-sageNumber). The last message has the LastMessage attribute. After hav-ing received this message, the provider confirms the receipt of the mes-sages with sequence numbers 1 and 3. Because the message with sequence number 2 has been lost, the consumer resends it. Then the sequence is complete.
WS-RM is supported by SAP NetWeaver at the protocol level. To support P2P interactions without using an integration server, SAP plans to have asynchronous services successively support this protocol in SAP Business Suite.
WS-RM
Sequences
291 Book.indb 181 6/8/09 11:20:58 AM
182
6 Development of Enterprise Services in ABAP
EndpointA
EndpointBReliable Messaging Protocol
Establish Protocol Preconditions
CreateSequence()
CreateSequenceResponse( Identifier = http://fabrikam123.com/abc )
Sequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 1 )
Sequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 2 )
Sequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 3, LastMessage )
SequenceAcknowledgement( Identifier = http://fabrikam123.com/abc, AcknowledgementRange = 1,3 )
Sequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 2, AckRequested )
SequenceAcknowledgement( Identifier = http://fabrikam123.com/abc, AcknowledgementRange = 1 ... 3 )
TerminateSequence( Identifier = http://fabrikam123.com/abc )
Messaging with WS-RM (Source: http://specs.xmlsoap.org/ws/2005/02/Figure6.10rm/ws-reliablemessaging.pdf)
The following section now describes how you implement services in the backend system.
Generating Proxies in the Backend System6.2
Whereas the design objects in ES Repository are platform-independent, proxy objects are platform-specific runtime objects that the system gener-ates according to the requirements of the respective runtime environment (e.g., ABAP or Java). A prerequisite for the generation of the proxy objects is that the related design objects are modeled in ES Repository or are at least available as an external WSDL description. In the ABAP backend sys-tem, a package structure needs to be created that defines in which package the proxies are created.
Figure 6.11 shows an excerpt of the navigation tree in the Enterprise Ser-vices Browser in the ABAP development environment. In the detail screen, you can view the name of the generated proxy interface and the imple-mented provider proxy class for the CostCentreLineItemBudgetMonitor-ingRuleByIDQueryResponse_In service interface.
Platform-specific runtime objects
Enterprise Services Browser
291 Book.indb 182 6/8/09 11:20:58 AM
183
Generating Proxies in the Backend System 6.2
Enterprise Services BrowserFigure6.11
The following description is based on a scenario with a provider proxy and a consumer proxy. The provider proxy is generated from an inbound service interface. For the inbound service interface, you can create the correspond-ing outbound interface from which the consumer proxy is generated.
ABAP Provider Proxy6.2.1
For the generation of proxies, start the Enterprise Services Browser using Transaction SPROXY .
Expand the nodes of the respective software component version 1. (SWCV) and the namespace, and then select the relevant service interface.
Double-click or use the context menu to generate the necessary proxy 2. objects. The system then requests additionally required data, such as the ABAP package and transport request to which the proxy objects are supposed to be added.
Transaction SPROXY
291 Book.indb 183 6/8/09 11:20:59 AM
184
6 Development of Enterprise Services in ABAP
As a result, you obtain an ABAP interface and ABAP class. The ABAP 3. class is also called a proxy class or implementing class and uses the ABAP interface. Furthermore, the system generates ABAP Data Dictionary objects (provided they don’t exist yet) as proxies for the data and message type definitions that are used by the service interface.
The ABAP class of a service provider contains the implementation of the service operations. It uses an ABAP interface that contains a method for each operation that has been modeled in ES Repository. For compatibility reasons with the SAP NetWeaver XI 3.0 protocol, the service interfaces of SAP Business Suite currently exist of only one operation each. The applica-tion developers finally implement the methods.
A provider proxy is based on an inbound service interface and has to be generated in the ABAP backend component by which the service is pro-vided. Here, you can specify a prefix that is included in the proposed names for the ABAP objects.
For the synchronous, inbound service interface, PurchaseOrderCreateRe-questConfirmation_In, the following objects were generated from the http://sap.com/xi/APPL/SE/Global namespace, which belongs to the ESA-ECC-SE 604 SWCV. PUR was entered as the prefix, and the names were shortened:
The EE _PUR_PURCHASEORDERCRTRC interface with the EXECUTE_SYNCHRO-NOUS method that is implemented
The implementing provider class, EE CL_PUR_PURCHASEORDERCRTRC
The EE ECC_PURCHASEORDERCRTRC service definition
If you generate the proxies yourself, you can overwrite their default names. If the service interface consists of several operations, the generated ABAP interface, of course, contains the respective method for each operation. The name of the method corresponds to the name of the operation.
You can use the service definition to create a runtime configuration. Section 6.3, ABAP Proxy Runtime and Configuration, provides more information on the runtime and configuration.
ABAP Consumer Proxy6.2.2
An application uses the ABAP consumer proxy to call, that is, to consume, a Web service. An ABAP consumer proxy contains object classes and is basically based on an outbound service interface. To consume a service
ABAP interface
Example
291 Book.indb 184 6/8/09 11:20:59 AM
185
Generating Proxies in the Backend System 6.2
that is described by an inbound service interface, create the correspond-ing outbound interface in ES Repository — provided it doesn’t exist yet. Alternatively, you can also generate the outbound service interface from a WSDL document of the inbound service.
In contrast to provider proxies for which you must implement a class in the ABAP backend system for each, the application can directly use consumer proxies. You can generate ABAP consumer proxies in any ABAP system, because a WSDL description is the only requirement.
If the respective outbound service interface is available in ES Repository, the process of generating the consumer proxy is identical to the generation of the provider proxy using the Enterprise Services Browser, which you can call with Transaction SPROXY. If only (external) WSDL documents are avail-able, you generate the consumer proxy via the Repository Browser, which you can access via Transaction SE80.
To configure the (outbound) consumer proxy, you also require a logical port. This is an SAP-specific concept for the configuration of the runtime properties of a consumer proxy. The logical port contains, for example, the URL address under which the service is supposed to be called. This aspect is described in more detail in Section 6.3, ABAP Proxy Runtime and Configuration.
Figure 6.12 illustrates the relationship between the consumer proxy, the provider proxy, and the corresponding service interfaces.
Enterprise Services RepositoryOutboundService Interface
InboundService Interface
ABAPApplication
ConsumerProxy
SAP NetWeaver Application Server ABAP
ABAPApplication
Provider Proxy
SAP NetWeaver Application Server ABAP
ABAPProxy Generation
ABAPProxy Generation
Web
serv
ice
Lauf
zeit
Web
Ser
vice
Run
tim
e
Web
Ser
vice
Run
tim
e
Generating an ABAP ProxyFigure6.12
Logical port
291 Book.indb 185 6/8/09 11:21:00 AM
186
6 Development of Enterprise Services in ABAP
ABAP Proxy runtime and Configuration6.3
This section deals with the ABAP proxy runtime and its configuration. These concepts describe how you process Web services at runtime.
For the sake of clarity, the description is restricted to synchronous Web ser-vices; SAP NetWeaver Application Server ABAP (SAP NetWeaver AS ABAP) also supports asynchronous services. This, however, requires an infrastruc-ture that enables a reliable delivery of messages, which is currently basi-cally implemented via the infrastructure of SAP NetWeaver PI.
The communication via Web services is based on SOAP. Currently, SOAP is only supported by HTTP(S). SOAP requests are processed via the Internet Communication Framework (ICF). For this purpose, SAP NetWeaver AS ABAP uses HTTP in the ICF for the communication between consumer and provider.
SAP NetWeaver AS ABAP can be used as a provider for Web services and as a consumer of Web services. The ABAP proxy runtime supports Web services for which an integration server is used as well as P2P connections via SOAP. In both cases, a consumer proxy is required to send the message to the receiver or a provider proxy that implements the desired function.
By configuring an ABAP consumer, you can define whether the connection is a SOAP-based P2P connection or whether the message is supposed to be sent via the SAP NetWeaver XI protocol. These two options are illustrated in Figure 6.13.
Integration Server
Integration Engine
Proxy
Proxy Runtime
LocalIntegration Engine
Web Services Framework
SAP Web/NetWeaver AS >= 6.40
Proxy
Proxy Runtime
LocalIntegration Engine
Web Services Framework
SAP Web/NetWeaver AS >= 6.40
XI Protocol
XI Protocol
SOAP
Communication via the Integration Server with the SAP NetWeaver XI Figure6.13Protocol or Point-to-Point Communication via SOAP
Process integration
Internet Communication
Framework
291 Book.indb 186 6/8/09 11:21:00 AM
187
ABAP Proxy Runtime and Configuration 6.3
Here, the following rules apply:
EE The communication via an integration server can either be synchro-nous or asynchronous. In the synchronous case, Best Effort is the cor-responding QoS; in the asynchronous case, this is Exactly Once or Exactly Once In Order.
The P2P communication via SOAP is currently synchronous, too, but EE
an asynchronous communication via WS-RM is feasible in the future, which supports Exactly Once In Order as the QoS.
Overview of Message Processing at runtime6.3.1
The following sections use the example of a synchronous Web service to illustrate what happens when a Web service is called. It is assumed that the service is called via HTTP.
Internet Communication Manager
The Internet Communication Manager (ICM) enables communication between the SAP NetWeaver AS and the outside world via the HTTP, HTTPS, and SMTP protocols. ICM manages HTTP requests and responses and provides services for further processing, which are briefly described in the following:
To obtain an overview of the ICM load, you can log accesses from or EE
to the Internet or intranet. You can export the log file to another file and then use external evaluation programs to analyze it.
Incoming HTTP requests can be modified before they reach the appli-EE
cation server. This includes the following operations:
Adding, deleting, and modifying HTTP header fieldsEE
Filtering requestsEE
Redirecting requests to another pageEE
Rewriting URLsEE
The ICM server cache stores objects before they are sent to the client. EE
If the object is later requested with a request again, the content can be read from the server cache if the expiry time hasn’t expired yet. This increases the processing performance of HTTP requests considerably.
ICM is managed and monitored via profile parameters, the ICM Mon-EE
itor (Transaction SMICM), or the web administration interface.
For further processing, the HTTP request is forwarded to ICF.
Quality of service
HTTP, HTTPS, and SMTP
291 Book.indb 187 6/8/09 11:21:00 AM
188
6 Development of Enterprise Services in ABAP
Internet Communication Framework
ICF is the layer between ICM, which sends or receives the HTTP requests, and the processing in the work process of the SAP NetWeaver AS. ICF has both server and client functionality. Incoming calls in the SAP system are forwarded to the HTTP request handler. An HTTP request handler is an ABAP objects class that implements the IF_HTTP_EXTENSION interface. The HTTP request handler is determined by means of the request URL at runtime.
To have the system call the HTTP request handler when a specific URL is entered in the browser, the handler needs to be integrated with an ICF service. Transaction SICF enables you to create and configure ICF services. ICF services are arranged in a hierarchical structure. In this hierarchy, you can derive the URL path for calling the ICF service from the path to the service.
Example
SAP NetWeaver AS ABAP runs on the saphost host at port 8080. The ping ICF service was created in the sap/bc node, and the CL_HTTP_MYPING handler was assigned to the ICF service. When you enter the http:// saphost:8080/sap/bc/ping URL, the system calls the handle_request() method, which was imple-mented in the handler.
For Web services, SAP provides the sap/bc/srt/xip/sap ICF service. The Web services that are available in ABAP systems can be found under this node and also inherit the corresponding request handler.
Processing in the Web Service Enabling Layer
The Web Service Enabling Layer checks whether the message uses the SAP NetWeaver XI protocol or SOAP. Accordingly, the system transfers the mes-sage either to the Web service runtime or to the local SAP NetWeaver XI runtime. The further processing now takes place in the ABAP proxy framework.
Processing in the Application Service Enabling Layer
During the message processing, the system calls the proxy implementation. Section 6.4, Implementation of Inbound Service Interfaces, discusses the related individual steps.
IF_HTTP_EXTENSION
Transaction SICF
291 Book.indb 188 6/8/09 11:21:00 AM
189
ABAP Proxy Runtime and Configuration 6.3
The service implementation then calls the business logic. This call can be made via the method of an ABAP objects class, a BAPI, or an API, which the application provides for this purpose. Figure 6.14 displays an overview that illustrates the processing of the messages at runtime.
Web Service Runtime
Local XI Runtime
ABAP Proxy Framework
Proxy Implementation
Method API BAPI
Service Implementation
Internet Communication Framework
Internet Communication Manager
Consumer Application
HTTP Communication Layer
RSOAP (via HTTP)
Web Service Enabling Layer
Application Service Enabling Layer
Application Layer
Processing of the Messages at RuntimeFigure6.14
291 Book.indb 189 6/8/09 11:21:01 AM
190
6 Development of Enterprise Services in ABAP
Configuration6.3.2 of Provider Proxies
A service definition itself is no unit that can be called. To consume a Web service, you first have to create a runtime representation of the service defi-nition, which is also referred to as service endpoint. The service endpoint contains the configuration settings for the Web service definition and is located on the provider system at a specific location, the so-called service endpoint URL. The consuming application uses this URL to call the config-ured Web service.
To create service endpoints, you can use the SOA Management tool, which can be called via Transaction SOAMANAGER. The service endpoints allow for the following configuration settings:
Provider SecurityEE You can implement the settings for the transport guarantee (e.g., with-out transport guarantee, HTTPS, signature and encryption, etc.) and for the authentication method (e.g., no authentication, HTTP authen-tication via the user ID/password, X.509 SSL client certificate, logon ticket, or message authentication with SAML 1.1).
Web Service AddressingEE Here you can select the protocol for the Web service addressing.
MessagingEE You can define the protocol for reliable messaging and the duration of the confirmation interval (in seconds) here. The confirmation interval is the period within which the provider must confirm to the consumer the receipt of a message.
Transport settingsEE In addition to the determined access URL, you can specify an alterna-tive access URL. If the service is not locally available (e.g., behind a firewall), you must specify the alternative path.
Message attachmentsEE You can define whether message attachments are supposed to be pro-cessed. In this case, several files can be sent with one message.
Operation specificEE Here you can specify a SOAP action for an operation. The SOAP action is defined as a URI and transferred as an HTTP header if the Web ser-vice is called via HTTP.
Figure 6.15 displays the screen for the configuration settings.
Service endpoint
SOAMANAGER
291 Book.indb 190 6/8/09 11:21:01 AM
191
ABAP Proxy Runtime and Confi guration 6.3
Screen for the Confi guration Settings of a Service EndpointFigure6.15
You can assign multiple service endpoints with different confi guration set-tings to a Web service defi nition. This enables you to provide identical Web service defi nitions with different confi guration settings to consumers.
Services defi ne groups of service endpoints. A service defi nition may include several services, which in turn may consist of several service end-points. This relationship is shown in Figure 6.16.
Service
Definition
Service 1
ServiceEndpoint 1
ServiceEndpoint 2
Service 2 Service
Endpoint 3
Services and the Corresponding Service EndpointsFigure6.16
Groups of service endpoints
291 Book.indb 191 6/8/09 11:21:06 AM
192
6 Development of Enterprise Services in ABAP
You can generate a WSDL document for each service endpoint. In contrast to the port type WSDL, which doesn’t contain configuration information yet, this WSDL document already contains the binding information.
Configuration of Consumer Proxies6.3.3
The configuration of consumer proxies is implemented via logical ports. Consequently, a logical port is created based on the requirements of the provider. A logical port refers to a service endpoint that is available under a unique location in the provider system. A logical port additionally contains a runtime configuration for accessing the service endpoint. Furthermore, the port also contains the logon data that is required for calling the service methods.
You can create multiple logical ports for each consumer proxy, but a logical port can only refer to one endpoint. You manage and configure consumer proxies via the SOA Management tool (Transaction SOAMANAGER).
Logischer Port LP_123Logischer Port
LP_123Logical Port LP_123
Consumer Proxy
Web Service Client
Consumer System
Provider Proxy
Web Service
Provider System
Logischer Port LP_123Logischer Port
LP_123ServiceEndpointSE_ABC
Relationship Between the Logical Port and Service EndpointsFigure6.17
Figure 6.17 illustrates the relationship between logical ports and service endpoints. A service consumer establishes a connection by sending a call via a logical port. A logical port can send a call only to one service end-point, but a service endpoint can be called via various logical ports.
The following options are available to maintain the logical ports:
Consumer securityEE Here you can implement settings for the transport security and authen-tication.
Web service addressingEE You can specify the protocol for the Web service addressing.
WSDL document
Logical ports
291 Book.indb 192 6/8/09 11:21:07 AM
193
ABAP Proxy Runtime and Confi guration 6.3
MessagingEE You can defi ne the protocol for the secure data exchange and the time interval for the confi rmation. The lifetime of a sequence is the time interval in seconds in which the sequence is active. 0 stands for end-less. The inactivity timeout is the maximum time period for which the sequence is kept open without any confi rmation.
Transport settingsEE Here you can implement the messaging settings. You should select Execute Local Call, if the consumer and provider are located on the same ABAP system. This has the result that no new logon is required for the service call. Maximum Wait Time WS Consumer defi nes the HTTP timeout, that is, how long the consumer waits for the response message.
Message attachmentsEE You can defi ne whether message attachments are allowed or not.
Operation specifi cEE Here you can specify a SOAP action for an operation. The SOAP action is defi ned as a URI and generated as an HTTP header if the Web ser-vice is called via HTTP.
Confi guration Scenarios
You can select confi guration scenarios in the SOA Management tool under Business Administration by choosing the Mass Confi guration entry. In a confi guration scenario, you can group several Web service defi nitions and assign them to profi les. Figure 6.18 shows the initial screen for the mainte-nance of a mass confi guration in the SOA Management tool.
Mass Confi guration of Services in the SOA Management ToolFigure6.18
Mass confi guration
291 Book.indb 193 6/8/09 11:21:07 AM
194
6 Development of Enterprise Services in ABAP
Configuration of the Message Processing via the 6.3.4Integration Server
If the message processing is not supposed to be implemented from point to point but via an integration broker, you must configure some settings in the integration directory. This section provides a brief overview. For more information, refer to the corresponding SAP documentation of the integra-tion directory.
You can implement the following settings in the integration directory:
Sender agreementEE Which adapter is used for the inbound processing?
Receiver determinationEE Where is the message received?
Interface determinationEE Which interface is used by the receiver?
Figure 6.19 provides an overview of the message processing on the inte-gration server. The message processing is configured in the integration directory.
Integration Server
ConsumerSystem
ProviderSystem
Outbound InterfaceSender Adapter
Inbound InterfaceReceiver Adapter
InboundProcessing Routing
OutboundProcessing
SenderAgreement
ReceiverDetermination
InterfaceDetermination
ReceiverAgreement
Sender Receiver
Integration Directory
Configuration in the Integration DirectoryFigure6.19
291 Book.indb 194 6/8/09 11:21:08 AM
195
ABAP Proxy Runtime and Configuration 6.3
Serialization and Deserialization6.3.5
The data that an inbound proxy receives or an outbound proxy sends is converted in two steps. For incoming messages, the first step involves a technical conversion of the data of the message whose type description is provided in an XML Schema Definition (XSD) into the data structures of the ABAP runtime environment. This process is also called deserialization. It is automatically implemented via the simple transformations (ST), which have been generated by the ABAP proxy framework.
ST describes transformations from ABAP data into XML (serialization) and from XML into ABAP data (deserialization). To call ST in an ABAP program, you can use the CALL TRANSFORMATION language command, which also sup-ports XSL transformations in addition to STs.
ST implicitly leads to a canonical serialization of ABAP data or a canonical deserialization to ABAP data before the actual transformation is executed. The SAP XSLT processor complies to a large extent with the specification for Version XSLT 1.0. These conversions are shown in Figure 6.20.
ABAP XMLSerialization
Deserialization
Serialization and DeserializationFigure6.20
In most cases, however, a technical conversion is not sufficient to format incoming messages, for example, in such a way that they can be transferred to the application, that is, to the existing internal programming interfaces. For example, it is possible that external ISO codes or units of measure must be converted into the SAP-specific format.
You can therefore also implement a conversion at the application level. In addition to the standard conversion of the application, the implementation of the Web service also provides Business Add-Ins (BAdIs), which enable further customer-specific conversions. Figure 6.21 illustrates the two-level conversion process.
GDTXSD Data Type
Proxy Data TypeABAP Data Type
BAPI/API Data TypeABAP Data TypeProxy
FrameworkProxy
Implementation
Conversion Conversion
Two-Level ConversionFigure6.21
Simple transformations
Canonical serialization
291 Book.indb 195 6/8/09 11:21:08 AM
196
6 Development of Enterprise Services in ABAP
The type systems, XSD and ABAP, however, are not completely compatible. Consequently, losses may occur when an XSD data type is mapped to the corresponding ABAP data type (and vice versa). It is therefore important to document these situations and define rules of how different value ranges are supposed to be handled. The core data types can be used as the basis because they form manageable sets, and all other data types are based on them. The following example illustrates this process.
The Amount core data type is defined in ES Repository as shown in Table 6.1.
Element Attribute XSD
Amount xsd:decimal totalDigits=”28”; fractionDigits=”6”
currencyCode xsd:token minLength=”3”; maxLength=”3” use=”required”
Definition of the Amount Data Type in Enterprise Services RepositoryTable6.1
The corresponding proxy data type, SAPPLSEF_AMOUNT, in the ABAP Dic-tionary is defined as shown in Table 6.2.
Structure Components Component Type Data Type
SAPPLSEF_AMOUNT
CONTROLLER PRXCTRLTAB
CURRENCY_CODE
SAPPLSEF_CURRENCY_CODE
CHAR(3)
VALUE SAPPLSEF_AMOUNT_CONTENT1
DEC(28,6)
Definition of the Corresponding Proxy Data Type in the ABAP DictionaryTable6.2
For a consistent mapping between the XSD and ABAP data type, the statis-tical methods, AMOUNT_INBOUND and AMOUNT_OUTBOUND, of the CL_GDT_CON-VERSION class are available. Besides type-appropriate checks and format-ting, the data is also checked against the Customizing settings in the SAP backend system.
The CL_GDT_CONVERSION class contains further methods that are available for the conversion of other core data types. The entire process of the con-version is outlined in Figure 6.22.
Type systems
Example
291 Book.indb 196 6/8/09 11:21:08 AM
197
Implementation of Inbound Service Interfaces 6.4
AB
AP
Prox
y Fr
amew
ork
Prox
y Im
plem
enta
tion
Convert XML to ABAP
Execution of the
Default Import Conversion
Call BAdIfor InboundProcessing
Execution of the
Business Logic
Call BAdIfor Outbound
Processing
Convert ABAP to XML
Entire Process of the ConversionFigure6.22
Now that you know the technical principles of Web services, the following sections discuss the implementation of service providers.
Implementation of Inbound Service Interfaces6.4
For the implementation of enterprise services, the goal is a standardized programming model to ensure that the services behave consistently at the technical level. This section introduces the corresponding rules.
General Implementation Considerations6.4.1
Enterprise services semantics is not only standardized, it is also imple-mented according to uniform guidelines. These guidelines also define the transaction behavior of the service.
Enterprise services are stateless and behave like atomic transactions. This restricts the usage of potential ABAP language elements, such as the usage of SET/GET parameters or the usage of the global SAP memory. They also define how the commit logic has to be implemented.
Numerous rules that have been specified for the BAPI implementation also apply to services. For example, no UI elements, such as dialog boxes, are allowed to be called during processing, and the business logic must be com-pleted before a database update can be registered. Authorization checks have to be performed according to the ABAP authorization concept to pro-tect data from unauthorized access via services. For transaction control reasons, language elements, such as CALL TRANSACTION or SUBMIT REPORT,
Atomic transactions
291 Book.indb 197 6/8/09 11:21:09 AM
387
Index
.NET Framework, 371
A
A2A, 40Communication, 123PCIM, 122Service, 42, 115
A2X, 40Service, 41, 123Service design, 73
ABAPConsumer proxy, 184Package, 256Prefix, 314Proxy runtime and configuration, 186UI field, 316Unit test, 259Web Dynpro, 312
ABAP List Viewer (ALV), 312ABAP proxy object
Generation, 257Naming convention, 257Prefix, 257
Abstraction, 78ActionCode, 255, 301Adaptive RFC 2 Model, 345Adaptive Web Service Model, 345Aggregated data type, 136Aggregation, 94
Track relationship backwards, 109Agility, 21AirlineCode, 255AirportCode, 255ALE, 80ALV, 312
Object-oriented, 324Table control, 312
Amount, 254Analysis
Object-oriented, 30, 76Annotation, 241, 242Apache Tomcat, 357Application
Error messages, 321Application integration, 22, 116Application link enabling (ALE), 80
Application Service Enabling Layer, 188Application-to-Application (A2A), 40Application-to-Unknown (A2X), 40Architectural model, 117Architecture
Service-oriented (SOA), 24Assignment, 85, 124Association, 48, 94Asynchronous communication, 43Asynchronous Request/Confirmation Pattern, 173At Least Once, 180At Most Once, 180Atomicity requirement, 265Attribute, 147Authentication level, 242Authentication method, 319Automation
Of standard processes, 40
B
B2B, 40Communication, 123PCIM, 123Service, 44, 115, 123
BAdIFor inbound processing, 199For outbound processing, 200
BAPI, 36Based-on relationship, 120BasicBusinessDocumentMessageHeader, 216, 255Best Effort, 180Bidirectional, 169Blocking, 169Broker, 173Bulk processing, 225Bundle processing, 225Business application, 168Business Application Programming Interface (BAPI), 36Business document, 107, 123
Message Header, 108, 111Structure, 111
Business document object, 107, 123Derivation, 109
291 Book.indb 387 6/8/09 11:22:11 AM
388
Index
Business function, 222Business function set, 222Business language, 29Business logic, 199Business network transformation, 22Business object, 29, 47, 74, 115, 143, 229, 237
Business partner, 78Create, 83Flight, 76, 95, 100Flight Connection, 95, 98Flight Customer, 77, 95Flight Sales Order, 77, 96, 101Identification, 76Independence, 48Integrated model, 92, 93Integrated object model, 47Leading, 107Maintain attribute, 85Model, 115Modeling, 92Node, 48, 93Node model, 103
Business object map, 67, 79Create, 82
Business object node, 96Business object type, 85Business partner application, 123Business process, 74Business Process Modeling Notation, 116Business process object, 60, 85Business process platform, 21, 125Business Server Pages, 312Business-to-Business (B2B), 40
C
CALL TRANSFORMATION, 195Cancel, 60Cancellation
Deletion, 60Cardinality, 93, 94Category, 132CCTS, 36, 98, 137, 145CDATA, 147Core data type (CDT), 137Certificate, 243Change list, 121Change operation, 60Change service, 203
ChangeStateID, 255Change state identifier (CSI), 205Check Flight Availability, 299Classification, 237, 246
System, 228, 237, 246CL_CENG_GEN_CODE_LIST_PROVIDER, 296CL_FEH_REGISTRATION, 220CL_GDT_CONVERSION, 196, 200Client proxy
Generation, 312CL_PROXY_FAULT, 220CL_SALV_TABLE, 324CL_SOAP_COMMIT_ROLLBACK, 202Code, 134Code list, 210Coherence, 34Comment, 147Communication, 117
Asynchronous, 43, 169Bidirectional, 169Pattern, 171Stateful, 244Synchronous, 43, 169Unidirectional, 169Using enterprise service, 117
Communication channel template, 66Communication pattern, 53, 143
Information, 56Notification, 55Query/response, 55Request/Confirmation, 54Request/response, 56
Compensation operation, 179Complete Transmission Indicator, 301Component, 24
Split, 25Component controller, 343, 345, 352Composite application, 21, 74, 228Composite Application Framework, 333Composition, 48, 94Compound key, 100Configuration, 186, 190
Scenario, 193Connector, 121Consistency
Of service signatures, 91Runtime behavior, 91
ConsumerSecurity, 192
Consumer proxy
291 Book.indb 388 6/8/09 11:22:12 AM
389
Index
External name, 318Generation, 313
Contains, 84, 96Context category, 223Context mapping, 349Controller, 345CONTROLLER, 209, 261, 304, 305Conversion
FlightConnectionID, 270Coordinated Universal Time (UTC), 283Core Component Technical Specification (CCTS), 145Core data type, 35, 134, 137Correct
Semantically correct, 149Coupling
Loose, 25Credentials, 380CRUD-Operation, 58CSI, 205
Calculation, 276Check, 275
Custom controller, 345CustomerID, 254
D
DatabaseCursor, 288, 290
Database block, 169Data consistency, 168Data integrity, 28Data link, 349Data modeler, 349Data type, 131, 134
Aggregated, 136Amount core, 104Code, 105Complex, 153Copy, 255Core, 35, 104, 134, 137Derivation rule, 151Derived, 151Facet, 150Freely modeled, 136Global, 35, 138, 233, 253Identifier, 105Indicator, 105Lexical, 150Maximum length, 255Measure, 105Minimum length, 256
Primitive, 150Quantity, 105Simple, 151Specification, 255Text, 105Value space, 150
Date, 254DateTime
Number format, 281Declaration
Create Flight Sales Order, 267Decoupling, 168Delete
Logically, 302Deployment descriptor, 360Deployment unit, 52, 115, 116, 229, 237
Create, 83Flight Sales Order Processing, 81Foundation layer, 81
Design by contract, 25Design object, 129, 182
Interface object, 66Modeling, 66Process component, 66Process integration, 66Specification, 66
Destination, 355Destination template, 337
Management, 337Document Object Model (DOM), 161Document Style, 159Document Type Definition (DTD), 149doGet, 364DOM, 161
Object, 161doPost, 364DTD, 149Duration, 254
E
Eclipse, 357EJB, 234
Model, 346Project, 234, 235Session bean, 234Stateful, 241Stateless, 241
Element, 147Endpoint, 307, 308End-to-end business process, 122
291 Book.indb 389 6/8/09 11:22:12 AM
390
Index
Enhancement package, 227Enhancement spot, 217Enterprise application project, 234, 235Enterprise JavaBean (EJB), 234Enterprise model
Harmonized, 29Enterprise service, 28, 31
ABAP, 167Category, 115Layout, 28, 32Metamodel, 44Programming model, 198Signature, 33Stateful, 168Stateless, 168
Enterprise Services Browser, 182, 183Enterprise Services Builder, 64, 65, 76, 129
Start, 81Enterprise services bundle, 227Enterprise Services Registry, 236Enterprise Services Repository, 32, 63, 75, 81, 129, 176, 182, 236
Content, 129, 130Folder, 76, 253Implementation, 251Namespace, 253
Enterprise Services Workplace, 226Enterprise SOA, 27Entity relationship modeling, 94Enumeration, 211Error handling, 200, 218Error message, 219ESM ERP, 69ESM INTEGRATION, 69, 120ES Repository content, 68EverybodyWins, 203Exactly Once, 180, 214Exactly Once In Order, 180Exception, 218
Technical, 323Executable GUI Language (XGL), 341Export conversion, 200Extensible Application Markup Language (XAML), 371Extensible Markup Language (XML), 146Extensible Stylesheet Language for Transformation <Pfeil>R<Norm, 162Extension, 199
Concept, 217Industry-specific, 220
F
Facet, 136Fault message type, 51, 131, 139, 218FEH, 200, 220Finalize method, 201FirstOneWins, 204Fixed value, 212FlightConnectionID, 255FlightID, 255FlightSalesCounterID, 255FlightSeatClassCode, 255Folder
In the Enterprise Services Repository, 76
FormattingOf values, 36
Forward Error Handling (FEH), 200Freely modeled data type, 136
G
Global data type (GDT), 35, 138Generalization, 78Generic Modeling Language (GML), 341Global data type, 35, 138, 233, 253GML, 341Governance process, 129
H
Harmonized enterprise model, 29Hash algorithm, 277Hash value, 277Helper class
ZMPTP_CL_PROXY_IMPL_HELPER, 269, 272
Hit listBrowse, 284, 285, 288, 292Limitation, 284, 285, 288
HomonymAvoidance, 49
HTTP, 186Request handler, 188
I
ICF, 186, 187, 188ICM, 187Idempotency, 215
framework, 180, 260requirement, 264
Identification
291 Book.indb 390 6/8/09 11:22:12 AM
391
Index
Change-relevant field, 304IDP, 180, 260Implementation
ABAP system, 251Cancel Flight Sales Order, 274Check service, 260Confirm Flight Sales Order, 274Create Flight Sales Order, 265, 269Enterprise Services Repository, 251Find Flight, 291Find Flight Customer, 285Read Flight Sales Order, 279Update Flight Sales Order, 302
Implicit connectionGenerate, 84
Import conversion, 199Indicator, 254Industry classification, 141
Industry classification context, 224Information pattern, 178In Order, 180Inside-Out, 233Integrated business object model, 92Integration
Business partner system, 22SAP and non-SAP applications, 23
Integration broker, 175Integration Builder, 64Integration object, 130Integration Repository, 52Integration scenario, 115, 117
Catalog, 124Create a model, 119Model, 116, 117
Integrity conditionCheck, 269
Interaction type, 117Interface determination, 194Interface object
Use, 75Interface pattern, 58, 132
Action, 58Manage, 58, 60Notification, 62Request/confirmation, 61
Internet Communication Framework (ICF), 186Internet Communication Manager (ICM), 187Interoperability, 145, 357
Semantic, 26Syntactic, 26
Technical, 26
J
Java, 233Artifact, 239
JavaBean, 359Model, 346
Java connector, 37JavaServer Pages (JSP), 357JAX-RPC, 358JAX-WS, 241, 358JSP, 357
K
KeyCompound, 100
L
Label, 351LastOneWins, 203Lifecycle status, 229, 237List
Handling, 301List box, 316Literal, 151Log, 112, 255
Element, 271Logically delete, 302Loose coupling, 25LPCONFIG, 318
M
Maintenance viewV_SCODE_REGISTRY, 297
Mapping, 124Mapping program, 66Mass Configuration, 193Mass data service, 224Master data, 80
Distribution, 80Master data object, 60, 85maxOccurs, 153Message attachment, 190Message category, 53
Confirmation, 55Information, 56Notification, 55Query, 55Request, 55
291 Book.indb 391 6/8/09 11:22:12 AM
392
Index
Response, 56Message Header, 108, 111Message interface, 52Message transformation, 124Message type, 50, 88, 131, 134
Definition, 253Messaging
Reliable, 180Metadata, 168Method
DO_CONVERT_REQUEST, 270DO_CONVERT_RESPONSE, 271DO_PERFORM_BUS_LOGIC, 271DO_VALIDATE, 269EXECUTE, 265
Metro, 358minOccurs, 153Model, 345
Integration scenario, 116Model-based development, 168Model binding, 349Modeling
Enterprise service, 21Object-oriented, 94
Modeling name, 57Model type, 67Model view controller, 359
N
Namespace, 131Package Mapping, 239
Naming conventionMessage type, 57
Navigation icon, 70, 122, 125Navigation link, 344Net data rule, 300Next practice business process, 115Node data type, 103Notification
Communication pattern, 55Interface pattern, 61
Notification pattern, 177NumberValue, 254NWDI, 343
O
Object class, 99Object-oriented analysis, 30, 76Object-oriented modeling, 94Open source, 357
Operation, 133Change versus update, 60Inbound, 170Outbound, 170
Operation-specific, 190Optimistic locking, 204Outside-In, 233
P
P2PCommunication, 173
Package, 364Pattern, 171
Information, 171Notification, 171Query/response, 171Request/confirmation, 171Tentative Update & Confirm/Compensation (TU&C/C), 178
Payload protocol, 208PCIM, 117, 122PIC, 145PI (SAP NetWeaver Process Integration), 64Placeholder, 118, 121Platform independence, 25Plug, 344Plug-in, 357Point-to-Point (P2P), 173Port
Logical, 185, 192, 318Prepare method, 200Process component, 29, 45, 74, 115, 226, 229, 237
Architectural model, 66Business Partner Data Processing, 79, 89Create, 83Create model, 85Flight Data Processing, 79, 89Flight Sales Order Processing, 79, 87Identification, 30Layout, 46Model, 85Partner, 118Third party, 118Type, 118
Process component model (SAP) ProComp model, 67Process components interaction models (PCIM), 117
291 Book.indb 392 6/8/09 11:22:12 AM
393
Index
Process Composer, 333Process design class, 30, 48Processing Condition, 112Processing instruction, 147Process integration, 115
Scenario, 66Process Integration Content Council (PIC), 145Process integrity, 28Process orientation, 115Property, 99Proxy
Inbound, 170Outbound, 170
PRXCTRL, 209Publication, 231Publication rule, 245PurchaseOrderCreate RequestConfirmation_In, 155
Q
Quality, 32Quality of service, 179, 187QueryCodeList, 211, 296
Metadata, 297Provider class, 296
QueryHitsMaximumNumberValue, 285
r
Receiver, 42, 123Receiver determination, 194Registry service, 147Relationship, 93
Contains, 84, 96Type, 94
Reliable messaging, 181Remote Function Call (RFC), 36Repository namespace, 141Representation, 99Representation term, 134, 210Request/confirmation
Communication pattern, 54Request/confirmation pattern
Asynchronous, 173Synchronous, 172, 200
RequestDispatcher, 359Reusability, 168Reuse, 22RFC, 36
Library, 37
Root element, 148Root node, 95rpc style, 159Runtime governance, 29
S
SAML 1.1, 190Sample application case, 74SAP Business Object Model, 96SAP Business Object Node, 103SAP Business Suite, 21SAP Data Type Model, 103SAP entity map, 67, 82SAP ERP
Foundation, 52Module, 30Without HCM, 53
SAP ERP HCM, 53SAP Exchange Infrastructure (SAP) NetWeaver Process Integration, 64SAPGLOBAL, 69, 71SAPGLOBAL 2.0, 130, 224, 253SAP global data type, 104
Aggregated, 104Basic, 104Model, 106
SAPGLOBAL MODEL, 69, 106SAP Integration Scenario Model, 121SAP Integration Server, 117SAPlink, 252SAP List Viewer (ALV), 312SAP logon ticket, 319SAP NetWeaver Administrator, 244SAP NetWeaver Application Server
Java, 233SAP NetWeaver Composition Environment, 64, 332
Developer Edition, 333SAP NetWeaver Developer Studio, 233SAP NetWeaver Development Infrastructure (NWDI), 343SAP NetWeaver Portal, 343SAP NetWeaver Process Integration, 23, 52, 64, 117, 186
Metamodel, 52PI Integration Server, 181SAP Exchange Infrastructure, 117XI content, 68
SAP NetWeaver Visual Composer, 41, 333
291 Book.indb 393 6/8/09 11:22:12 AM
394
Index
SAP NetWeaver XI content, 68SAP ProComp, 86
Interaction Model, 124Model, 67
SAP Scenario Catalog, 124SAP SERM, 94SAP Solution Map, 227SAX, 161Scaling, 170SEI, 239Semantically correct, 149Semantic interoperability, 26Sender, 42, 123Sender agreement, 194Separation
Interface and implementation, 25Sequence, 181Serialization
Deserialization, 195Service, 24
At advanced level, 34At entry level, 34Cancel Flight Sales Order, 86Category, 40Check Flight Availability, 89Confirm Flight Sales Order, 87Contract, 32Create Flight Sales Order, 86Endpoint, 190Find Flight, 89Find Flight Customer, 89Idempotent, 215, 260, 265, 266, 329Implementation class, 259Lifecycle, 29Mass data service, 224Operation, 50Pattern, 53QueryCodeList, 316Read Flight Sales Order, 86Signature, 115Synchronous, 307Update Flight Sales Order, 86
Service callCheck Flight Availability, 327Create Flight Sales Order, 328Find Flight, 320Result, 321
Service consumer, 24, 123Service endpoint interface (SEI), 239Service endpoint URL, 190
Service interface, 51, 131, 229Abstract, 132Definition, 253Difference, 51Inbound, 43, 132, 170Maintain attribute, 88Model, 86Outbound, 43, 132, 170Stateful, 132Stateless, 132Stateless (XI 3.0-compatible), 132TU&C/C, 133
Service operation, 74, 229Attribute, 88Model, 86
Service-oriented architecture (SOA), 24Service provider, 24, 123Service signature, 90
Derivation, 107Services Registry, 26, 64, 227Servlet, 357, 359Session-afflicted, 38SICF, 188Simple API for XML (SAX), 161Simple transformations, 195Skeleton, 168, 364SLD, 75, 120, 130SOA, 24, 167
Architectural pattern, 27By Design, 30, 80By Evolution, 30, 47, 52, 73, 80Enterprise SOA, 27Goal, 21Governance, 29
SOAMANAGER, 190, 307, 372Logical port, 318
soap\body, 159
SOAP, 146, 147, 160, 168, 186Software catalog
Entry, 120Software component, 130
SAP GLOBAL MODEL, 106Software component version, 130, 229, 237
Property, 75Software component version (SWCV), 68Source
Code, 298Fixed values for domains, 298IMG table, 298
291 Book.indb 394 6/8/09 11:22:13 AM
395
Index
Specialization, 78Specification
Create Flight Sales Order, 262Find Flight, 291Find Flight Customer, 284Read Flight Sales Order, 278Update Flight Sales Order, 300
SPROXY, 183, 257Service test, 308
Stability, 32Standard element
ProcessingCondition, 284StandardMessageFault, 218, 219Starting point, 288Statelessness, 290Strategy
FirstOne Wins, 300FirstOneWins, 264
Supplementary component, 104Removal, 256
Switch, 222Switch Framework, 221Synchronous communication, 43Synchronous request/confirmation pattern, 172Synchronous service, 307Synonym
Avoidance, 49Syntactic interoperability, 26System Landscape Directory (SLD), 130
T
targetNamespace, 157Technical interoperability, 26Template, 162Test
Synchronous service, 307Time, 254
Coordinated, 283Transactional behavior, 168Transport guarantee, 243Transport setting, 190, 193Type system, 196
U
UDDI, 26, 146, 228UML
Activity diagram, 124Class chart, 94Sequence diagram, 124
UN/CEFACT, 35Unicode, 157Unidirectional, 169United Nations Center for Trade Facilitation and Electronic Bus, 35Universal Description, Discovery and Integration <Pfeil>R<Norma, 26UnlimitedQueryHitsIndicator, 285Update
Local, 199Update operation, 61Update service, 204Use
Interface object, 75UTC, 283UTF-8, 148, 157
V
Value table, 212View, 344Visual Studio, 371
W
W3C, 145Web application, 360Web Dynpro, 41, 333, 343
explorer, 347Web Dynpro component, 343, 348Web Dynpro development component, 346Web Dynpro Flex, 342Web Dynpro HTML, 342
Web projectDynamic, 359
Web service, 25, 146Addressing, 192
Web Service Creation wizard, 239Web Service Enabling Layer, 188Web Services Description Language (WSDL), 25Web Services Navigator, 247, 307Web Services Reliable Messaging (WS-RM), 244web.xml, 363Window, 343, 345Windows Presentation Foundation, 371World Wide Web Consortium (W3C), 145WSADMIN, 307WSCONFIG, 307
291 Book.indb 395 6/8/09 11:22:13 AM
396
Index
Sven Ringling, Jörg Edinger, Janet McClurg
Mastering HR Management withSAP ERP HCM
This new updated and enhanced edition of the definitive guide toSAP ERP HCM, is written to teach HR managers, functional users,project managers, and others working with HCM about how to useand customize it throughout the entire HR process. From recruiting personnel to transferring HR data to accounting are all covered basedon the current release SAP ERP 6.0. This is the one resource the HRteam needs to get the most out of their HCM implementation.
664 pp., 2. edition 2009, 69,95 Euro / US$ 69.95
ISBN 978-1-59229-278-3
>> www.sap-press.de/2065
Completely updated and revised edition of complete guide to SAP ERP HCM
Explains how to meet your business needs using HCM
Covers all core areas from recruiting personnel to transferring HR data to accounting
Up to date for ERP 6.0
www.sap-press.com
wsdlbinding, 155definitions, 155message, 155port, 155portType, 155service, 155types, 155
WSDL, 25, 45, 146, 155Document, 192Import wizard, 235
WS Navigator, 214, 225WS-RM, 181, 244
X
X.509SSL client certificate, 190
XAML, 371XGL, 341XI protocol, 186, 215XI (SAP NetWeaver Process Integration), 64XML, 146, 147
Message, 50Namespace, 130, 141
XML documentValid, 150Well-formed, 149
XML handlingExtended, 208, 303, 304
xmlns, 149XML parser, 161XML Path Language (XPath), 164XML schema definition (XSD), 149XPath, 164xsd
all, 154choice, 154extension, 154list, 153normalizedString, 151restriction, 151sequence, 153string, 151token, 151union, 153
XSD, 149, 195Editor, 134
xslstylesheet, 162template, 162transform, 162
XSLT, 162Processor, 163
291 Book.indb 396 6/8/09 11:22:13 AM