BDoc Mobile

8/3/2019 BDoc Mobile

1/7

SAP CRM for Mobiles Replication Architecture is the motivation of utilizing BDocs asknowledge container for processing business objects and for transporting them betweenthe CRM Middle ware and the cell shoppers is you could process/transport them as oneunit, as an alternative of getting to course of/transport a number of individual deskentries.

BDoc's

While you talk about BDocs, it's a should to distinguish between the BDoc sort, theBDoc instance and the BDoc message.A BDoc type or construction needs to be definedfor every required business object, e.g. Contact Individual,Sales Order etc. It containsall the R/3 table entries that make up the corresponding enterprise object.A BDocinstance is a concrete instance of a given BDoc kind containing all field values.A BDocmessage (or just BDoc) contains modified fields only. These embody new fields aseffectively as deleted fields. The distinction between a BDoc message and a BDocinstance is that there's just one BDoc instance for a Business Object however there canbe multiple BDoc messages (with their own Ids) for one BDoc instance. However a

BDoc instance is replicated to a cellular consumer utilizing a BDoc message the placeall fields are filled.

A BDoc sort consists of a header and a body.The BDoc header consists of one singledata section, the so-known as control segment.The BDoc physique consists of one ormore data segments and of 1 error segment.The control section merely incorporatesheader information, whereas the individual data segments comprise the actual tableentries that make up the corresponding enterprise object.The error section can beutilized to retailer error information.

Everyknowledge segment incorporates section fields, additionally known as segmentattributes. These fields are mapped to actual data fields of physical database tables.InBDoc varieties used for knowledge alternate between mobile clie nts and the CRMServer, an information segment is mapped to exactly one database desk, whereas in
http://2.bp.blogspot.com/-tlPVAtLaVQk/TqmHYNLyRoI/AAAAAAAAB-w/_w8rSbF-NbU/s1600/SAP+CRM+FOR+MOBILE+REALINMENT+1.png


2/7

BDocs used, for instance, on the shopper side only, a information section willadditionally be mapped to a join of tables or to a desk view.

BDoc Message

The Header of a BDoc message comprises the message ID, the sender ID and detailsabout the BDoc instance and BDoc type.The first data phase of the Body of a BDocmessage can be referred to as root segment. In contrast to all other data segments, thebasis segment solely comprises one key field. All subsequent knowledge segments

include two key fields: an personal one and the one of many parent informationsegment.As effectively as, every knowledge phase accommodates the duty that hasbeen carried out (i.e. INSERT, UPDATE or DELETE) and the so-referred to as SendBits, which inform about the subject on which this activity has been performed.

The Recipient Listing is decided and added by the replication service and utilized by theoutbound adapter.On the cellular clients, BDocs appear only on the Transaction Layer(TL). The attributes of data segments correspond to fields of the physical databasetables on the one hand and then again to properties of Business Objects.

Relation between BDoc and replication object:

The replication object bears information about how BDocs of one kind are replicatedand which fields of the BDocs can be used as replication criteria.Every replication objectrefers to exactly one BDoc type of the BDoc repository. Nonetheless, not each BDoctype must have a corresponding replication object (since not all BDocs are used forreplication purposes).Used abbreviations for replication object are for instance CAP(buyer and prospects), CON (contact persons), ACT (activities), OPP (alternatives) orQOM (citation and order management).
http://2.bp.blogspot.com/-tlPVAtLaVQk/TqmHYNLyRoI/AAAAAAAAB-w/_w8rSbF-NbU/s1600/SAP+CRM+FOR+MOBILE+REALINMENT+1.png


3/7

Guidelines for replication objects :

One physical knowledge file belongs to precisely one occasion of 1 BDoc kind andsubsequently to not less than one replication object.A BDoc kind ought to comprise asmuch logically interrelated tables as possible.The key fields of root segments all thetime have to be stuffed, as a end result of they could probably be relevant forreplication. That is particularly necessary for modifications of dependent replicationobjects.

Used table: SMOKNA1 (Normal Information in Customer Grasp) with a number of unitsof information (key area buyer number K*) and the relating replication object type CAPor CON. Each of them is said to no less than one single replication object (buyer orcontact particular person).One data document isn't included in a couple of replicationobject, for instance:

1. CAP (customer and prospects)

2. CON (contact persons)3. QOM (quotation management)4. OPP (alternatives)5. ACT (actions)Criteria for an Clever Replication Object:

1. The BDoc is distributed by approach of an own look-up table2. Attributes are defined as standards fields3. The look-up table is up to date routinely using defined guidelinesIntelligent replication object varieties trigger upkeep of an personal look-up table and

are distributed based on the entries in this table. In the course of the upkeep of look-uptables, the standards for assignment on the replication objects stage is in contrast withthe lively subscriptions.Clever replication objects have only one information document oftheir root segment. The replication key should be in the root segment.

Standards for a Dependent Replication Object:

1. The BDoc is distributed via an existing look-up table2. No attributes are outlined as standards fields3. No own guidelines exist, except these of the guardian objectDependent replication objects are distributed referencing a BDoc look-up desk of an

