02 crm middle ware overview

1

CRM Middleware overview:Middleware & Message Flowin SAP CRM 5.0

SAP AGCRM CoE EMEA

December 2008

2

1. Message Flow Overview2. BDocs3. Data Distribution4. Internal Data Flow5. Flow Contexts6. CRM Middleware Services7. Appendices

Middleware and Message Flow

3

Message Flow Overview

CRM Server

Inbound

R/3 BackendMobile Clients


Outbound

data flow

Validation

The internal data flow consists of three main steps:

inbound processing,

validation, and

outbound processing.

4

Message Flow Overview

CRM Server

Inbound



sBDocBAPI

mBDoc

sBDocBAPI

OutboundValidation

Inbound processing: Incoming data of different formats, eg BAPI structures from a SAP R/3Backend, XML/SOAP or IDocs, are converted into messaging BDoc messages.

Validation: the integrity of incoming data is validated by the respective application. In case of asuccessful validation, the data unit is passed on to outbound processing. In case the incomingdata is not valid, the original message is sent back to the sender with an error status.

Outbound processing: the receiving systems, eg SAP R/3 Backend or external systems, aredetermined. Then the messaging BDoc message is passed to the corresponding outboundadapter, which converts the message into the data formats of the receivers.

5



6

The data container of choice in SAP CRM is a so-called Business Document which can bedefined as

a container of business data that contains all the required information for a business process(instead of having to process/transport several individual table entries),

the smallest unit of data for supporting a single complete business transaction,

a logical unit of data involved in business flow (for example all data about one order or onepartner and so on)

BDoc messages are used for

data processing within the CRM System,

data exchange with Mobile Clients

CRM ServerMobile Clients

CRM ServerMobile Clients

ExchangeCustomer “Smith”

KNA1 ADRC KNVV...

BDoc “Smith”

BDocs are units for processing and transporting business objects

BDocs: what are they ?

7

There are BDoc types, BDoc instances, and BDoc messages:

A BDoc type or structure has to be defined for each required business object, such as contactperson or sales order. It contains all the R/3 table entries that taken together make up thebusiness object.

A BDoc instance is a specific example of a given BDoc type containing specific values for allfield values.

A BDoc message (or just BDoc) contains modified fields only. These include new fields as wellas deleted fields. The difference between a BDoc message and a BDoc instance is that there isonly one BDoc instance for a Business Object but there can be multiple BDoc messages (withtheir own IDs) for one BDoc instance. A BDoc instance is replicated to a Mobile Client using aBDoc message in which all fields are filled.

BDocs: basic concepts, nomenclature

Customer BDoc “Smith”:TASK = “update” [or insert, or delete]Fields: CITY1 = “New York”,

STREET = “1 Broadway”

BDoc type

BDoc instance

BDoc message

KNVV

ADRC

KNA1

Customer BDoc “Smith”:NAME1 = “Smith”NAME2 = “John”KUNNR = “2045”....

structure,values for all fields

structure,no content

Modified contentof some fields

8

BDocs: BDoc flows

CRM ServerSAP R/3System

OtherSystems

SynchronisationFlow (sBDocs)

BW

Mobile Clients

MessagingFlow (mBDocs)

Messaging flow using mBDocs is an infrastructure for transferring data to the CRM ServerApplications within the CRM Server and from/to external systems. The “philosophy” of anmBDoc is mainly that of a temporary data container (not unlike an IDoc). After an mBDoc hasbeen delivered, its ceases to exist and its status is unimportant.

Synchronization flow using sBDocs is an infrastructure especially designed for the highlydistributed mobile scenario where due to the large number of databases supplied with data it isnecessary to optimise the data volume distributed. Not all potential recipients get all data, andwhen the distribution rules are changed, it has to be possible to find out who received what dataaccording to the old rules in order to adjust the data. The status of sBDoc flows is therefore kept(in so-called look-up tables, see below).

Synchronization and messaging flows are linked through mapping services.

