SBDM is a transaction in CRM Server used for BDoc modeling. Before we get into the actual properties and what they mean, we will sow how a BDoc looks in the SBDM. 
Now, in the transaction SBDM every BDoc (tab BDoc Overview) has a BDoc identity, BDoc class, Mobile Application Processing Type and the General data. We will see what these actually signify. The BDoc identity has details like the name, shot name which are used to uniquely identify the BDoc. It also has the status of the BDoc. The various statuses of a BDoc are: New - A BDoc is in NEW status when it is createdInactive ~ Unchecked - If the BDoc definition is modeled and but not checked.Inactive ~ Checked - If the BDoc is saved after checking without errors.Active - If the BDoc is successfully activated. This also means that the runtime objects are generated.Released - If the BDoc definition is successfully Released. After this only 'compatible ' changes are allowed to the released parts of the BDoc definition.Partially Released ~ Inactive~Unchecked - When a Released BDoc is edited and saved without checking for errors.Partially Released ~ Inactive~Checked - When a Released BDoc is edited then saved after successfully checking for errors Partially Released ~ Active - If a Released BDoc is modified, a new version is created and activated. And finally the version which specifies the version number of the BDoc. The next set of properties is related to the BDoc class. The various types are: Mobile Application (Read Only) - Used by the mobile application to read from IDES (local database in the client).Mobile Application (Modifiable Read - Used by mobile application to read the database. The application can use the same to update he in memory recordset and later should use the Sync Bdoc to update the database.Synchronization (Write) - Used by Adapters for communication with Mobile Clients.Messaging - Used by the CRM for message exchange with OLTP R/3, CDB and external systems. And the various Processing types used in Bdoc modeling are : Standard - This type is meant to be used for transactions which are used for creation of Business Objects. The Recordsets coming out of this type of transactions should have only one record (by definition of a Business Object).Query - This type is used for Business Collections and Combo Engines. Modifications to Recordsets created out of this type of transactions can not be committed to the database (Commit Transaction of this type of transaction throws an error )Special - This type of transactions should be used for Business Objects where the Object is created either through Primary key or through Parent key. For example in one-one relations And finally, the general properties that relate to the data type and Function Modules used. The general data constitute of the following properties:Related Data Type - This is specified only for messaging BDoc. For messaging BDoc, it has a classical part which is used by replication & a complex part which carries data. This field stores the complex part. Mapped Messaging BDoc - For sync BDoc’s, this field has the related messaging Bdoc.Function Module - These get automatically generated when activating the BDoc. But when you transport a BDoc, the function module also needs to be transported. During upload from mobile, this function will accept the data from conntrans gives out sync BDoc and starts the flow.Message Structure - These get automatically generated when activating the BDoc. This is like the data type for the BDoc. Adapter uses this for writing data into the BDoc. It is the admin data for messaging Bdoc. We will deal with some attributes related to the segments in the next blog.
Now, in the transaction SBDM every BDoc (tab BDoc Overview) has a BDoc identity, BDoc class, Mobile Application Processing Type and the General data. We will see what these actually signify. The BDoc identity has details like the name, shot name which are used to uniquely identify the BDoc. It also has the status of the BDoc. The various statuses of a BDoc are: New - A BDoc is in NEW status when it is createdInactive ~ Unchecked - If the BDoc definition is modeled and but not checked.Inactive ~ Checked - If the BDoc is saved after checking without errors.Active - If the BDoc is successfully activated. This also means that the runtime objects are generated.Released - If the BDoc definition is successfully Released. After this only 'compatible ' changes are allowed to the released parts of the BDoc definition.Partially Released ~ Inactive~Unchecked - When a Released BDoc is edited and saved without checking for errors.Partially Released ~ Inactive~Checked - When a Released BDoc is edited then saved after successfully checking for errors Partially Released ~ Active - If a Released BDoc is modified, a new version is created and activated. And finally the version which specifies the version number of the BDoc. The next set of properties is related to the BDoc class. The various types are: Mobile Application (Read Only) - Used by the mobile application to read from IDES (local database in the client).Mobile Application (Modifiable Read - Used by mobile application to read the database. The application can use the same to update he in memory recordset and later should use the Sync Bdoc to update the database.Synchronization (Write) - Used by Adapters for communication with Mobile Clients.Messaging - Used by the CRM for message exchange with OLTP R/3, CDB and external systems. And the various Processing types used in Bdoc modeling are : Standard - This type is meant to be used for transactions which are used for creation of Business Objects. The Recordsets coming out of this type of transactions should have only one record (by definition of a Business Object).Query - This type is used for Business Collections and Combo Engines. Modifications to Recordsets created out of this type of transactions can not be committed to the database (Commit Transaction of this type of transaction throws an error )Special - This type of transactions should be used for Business Objects where the Object is created either through Primary key or through Parent key. For example in one-one relations And finally, the general properties that relate to the data type and Function Modules used. The general data constitute of the following properties:Related Data Type - This is specified only for messaging BDoc. For messaging BDoc, it has a classical part which is used by replication & a complex part which carries data. This field stores the complex part. Mapped Messaging BDoc - For sync BDoc’s, this field has the related messaging Bdoc.Function Module - These get automatically generated when activating the BDoc. But when you transport a BDoc, the function module also needs to be transported. During upload from mobile, this function will accept the data from conntrans gives out sync BDoc and starts the flow.Message Structure - These get automatically generated when activating the BDoc. This is like the data type for the BDoc. Adapter uses this for writing data into the BDoc. It is the admin data for messaging Bdoc. We will deal with some attributes related to the segments in the next blog.