INTRODUCTION:
This blog is about the records in the Web Application Server and the R/3 backend when a generic synchronization is performed. This is an asynchronous application. These records will help you to understand the process and monitor the data flow in the WAS and R/3 backend during generic synchronization. Now let me give a general overview of the process. The end user has the mobile client installed on his mobile device which might be a laptop or PDA etc and wants to work offline with his application. When he’s finished with his work in the offline scenario he needs to synchronize his data with the backend. The process of data flow would be from your client to your WAS (middleware), WAS to backend and when another synchronization is performed data is transferred from backend to WAS and then to client.
This blog will help you to understand the process that takes place between the WAS and the backend.
ASSUMPTIONS:
- Mobile Client & Server are up and running.
- Mobile Application is deployed in the MI client
- The end user has synchronized his data and the data container has reached the WAS. This is a whole another process which is out of the scope of this blog.
PROCESS:
Step-1
Let us start with the processes in the Backend.
A “ZFM” – a function module with all the business logic is to be created and a wrapper for this “ZFM” is created using the transaction ME_WIZARD. The name of the method is the alias name for the wrapper function we just created. We refer this method name to access this function module from the application. There is also an optional name field which will be the name of the wrapper. When this field is left blank it will automatically generate a name in the format “ME_ZFM”. This alias method gets an entry in the table BWAFMAPP in the backend against the generated function module.
Step-2
On the Web AS – MI Server, we enter the alias method and the name of the “generated function module” in the table BWAFMAPP and a corresponding entry in the table MEMAPPDEST with the RFC destination pointing to the backend. With above mentioned entries, the function module WAF_MW_SYNC in the server maps to the backend and executes the business logic – “ZFM”.
Step-3
When the client synchronizes the application the data container is generated and comes to the inbound container of the MI Server. The details of the container are in the table MESYBODY. The type I is highlighted in the picture, which means INBOUND CONTAINER. The device ID that is seen here in the picture is generated automatically and is different from that of the device ID on the client. It always remains unique for that client device. The data container is transferred to the backend and the “ZFM” is executed in the process described in step 2.
Step-4
The data container from the backend resides in the outbound container of MI Server with the same device ID but different container ID. Since this process is asynchronous, a second synchronization is needed from the client to get the updated data. When this happens, the outbound container will be delivered to the client and MESYHEAD is cleared. The type I seen in the above picture will be converted to O which means outbound container.
ISSUES:
If Step 2 is overlooked you will get this following error.