9

Messaging BDoc Types

mBDoc types consist of two parts

• Classical part

Receiver information

• Extension

Transactional data

BDocs: messaging BDoc types (1)

mBDoc

/1CRMG0/CRMW_BUPA_HEAD002

BUS_EI_MAIN

The classical part that is supposed to hold data used for receiver determination (in outbounddirection):

Hierarchical segment structure

Generated structure

Contains data relevant for receiver determinationThe extension part that is supposed to hold delta or extract data intended to pass into the CRMServer application (inbound case) or to send to remote systems (outbound case):

Complex data type

Contains the transaction data

The classic part is designed in the BDoc modeler. You require data elements for field definitions.The extension part is maintained in the data dictionary and only a reference is maintained in thedata dictionary.

For master data the extension part usually contains the following structure:

There is one data type that can hold delta or extract data for one object instance. Usually there isone root segment and possibly several child and grandchild segments. Each segment more orless reflects one database table. For each data field there is a change indicator field. For eachrow there is some control information to indicate row operation for delta messages. The entitytype then holds all data of all segments for one object instance. The related data type, which ismaintained in the BDoc modeler, then is a table type of this entity type.

When creating the mBDoc type in the BDoc modeler you maintain the classical part of the BDoc by

10

mBDoc Classic & Extension Part

Classic Part – receiver info

Extension Part – transactional data

11

BDoc Modeler: Transaction SBDMBDocs: Exploring a BDoc type

Segment Structureof BDoc typeBUPA_MAINwith header

segment fields

Segment Structureof BDoc typeBUPA_MAINwith header

segment fields

SBDM

The BDoc Modeler is a tool used for displaying, creating and enhancing BDoc types.

The existing BDoc types are listed in the BDoc overview (navigation tree) of the BDoc Modeler.Here you can select and expand a BDoc type to display its structure. The structure shows thehierarchy of the data segments.

Note that the definition and enhancement of BDoc types require knowledge of the application.The CRM Middleware does not have the business logic to create or enhance BDocs. From thispoint of view, it is just a data container to transport and process BDoc messages.

BDoc modeling features are available with CRM 3.0 and higher

Modeling of messaging BDoc types.

Assignment of one or more synchronization BDocs type to a messaging BDoc type (n:1relationship).

Assignment of site types (see unit “Data Exchange”) to synchronization and messagingBDoc types.

12

BDocs: Exploring a BDoc type – Extension partof mBDoc

The Extension partof the mBDoc is astructure in thedata dictionary

double-click to seethe Extension part

of the mBDoc

SBDM

The classic part is designed in the BDoc modeler. You require data elements for fielddefinitions. The extension part is maintained in the data dictionary and only a reference ismaintained in the data dictionary.

13



14

Replication = Message forwarding to one or more sites

Different Types:

Bulk replication

Intelligent replication

Data distribution: different types of replication

BDoc

? ?

??

?

BDoc messages are replicated to sites (local databases) and not to individual users.

Two different replication types can be distinguished: bulk replication and intelligentreplication.

bulk means, everybody gets all or nothing,

intelligent means distribution by rules.

mBDocs can be replicated in bulk, or simple intelligent

by default: bulk

sBDocs can be replicated in bulk, or through any kind of intelligent replication

By default: mostly intelligent; this is necessary because of the sophisticated data distributionin mobile scenarios. However, the replication types for BDoc types can easily be changed, ifrequired.

The replication type of a BDoc is customized in the Administration Console (TransactionSMOEAC)

15

Data distribution: bulk replication

A B C D

#1 ..#2 ..#3 ..#4 ..#5 ..#6 ..#7 ..#8 ..#9 ..#8 ..

#1 ..#2 ..#3 ..#4 ..#5 ..#6 ..#7 ..#8 ..#9 ..#8 ..

#1 ..#2 ..#3 ..#4 ..#5 ..#6 ..#7 ..#8 ..#9 ..#8 ..