intelligent dad or mum replication object. They do not trigger a realignment. Additionalreplication standards can't be defined.Whereas making a dependent replication object,the consumer must take care of the replication key, for example SFAKNA1 for an order.This simplification is simply possible if the distribution refers to only one (and notseveral) mum or dad replication objects.It's impossib le to reproduce a extra advanceddependency - like actions with relation to clients, objects or employees. For realignmentfunctions you will all the time want entries in an personal look-up desk and never in theone of many dad or mum object.


4/7

Standards for an Clever Dependent Replication Object:

1. The BDoc is distributed through an personal look-up desk2. Attributes are outlined as standards fields3. The look-up desk is updated automatically utilizing outlined rules and using entries of

another current look-up table.Further replication standards can also be defined for such an object.When you select areplication object in the hierarchical structure of the navigation window, the following isdisplayed in the particulars area on the proper hand facet:

1. The mother or father replication objects of the chosen replication object (in this casenone).

2. The replication objects relying on the chosen replication object (on this case oneintelligent

3. one and several other dependent ones).4. All publications that contain the selected replication object.

5. Replication-relevant fields with operator and distribution kind (crittype) whether it isan intelligent one.

Throughout a realignment, the replication key (equal to the root ID, the system key inthe root section) and the appropriate site ID are written into the Look-Up Table . Forobject replication, it is then only essential to learn the entries of the look-up table.Thedata movement between the cell purchasers and the CRM Middleware is handled viainbound queues and outbound queues located on each side, the place as every cellconsumer has one inbound queue and one outbound queue and the CRM Middlewarehas one inbound queue and one outbound queue for each connected mobile client.
http://1.bp.blogspot.com/-YK8uRZJSOmg/TqmHtwNO3yI/AAAAAAAAB_I/xZp4oj-jkns/s1600/SAP+CRM+DATA+FLOW+4.png


5/7

1. A BDoc message is shipped from the outbound queue of a mobile consumer to theCRM Middle ware.

2. The BDoc message is placed in the corresponding CRM Middle ware inbound queue.3. The BDoc message is mapped to a replication object.4. In the look-up table of this object, the replication secret is used to identify the

positioning IDs for the subsequent replication.5. Based on these website IDs, the BDoc is positioned within the outbound queues forthe corresponding cellular clients.

6. The BDoc message is obtained within the inbound queue of each of these mobileclients.

Interlinking

Description of an n:m relationship between objects of the identical or of two completelydifferent object sorts.Inside the client software, relations (interlinkages) seem ashyperlinks for navigation purposes.A number of the tables used for interlinkages ofbusiness objects are:

1. SMOKVBEZ4 (customer - associated actions)2. SMOKVBEZ6 (enterprise companion - business companion)3. SMOKVBEZ7 (customer - staff of gross sales crew)4. SMOKVBEZ9 (buyer - opportunity)5. SMOKVBEZ11 (activity - worker)Every relationship between two objects is qualified by the attribute Relation Type(RELTYP).Generally there are tons of predefined relation types which should cowl theprimary requirements of an implementation project. Nevertheless, extra relation types
http://2.bp.blogspot.com/-BdDLL_LsDAg/TqmH2emdxtI/AAAAAAAAB_U/2uEh5JHMG2Y/s1600/SAP+CRM+DATA+FLOW+4.png


6/7

will be created. Desk name convention for interlinkage tables: SMOKVBEZ + Number.

BDoc Processing into the Middle ware

Frequent companies throughout the CRM Middle ware:

1. The R/3 Adapter uploads enterprise objects to the related OLTP R/3 system.2. The CRM service exchanges enterprise objects with the CRM on-line components.3. The CDB service saves the fields of a BDoc message within the corresponding CDB

tables.4. The Replication and Realignment service determines whether a realignment is critical

or not.If a realignment needs to be performed for a BDoc message, this message is copied

right into a separate realignment queue for additional processing. If realignment

shouldn't be required, the sites are decided, to which a BDoc message must be

replicated. The Outbound Adapter receives the checklist of internet sites computed by

the Replication and Realignment service and appends the BDoc message to theoutbound queues for all sites on that list.When a BDoc is delivered by the stream, the

Replication and Realignment service to begin with performs the info replication. The

replication key in the involved look-up table is used to identify the site IDs related for

replication, and the recipient record is decided by utilizing these site IDs.

The BDoc and the location IDs are then returned to the flow and from there handed on

to the Outbound Adapter, which places the BDoc into the related outbound

queues.Lastly the replication realignment service determines whether a realignment is

required or not.


7/7

As quickly as a realignment is required, the BDoc message is copied into a separate

realignment queue for further processing.The realignment course of is answerable for

maintaining the look-up tables. In these look-up tables,assignments are maintained

between replication objects and sites. If a beforehand made task is changed - for

example, if new objects are entered or previous objects are deleted or distribution

criteria are modified - this should be reflected in the relevant look-up table.The activities

required because of these modifications to a glance-up table are written into an extract

queue.By using a BDoc message, these actions are then handed on to the concerned

websites by way of the Outbound Adapter and the corresponding outbound queues.
http://1.bp.blogspot.com/-6QyG_ia2EUc/TqmH93m6YGI/AAAAAAAAB_g/jYYgIkEtaWE/s1600/SAP+CRM+BDOC+PROCESSSING+IN+MIDDLEWARE+5.png

BDoc Mobile

Documents

Transcript of BDoc Mobile