Generic Sync - Table MESYBODY

[Former Member]

Hi,

I have an AWT-Generic Sync application that uploads data from the MI Client to R3. I'm using SP19 with WM5/CreMe on, believe it or not, a Treo 750wx Smartphone. And I'm a happy guy, because data is making it to Table MESYBODY.

I have a wrapper function, a Function Module, and a final destination table.

However, the data is not making the leap from MESYBODY to my table. I must admit to being a little confused, because the wrapper function, function model and table all pass syntax check, are activated and pass emulation tests (i.e., I enter data into the inbound container on the function module, and it appears in the destination table)

The documentation hints that a batch user handles the move of data from MESYBODY onwards. Can anyone shed some light on this batch process, or otherwise comment on what might be going on?

PS - at the moment my application could care less about any response from R3 post upload (luckily!).

Thanks in advance

[Former Member · Accepted solution]

Hi David,

The term being used that data is not making a leap from MESYBODY to your tables is wrong here. MESYHEAD & MESYBODY are MI-specific tables. The containers that travel to and forth the client and the middleware are stored in these tables.

There are 2 types of sync that the client can make with middleware - Synchronous and Asynchronous. What you mentioned about the batch job is asynchronous mode of sync. Here when the client sync, the containers are stored in the table MESYHEAD & MESYBODY. When you trigger the batch job the containers are picked and processed. The name of this batch job is MEREP_RETRY_BP. You can even execute it directly rather than scheduling it as a batch process.

The middleware will know on what method to call via the method field contained in the container. So just check whether the containers sent by the client have the alias method field or not. This is in turn mapped to the actual method to be called in the backend in the table BWAFMAPP.

Just check whether you have all these points in place.

Regards,

Nameeta

[Former Member · Accepted solution]

Thanks Nameeta,

It turns out that MEREP_RETRY_BP had not been scheduled.

Dave