#1 ..#2 ..#3 ..#4 ..#5 ..#6 ..#7 ..#8 ..#9 ..

Definition of theresponsible

sites

BDoc messages ofone type

Filter on BDoctypes

Bulk Replication

The simplest replication type is bulk replication: every site that is subscribed gets all or nothing ofthe data.

Bulk replicated BDoc messages are distributed according to their type, regardless of themessage content and their relation to other BDoc messages. In this example, all bulk BDocmessages are replicated to site A, B and D.

These objects do not cause content-based realignment (data redistribution).

Bulk replication is particularly suitable for small tables.

typical examples for bulk-replicated data are customizing data (the T* tables) or employeedata.

Both sBDocs and mBDocs can be bulk replicated for example mBDoc BUPA_MAIN.

16

Data distribution: intelligent replication

#1 ..#2 ..#3 ..#4 ..#5 ..#6 ..#7 ..#8 ..#9 ..#8 ..

#1 ..#2 ..#3 ..#4 ..#5 ..#6 ..#7 ..#8 ..#9 ..

#1 ..#2 ..#3 ..#4 ..#9 ..

#8 ..#9 ..

#1 ..#3 ..#4 ..#7 ..#8 ..#9 ..

A B C D

Definition of thereplication rules

Filter on BDocmessages

BDoc messages ofone type

Intelligent Replication

Replication objects are distributed depending on their contents and their relation to otherreplication objects (in this example, only site A receives the complete set of data; sites B, C andD obtain merely a subset).

Specific replication rules are necessary.

Example: for intelligent replication sBDoc type “CAPGEN_OBJECT_WRITE” (customer andprospects).

17

BDocType

1:1 relationAssignment of replicationtype to BDoc type

Assignment of possiblecriteria fields

Inclusion of replicationobjects into one or morepublications

Assignment of actualcriteria fields

Assignment of criteriavalues

Assignment of sites tosubscriptions

Subscription

SiteID SiteIDSiteID

ReplicationObject

PublicationPublication

Data Distribution: replication modeling

SiteID SiteID SiteID

Subscription Subscription

1

2

3

4

Steps to define the replication for a BDoc type in the Administration Console

Step 1: you have to specify the replication type, ie bulk, intelligent. For an intelligent replicationobject, you also have to specify potential distribution criteria.

Step 2: define one or more publications for your replication object. A publication is a logicalgrouping of BDocs to enable subscribers to only pick up data needed. An intelligent publicationmeans that it has one intelligent replication object assigned and that it specifies the actualcriteria fields used for data distribution.

Step 3: Create subscriptions is a assignment of sites based on these publications. By definingcriteria values for the subscriptions data is filtered for the target site (e.g. German BP only).

Step 4: assign one or more sites to the subscription.

Example:

A Publication is created, for example "postal code area customer". This is the basis for thedistribution of the replication object "customer" according to postal codes.

Then Subscriptions are defined for the Publication "postal code area customer". Various sitescan now be subscribed here for certain criteria values (for example site 1 for the postal codearea 30000-40000 and site 2 for the area 40000-50000).

Replication modeling is not topic of this course. It is discussed in course TACRM5 “mySAPCRM Mobile Sales + Service”.

18

BDoc Type 1:1 relation

SubscriptionBP by AG=1005-1008

SiteIDCRM_SITE_000000000000001

Replication Object

PublicationPublication

Data Distribution: replication modelingexample

SubscriptionBP by AG

= 1009

SubscriptionBP by Country=DE

CAPGEN_OBJECT_WRITE

Customer & Prospects(by Account Group)

Customer & Prospects(by Country + Region)

CAPGEN_OBJECT_WRITE

SiteIDCRM_SITE_00..2



Subscription can be created using the subscription agent (SMOEAC)

Subscription name is defined by creator

Site ID represents a mobile client

CAPGEN_OBJECT_WRITE = sBDOC

19



20

Internal Data Flow (1)

OutboundAdapter Mobile

