Designing the mbdoc data type
§Typical fields of the mbdoc data type would include
-TASK field: to indicate if its an insert (‘I’ ), update (‘U’), delete(‘D’)
-Guid of the primary object key
-There is also a separate structure –containing change flags for the changed fields (indicated by sendbits)
§This complex datatype is used in the extension part of the mbdoc
Creating mbdoc
§Create the new mbdoc type in bdoc modeler (tcode:SBDM)
§Set bdoc type to messaging
§Maintain the related data type (complex type created previously)
§The mbdoc root segment is created , this should at least contain the guid field.
Creating sbdoc
§Create the new sbdoc type in bdoc modeler (tcode:SBDM)
§Set bdoc type to synchronization
§Add the previously created mbdoc as a mapped messaging bdoc
§Add site type Mobile client in ‘Site Type info’ tab
§Create the sbdoc segment definitions
§There must be one root segment & the segment(s) should be mapped to the corresponding CDB table(s)
§The segment fields have to be maintained
§Maintain field name, key flag, data element, description, and table alias and table field. The invisible fields R/3 key field, R/3 field, sort order and Sort ASC (ascending) all have initial values.
§Activate the sbdoc type
Triggering message flow
§A typical application design is explained here
§In a CRM online- CDB scenario, the following services are required-
-mapping modules to map the inbound sbdoc to an inbound mbdoc
-The mbdoc inbound service- which is the validation module to check the data
-The outbound call after validation
-a mapping module to map the outbound mbdoc to one or more sbdocs (Mobile Bridge)
Inbound sbdoc to mbdoc mapper
§Create an ABAP class implementing the interface IF_SMW_MAP
§Code the mapping logic in method MAP_SYN2MSG
§The method uses the sbdoc & mapped mbdoc as parameters
§The mapping logic would be to read the sbdoc data & transfer it to the mbdoc structure
No comments:
Post a Comment