BDOC Merge (5.0 SP 07 and 4.0 SP 12 onwards)In the current CRM Mobile solutions one BDoc message is generated every time the user saves the data by using the save option. When the user modifies the same business object, navigating to a different tile set in the same application, and performs a save on each tileset for the same business object, a number of BDoc messages are created on the Mobile Client outbound queue for the same BDoc Instance. This means that the same instance of the BDoc which comes as different messages should be processed the number of times save is done on the object in the CRM server. This phenomena could be better explained by the following example of an opportunity.To create an opportunity, the user normally performs the following steps:. Adds the main information. Navigates to tileset1 and adds information about the team members who will work on this opportunity.
![]()
Navigates to tileset2 and adds information about the products. Navigates to tileset3 and adds information about partnersAll the steps mentioned above modify only the OPPORTUNITYWRITE sBDoc type. However, as the user navigated to four different tile sets, four BDoc messages are generated and transferred to the outbound queue of the mobile client.
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. SAP Hybris Training Portfolio Overview April 2017. Functional CR500 – CRM Middleware n.a. Functional CR600 – CRM Marketing n.a. Functional CR700 – CRM Service n.a. Planned availability Q2 2017 Legend ‘Integration’: = Covers integration to specific SAP Hybris areas in detail.
This increases the processing time on the CRM server as it has to:. Perform Mapping conversion from sBDoc to the corresponding mBDoc type. Perform validation for all the messages. Replicate the data contained in these messages to other mobile clients that have subscribed to this data as import messages. Send notification to all the mobile clients which have to receive this data. Send confirmation to the mobile-client who created this data.Also If there are 10 mobile clients subscribed to this opportunity, then there are about 88 messages created on the CRM Server for the above operation. (4 inbound messages, 4 confirmation messages to the creator, 40 import messages and 40 notification messages to all the subscribers).
These messages could be reduced if there was a possibility to merge the BDocs as and when they were created on the mobile client.Instead of creating 4 different messages for opportunities for saving the same object on 4 different tilesets, if there was a possibility to create just one message, then it would reduce the processing to a factor of 0.25 as follows. There would only be 22 messages created. (1 inbound messages, 1 confirmation messages to the creator, 10 import messages and 10 notification messages to all the subscribers). This would also mean making the number of messages independent of the number of consecutive saves on the same business objects on different tilesets.
This would also improve the performance of the message flow both in the CRM server side and the mobile client because of the reduction of processing of information on all cycles viz. Mapping, validation, replication & realignment, and the number of messages as confirmations, impor and notifications. Pre-requisitesIs should also be noted that there are many limitations to achieve the above functionality. First of all there has to be a balance struck between the extra processing time for merging the BDocs and the actual acceptable limits for performance of application on the mobile client.
This made us to think about an intermediary stage where the messages would be saved and merged before finally sending them to the outbound queue instead of reading the data from the queues which meant loss of performance. Also, there are certain application fields if merged would cause rejections from the CRM Server which would not happen otherwise. For all these reasons, we had to put many pre-requisite which had to be satisfied so that the merging of the BDocs would not cause loss of performance and unnecessary rejections from the CRM Server. The pre-requisites are mentioned below.
The conditions mentioned below requires BDoc merge to be enabled on the system. Successive saves in MSA produces BDOCs of the same type.If the BDoc merge is enabled, whenever there is a save in the application, it would check if there are any messages in the temporary stage. If there is a BDoc already present in the temporary stage, then the first check is if the BDoc types are the same. If the BDoc types are the same, then the first criteria for merge is satisfied. If this is not the case, then the staged entry would be flushed to the mobile client outbound queues and the new entry would be staged to the temporary stage tables. Successive saves in MSA produces BDocs of the same instance.Once the above criteria are satisfied, then there is a check if the BDoc are of the same instance. This means that the Root ID which distinguishes two BDoc instances should match.
If they match then the second criteria is satisfied. If this is not the case, then the staged BDoc is flushed to the mobile client outbound queue and the new BDoc message is stage to the temporary stage.
![]()
If all the segments of the BDocs are mergeable.If both the criteriae above are satisfied, then it should be checked if the BDoc segments should be merge-able or not. This checking is done to avoid unnecessary rejections on the CRM server due to merging of fields that should not be merged. Here, the checking is done only at the segment level as field level checking would reduce the performance. If a segment in a BDoc contains one or more fields which would cause problems if merged, then this segment is considered as non mergeable. These segments should be identified at the application level by each application on the mobile client.A customizing entry should be present in the SMO5CRITERIA table which contains the information of those segments in a BDoc that can be merged.
This customizing is done on the CRM Server using the transaction CRISEG. All the segments of all the BDoc types that can be merged should be entered here. The mobile client with BDoc Merge enabled have to subscribe to the publication ' Criteria for BDoc Merge'.
This should be a bulk subscription. This will enable the changes to be done on the CRM system one time and let the replication and the realignment service take care of data distribution to all the subscribers who has BDoc merge enabled.If there is no entry for a segment of a BDoc type in the SMO5CRITERIA table, then it means that this BDoc segment could not be merged. If there is a single entry for the BDoc type without any corresponding entry for the segment in the SMO5CRITERIA table, then it means that all the segments of this BDoc are mergeable.If a BDoc message on save contains a segment that is not mentioned in the SMO5CRITERIA table, then it means that this BDoc message cannot be merged. If such a message is created and If there are any messages in the temporary stage table, both the message in the temporary stage as well as the new message will be flushed to the outbound queue as there is no point in retaining them on the temporary stage as it contains segments that cannot be merged. A merging will happen only if all the segments of the BDoc message are has entries in the SMO5CRITERIA table. How can BDoc Merge be enabled?By default, BDOC merge is disabled and to enable this we need to modify the following registry key.HKEYLOCALMACHINESOFTWARESAPMSAMWTLBDOCMERGE ENABLED = 1 Limitations. Currently this feature support standalone installation having dedicated local ides database.
But it doesn’t supports workgroup or citrix or multi-user connection to the same ides database. The onus lies on the administrator to disable BDOC merge in such environment. Behavior is undefined if this is not the case. In 5.0 each application has its own Arsrep.dat file. This is stored in the path e.g c:program filessapmobileapp.netmsabolappssfabolars folder. If multiple applications are installed on a single machine and if the Arsrep.dat file is different in terms of modeled metadata for each of the application then BDoc Merge could fail when flushing the message to the outbound queue.
Incase you would like to use multiple applications on the same machine, then one needs to first exit the first application gracefully. This will ensure that the messages from this application is correctly written to the outbound queue by the framework. The second application can be executed after the first application is closed.
SAP CRM Middleware OverviewTopics to be discussed. Introduction. BDOC introduction.
BDOC classes. sBDOC (Synchronization BDOC).
mBDOC (Messaging BDOC). I nitial setup steps for BDOC. BDOC monitoring stepsIntroduction. SAP has a very strong middleware tool when compared to other applications like Oracle where it is pretty easy for SAP CRM application to connect with and exchange data with other SAP Applications like SAP BW, SAP R/3 system etc. This connection and data transfer is established through middleware.
From an ERP application perspective this is an extremely important aspect the data exchange among the systems is kind of back-bone and the crux of very existence of the application. This data exchange can be of following types between other systems and CRM:1. Initial data transfer which is also called as Initial Load in SAP terminology2.
Intermediate synchronization of data among the applications also called as Delta Load in SAP terminology3. Synchronization.Introduction.
Just to throw some light on the kinds of data exchange mentioned above, it can be better understood if we look at the frequency of the data exchange. Initial load is primarily a one time activity wherein when the connectivity is established between the systems, the data is transferred from one system to another. This data can range from configuration data (like pricing conditions) to master data (like Business Partners and Products) to transactional data (like Sales Quotations, Contracts and Sales Orders).
Delta load is an activity of intermediate data transfer among the systems. This activity takes place more often than not to keep the data in various systems in sync and also take care of the changes to details of the data in various systems. It also takes care of newly created data in the system and distributes the same to other connected applications. Primarily this takes place in real-time and is primarily done automatically.Synchronization activity is to take care of any out of sync data. This may be a cause of connectivity failure or might as well be an outcome of maintenance activity. This is primarily done manually as and when needed.SAP CRM Middleware in SAP CRM ArchitecturesBDoc (Synchronization BDoc ).
Only used for data synchronization with mobile clients. sBDoc types contain direct mappings to tables of the consolidated database.
![]() Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
March 2023
Categories |