Replication /

Realignment

Inbound processing

sBDoc

InboundqRFC

R/3 Adapter

XIF Adapter

BW Adapter

sBDoc

R/3 Adapter

BW Adapter

XIF Adapter

Mobile Bridge

BAPI

BAPI

OutboundqRFC

sBDoc

synchronization flow

InboundAdapter Mobile

Outbound processing

SynchronisationFlow

mBDoc

The internal data flow consists of three main steps

Inbound processing,

Validation, and

Outbound processing.

Inbound processing: Incoming data of different formats, eg BAPI structures from a SAP R/3Backend, sBDocs, XML/SOAP or IDocs, are converted into mBDoc messages. Note that aninbound sBDoc can be processed in two ways:

if it is assigned to a mBDoc type, it is mapped to a mBDoc message.

if not assigned to a mBDoc type, the sBDoc message is directly passed to outboundprocessing (ie the synchronization flow), eg Customizing settings from one mobile client isdistributed to other mobile clients. The CRM Server is not interested in this information andtherefore the incoming sBDocs are directly passed to the outbound adapter.

21



Replication /

Realignment

Inbound processing

sBDoc

mBDocR/3 Adapter

XIF Adapter

BW Adapter

R/3 Adapter

BW Adapter

XIF Adapter

Mobile Bridge

BAPI

OutboundqRFC

sBDoc

synchronization flow


Outbound processingValidation

SynchronisationFlow CRM

Adapter

Validation: the incoming data in form of mBDoc messages is validated by the application, eg forthe mBDoc BUPA_MAIN a function module CRM_BUPA_MAIN_VAL performs the validation ofthe data.

if validation is successful, the mBDoc message is passed to outbound processing.

if the incoming data is not valid the mBDoc is updated with an error message and then sentback to the sender.

22



Replication &

Realignment

Inbound processing

sBDoc

R/3 Adapter

BW Adapter

XIF Adapter

Mobile Bridge

BAPI

OutboundqRFC

sBDocsynchronization flow


CRMAdapter

mBDoc

Replication

Outbound processing: the receiving systems, eg SAP R/3 Backends, external systems orMobile Clients, are determined by the replication service. Then the mBDoc message is passed tothe corresponding outbound adapter which converts the message into the data formats of thereceivers.The Replication & Realignment Service determines to which mobile clients the sBDocis forwarded.

23



24

Flow Context basics

Flow Contexts

Informally described steps in the general message processing model

Predefined and associated with lists of services to be called in this context

Inbound processing

Service 3

Service 1Service 2

Service 7Service 8Service 9Service 10

Service 4

Outbound processing ValidationService 5

Service 6Service 11Service13 Service 12

A sequence of services for a BDoc type is called Flow Context (see also Transaction SMO8FD).

The entire flow of a BDoc type through the system may consist of one or more Flow Contexts.

The processing eg inbound, outbound is done by so called services (function modules)

25

Flow Contexts: nomenclature

Existing Flow Contexts:

Naming convention:

Messaging FlowSynchronization Flow

InboundProcessing

OutboundProcessing

SI0, SI1

MO1, MOA, MO2, MOB,MO3, MOC, MO4

SO1, SOA, SO2, SOB,SO3, SOC, S04

MI0

M03

“S” = Synchronization Flow,“M” = Messaging Flow

“I” = Inbound Processing,“O” = Outbound Processing

# = 1, 2, 3 standard flow# = A, B, C specific flow

The first two characters are self explaining. The third character is related to the sequence of theFlow Contexts. A number indicates a standard SAP sequence while a letter indicates a customer-defined Flow Context which will be called in the sequence always after the SAP Flow Context.For the Mobile Bridge (SAP standard) also the letter indicated Flow Contexts are used.

26

Logical versus maintenance context

Logical context mBDoc Notification

For this one Logical context mBDoc Notification wehave two maintenance contexts MO2 and MOB

SMW3FDSTD

