Skip to Content

A document created in Mobile Service R/3 Edition is sent to R/3 always through the CRM Server. The pictorial representation of the data flow from Mobile Client to R/3 is as shown below:

When a document is created in the Mobile Service R/3 Edition and uploaded, an entry is created in the inbound queue of the CRM Server. From here the Middleware(MW) inbound adapter creates the sBDoc(Synchronization Business Document) sent from the Mobile client. Based on the BDoc(Business Document) type, the MW flow fetches the mapping class and sends the inbound BDoc to the mapper. The mapper function converts the sBDoc sent from the mobile client into an mBdoc(messaging BDoc) called RmBdoc (Request/ Response messaging Bdoc). The flow calls the validation for the RmBdoc once it is created. No real validation is done within CRM  since the CRM middleware is used to route the notification from mobile clients to OLTP only. This module calls notification RmBdoc outbound processing in order to route the data to the OLTP. The validated RmBdoc calls the mapper that maps the structure to BAPI structures, a R/3 understandable format, which are used as parameters for the upload proxy. The proxy is called within R/3 through RFCs. Beyond this point, normal processing of the document happens in R/3 and the document is saved in R/3.

After the document is saved in R/3, a MW flow is called that fetches the mapper. The download mapper converts the BAPI structures to the corresponding DmBDoc(download messaging business document). The contents of the bapi are first copied into suitable data structures (internal tables). At this stage, we can view the data sent from R/3. After the contents are copied, they are mapped to the corresponding segment of the DmBDoc. This mapper also does some special handling too like converting the long text in the ITF(Interchange Text Format) format to the ASCII(American Standard Code for Information Interchange) format and filling the guids. After mapping the R/3 data into the DmBDoc, the validation function for the DmBDoc is called using the middleware.

Again, since CRM is used just to route the notifications to the mobile bridge, there is no real validation happening here. This validation routine calls the download mapper (DmBDoc to sBDoc) directly or through the MW tables. This is followed by a mapping of the DmBDoc to the corresponding sBDoc and the sBDoc notification flow is called which calls the CDB(Consolidated Database) service and replication services as defined in the middleware table. Once the data is written into the cdb successfully, the replication and realignment services are called. In case of any problem in cdb service, the entire process is rolled back. The replication service sends the sBDoc to the sites that have subscribed for it. And the data comes down to the Mobile client when Conntrans is run in the laptops.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Anonymous
    I’ve been working with MSA and MSE since more than two years and have developed quite a lot in the Mobile App Studio.
    But don’t ask me how many times I had to explain this picture to colleagues. Now i will just send them the link, thanks 🙂
    By the way the data transfer is taking place the same way for the CRM Mobile Service or Mobile Sales Application, the only thing is that in this case the CRM-DB is also written when where you have the “dummy-validation”

Leave a Reply