Hi, I create a syncbo of type S01, but i can´t receive the data, why? I create a smart project. The SyncBo is enable, but not receive the data in the app, have i configure anything?
Increase the logging level and see what the log says. Also check if there were any short dumps at the time of synchronising. Type of syncbo will not matter since we generate different funciton modules for different sync types.
I change the type of sync, because i see that the type T01, when sync, sync all table (the time is greater), and i want that only sync the changes (the time will be minor).
ohh - and just to add --- even I make it more complex.
Perhaps it is a good idea to look into type T51 - because this type really only replicates changes and syncs changes. But to set that up, you have to have some knowledge inside R/3 regarding IDocs and that stuff. It is getting very complex here compared to T01 syncbos.
yes, this is correct. T01 always replicates the complete datastack!
But: simply siwtching the SyncBO does not really help you! In your case you mentioned you just changed the BO from T01 to S01. This means:
T01: every replicator run triggers a complete selection on the backend. Because T01 is for data, that does not change that often, you can run this replicator in the night. So the load on the server happens in a time when he has not so much to do - because all employees are at home - and so it is fine. All Syncs run on the middleware only, so the backend is not effected at all.
S01: EVERY SYNC triggers a complete selection on the backend. And this is really not the thing you want! If you say your replication runs a while, then I expect you have a hughe selection. If you just change the SyncBO type without changing the selection, you as well select this large dataset on the backend. But now with every sync. First of all this takes the same amount of time then the selection for the replication of T01 AND you do that now for every user and every sync on the backend.
Are you still with me?
I think you need either to change the selection criteria if you really think S01 is correct for you or change to T51.
In T51 you run a replication similar to T01 one time. Now you have an exact copy of the dataset on the middleware. From that point on you replicate only the changes from the backend to the middleware. But as I said: be aware, this setup is complex and it takes place in backend and middleware!
S01 is really only for Orders, Notifications,.... Stuff that changes really often and where you need really the most up to date data on the client AND where a selection gives an extremely limited result. An employee has just a max of 30 orders that he handels - but he has about 20.000 Equipments. So equipments will never be handeld as a S01 but orders make sence.
very good explication... My program is an inventory of store, so, i think that i need the type S01 no?
In your post, you say:
"S01 is really only for Orders, Notifications,.... Stuff that changes really often and where you need really the most up to date data on the client AND where a selection gives an extremely limited result."
Ok, so, if i will use S01, but now, i´m doing tests, i have a syncbo of type S01 and don´t receive the data... Why? instead, if i use the same GETLIST in a Syncbo os type T01, i receive the data... Not appear errors, and it´s enable... What happend?
I would suggest - for testing - limit the getlist handler so it delivers ony just one entry. I guess it is the time it takes to do the getlist that causes you problems. You said in a previous post: "it takes a long time to replicate".
Try that - normally there is no difference between S01 and T01 getlists - not that I am aware off.
Still: a repository does change, yes, but not that often. To be honest - in your case T51 makes more sence. It is not a problem if you get the result that is perhaps a few secs old - and this can be handeld with T51. I thnik in your case S01 produces too much load on the backend!
So, you think that for my case is necessary use T51 no? But... in T51, i have to develop something in the Bapi no? Where can i see this develop of type T51?
From performance point of view, the best option is T51 syncbO. Some explantions for different syncBO types.. Hope its useful..
T51- Changes are informed to MI from backend. So replication is only for the changed data. Delta is identified during replication and only the delta is sent to device on sync.
T01 - MI pulls all data from backend and compare it with the data already present in RDB to find out the delta. Here also delta is identified during replication and only delta is sent to device.
S01 - No concept of replication. Data is fetched from backend and then compared with the exsisting data to find out the delta during sync. Also data is stored per user in MI RDB.
T01 & T51 sycn time is the same. Only difference is for replication. Replciation time will be very small for T51. For T01, the MI RDB will be updated periodically via replication jobs. So the changed in the backend will reach MI and then the devices only after the replcaition which is generally once a day. In T51, backend informs MI immedietly after the change and so MI RDB is updated almost instanly. So updated data reach the devices fast.
S01 - Very high performance problems. Especially when data volume is big. Should use only for critical objects that chagne very often and is user specific.
S01 only advantage is that updated data in the backend will reach the device in next sync (two sync if async mode is used). This behaviour can be achieved using T51. The only catch is that its not guranteed in T51, but guaranteed in S01.
You need to have a parameter ME_ACTION in the Getlist. Its explained in the note.
<< Prerequisites for GetList BAPI Wrapper Implementation >>
- Receives R/3 key lists from the middleware (transferred via
header tables parameter)
- Transfer the header data for the requested R/3 key list only
- Field ME_ACTION (CHAR 1) defined in header structure
Use the second option for trigerring replciation. During replication, the Getlist is called with the R/3 keys which the backend reported to MI as changed with the corresponding actions (A/M/D). The Getlist just have to verify this and get back with the actual actions.
You can even skip the implementaion for GetList (dummy method which does nothing)as this is useful only in some rare scenations.The real implmentaion will be to verify these R/3 keys and their actions are correct or not.
How can create the ME_ACTION field? I go to the BAPI, in import, i create ME_ACTION - TYPE - CHAR1 but say that RFCs are not permitted parameters reference.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.