SMW3FDCUST

SMO8FD

Note that one logical context may consist of more than one maintenance context. Forexample the logical context mBDoc Notification consists of the two maintenance contexts"mBDoc Notification" and "mBDoc Notification (additional calls)". First all flow services fromthe maintenance context "mBDoc Notification" are called in the order given by the ordervalue, then all flow services from then maintenance context "mBDoc Notification (additionalcalls)" are executed.

In the transaction SMO8FD, SMW01 and SMW02 the logical context is used.

27

All available Flow Contexts can be displayed

Flow Contexts: definitions

SMO8FD

Flow Context

Service in aFlow Context

The available Flow Contexts for a BDoc Type may be viewed via the transactionMiddleware Message Flow Display and Check Flow Definitions (SMO8FD).

Each flow context consists of a sequence of services (function modules)

28

Flow Contexts: overview


Replication &

Realignment

Inbound processing

sBDoc

InboundqRFC

mBDocR/3 Adapter

XIF Adapter

BW Adapter

sBDoc

R/3 Adapter

BW Adapter

XIF Adapter

Mobile Bridge

BAPI

BAPI

OutboundqRFC

sBDocSynchronization flow




Adapter

mBDoc

replication

SI1 MI0

MO1, MO2, MO3, MO4MOA, MOB, MOC

SO1, SO2, SO3, SO4SOA, SOB, SOC

The Flow Contexts SOA, SOB and SOC for the Synchronization Flow and MOA, MOB and MOC for the MessagingFlow are processed after the corresponding Flow Contexts SO1, SO2, SO3, MO1, MO2 and MO3 are finished.

Inbound Processing

SI1: calls the Mapping Service sBDoc mBDoc. May be customized.

MI0: calls the Validation Service. Not customizable.

Outbound Processing

SO1, SO2, SO3, SO4: different outbound Flow Contexts (synchronization).

SOA, SOB, SOC: additional services (synchronization).

MO1, MO2, MO3, MO4: different inbound Flow Contexts (messaging).

MOA, MOB, MOC: additional services (messaging).

29



30

CRM Middleware Services

Inbound processing

InboundqRFC

R/3 Adapter

XIF Adapter

BW Adapter

R/3 Adapter

BW Adapter

XIF Adapter

Mobile BridgeOutboundqRFC synchronization flow




Adapter

ReplicationCDB Service

OutboundAdapterMobile

Replication&Realignment

Some services within the CRM Middleware are

The CRM Adapter / Validation Service is called within the Messaging Flow to pass inbound BDocmessages to the CRM Server Application for validation. The Validation Service receives the datacontained in BDoc messages from the inbound processing. In case of success validation by the CRMServer Applications the content of the BDoc (from the extension part) is written into the correspondingtables of the CRM database. If the validation was not successful, the BDoc message is sent back to thesender with an updated error message.

The Replication service determines to which adapter the message has to be distributed.

The Replication and Realignment Service determines whether a replication and/or a realignment isnecessary or not. If a realignment has to be performed for a BDoc message, this message is copiedinto a separate realignment queue for further processing. If realignment is not required, the receivingsites for a BDoc message are determined by the subscriptions.

The Mapping Service maps sBDoc messages to mBDoc messages. The reverse direction is mappedusing the Mobile Bridge. The Mobile Bridge takes a messaging BDoc message and creates one ormore synchronization BDoc messages (1:n relationship). The Inbound Adapter Mobile also takes one ormore synchronization BDoc messages and produces exactly one messaging BDoc message of onepredefined type (n:1 relationship).

The CDB Service saves the content of a synchronization BDoc message in the corresponding CDBtables.

31

CRM Middleware Services: Adapter steps

Examples: R/3 Adapter, XIF Adapter, BW Adapter

mBDoc

R/3 Backend

Mobile Client

Non-R/3Backend

CRMMiddleware

AdapterData/fieldrestriction

Mapping

Conversion

Keycompletion

Defaulting

