SAP NetWeaver Process Integration 7.1 Overview of Supported Standards
SAP NetWeaver Regional Implementation Group SAP NetWeaver Product Management December 2007
SAP NetWeaver Process Integration 7.1 - Standards 1 Agenda
1. Introduction 2. Web Service Standards 3. Other Standards 4. Summary
SAP NetWeaver Process Integration 7.1 - Standards 2 Agenda
1. Introduction 2. Web Service Standards 3. Other Standards 4. Summary
SAP NetWeaver Process Integration 7.1 - Standards 3 [Introduction – Motivations & Overview] Business Drivers for Standards
Invest in differentiating features Better support customers Provide complete solution Extend business networks Time-to-value Business process flexibility
De-invest in non-differentiating features Buy standard software Best practices Compliance Conformance to industry standards Lower TCO Increase data accuracy, level of automation, productivity, supply chain performance Open source software (licensing cost and reuse of skills set)
Approach new markets
What makes standards important? One of the main reasons is the wide spread adoption. Speaking about differentiating features, this wide spread adoption will ease the integration among components, applications and business partners : – Boosting the customer support – Extending the functionality scope of these solutions, – Extending also the business networks – Improving the time-to-value of any investment – And finally providing business process flexibilities to adapt to ever changing business needs.
Regarding non-differentiating features, standard software will help comply with: Best practices General compliance topics Industry standards, Lowering developments cost, what will finally help also lower the total cost of ownership.
Consider that each time a customer approaches a new market, any integration effort will be significantly reduced too.
SAP NetWeaver Process Integration 7.1 - Standards 4 [Introduction – Motivations & Overview] General Value of Open Standards
Provides interoperability of SOA-based applications
Simplifies development of enterprise SOA applications
Increases platform accessibility for developers
Lowers TCO by reducing integration costs
Open standards help naturally achieve interoperability among SOA-based application, with lower integration efforts. They also simplify the development of Enterprise SOA applications in different ways. Since many usual types of requirements you usually find, like interoperability, security, semantics, modeling, etc., are already defined and implemented, you can concentrate on service composition and orchestration tasks. Developers also find it easier to learn and use, since they quickly become familiar and find out how to use new tools.
Again, all these benefits will redound in a lower total cost of ownership.
SAP NetWeaver Process Integration 7.1 - Standards 5 [Introduction – Organizations and Consortiums] OASIS
OASIS: Organization for the Advancement of Structured Information Standards.
Not-for-profit, international consortium that drives e-business standards : Development, Convergence and Adoption.
Founded in 1993
5,000 participants: over 600 organizations and individual members 100 countries.
http://www.oasis-open.org
One of the organizations is OASIS OASIS stands for “Organization for the Advancement of Structured Information Standards” It drives e-business standards development, convergence and adoption. They have a number of committees that work on different categories like Web services, XML processing, standard adoptions, etc. SAP is a foundational sponsor. Foundational sponsors are globally recognized as industry leaders and innovators.
SAP NetWeaver Process Integration 7.1 - Standards 6 [Introduction – Organizations and Consortiums] W3C
W3C: World Wide Web Consortium.
International consortium
Member organizations, a full-time staff, and the public work together to develop Web standards.
Mission: “To lead the World Wide Web to its full potential by developing protocols and guidelines that ensure long-term growth for the Web”
Published more than 90 standards, called W3C Recommendations.
More than 400 Members
http://www.w3.org
The World Wide Web Consortium, compiles the work of member organizations, its full time staff and other public work, to develop web standard protocols and guidelines. They have already issued more than 90 standards called W3C Recommendations. There 400 Member, SAP is one of them.
SAP NetWeaver Process Integration 7.1 - Standards 7 [Introduction – Organizations and Consortiums] WS-I
WS-I: Web Services Interoperability Organization
An open industry effort chartered to promote Web Services interoperability across platforms, applications and programming languages.
A standards integrator to help Web Services advance in a structured, coherent manner
Approximately 130 member organizations 70% vendors, 30% end-user organizations
http://www.ws-i.org
The Web Services Interoperability Organization, is an industry organization chartered to promote Web Services interoperability across – Platforms – operating systems and – programming languages.
SAP is also a Member of the WS-I Organization.
______ Specifically, WS-I creates, promotes and supports generic protocols for the interoperable exchange of messages between Web Services. In this context, “generic protocols” are protocols that are independent of any action indicated by a message, other than those actions necessary for its secure, reliable and efficient delivery, and “interoperable” means suitable for multiple operating systems and multiple programming languages. The organization’s diverse community of Web Services leaders helps customers to develop interoperable Web Services by providing guidance, recommended practices and supporting resources. All companies interested in promoting Web Services interoperability are encouraged to join the effort.
SAP NetWeaver Process Integration 7.1 - Standards 8 [Introduction – Organizations and Consortiums] UN/CEFACT
UN/CEFACT: The United Nations Centre for Trade Facilitation and Electronic Business
Perform activities dedicated to improve the ability of business, trade and administrative organizations, to exchange products and relevant services effectively.
Focus on facilitating national and international transaction through the simplification and harmonization of: processes, procedures and information flows
http://www.unece.org/cefact/
The United Nations Center for Trade Facilitation and Electronic Business, works to improve the ability of: – business – trade and – administrative organizations, to exchange products and services effectively.
They focus on the simplification and harmonization of: – processes – procedures and – information flow
SAP NetWeaver Process Integration 7.1 - Standards 9 [Introduction – Organizations and Consortiums] OSOA
OSOA: Open Service Oriented Architecture Group
Group of industry leaders
Define a language-neutral programming model for enterprise developers exploiting the Service Oriented Architecture characteristics and benefits.
Two main projects: Service Component Architecture (SCA) Service Data Objects (SDO)
http://osoa.org
OSOA stands for “Open Service Oriented Architecture Group” It is a group of industry leaders, and SAP is one the partners that joined the group. OSOA Group is focused on 2 projects: The “Service Component Architecture Project” is the hearth of the service oriented architecture, and is based on the idea that business functions are a series of orchestrated services. And the “Service Data Objects Project” that aims to create an abstract layer to manipulate generic data sources ______ Projects: Service Component Architecture aims to provide a model for the creation of service components in a wide range of languages and a model for assembling service components into a business solution - activities which are at the heart of building applications using a service-oriented architecture. Based on the idea that business function is provided as a series of services, which are assembled together to create solutions that serve a particular business need. These “composite applications” can contain both new services created specifically for the application and also business function from existing systems and applications Service Data Objects aims to provide consistent means of handling data within applications, whatever its source or format may be. SDO provides a way of unifying data handling for databases and for services. SDO also has mechanisms for the handling of data while detached from its source. Designed to simplify and unify the way in which applications handle data. Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web services, and enterprise information systems.
SAP NetWeaver Process Integration 7.1 - Standards 10 Agenda
1. Introduction 2. Web Service Standards 3. Other Standards 4. Summary
SAP NetWeaver Process Integration 7.1 - Standards 11 [WS-Reliable Messaging] Standard Specification
Describes a protocol that allows messages to be delivered complying a certain quality of service.
Independent of Network technologies.
Based on Web Services Specification.
The February, 2005 version was submitted to the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee. Voting to approve the resulting WS-Reliable Messaging 1.1 as an OASIS Standard begins on May 16th, 2007.
Source Application Target Application
Reliable Message Layer information Reliable Message Layer
In accordance with OASIS, the purpose of the WS-Reliable Messaging (WS-RM) specification is “… to create a generic and open model for ensuring reliable message delivery for Web Services.” This specification describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of either software component, system or network failures, and this protocol is described in a “transport independent way” allowing it to be implemented using different network technologies. The basic value of this specification is the description of a foundation level support layer for information replication. Version 1.1 will be an OASIS standard on May 16, 2007. Other vendors like Microsoft and IBM also support WS-Reliable Messaging specification. ______ To support interoperable Web Services, a SOAP binding is defined within this specification.
SAP NetWeaver Process Integration 7.1 - Standards 12 [WS-Reliable Messaging] Reliable Message Layer Responsibilities
Independent Software Layer from Application Layer.
Specifies a "delivery assurance”. If RM source or destination layers can’t comply with it, an error is raised to the sender application.
Source System Target System 1
Business Application
1 replicate MessageMessage 4 Error 2 Reliable Message Layer replicate Reliable Message Layer
3
Many errors may interrupt a conversation. Messages may be lost, duplicated or reordered. Further, the host systems may experience failures and lose messages. The “delivery assurance” is the concept that defines the quality of service for a message. Messages for which the delivery assurance applies, contain a sequence header block. The protocol supports the endpoints in providing these delivery assurances. It is the responsibility of the RM Source and RM Destination to fulfill the delivery assurances, or raise an error to the application layer. The protocol defined allows endpoints to meet this guarantee for the delivery assurances.
SAP NetWeaver Process Integration 7.1 - Standards 13 [WS-Reliable Messaging] “Sequence”: Definition and Exchange Protocol
EndPoint A EndPoint B Preconditions
CreateSequence()
CreateSequenceResponse(Id = http://www.mytest.com/test)
Message 1 Sequence(Id…;MessageNumber= 1) Message 1 Message 2 Sequence(Id…;MessageNumber= 2) Message 3 Sequence(Id…;MessageNumber= 3) Message 3 Message 4 Sequence(Id…;MessageNumber= 4)
Message 5 Sequence(Id…;MsgNum= 5;LastMessage) Message 5 SequenceAcknowledgement(Id…;AcknowledgementRate=1,3,5)
Sequence(Id…;MsgNum= 2) Message 2 Sequence(Id…;MsgNum= 4;AckRequested) Message 4 SequenceAcknowledgement(Id…;AcknowledgementRate=1,2,3,4,5)
TerminateSequence(Identifier…)
The WS-RM protocol uses a "Sequence" header block to track and manage the reliable delivery of messages. Each sequence has a “unique identifier element”, and each message within a sequence, has a “message number element” that increments by 1 from an initial value of 1. These values are contained within a “sequence header block” accompanying each message being delivered in the context of a sequence. In this slide, you can see an example where two endpoints exchange a sequence of messages. The protocol is as follows: – First of all, some preconditions are arranged – Then, the consumer endpoint A, asks endpoint B (the provider) to create a sequence and endpoint B, answers with a sequence identifier. – After that, the consumer endpoint starts to send messages, including the number and the “last message” token when required. – Later Endpoint B (the provider side), sends back an acknowledgement with a list of the message numbers it received. – If the consumer realizes that the server missed some of the messages, it sends the missing messages again, adding an acknowledgement request at the end. – At that moment, the provider side issues the new acknowledgement message. – When the consumer finally makes sure that every message reached the server, it sends a “terminate sequence” command.
SAP NetWeaver Process Integration 7.1 - Standards 14 [WS-Reliable Messaging] Implementation in SAP NetWeaver 7.1 PI
WS-Reliable Messaging (WS-RM) Asynchronous messaging (EO, EOIO) based on open WS standard Native support through Integration Engine (w/o adapter engine)
Integration Server
BusinessBusiness ProcessProcess EngineEngine
IntegrationIntegration EngineEngine
CentralCentral AdapterAdapter EngineEngine
FTP JMS SMTP … XI Protocoll WS-RM
The PI SOAP adapter as of today supports already asynchronous messaging, however with proprietary means since there was no standard available before. The WS-RM protocol is supported via an own entry in the integration engine (implemented in ABAP) and not the Adapter Engine. The XI 3.0 and XI 2.0 protocol will still be supported as well.
SAP NetWeaver Process Integration 7.1 - Standards 15 [WS-Reliable Messaging] Sequencing Support: SAP Design Criteria
Offer abstraction from the Technical Sequences (WS-RM). Application works with a "Logical Sequence" (ID) and WS Runtime maps this to WS-RM Sequences. Transactional Behavior. On consumer-side either all or none of collected calls are sent to the provider. On provider-side each call is executed in a separate transaction.
Let’s see how SAP implemented the WS-RM sequencing: The SOAP Sequence is a “Logical Sequence” and the “WS-RM Sequence” is the technical one, that is applications interact using a Logical Sequence ID, and the WS Runtime environment maps them to the WS-RM sequence. This sequencing have a transactional behavior – A whole sequence is represented by a transaction, but on the other hand on the provider sides, each message represents a separate transaction.
SAP NetWeaver Process Integration 7.1 - Standards 16 [WS-Reliable Messaging] The SAP TU&C/C Replication Pattern
Service Consumer Service Providers
Sales Portal SAP Back-end NetWeaver Systems Process
Trans id Store Compensation Info Integration
Sales Order Simulated LUW 10 PC 1 Printer 1 mouse 9 Consistent Status Accepted
Prod Order 10 PC 1 Printer 1 mouse 9 1 mouse Accepted
Confirm Updates Confirm Changes
SAP designed a replication pattern based on sequencing. The pattern is as follows: – First, a transaction ID is created on the consumer side – After that, it is necessary to store message compensation information. It will be automatically used by the kernel if something wrong happens before the sequence is terminated. – Then we can execute as many synchronous replications or lookups as necessary. – Once we have successfully finished, we send the confirmation and explicitly issue a commit-work statement. – The confirmation operation in an asynchronous replication with quality of service Exactly Once In Order, it is executed by the kernel after the local commit-work procedure finished. – The provider sides should at that moment also confirm the changes and delete any transient information used to simulate the logical unit of work.
SAP NetWeaver Process Integration 7.1 - Standards 17 [WS-Reliable Messaging] Monitoring the Integration Engine Message Exchange
Based on the previous example:
Synchronous SalesDocument_Replicate Æ Invoice
Synchronous SalesDocument_Replicate Æ Sales Asynchronous SalesDocument_Replicate Æ Confirm Order
In the PI 7.10 Integration Engine it is possible to monitor the messages exchanged during the replication process. This first two lines, correspond to the invoice replication (taken from the previous example), the next two, correspond to the sales order, and finally the last one belongs to the confirmations. There are some important things to bring out from this example: The first two interfaces (both the invoice and the sales order) are synchronous and the last one is asynchronous The protocol used is WS (for web services reliable messaging) At this moment the information displayed is at interfaces level and not at operation level (the operation concept is introduced in the next slides) From the moment the consumer program issues the commit-work until the WS runtime issues asynchronous operation, some delay could happen. The Confirm operation QoS is Exactly Once in Order Should a problem in the replication happen (system error, ABAP Roll-back statement, program cancellation, etc.), the kernel will replace the confirm operation by the compensate operation saved before the normal operations are executed. Finally, the QoS of the whole sequence can be considered both Best Effort + Exactly Once, what was not previously natively supported by the proprietary SAP RFC protocol.
SAP NetWeaver Process Integration 7.1 - Standards 18 [WS-Reliable Messaging] Error Situation
Service Consumer Service Providers
Sales Portal SAP Back-end NetWeaver Systems Process
Trans id Store Compensation Info Integration
Sales Order 10 PC Simulated LUW 1 Printer 1 mouse 9 Replication Rolled-back Accepted
Prod Order 10 PC 1 Printer 1 mouse
Compensate! Cancel Changes
Let’s now replicate the TU&C/C example, to see how it reacts in case of error The processing starts as usual, but something goes wrong when replicating the invoice. The consumer program must somehow rollback the work, so as to let the kernel know that the compensation message has to be triggered. Since the consumer works in a single logical unit of work, everything is handled by the kernel But on the provider sides, since there is no logical unit of work, the changes have to be rolled back manually. That also means that the previously replicated sales order, has to be kept in the meanwhile somehow not available to the application layer. That is, the providers have to implement a logic to validate and keep the information in a transient status until it is finally either confirmed or deleted. ______ SAP NW System >= 7.0 SPs 13 (since WS-RM will be down ported to SAP NW 7.0 SPS 13)
SAP NetWeaver Process Integration 7.1 - Standards 19 [WS-Reliable Messaging] TU&C/C Service Interface Design
You can design the TU&C/C interfaces in the Enterprise Services Builder
In the Enterprise Services Builder (ESB) you can create service interfaces with operations inside, also following the TU&C/C pattern. These operations correspond to a logical sequence. The new service interface object, that replaces the previous message interface object, is specially designed to be able to model TU&C/C sequences. The operations are components of the service interface and they can be: Normal Operation: To validate or retrieve information Tentative Update Operation: Used to replicate information Confirm Operation: Is the one that sends the successful finish message, or Compensate Operation: Always used in the TU&C/C pattern, but rarely used at runtime to inform the providers about replication problems.
SAP NetWeaver Process Integration 7.1 - Standards 20 [WS-Reliable Messaging] SAP TU&C/C Replication Pattern
TU&C/C = Tentative Update and Compensate or Confirm Interface pattern for synchronous, stateless and writing Compound Services Consists of three message types Tentative Updates, Compensate and Confirm Used for online transactions to fulfill user expectations
Business Agreement / Business Protocol Not a technical protocol that could be used regardless a deep knowledge of the called business logic
Involves Application to handle tentative updates and compensates Paradigm shift
Currently used to support stateless synchronous writing Web Services Completion of a TU&C/C transaction is bound to LUW lifetime Requires reliable messaging for confirm and compensate messages
Compensates are rarely Only used in case of an technical error or TA rollback Transaction should be completed to fulfill user expectation Errors during tentative updates (TU) do not inevitably cause a compensate Are sent asynchronously w/ EO semantic
Confirm Messages are "normal" business messages Contains business logic Are sent asynchronously w/ EO semantic
TUC&C is an pattern created by SAP that enhances the "Best Effort" (BE) quality of service (Qos) provided by synchronous messages to "Exactly Once"(EO) . Therefore, this pattern allows you to synchronously replicate information with both QoS BE and EO. The TU&C/C pattern must be supported and handled by the consumer and provider applications!! – XI at runtime executes message transmission, but the messaging framework cannot differentiate from standard messages! Client rollback will automatically trigger the previously registered "compensate" operation asynchronously. "Tentative Update" operations are synchronous. – Æ QoS BE not BE + EO (or EOIO). – It does not handle sequences, so in case of software errors (client, middleware, network, etc.), the provider could receive the message duplicated or even miss a message. It should be handled by the applications. – To make sure that information is properly replicated, you have to: - save the information to the database in such a way that it is not considered as "tentative" business information, - design the confirmation procedure to make sure that all the previous interactions have been successful and then change the information status to real business information. - Example:
Æ create sales order in draft mode (TUO Æ BE) Å retrieve sales order number (TUO Æ BE Response) Æ update sales order status to "released" (Confirm Æ EO).
SAP NetWeaver Process Integration 7.1 - Standards 21 [WS-Reliable Messaging] Configuration Time
The communication channel is configured to use adapter type “Web Service” The WS-RM (version 2005/02) protocol is automatically selected.
At configuration time, when you are creating your communication channels in the Integration Directory, there is a new type of adapter called “WS” (Web Service). The protocol is automatically set to “WS-RM 2005/02”
SAP NetWeaver Process Integration 7.1 - Standards 22 [WS-Security] SAP Web Services Security – Building on Industry Standards
¾ Security mechanisms based on open, standard-based and interoperable solutions for integration in existing infrastructures
Federation SAML 2.0
WS-Security WS-Secure Policy & Trust WS-Trust Performance Policy Conversation
Authorization XACML SPML LDAP Provisioning
WSS SAML WSS X.509 WSS Username Authentication Token Profile Token Profile Token Profile
Message Security WS-Security S/MIME
Document Security XML Sig XML Enc PKCS#7
Transport Security SSL/TLS GSS
Supported by SAP Future Work Under Evaluation
SAP NetWeaver Process Integration 7.1 - Standards 23 [WS-Security] New and Improved Features
Federation SAML 2.0 New Performance WS-Secure Conversation New
Policy and Trust WS-Security Policy New Authentication WSS SAML Token Profile New
Message Security WS-Security Improved handling of encrypted/signed data with SAP NW 7.1
SAP NetWeaver Process Integration 7.1 - Standards 24 [WS-Security] WS Security in SAP NetWeaver 7.1
Message Security
SOAP Messages
Point-to-Point Security Transport level security may not be sufficient SOAP WS-Security Standard 1.0 for SOAP document Messages security Encryption and Digital Signatures for messages XML encryption & XML digital signatures Document Level Authentication using Username token profiles X.509 certificate token profiles SAML Token Profile Full Support in ABAP/Java
Support for document level authentication used to depend on the underlying technology stack: – AS Java 7.0 supports all – AS ABAP 7.0 support was limited to Username token profiles with XML signature – AS ABAP 7.1 now supports all (inc. XML encryption and SAML token Profile) Securing the communication based on web services can be achieved by employing transport security, that is securing the communication channel (e.g. https). This way of realising secure communication is appropriate for point-to-point communication. With web services, it is mostly the case that one or more intermediates are employed. This means, point-to-point security is not enough. End-to-End security can only be achieved by securing the message. When messages are encrypted, it is vital that all participating entities respect a certain standard. There are currently many organizations which work towards standardization in message level security. The Oasis Group developed the SAML standard, for transmitting authentication and authorization information accross systems. IBM and Microsoft work on the WS-Security standard, which, beside authentication and authorization, handles the message security and authenticity based on various credentials (X.509, Kerberos, Username/Password, Single Sign On) at a more general level.
SAP NetWeaver Process Integration 7.1 - Standards 25 [WS-Security] Technology: WS-Trust
Problem Space Need to enable applications to construct trusted SOAP message exchanges
Technology Scope WS-Trust extends WSS to get security tokens from Security Token Service (STS) Actions: issue, renew, validate Tokens can be issued for a specific web service
Standards WS-Trust version 1.1 Specification (May 2004) Authors: Microsoft, IBM, Oracle, BEA
SAP NetWeaver Process Integration 7.1 - Standards 26 [WS-Security] Technology: WS-SecureConversation
Problem Space Need to provide secure communication for multiple SOAP messages
Technology Scope WS-SecureConversation extends WSS, WS-Trust to establish security context tokens between Web service and Web service consumer Mechanism to derive secret keys (which can be used for signature and/or encryption)
Standards WS- WS-SecurityConversation version 1.1 Specification (May 2004) Authors: Microsoft, IBM, Oracle, BEA
SAP NetWeaver Process Integration 7.1 - Standards 27 [WS-Security] Security Assertion Markup Language (SAML)
SAML is a protocol for encoding security related information (assertions) into XML and exchanging this information in a request/response fashion For message exchange, SAML relies on standard security protocols like SSL and TLS SAML authorities produce “assertions” in response to client requests. An assertion can be either an authentication or an authorization assertion Authentication assertion: piece of data that represents an act of authentication performed on a subject (user) by the authority Authorization assertion: piece of data that represents authorization permissions for a subject (user) on a resource SAML is an OASIS standard SAML Token Profile - WS-I interoperability profile for SAML security token that is used with WS-Security.
The Security Assertions Markup Language (SAML) is an XML-based framework for Web services that enables the exchange of authentication and authorization information among business partners SAML was developed by OASIS (Organization for the Advancement of Structured Information Standards), and is being supported by Liberty Alliance. SAML does not directly provide message integrity or confidentiality; it relies on XML Signature to protect integrity and on SSL/TLS for confidentiality
SAML defines an XML framework for exchanging authentication and authorization information. SAML uses XML-encoded security assertions and XML-encoded request/response protocol and specifies rules for using assertions with standard transport and messaging frameworks. SAML provides interoperability between disparate security systems. SAML can be applied to facilitate three use cases: single sign-on, distributed transactions, and authorization services
SAML Token Profile This is the interoperability profile for the Security Assertion Markup Language (SAML) security token that is used with WS-Security. WS-I creates profiles, which recommend what to use and how to use it from the various web services specifications created by W3C, OASIS, and the JCP
SAP NetWeaver Process Integration 7.1 - Standards 28 [WS-Security] Benefits of SAML
SAML The Security Assertions Markup Language SAP Logon Ticket Interoperable security solution to allow systems integration with great ease and minimal resources
Enables remote access to protected resources by exchange of authentication Domain Boundary information authorization information (currently not supported)
Provides standard based mechanisms to exchange security information using SOAP, HTTP(s)
Identity Federation – Provides technology to allow a business to securely interact with users originating from its vendors, suppliers, customers etc.
– Single Sign-On for Web Services Fine Grained Authorization – Users may authenticate at one site and be authorized by another
SAP NetWeaver Process Integration 7.1 - Standards 29 [WS-Security] Principle Propagation Based on SAML
Principle Propagation based on SAML Forward user context from sender to receiver Authorization check in receiving system based on original user
Integration Server
Request status Authorized?? of order xyz??
Principle propagation allows to forward the user credentials (user name, password) from the sender to the receiver according to the single-sign-on principle. With this the user credentials don’t have to be configured in the receiver adapter, but can be dynamically forwarded from the sender. An authorization check in the receiving system based on original user is performed. The implementation of this feature is based on the open standard SAML and can be used with backend systems that support the SAML technology. This feature uses the WS-RM protocol. Principle propagation based on SAP logon tickets as introduced with the previous PI releases (SP19 / SP10 ) will be still supported in SAP NW PI 7.1.
SAP NetWeaver Process Integration 7.1 - Standards 30 [WS-Policy] Requirements for a Web Services Policy Language
Expressiveness Describe any Web service constraint and capability Carry parameters
Robustness Don‘t change whenever new Web service constraints and capabilities are developed
Compose ability Attach policy to WSDL elements and UDDI entities Associate policy with WS-Addressing Endpoint References
Non-Goals Domain-specific policy attributes Policy exchange model
How can corresponding Web service features/requirements/capabilities be described? Supported security token type (X.509, Kerberos, etc.) Reliable messaging retransmission interval Etc. Message Integrity Message Confidentiality Authentication Authorization Reliable Messaging Distributed Transactions Stateful Services Business Context
SAP NetWeaver Process Integration 7.1 - Standards 31 [WS-Policy] Standard Specification
Provides XML Web Services-based system with a flexible and extensible grammar for expressing: Capabilities Requirements General characteristics
Allows Web Services to advertise their policies on security, QoS, etc. and Web Services consumers to specify their policy requirements.
Submitted to the W3C on the 25th April 2006.
Example policies: – Required security tokens – Supported encryption algorithms, and privacy rules. – how to associate policies with services and end points.
SAP NetWeaver Process Integration 7.1 - Standards 32 [WS-Policy] Example Security Policy
Valid Policy Operator Interpretations
This example illustrates a security policy using assertions defined in “WS-SecurityPolicy” Lines represent a policy for the algorithm suite required for performing cryptographic operations with symmetric or asymmetric key-based security tokens.
SAP NetWeaver Process Integration 7.1 - Standards 33 [WS-Policy] WS-Policy Information Model
It shows the normal form of a policy description
SAP NetWeaver Process Integration 7.1 - Standards 34 [WS-Policy] Compact Form – Reference Mechanism
URI-based policy identification mechanism
wsu:ID
Document-internal references can be resolved using the fragment identifier. References to external policy expressions need to be resolved using other mechanisms – When using URIs that identify network resources (URLs), the policy expression can be resolved using HTTP-GET – When using URIs that don‘t actually identify network resources, but rather identify abstract objects, the policy expression may be resolved using exchange mechanisms such as WS- MetadataExchange.
SAP NetWeaver Process Integration 7.1 - Standards 35 [WS-Policy] Web Services Policy Attachment (WS-PolicyAttachment)
Association of policies with Web service subjects
Subject type Arbitrary XML elements WSDL elements UDDI entities
Association type Internal association (see next slide) External association PolicyAttachment associates
Specifically, the specification of WS-PolicyAttachment defines the following: How to reference policies from WSDL definitions. How to associate policies with deployed Web service endpoints. How to associate policies with UDDI entities.
SAP NetWeaver Process Integration 7.1 - Standards 36 [WS-Policy] Attaching Policy to WSDL and UDDI
WSDL Policy references are made via global Policy attributes or PolicyReference element as WSDL defined in WS-Policy Policy references can be made to policy expressions defined inline, e.g. in wsdl:definitions section WSDL P UDDI Policy references are made via UDDI categorization mechanism Policy expressions are always remote to UDDI Policy entities UDDI Reusable policy expressions can be registered as distinct Models Policy-based discovery is limited to policy expression URIs Policy UDDI
SAP NetWeaver Process Integration 7.1 - Standards 37 [WS-Policy] WS-SecurityPolicy
WS-SecurityPolicy defines how to describe policies related to features defined in WS-Security
Specification released December 2002 by Microsoft, IBM, Verisign, and RSA Security
Example of policy:
“This Web service accepts X.509 certificates and Kerberos tickets, but you must choose exactly one of these and X.509 certificates are the preferred mechanism”
Policy Assertion – represents an individual preference, requirement, capability, or other property
“This Web service accepts X.509 certificates”
“This Web service accepts Kerberos tickets”
SAP NetWeaver Process Integration 7.1 - Standards 38 [WS-Policy] Policy Expression Using SecurityToken Assertions
This Web Service accepts X.509 certificates (preferred) and Kerberos tickets
X.509 certificates and Kerberos tickets are accepted by this Web service, with X.509 certificates preferred
SAP NetWeaver Process Integration 7.1 - Standards 39 [WS-Policy] Policy Assertions
Security Token assertion: Specifies security token types required/accepted by a Web service
Integrity assertion: Specifies that specific portions of a message must be signed, and specific algorithms/keys to be used (ex: SHA-1 algorithm, RSA key)
Confidentiality assertion: Specifies that specific portions of a message must be encrypted, and a specific algorithm to be used (ex: AES, 3DES)
Visibility assertion: Indicates portions of a message that must be visible to an intermediary or endpoint (i.e. unencrypted)
Message age assertion: Specifies the acceptable time period before messages are declared “stale” and discarded
SAP NetWeaver Process Integration 7.1 - Standards 40 [WS-BPEL] Standard Definition
BPEL: Business Process Execution Language
Executable business process modeling language.
Means to formally specify business processes and business interaction protocols
Web Service Based
WS-BPEL 2.0 was approved as an OASIS Standard in April 2007
What is BPEL? BPEL stands for Web Services Business Process Execution Language, and is a “process modeling language” that can be executed. The original main goals of BPEL were: Define business processes that interact with external entities through Web Services using an XML based language. Define a set of Web service orchestration concepts. Provide both hierarchical and graph-like control structures. Provide data manipulation functions. Support an identification mechanism for process instances Support the implicit creation and termination of process instances Define a long-running transaction model. Use Web Services as the model and to be Built on Web services standards.
As mentioned before, previous versions of XI and PI already supported BPEL4WS Version 1.1 to create and execute Integration Processes in the Exchange Infrastructure Business Process Engine, but recently, in April 2007, OASIS approved version 2.0 as an Standard, which includes a set of new functionalities, and a preview of these functionalities are going to be supported in PI 7.10.
SAP NetWeaver Process Integration 7.1 - Standards 41 [WS-BPEL] BPEL 2.0 Delta
New functionalities described in BPEL 2.0: New activity types: if-then-else, repeatUntil, validate, forEach (parallel and sequential), rethrow, extensionActivity Completion condition in forEach activity Variable initialization XSLT for variable transformations (New XPath extension function bpws:doXslTransform) XPath access to variable data (XPath variable syntax $variable[.part]/location) XML schema variables in Web service activities (for WS-I doc/lit style service interactions) Locally declared messageExchange (internal correlation of receive and reply activities) Clarification of Abstract Processes (syntax and semantics)
SAP NetWeaver PI 7.1 supports a preview of this functionalities
SAP NetWeaver Process Integration 7.1 - Standards 42 [WS-BPEL] BPEL Support in Detail
Activities (everything in lowercase) if-then-else 9 repeatuntil 9 validate 8 foreach 9 rethrow 8 extensionactivity 9 Completion condition in forEach 9 activity
Variable initialization 9 (supported in the import interface)
SAP NetWeaver Process Integration 7.1 - Standards 43 [WS-BPEL] BPEL Support in Detail
XSLT for variable transformations 9 supported as XI service
XPath access to variable data planned support in 7.1
XML schema variables in Web service 9 (except complex types as they are not activities supported in the XI repository) Locally declared messageExchange 9
Clarification of Abstract Processes 8(considered for future release for process (syntax and semantics) templates)
SAP NetWeaver Process Integration 7.1 - Standards 44 [WS-BPEL] BPEL4People
Standard Support BPEL4WS 1.1 (specification / already adopted) WS-BPEL 2.0 (specification / preview / implementation) Plans to support BPEL4People
SAP is A leader in BPEL-Standard adoption A driver of the BPEL-Standard SAP was one of the proposers of the OASIS WS-BPEL Technical Committee SAP works together with IBM on BPEL standard extensions
In July 2005, SAP and IBM worked together to publish the “BPEL4People” whitepaper which describes how the Web Services Business Process Execution Language (WS-BPEL) needs to be extended in principle to cover user interactions with business processes. In practice, a user must sometimes decide which processing branch an integration process is to continue in.
SAP NetWeaver Process Integration 7.1 - Standards 45 [WS-BPEL] BPEL4People Implementation in SAP NetWeaver PI 7.1
User Interaction Modeling in ESR Integration Process
This is a screen preview showing how the “generic user decision” step is going to be modeled. To include the user interaction, you will need to add a “User Decision” step to the definition of the process and then, define the required decision options. The system will insert a processing branch for each decision option. Later you will insert the required processing steps in these processing branches. The agent for the decision, could be either a user or a role already defined on the Integration Server. At runtime, the intended user receives a dialog work item in the workflow inbox. This displays a corresponding button for each decision option that you defined. As soon as the user chooses a button, the system resumes the integration process in the relevant processing branch.
SAP NetWeaver Process Integration 7.1 - Standards 46 [WS-BPEL] Implementation in SAP NetWeaver PI 7.1
BPEL Preview
In the Integration Process of the Enterprise Service Builder you can always switch the editing area to show the BPEL for the integration process defined. You will notice there, the use of the “extensionActivity” element as described in the BPEL 2.0 standard and the “UserDecision” SAP extension as described in BPEL4People specification. Both these two functionalities allow the implementation of the “Generic User Decision” in a standard way.
SAP NetWeaver Process Integration 7.1 - Standards 47 Agenda
1. Introduction 2. Web Service Standards 3. Other Standards 4. Summary
SAP NetWeaver Process Integration 7.1 - Standards 48 [Core Components Technical Specification] Standard Specification
Describes a suite of standards to create a new paradigm on semantic interoperability. Provides:
A methodology for semantic data modeling, achieving a common understanding of data structures and message types on a syntax independent level.
A way to identify, capture and maximize the re-use of business information to support and enhance information interoperability across multiple business situations.
The specification focuses both on:
human readable
and machine-processable representations of this information.
ISO/TS 15000-5 Version 2.01
The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) has defined a suite of standards that together create a new paradigm in semantic interoperability. At the heart of this standards stack is the Core Components Technical Specification, that describes and specifies a semantic-based approach to the well-understood problem of the lack of information interoperability within and between applications and data bases in the e-business arena. CCTS is gaining widespread adoption in vertical and horizontal standards development organizations around the globe and will enable SAP to provide the highest level of semantic interoperability possible between SAP and non-SAP applications. SAP is significantly engaged in UN/CEFACT CCTS work, to improve the CCTS standards stack as the methodology of choice to create true worldwide, business semantic interoperability. CCTS basically provides a semantic for data modeling in a general and reusable way making the modeled objects both human readable and also machine processable. CCTS is described in the ISO (International Organization for Standardization) Technical Specification 15000 Part 5 Version 2.01 ______ Articles in SDN: https://www.sdn.sap.com/irj/sdn?rid=/webcontent/uuid/1baa57f9-0a01-0010-1684-c42a08982294 ISO/TS 15000 consists of the following parts, under the general title Electronic business eXtensible mark-up language (ebXML): – Part 1: Collaboration-protocol profile and agreement specification (ebCPP) – Part 2: Message service specification (ebMS) – Part 3: Registry information model specification (ebRIM) – Part 4: Registry services specification (ebRS) – Part 5: ebXML Core Components Technical Specification, Version 2.01(ebCCTS) ebXML: Electronic Business using eXtensible Markup Language, is a family of XML based standards sponsored by OASIS and UN/CEFACT whose mission is to provide an open, XML-based infrastructure that enables the global use of electronic business information in an interoperable, secure, and consistent manner by all trading partners. The ebXML architecture is a unique set of concepts; part theoretical and part implemented in the existing ebXML standards work. The ebXML work stemmed from earlier work on ooEDI (object oriented EDI), UML / UMM, XML markup technologies and the X12 EDI "Future Vision" work sponsored by ANSI X12 EDI.
SAP NetWeaver Process Integration 7.1 - Standards 49 [Core Components Technical Specification] Basic Components Overview
Core Components Technical Specification
Generic Realm “Business Context” dependent
Business Information Entities: Core Components: Basic BIEs. Basic CCs. Association BIEs. Asoc. CCs. BasedBased onon Aggregate BIEs. Aggregate CCs. CC Types
Data Types
Let’s see some basic CCTS objects definitions: – The “Core Component”: is a semantic building block, which is used as a basis to construct all electronic business messages. – The “Business Context”: Is the formal description of a specific business circumstance as identified by the values of a set of “Context Categories”, allowing different business circumstances to be uniquely distinguished. – The “Business Information Entity” (BIE): Is a piece of business data or a group of pieces of business data with a unique Business Semantic definition. – And finally the “Data Type”: defines the set of valid values that can be used for a particular Basic Core Component Property or Basic Business Information Entity Property. It is defined by specifying restrictions on the Core Component Type that forms the basis of the Data Type. For example, A generic “Address” core component could be defined using other components and finally using data types. But when that address, is used in the business context of a particular sales order type, to identify the delivery address for a customer, it becomes a business information entity.
SAP NetWeaver Process Integration 7.1 - Standards 50 [Core Components Technical Specification] Implementation in PI
structure
SAP Global Data Types (GDT) are based on the CCTS components. Here you can see the correspondence between the CCTS definition and the implementation in PI. In this example we show a GDT based on a Core Data Types (CDT): CDTs: …are syntax neutral and represent the smallest and most generic pieces of information in a business data model. …have a library that currently consists of 22 discrete types such as Amount.Type, BinaryObject.Type, Code.Type, DateTime.Type, Identifier.Type, Measure.Type, Text.Type, etc. …are intermediate data types, that are a level above primitive types - such as Decimal, String, Boolean, Binary, and Numeric. …differ from primitives because they carry relevant characteristics, which further define and refine the CDT value domain. …have only a primarily business meaning and can thus be used by all existing Basic Core Components (BCCs) and their affiliated contextualized Basic Business Information Entities (BBIEs) as a means for characterizing the actual type of information (e.g. Amount, Identifier, etc.). In this picture you can see the relationship between the CCTS specification and SAP Implementation for the Amount, Binary Object and Date GDTs based on a CDT.
SAP NetWeaver Process Integration 7.1 - Standards 51 [Core Components Technical Specification] Implementation in PI - Continued
GDTs could be either more complex, which is comparable to a CCTS “Aggregated Business Information Entity” or even simple that is comparable with a CCTS “Basic Business Information Entity Property” (which is newly defined in CCTS V3.0 working draft). In this screenshot you can also see the example details of the simple “Amount” GDT, It has: – a classification to determine if it is based on a Core or aggregated data type along with its representation term. – A Set of Primary components like name, namespace, XSD type, etc. – Supplementary components, with their specific properties detail – plus a comprehensive documentation that covers the definition, usage, structure, value ranges and an example – In the PI 7.10, Software Component Version “SAP BASIS 7.10”, namespace “http://sap.com/xi/BASIS/global”, you will find a set of folders with GDTs.
SAP NetWeaver Process Integration 7.1 - Standards 52 [Core Components Technical Specification] Implementation in PI - GDT Aggregation
Aggregated
Core
As mentioned before, a GDT can be simple or more complex as you aggregate them. They are distinguished in Basic GDTs and Aggregated GDTs. Basic GDTs are always built directly on a CDT. Aggregated GDTs are built either on Basic or Aggregated GDTs an shown in this example: – The Basic DateTime GDT is based on the CDT “DateTime” – The Aggregated TimePoint GDT is using the DateTime simple GDT as one of its components – And in also been used as a component in a more complex aggregated GDT.
SAP NetWeaver Process Integration 7.1 - Standards 53 [Core Components Technical Specification] Relationship between GDTs and Other PI Objects
This slide shows from a higher point of view, how you aggregate objects: – starting from a basic built-in XSD type, – That then is used in an SAP Core Data Type, – What in turn, is used again to build the GDTs with a business semantic orientation.
These GDTs are included in “Context Data Types” specific for an Application Scenario, Later a set of this Context Data Types could be used to create the: – PI Message Types, – and Service Interfaces Operations.
SAP NetWeaver Process Integration 7.1 - Standards 54 [Core Components Technical Specification] SAP Global Data Types Summary
Are company wide defined data types based on international standards Defined in a standards based way in the ES Repository SAP – wide approved with reference to the Governance process Semantic building blocks for service interfaces enabling reuse Based on ISO 15000-5 and UN/CEFACT CCTS Basis for Message Types in the ES Repository Will replace the current IDoc and BAPI technology in the long term.
To summarize, GDTs – ... are based on the rules described in the international standard UN/CEFACT CCTS (Core Component Technical Specification) – ... are reusable semantic building blocks for service interfaces and business objects used in PI through the corresponding Message Types – … are SAP-wide established and reconciled data types with business-related content – .. the catalog, collects all the GDTs approved by the Governance Process for Business Content (embedded in the SAP standard ’Application Integration & Interfaces‘) of the SAP Process Integration Council (PIC). - They have been defined in the Enterprise Service Repository, are described by XML schema and have been documented in accordance with the documentation templates - Therefore within SAP, it is mandatory to use GDTs to define business object attributes and service interface parameters (also called signatures). - With this approach, SAP ensures that if the same attribute occurs in business object nodes or service interfaces, it is always described by the same or a derived GDT. – SAP uses the CCTS as a basis for the development of the new SAP GDTs, which will replace the current IDoc and BAPI technologies in the long term. ______ Individual GDT documents can be accessed based on their PIC approval status. Keyfigures (as of December 2006): 2070 GDTs including 960 codes and 470 identifier. For SAP it is crucial to support open standards when defining business objects and service interfaces, with the basis being Global Data Types (GDTs). GDTs represent a set of data types with clear business semantics mandatory for all SAP applications. GDTs have the following characteristics: – Re-usable data types for service interfaces and business object nodes – Development based on the data type development methodology described in the international – Standards ISO 15000-5 and UN/CEFACT CCTS (Core Component Technical Specification) – Defined in ES Repository using Extensible Markup Language (XML) schema – Approved SAP-wide by the Governance Process for Business Content (advanced by Process Integration Council (PIC)) – Development methodology designed for composing a consistent data type model out of a predefined and controlled semantic vocabulary and predefined XML fragments within a community
SAP NetWeaver Process Integration 7.1 - Standards 55 [Core Components Technical Specification] http://www.untmg.org/
SAP plays a leading role in CCTS adoption and implementation, and the UN/CEFACTorganization recognizes this level of engagement. This screenshot shows the UN/CEFACT Techniques and Methodologies Group home page, where you can see an important reference to SAP GDTs as basis for the business objects and Enterprise Services.
SAP NetWeaver Process Integration 7.1 - Standards 56 [Core Components Technical Specification] CCTS and SAP in Wikipedia
SAP is also directly referenced in the UN/CEFACT description in wikipedia.
SAP NetWeaver Process Integration 7.1 - Standards 57 [UDDI] Standard Specification
UDDI: “Universal Description, Discovery and Integration”
UDDI - a specification of: APIs for publishing and searching for business services and service descriptions, and subscribing to changes to these. A data model with built-in metadata extensibility to characterize business services according to enterprise needs. Nodes, registries, affiliated registries
UDDI v3 became an OASIS Standard 3 February 2005
UDDI stands for Universal Description, Discovery and Integration. This specification basically describes the required model and APIS for a services registry where applications typically – Publish or find web services that meet arbitrary criteria - Either within an organization or across organizational boundaries – Determine the security and transport protocols supported by a given web service and – Insulate applications from failures or changes in invoked services. UDDI Version 3 became an OASIS Standard in February 2005. UDDI was integrated into the Web Services Interoperability (WS-I) standard as a central pillar of web services infrastructure ______ UDDI v3: – Support for registry affiliation – Publisher assigned keys – Human-friendly, URI-based keys – Subscription API – Support for digital signatures – Information Model Improvements – categoryBags on bindingTemplates – Operational information – Support for Complex Categorization – Extended Discovery Features – Support for previous multi-step queries into single-step complex queries – Extended Wildcard support – Management of large results sets
SAP NetWeaver Process Integration 7.1 - Standards 58 [UDDI] The Need for a Services Registry
CONSUMER TOOLS (e.g. Visual Composer) SERVICE DEFINITIONS Which services are modeled or implemented in the landscape? Which services can be invoked in the landscape? Where to publish the invocable service endpoints?
CONSUMER PROVIDER
CONSUMER SERVICE APPLICATION IMPLEMENTATION INVOCATION SERVICE ENDPOINT
Why is a “services registry” needed in a service oriented application architecture? – A registry is usually identified as one of the first requirements of SOA adoption, and registries play an important role in governance. In simple terms, a registry is a catalog or index that acts as the “system of record” for the services within an SOA. – A registry is not designed to store the services themselves; rather, it indicates their location by reference. – Also, having a centralized catalog of services is significant from an organizational perspective because it enables the easy discovery, reuse, and management of services. – A robust registry is an important component of any SOA governance solution.
SAP NetWeaver Process Integration 7.1 - Standards 59 [UDDI] Implementation in SAP NetWeaver PI 7.1
Services Registry ES Repository Adds location information to ES Repository necessary for consumption PROVIDER MODEL METADATA (UDDI standard) Service Interfaces Single source for discovery, enables Operations SERVICE Data Types IMPLEMENTATION simple mass configuration and runtime governance Taxonomy put services in business REFERENCE context Services Registry Interoperable with other UDDI registries UDDI V3.0 (Systinet) SERVICE MODEL PUBLISH PUBLICATIONS
SERVICE ENDPOINT PUBLICATIONS
CONSUMER TOOLS
COMPOSITION ENVIRONMENT DISCOVER
Another important factor is the interoperability of the registry with other components of the SOA infrastructure. As mentioned before OASIS provides a platform-independent standard for registry interoperability known as UDDI (Universal Description, Discovery, and Integration). – UDDI defines a Web Services-based programming interface that allows different consumer applications, tools, and run-time systems to query the registry, discover services, and interact as required to provide management and governance capabilities. – UDDI is the most commonly adopted standard and ensures the greatest degree of compatibility with other products in the environment. SAP Enterprise Services Repository contains the model metadata along with the interfaces, its operations and global data types. Services Providers implement the services using Enterprise Services Repository metadata and then publish these implemented services in the Services Registry. Consumer tools in turn access the Services Registry to find the centrally published services with all the required information to consume it. – To simplify the search, services are grouped and organized in taxonomies. – This SAP Services Registry information is published in an open standard way complying with the UDDI V3.0 requirements. SAP Services Registry can interoperate with other UDDI registries like Systinet.
SAP NetWeaver Process Integration 7.1 - Standards 60 [UDDI] The Services Registry - Benefits
UDDI 3.0 based Naming standards and classifications enabling governance Procedures for client development Service evolution and versioning Service management and governance Procedures for backend publications Taxonomy search Keyword search services Service configuration Documentation
We can conclude that the “Services Registry” has a large number of centralization related benefits like: – General governance enabling or improvements for: - services management, - Standardization - Classification - definition of procedures. – And some other advantages like centrally defining and exposing functionalities for configuration, documentation, creation of global taxonomies and versioning web services. Additionally at runtime the consumer is able to configure the web service dynamically, what provides additional flexibility in terms of performance and service level agreements.
SAP NetWeaver Process Integration 7.1 - Standards 61 [UDDI] Access to the Services Registry in PI
1- Access java engine home page: http://{host}:{port}
2 – Select “Services Registry”
To access your PI 7.10 Services Registry front end application, you have to access first your SAP Web Application Server home page. Then select “Services Registry” And finally a separate windows will start the WebDynpro application.
SAP NetWeaver Process Integration 7.1 - Standards 62 [UDDI] Services Registry APIs
The Services Registry provides a set of standard UDDI APIs plus additional proprietary SAP Interfaces both in Java and ABAP.
SAP Services Registry implements the required UDDI Version 3.0 APIs Additionally there are three sets of proprietary interfaces: Classification Services Additional Services Registry APIs for Java and Additional Services Registry APIs for ABAP too.
SAP NetWeaver Process Integration 7.1 - Standards 63 [UDDI] Accessing SDN Services Registry
There’s a “Services Registry” published on SAP Developers Network. To access the application: – Go to SDN home page (http://sdn.sap.com) – Select “Enterprise SOA” Æ “Explore Enterprise Services” – Select “Services Registry” Æ and “Service Registry for the ES Workplace”
You will be able to access the application and browse the services published from different internal systems. It is even possible to test the services
You will notice that services are classified in groups, the meaning of the groups are: – DPB: This group consists of the three classification systems Deployment Unit – Process Component – Business Object. - Each deployment unit consists of process components. Each process component consists of business objects. – And SPB: This group consists of the three categories Software Component Version – Process Component – Business Object.
SAP NetWeaver Process Integration 7.1 - Standards 64 Accessing SDN Services Registry
SAP NetWeaver Process Integration 7.1 - Standards 65 [MTOM] Standard Specification
MTOM is the method of efficiently sending binary data to and from web services.
It uses XOP (XML-binary Optimized Packaging) to transmit binary data and is intended to replace both MIME and DIME attachments.
MTOM: SOAP Message Transmission Optimization Mechanism
Based on SOAP 1.1 Binding for MTOM 1.0
MTOM stand for SOAP Message Transmission Optimization Mechanism and is a W3C Recommendation that describes a method to package SOAP messages in order to improve transmission efficiency. Before this mechanism appeared, there were different predecessors defined to send binary data with SOAP 1.1. MTOM is based on XOP (XML-binary Optimized Packaging), a method of efficiently embedding binary data in XML. ______ MIME (Multipurpose Internet Mail Extensions) is the original attachments specification, developed for sending attachments via email. MIME has been used for the original SOAP with Attachments specification and uses MIME multipart to send attachments. DIME (Direct Internet Message Encapsulation) has been developed as a replacement for MIME. Like MIME, DIME uses data records with headers. However, with DIME each header contains the length of the payload, rather then a separator string. MTOM on sdn: https://www.sdn.sap.com/irj/sdn?rid=/webcontent/uuid/fcbc97b6-0a01-0010-6594- f8208ff674f9
SAP NetWeaver Process Integration 7.1 - Standards 66 [MTOM] Configuration in PI
Configure the communication channel to optimize XML transfer using MTOM XML Format.
To configure MTOM usage in you WS communication channel, you simply select “Binary MTOM XML format” as method for optimizing the XML Transfer.
SAP NetWeaver Process Integration 7.1 - Standards 67 Agenda
1. Introduction 2. Web Service Standards 3. Other Standards 4. Summary
SAP NetWeaver Process Integration 7.1 - Standards 68 Summary of Supported Standards
Consortium/Org Standard Supported Implementation anization Specification Version
W3C WS-Security 1.0 Message Header W3C WS-Policy 1.2 WSDL document W3C MTOM 1.0 Integration Engine OASIS WS-BPEL 2.0 Integration Processes OASIS WS-RM 1.1 Integration Engine OASIS UDDI 3.0 Service Registry UN/CEFACT CCTS 2.01 SAP Global Data Types
This is the list of most important supported standards versions in SAP NetWeaver PI 7.10 Considering W3C Recommendations, we will be supporting WS-Security 1.0, WS-Policy 1.2 and MTOM 1.0 OASIS WS-BPEL 2.0 was very recently released and just a preview of these functionalities are going to be included, but both the forthcoming WS-Reliable Messaging 2.0 and also UDDI 3.0 will be fully covered and there are additional features developed both for Reliable Messaging (like the TU&C/C pattern) and the additional functionalities and APIs for the Services Registry. Regarding UN/CEFACT CCTS 2.01 and considering that SAP is a technology leader with a strong knowledge of business processes, it is quite natural for the company to take the lead and drive the adoption of this standard.
SAP NetWeaver Process Integration 7.1 - Standards 69 Usage Summary
Standard / Benefits Specification / Recommendation
WS-Security Design Time: Interoperability at security level
WS-Policy Design time: Interoperability at several levels WS-BPEL 2.0 Design Time: Simplify user interaction in the Integration Processes
Runtime: Increase support for user interaction (PI 7.10)
WS-RM Design time: provides abstraction from communication layer.
Runtime: Standard communication layer
UDDI Discovery: Support Governance and reuse/Interoperability
Runtime: Dynamic Configuration
CCTS Design and modeling times: Interoperability at data level and business semantics
MTOM Runtime: optimize SOAP message size to boost performance
Now you see summarized in a single slide the most remarkable benefits that you get from each one of these standards: WS-Security, WS-Policy, UDDI and CCTS basically increase interoperability at several levels. BPEL2.0 specifically extended the original reach for automated process execution, and opened the door to human interactions. WS-Reliable Messaging specification defined a standard layer for dependable messages transmission, what is enriched by a set definitions on the security arena (provided by the WS-Security standard), the interoperability rules (provided by the WS-Policy standard) and also a improvement in runtime performance (provided by MTOM) defining a comprehensive standard way to securely and effectively exchange information.
SAP NetWeaver Process Integration 7.1 - Standards 70 Copyright 2007 SAP AG. All Rights Reserved
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.
The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non- infringement. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.
SAP NetWeaver Process Integration 7.1 - Standards 71