Upload
uaxrr
View
1.225
Download
9
Embed Size (px)
Citation preview
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
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
R/3 BackendMobile Clients
R/3 BackendMobile Clients
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
1. Message Flow Overview2. BDocs3. Data Distribution4. Internal Data Flow5. Flow Contexts6. CRM Middleware Services7. Appendices
Middleware and Message Flow
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
1. Message Flow Overview2. BDocs3. Data Distribution4. Internal Data Flow5. Flow Contexts6. CRM Middleware Services7. Appendices
Middleware and Message Flow
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
SiteIDCRM_SITE_00..3
SiteIDCRM_SITE_00..4
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
1. Message Flow Overview2. BDocs3. Data Distribution4. Internal Data Flow5. Flow Contexts6. CRM Middleware Services7. Appendices
Middleware and Message Flow
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
Internal Data Flow (2)
OutboundAdapter Mobile
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
InboundAdapter Mobile
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
Internal Data Flow (3)
OutboundAdapter Mobile
Replication &
Realignment
Inbound processing
sBDoc
R/3 Adapter
BW Adapter
XIF Adapter
Mobile Bridge
BAPI
OutboundqRFC
sBDocsynchronization flow
Outbound processingValidation
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
1. Message Flow Overview2. BDocs3. Data Distribution4. Internal Data Flow5. Flow Contexts6. CRM Middleware Services7. Appendices
Middleware and Message Flow
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
OutboundAdapter Mobile
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
InboundAdapter Mobile
Outbound processingValidation
SynchronisationFlow CRM
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
1. Message Flow Overview2. BDocs3. Data Distribution4. Internal Data Flow5. Flow Contexts6. CRM Middleware Services7. Appendices
Middleware and Message Flow
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
InboundAdapter Mobile
Outbound processingValidation
SynchronisationFlow CRM
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
1. Message Flow Overview2. BDocs3. Data Distribution4. Internal Data Flow5. Flow Contexts6. CRM Middleware Services7. Appendices
Middleware and Message Flow
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 – Page 37