Adapters are special services that provide connectivity to external systems in order to exchange data between theCRM Middleware and the Mobile Clients, R/3 Backends or other non-SAP Systems. The content of the BDocmessage may be modified in the following ways.

In order to support transition from one system and possibly data format to another, adapter may fulfill the followingtypical tasks

Data/ field restrictionExample: Some control segments like the recipient list are not delivered to the Mobile Client.

Mapping:Example: The R/3 Adapter fills up the import fields of R/3 BAPI with data coming from a BDoc.

Conversion:Example: Data that is imported from external systems via the XIF Adapter using XML or IDocs is converted intoBDoc messages before it is passed on to the CRM Server Applications.

Key completion: The different key systems of the external components need to be translated.

Defaulting: Fields which need to be filled obtain default values.

32

Purpose: data exchange between major systems

The Middleware allows easy integration of other adapters

Adapters receive data through the replication mechanism

CRM Middleware Services: common adapters

R/3 BackendMobile Client Non-R/3 Backend

In/Outbound

Adapter M

obile

R/3

Adapter

Ext. Interfaces(XM

L / IDocs)

AdministrationConsole

Adapters

SMOEAC

Administrator

Groupw

areA

dapter

Lotus Domino /MS Exchange Server

Adapters are interfaces between different systems. Data exchange in the new SAP CRMenvironment is based on the Adapter Framework. The Adapter Framework consists of thefollowing main components which are used as synchronization mechanisms between the CRMServer and the participating sites:

Initial data transfer: The Adapter Framework handles the entire data transfer of defined objectsfrom the OLTP R/3 System.

Delta data transfer: For example, it provides change information from the OLTP R/3 system forthe CRM Server. Delta data transfer means that once the initial data transfer has beencompleted, permanent data is available. OLTP users can make changes to existing customermaster data or create new requests. This delta information must be forwarded to the CRMServer.

Data transfer to the OLTP R/3: Here the OLTP R/3 System is supplied with information from theCRM Server.

Synchronization: The different datasets are synchronized. This can be controlled in time slots orcan be triggered manually. You can restrict the synchronization, for example, to one requestonly. The synchronization component can be used everywhere where a delta data transfercannot be used. It can also be used to clean up inconsistent data.

33



34

Appendix A: Comparison of sBDoc and mBDoctypes

sBDoc type mBDoc type

Structure and information about data location Structure of classical part defined in BDocmodeler, DDIC-structure is generated from this

Created in BDoc modeler Name of extension part defined in BDoc modeler

Extension part defined in DDIC

Strong rules about data model Structure not in so strong rules defined

Located in CDB Data is stored in online DB

This offers without application processing:

Initial load

Realignment

Dependent replication and interlinkages

Replication only bulk or simple intelligentpossible, receiver finding by classical part

A BDoc type is defined within the BDoc modeller (SBDM). sBDoc types have beside the structuredefinition a information how the message content is stored in the consolidated database tables.The BDoc repository contains for sBDoc types structure and database schema information.

For mBDoc types the so called classical part is defined in the BDoc modeller and out of this a DDICstructure is generated. Furthermore the mBDoc exists of an extension part. For the extension partonly the name of the DDIC type is deposited in the BDoc modeller. The field for the extension partis called “Related data type”. The middleware services naturally only work on the classical part,eg for receiver determination in the outbound processing. The extension part of a BDoc messagecontains the reference data for the receiving application respectively the adapter that shouldprocess the message.

35

Appendix A: comparison of sBDoc and mBDoctypes

sBDoc instance mBDoc instance

Stored in CDB in SMO*-tables with keySFA*

Makes possible to write look-up tables:„Who gets what“

Makes realignment possible

Extract takes the BDoc instances andcreates BDoc messages from them

Not directly known, only by applicationextractors or API‘s available

