Data push from merep_deltabo to merep_207

[Former Member]

Hi All,

I wanted to know whats the significance of merep_deltabo and merep_207 table.We have one report for pushing the data from merep_deltabo to merep_207 but its not scheduled do we need to run this periodically.

We have around 2 millions records in merep_207 and 0.8 million in merep_deltabo.Is it normal amount or do we need to take some corrective actions?

Ques: Replicator pushes the data for partner material syncbo from backend to middleware(merep_deltabo)?

Ques: Report like"Z_MAINTAIN_SERVER_DRIVEN_CUST"

pushes the data from merep_deltabo to merep_207.?

Thanks & Regards

Devendra

[Former Member]

Hi,

to get a better understaing this document should be helpfull:

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/818ac119-0b01-0010-ba8b-b6e3f349...

As well it is a detailed setup guide with error handling at the end - so it should help.

First a few answers:

- in a normal case the replicator running in the backend (FIBF) will push any change of a Functional Location for example into table MEREP_DELTABO in the middleware. Furthermore this push will plan a job (visible in SE37) that starts after about 5mins. This job then should process your entries from MEREP_DETABO to MEREP_207. These steps should happen automatically - without you doing anything. That is the reason for havin server driven replications.

If the data stays in MEREP_DELTABO, something in your setup is wrong. It could be anything from a wrong user in the RFC, a wrong configured RFC connection anyway.

Please use the mentioned document above to really check your setup again.

Hope this helps - if not feel free to ask further questions.

Regards,

Oliver

[Former Member]

Hi Oliver,

Thanks for the reponse but in our scenario we dont have change point trigger like for material or partner we have to run one report in backend to push the data to merep_deltabo as it is not changed frequently once in 3 months or so.Previously it used to work fine but now partner data and material data is stuck in Merep_deltabo with status"M".You mentioned the MI will trigger the push of data from merep_deltabo to merep_207 via some function module how to check that?which FM..can i check why its failing and how?

Thanks again..

Regards,

Devendrta

[AjithC]

Hi Devendra

Its not fine to have records in MEREP_DELTABO table. 0.8M records means there is some settings problem as rightly pointed by Oliver.

Z_MAINTAIN_SERVER_DRIVEN_CUST will not push data from merep_deltabo to merep_207 or vice versa.

The table MEREP_DELTABO is used only by T51 (server driven) syncBOs for replication.

If you have T51 SyncBOs and the records are struck up in deltabo table, try running the replicator for the above syncBOs. If the entries are in Status 'E', check the logs for more details..

Regards

Ajith Chandran

[Former Member]

Hi,

well, if you do not have a change point trigger - then why do you have 0.8M entries?

Anyway, if you go through the document I mentioned then you will most likely find the solution. If entries have status 'M', then this is a modify request. But there should be the status of the actual processing. This is epty if no job was started for this item - it is P as the job is runing or the item gets deleted if the job is finished.

Well, we have a planned job - in SM37 - MEBDT...... or something similar. For example: you have an order. This order is - for example - realted to a functional location and a pratner is attached to this order as well. Whenever you release this order, the trigger in the backend - that should be active - sends the key of these objects with status M to the middleware. Then the job is planned and you should find it in SM37. this job will start after 5min and process the data flow form DELTABO into 207 while it takes the item key from deltabo, gets the details from backend and stroed these details in 207.

Ok, even you say you have no changes or do not use these things - well, based on the scenario mentioned above I would say you do use these things - cause an order is related to an employee at least (person responsible) and this person is a partner and so you need the trigger and the correct setup.

Caused by this I come back to my very first appointment: please take the document I mentioned and go through it. It is crearly about this subject and not wasted time or filled with unnecessary stuff.

Going through this document will clearly solve the issue. s well there you will find a very clear explanation about the process and where which function module is called for whatever scenario and object.

I guess this wil help you the most.

Regards,

Oliver