Information on 'Backend Push Oriented Approach'

[Former Member]

Hi,

How does this Push Oriented Approach in MI?.

It would be great enough if you could give a ellaborate information on this.

Regards,

Bharath.

[Former Member]

Hi Bharath,

A few points I wanted to add to a lot of useful information posted.

Server-driven is a future path for most of SyncBos. In fact from MA3.0 SR3 most of T01s will be released in standard package only as server-driven.

As for converting Order SyncBO to replicated type - MAM designed with a thought in mind that only data that does not change too often, so called master data, is replicated to the middleware. It is done because for offline application the moment sync is finished device is presumed outdated. With middleware you add one more chance that device will have old data and will run into conflicts. Plus middleware gets bigger and sometimes can not cope with all the data required.

From your message I understood that the main reason for considering converting order SyncBo is that device does not go to the backend. I believe that using MEREP_DISTRIBUTOR will suit your need better. You can run it at night time and when device syncs all the data is ready on the middleware.

Cheers,

Larissa

[Former Member]

Hi Karthick,

here are two disadvantages related to the usage of T51:

1. As you have described in your thread the backend will push the delta data key to the middleware and later on the middleware will start the replication. You could run into performance problems on the backend if the amount of delta data is too big (e.g. because of month-end closing activities) and therefore the delta data replication takes a long time and during this time period the replication will put a lot of load on the backend system and might affect dialog users.

2. If you use S01 you will get everytime the most up to date information. Depending on the scheduling of the replication job the data might not be up to date.

Overall T51 has a lot of advantages but it really depends on your business case if you could use T51.

Best regards,

Flo

[Former Member]

Hi all,

We are using MAU, and someone suggested changing the Order SyncBO from 2-way (S01) to Server Driven (T51). This would save on the mobile users having to reach all the way to the backend when syncing, which would speed things up. I can now see a downside - that perhaps only the order key exists in the replica db and not the rest of the order info.

Is this correct, and are there any more advantages/ disadvantages to consider?

Rgds,

Eamonn.

[Former Member]

Hi Eamonn,

It is not correct that only order key is stored in the Replica DB if the order is converted to a T51 SyncBO. Whole Order information is stored in the Replica DB. The process of pushing data to the middleware is quite different from T01 SyncBO.

Here we the process is as follows:

We inform the Middleware of changes to the data in the backend by sending the keys of such objects to the table MEREP_DELTABO in the middleware. This table will store the keys of all the businees objects. Once keys are present in this table, we call the getdetail BAPI to get further info to populate the Replica DB.

The advantage in T51 SyncBO is that data is always the latest in the RDB.

During upload from client there is no difference between S01/T01/T51 from MI2.5(SP19) onwards. Only initial download will be faster in T01/T51 from MI2.5(SP19) onwards. If MI is less than SP19 then T01/T51 will be faster since the data is fetched in the middleware if replicator has run during upload. But there is some disadvantages in SP18 or less, that sometimes the changes in the backend are not reflected in middlware and they tend to get overwritten by the changes from the client.

Thanks...

[Former Member]

Hi Eamonn,

As Preetham has explained the entire process, i would like to add few more points in detail:

1) T51 is advantages of all syncbos.

2) The difference between T51/TO1 is the way it gets replicated to Middleware from Backend.

3) Performance is high in T51:

a) For TO1 when replicated, Middleware R/3 keys will be compared to Backend R/3 keys(So it has to compare each and every key and then update the middleware with the latest R/3 keys)

b) But for T51 when replicated from backend (We need to run the report for replication from the backend, so data is pushed from backend to Middleware, so only these newly added,deleted,modified records come into MEREP_DELTABO.So from there some job has to be scheduled(getlist bapi is called) in the middleware and middleware is updated with the data in MEREP_DELTABO.

4) Latest data is available with T51 syncbo.

Other than replication process for T51 every thing is similar to TO1.

Cheers,

Karthick

[Former Member]

Preetham,

Thanks for the response.

Is there any reason why S01 is used instead of T51 for "UMAM_001 Orders" in standard MAM/ MAU?

Thanks again,

Eamonn.

[Former Member]

Hi,

I am not really sure, but the orders are allocated based on the users and since the data is stored separately per mobile user in MEREP_10100 table and mobile id is unique per user, the data is sent only for the required users.

It can be achieved in the same way in T01/T51 by making use of filters.

Thanks...

[Former Member]

Hi Bharath,

<b>'Backend Push Oriented Approach'</b>

Whether ur refering to push data from backend to MI Client or Middleware server.

If ur referring to Middleware then while creating Smart Sync Application u need to define the Synchronization Type.

There are thre type of Synchronization Type S01, T01 and S51.where S51 refers to server driven type in which when ever there is change in the backend R/3 system it will by itself do the delta determination and push the changed data on replica DB of MI server.

Pushing data to MI client is not supported in MI as per my knowledge.

Regards

Devendra

[Former Member]

Hi Devendrakumar,

There is no Synchronisation type called S51 but there is a Sync Type called T51 which is also known as Server Driven SyncBO where data is pushed into the Middleware Replica Database from the Backend. The data that is pushed are changed data and new data. This can be triggered by configuring the BTEs or running a suitable report that will do the job of sending the R3keys to the MI middleware.

My previous post does not mention that the data is pushed into the MI Client.

Thanks,

Preetham S

[Former Member]

Hi Preetham,

Thanks for correcting me ya u r right it is T51.My mistake i have written that.

regards

devendra

[Former Member]

Hi Friends,

As we know that we have T01,S01,T51,U01 type of syncbo's.

Out of all T51 is very useful and synchronization time is also very less.

We need to trigger the replication from Backend(for that we have a report), after this report executed all data will come to Merep_deltaBO table, from there onwards data will go to Middleware(merep_207 table)(For this we need to schedule a job(means when ever Middleware finds any records in Merep_deltaBo, it will take all records from it after a specified delay.

Advantages are:

1)It will push only delta records to Middleware, so in this way replication process is also very fast.(This over comes T01 type disadvantage)(In T01 while replicating all records are compared to Midlleware records and then update, but in T51 type as its a Backen driven, Backend knows which record has been modified so it pushes only those records to Middleware.)

But i would like to know if at all there are any disadvantages of T51 type in detail.

Thanks in advance.

Hope this is clear about T51 type.

[Former Member]

Hi Bharath,

Backend Push Oriented Approach is basically used to keep the Middleware up to date with latest changes with the backend where the changed data sent from the backend to the middleware. Here whenever data undergoes changes in the backend, its Key is pushed into the middleware. When the Key is pushed into the middleware a Backgorund job is scheduled which processes the key and gets the remaining data into the middleware.

This is called Backend Push Oriented Approach in the middleware.

Thanks,

Preetham S