BDoc instances are objects (not object-types). sBDoc instances are stored in the CDB, therefore theschema information are stored in the BDoc repository. A sBDoc instance, egCAPGEN_OBJ_WRITE (customer) exists of a table entry in SMOKNA1, identified with the keyfields SMOKNA1-SFAKNA1 and all the associated table entries in the child tables. With theextract service a sBDoc instance could be fully extracted of the CDB table and the sBDocmessage can afterwards be distributed to one or more mobile clients. This happens eg when anew mobile client is assigned to a subscription.

36

Appendix C: comparison of sBDoc and mBDocmessages

sBDoc message mBDoc message

Stored in SMW3_BDOC*-tables

Contain information about one or moreBDoc instances

Used in s-Flow

Stored in SMW3_BDOC*-tables

Contain information about one or moreBDoc instances

Used in m-Flow

A BDoc message always contains information of one or more BDoc instances. Both terms cannot beequated with each other. For a BDoc instance eg customer Hugo Mueller more than one BDocmessage could exist. On the database a stored BDoc message exists with exactly one entry intable SMW3_BDOC and one or more entries in miscellaneous other SMW3_BDOC* tables.

37

Copyright 2008 SAP AGAll 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 changedwithout prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as theirrespective 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 andassociated logos displayed 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. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains 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. 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, orother 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 ofmerchantability, 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 limitationshall 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 thesematerials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages

Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durchSAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden.Einige von der SAP AG und deren Vertriebspartnern vertriebene Softwareprodukte können Softwarekomponenten umfassen, die Eigentum anderer Softwarehersteller sind.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge und andere in diesem Dokument erwähnte SAP-Produkte und Servicessowie die dazugehörigen Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und in mehreren anderen Ländern weltweit. Alle anderen in diesem Dokument erwähntenNamen von Produkten und Services sowie die damit verbundenen Firmenlogos sind Marken der jeweiligen Unternehmen. Die Angaben im Text sind unverbindlich und dienen lediglich zuInformationszwecken. Produkte können länderspezifische Unterschiede aufweisen.

Die in diesem Dokument enthaltenen Informationen sind Eigentum von SAP. Dieses Dokument ist eine Vorabversion und unterliegt nicht Ihrer Lizenzvereinbarung oder einer anderenVereinbarung mit SAP. Dieses Dokument enthält nur vorgesehene Strategien, Entwicklungen und Funktionen des SAP®-Produkts und ist für SAP nicht bindend, einen bestimmtenGeschäftsweg, eine Produktstrategie bzw. -entwicklung einzuschlagen. SAP übernimmt keine Verantwortung für Fehler oder Auslassungen in diesen Materialien. SAP garantiert nicht dieRichtigkeit oder Vollständigkeit der Informationen, Texte, Grafiken, Links oder anderer in diesen Materialien enthaltenen Elemente. Diese Publikation wird ohne jegliche Gewähr, wederausdrücklich noch stillschweigend, bereitgestellt. Dies gilt u. a., aber nicht ausschließlich, hinsichtlich der Gewährleistung der Marktgängigkeit und der Eignung für einen bestimmten Zwecksowie für die Gewährleistung der Nichtverletzung geltenden Rechts.SAP übernimmt keine Haftung für Schäden jeglicher Art, einschließlich und ohne Einschränkung für direkte, spezielle, indirekte oder Folgeschäden im Zusammenhang mit der Verwendungdieser Unterlagen. Diese Einschränkung gilt nicht bei Vorsatz oder grober Fahrlässigkeit.Die gesetzliche Haftung bei Personenschäden oder die Produkthaftung bleibt unberührt. Die Informationen, auf die Sie möglicherweise über die in diesem Material enthaltenen Hotlinkszugreifen, unterliegen nicht dem Einfluss von SAP, und SAP unterstützt nicht die Nutzung von Internetseiten Dritter durch Sie und gibt keinerlei Gewährleistungen oder Zusagen überInternetseiten Dritter ab.Alle Rechte vorbehalten.

© SAP 2008 / SMO SA –

02 crm middle ware overview

Documents