cancel
Showing results for 
Search instead for 
Did you mean: 

Server Driven SyncBO (T51)

Former Member
0 Kudos

Hi All

I have to create a Server driven SyncBo (T51). I have read all its theory

and I think I now understand its working well. I just have some technical queries for you all, which may be related to coding and stuff.

It seems to me that for Server Driven SnycBo, the back end needs to 'Catch a event' and then make a RFC call to the middleware to a particular FM. My question is how will the back end 'Catch the event' and automatically execute the programme makin the RFC call.

How will the back end know if some back end data is changed or created and how will it react on its own. Is it some user exit or something else...

The data which is in use might lie in Custom tables.

And how will the GetList BapiWrapper will only get the delta data. How will it send only the keys of the objects which have been changed.

Do we have to use some time or date fields and compare them to see which data has been changed or not.

Or we can use CDPOS tables to record changes.

Sample code and ideas are welcome.

If Any clarification is needed.. please free feel to ask me

Points will be awarded for sure.

Thanks, Ankur

Accepted Solutions (1)

Accepted Solutions (1)

AjithC
Employee
Employee
0 Kudos

Hi Ankur,

The easiest way to catch changes in the backend is to use BTEs. Or you can find some exits and write the code in that.

Depends on the business scenario its not difficult to identify the changes for the object. The object lies in the backend system. Find out which program UI make changes to your business object. Once you identify that, you can easily track the changes by writing some code in the exits. Or incase the changes to the business object can be done via multiple UIs and even from remote systems, you can use BTE (if available).

Worst case, write a program to identify the changes (via timestamp or similar fields) and then run this periodically to push the data..

From MI perspective, the backend will inform the changes via calling the method MEREP_DELTABO. Once the call is made, MI will schedule a job to do the replication. The delay for the job is default 5mins, which can be configured in merep_pd (SP19 onwards). All the changes informed by the backend in this delay time is consolidated and then passed to Getlist. The only job of getlist is to verify this and return.

Hope its clear..

Regards

Ajith

Former Member
0 Kudos

Hi Larissa,

Thanks for the reply and the link. But my question still seems to be unanswered to me.

The link is very detailed and helpful, but I am interested in the more technical side of it.

How to exactly catch the events in the backend and the pass only the delta data to themiddleware.

Hi Ajith,

Thanks for the reply.

I am really interested in the details of the first paragraph of your reply. I am still an

novice in SAP. Did not know about BTEs and stuff, but read about them after I read your reply and I seem to understand that they do exist for particular Business Scenarios and we can find them for the 'required' business scenario and write the required code in the exits available. That is perfectly fine.

But the problem with me is that I dont seem to have any Business scenario with me. I am tryin to make an assignment, in which I have some custom tables(which I have created myself) and some data in them.

I have to deal with them only (as of now).

And supposing I add data or modify some data in them.. say through se16 or some program does that or any other way, how is the back-end supposed to catch this event and make an RFC call to the middleware.

Do we have to use UserExits in this case.. if yes, how to find which one to use?

Also there are two ways the T51 sync can work, the backend can tranfer the Object keys which have changed to the FM or transfer the SyncBO ID which is connected to the tables in which the data is being modified.

In the first case, I think we can use the objects keys (which will be in MEREP_DELTABO table) to find the records to be accessed by the BapiWrappers and will give only the delta data.

Please tell me if I seem to be writing anything wrong in part or fully.

In the second case, I am still confused as to how to access only the modified data.

I will not prefer the job to be run periodically which will loose much of the effiency of T51 SyncBO.

It will be nice if you can clarify more.

Any sample codes will surely be welcome.

Thanks, Ankur

Former Member
0 Kudos

Hi Ankur,

For the T51 type of syncbo, the replication is done from the backend.

We have to run a report to achieve this delta replication.

so when we run the report, all the delta record will come and sit in MEREP_DELTABO table in the middleware.

Thus the replication report's job is done

From here all the records in table MEREP_DELTABO should be puuled to table MEREP_207 which is the RDB in the middleware, for this we have to create entried in the MCD about the syncbo.

When the records are in MEREP_DELTABO, getdetail along with getlist is called and pushed to MEREP_207.

Find the code sample of the replication report:(sample example)

REPORT ZTEST_T51.

PARAMETERS: SYNCBO TYPE MEREP_401-SCENARIO,

RFCDEST TYPE MEREP_401-RFCDEST.

data: ldt_r3keys_bo type merep_deltabos occurs 0,

lds_r3keys_bo type merep_Deltabos,

  • ldt_CUSTOMER_HEADER type Z1CUSTOMER_DELTA1 occurs 0,

ldt_CUSTOMER type OTC_HOTELROOM00 occurs 0,

LDT_CUSTOMER_STRUCT LIKE OTC_HOTELROOM_DELTA OCCURS 0,

ldt_return type bapiret2 occurs 0,

Wa_customer_struct like line of ldt_customer_struct.

field-symbols:

<l_CUSTOMER> type OTC_HOTELROOM00 .

*OTC_HOTELROOM00--> Header table

*Check

CALL FUNCTION 'ZOTC_REPORT1'

*'ZOTC_REPORT1'-->getlist bapiwrapper

TABLES

*Check

t_top = LDT_CUSTOMER_STRUCT .

*select * into table ldt_CUSTOMER from Z1CUSTOMER_DELTA.

loop at ldt_CUSTOMER_STRUCT into Wa_customer_struct.

lds_r3keys_bo-r3key = Wa_customer_struct-roomid.

  • initial download

if Wa_customer_struct-me_action = 'A'.

lds_r3keys_bo-msgfn = '009'.

endif.

  • modify

if Wa_customer_struct-me_action = 'M'.

lds_r3keys_bo-msgfn = '004'.

endif.

  • resend

  • lds_r3keys_bo-msgfn = '018'.

  • Delete

if Wa_customer_struct-me_action = 'D'.

lds_r3keys_bo-msgfn = '003'.

endif.

append lds_r3keys_bo to ldt_r3keys_bo.

endloop .

*call function

CALL FUNCTION 'MEREP_DELTABO' DESTINATION RFCDEST

EXPORTING

OBJTYP = SYNCBO

TABLES

DELTABO = ldt_r3keys_bo

RETURN = ldt_return.

Hope this is helpful to some extent.

Cheers,

Karthick

Former Member
0 Kudos

Hi Karthick,

Thanks for the reply. It surely does seem helpful. Really a good report, I had to spend some good amount of time tryin to understand its functionality.

Still I have some questions.

First: How will the report be executed? Manually? Or it can be automated and it will run everytime the data is modified.

Second: It does seem like that the GetList BapiWrapper is returning the values of Me_Action field. How is that so? (How does the GetList BapiWrapper knows which field has been changed, created or deleted, Do I need to look into the BapiWrapper code too?)

And why for Every value of Me_Action you have given a value to the field, msgfn (I even dont know what it is), like for Me_Action = 'M', you have equated msgfn to '004'.

It can be specific to your report, but I thought better to ask.

Will be looking for clarifications, This report has been wonderfully helpful though.

Thanks, Ankur

Former Member
0 Kudos

Hi Ankur,

Firstly, you can execute this report manually or schedule a job..which runs periodically.

T51 Syncbo's Getlist bapi wrapper is different to T01/S01, its functionality should be some thing like this......when ever we execute getlist bapiwrapper it should only return the delta data each time (not all records unlike in T01/S01 type of Syncbos).

Example:

if Wa_customer_struct-me_action = 'A'.

lds_r3keys_bo-msgfn = '009'.

lds_r3keys_bo reffers to MEREP_DELTABOS (Structure)

so msgfn is a field over there.(field of merep_deltabos structure).

Cheers,

Karthick

Former Member
0 Kudos

Hi,

Thanks for the reply.

But now it seems that One half of what I wanted to know lies in the coding of the GetList BapiWrapper i.e. How to get the Delta Data?

(You think that code can be made available, as a reference for me?)

And the Second half is that I think in T51 SyncBo replication has to be an automatic process. So still confused as to how to automate it, so that whole of your replication reports logic will be performed, on its own, everytime some data is being changed, created or modified.

I really appreciate the help you have given me till now and may be I am looking for more.

Thanks, Ankur

Former Member
0 Kudos

Hello Ankur,

Just to explain in very simple manner how T51 can be made to work.

Option 1: Delta identification by B/E.

1. Imagine there is a application "ztable1" with a timestamp and replication table "zlastreplic" with a time stamp field.

2. Assume that whenever you insert/change rows by application, the timestamp is updated in ztable1.

3. Create a report in R/3. This report should collect the records in ztable1 which has timestamp more than zlastreplic-timestamp field. These records should be send to m/w using MEREP_DELTABO function module. At the end of report, update timestamp in zlastreplic.

4. Middlware will collect the records i.e., keys from MEREP_DELTABO and calls corresponding getlist bapi wrapper.

5. In getlist and getdetail wrapper, you can simply read the records from ztable1 because you will only read the records which are modified/added from the last time whenever m/w was updated.

6. You can skip 3rd step if any application is inserting/modifying rows in ztable1. At the end of application code, you can call MEREP_DELTABO function module to insert rows in M/W merep_deltabo table. The getlist/getdetail wrapper can still remain the same.

Option 2:

7. Assume that the records you want to replicate lies in ztable1. It has single char field called "Replicated", 'X' or ' '

8. In the getlist, collect all the records for which "Replicated" field value is ' '(blank). At the end of getlist code, update "Replicated" field value to 'X' for all the collected records.

9. Whenever your application modifies the records in ztable1, "Replicated" field value should be updated with ' '(blank). Whenever it inserts a record, even then "Replicated" field should be blank.

10. So, here getlist is identifying only delta.

In the real world, the business cases are not so simple but anyways hope it helps you to get an idea.

Best Regards,

Subhakanth

Former Member
0 Kudos

Hi Subhakanth,

Thanks for the reply. It was very informative.

In Option 1: I am a lil bit confused as you how, In a R/3 report, Can we compare the 'timestamp in the application' and the 'time stamp field in the replication table'.

And how will that Report be executed? Manually?

And I did not at all understand your Step No. 6

In Option 2: I really like this option. But say, I want to make this T51 for an existing custom table. Do I have to go and add a 'Replicated' field in that table?

I dont think I will like to do that.

Once more I want to say, your reply was very informative.

I still am looking for more replies to my questions.

Ankur

Former Member
0 Kudos

Hi Ankur,

<b>In Option 1: I am a lil bit confused as you how, In a R/3 report, Can we compare the 'timestamp in the application' and the 'time stamp field in the replication table'.</b> Ans: here we cannot compare the timestamp of the application data with that of the MI tables using the report. You will have to maintain a timestamp when the report was last run so that you can replicate only those data that have been modified after the this timestamp of last run of the report.

<b>

And how will that Report be executed? Manually?</b>

Ans: The report can be executed manually or schedule it backgorund.

Thanks...

Preetham S

Former Member
0 Kudos

Hi Ankur,

<b>And I did not at all understand your Step No. 6</b> Ans: What shubakanth meant is that, if you are populating the data to the ztable1 automatically by the application then the 3rd step is not required. If the application does not populate the data automatically then you will have to do the step3.

Thanks..

Preetham S

Former Member
0 Kudos

Hi Preetham,

Thanks for the clarification. Still I am confused. May be I am using my brains less and asking more.

One time stamp field can be maintained in the table in which the data is being modified and all that. Where do you think the other timestamp(the time at which the report was last run) is to be maintained?

And I dont know if I have got the concept all wrong, but it seems to me that in T51, the <b>replication takes place automatically</b> whenever the data is modified or created.

Why is everybody asking for the report to be run manually or schedule in the background? Please clarify.

And I still dont understand the Step No. 6. Are you referring 'ztable1' as an application or a table in which data is being modified or created. If its a table, how can we not need to run that report...

And if somebody can take some time to read all the above posts, some unanswered questions still are lingering..

Thanks, Ankur

Former Member
0 Kudos

Hi Ankur,

The concept of <b>Replication Taking Place Automatically in Case of T51 is Wrong</b>.

The difference in replication between T01 and T51 is that, in T01 entire data from the backend is picked and compared with the data present in the middleware and the changed data is updated. For Ex. If there are 10000 sales orders in the backend and only 1(may be VEBLN = 9999) sales order is changed, then in T01 we still pick all 10000 sales orders and compare it with middleware data to identify the changed record. So lot of overhead in replication due to unecessay comparison.

However in case of T51, we only replicate the Change records. Here backend has to explicitly inform the middleware which data is changed by passing the keys of the changed data to MEREP_DELTABO function module which is present in the middleware. So in the above example, the backend will inform that the middleware that sales order 9999 was changed. Then middleware will only pick sales order 9999 to update changes to data stored in middleware. Lot of saving in time and resources since only record was picked from backend for update.

Now...question is how will backend know the changed data and how will it inform it to middleware. There are 2 approaches, one is using BTEs (Business Transaction Events) and other is running some report in the backend which identifies the changed data.

Now BTEs can be used only those places where transaction provides the place, that is whenever a sales order is changed we trigger BTEs, which in turn transfers this sales order number to middleware.

Now in report, logic of identifying changed data was explained by Shubhakanth, you can implement any logic to identify the changes. Use of timestamp and temporary tables is one of the ways....

Hope this clears the doubt....

Thanks.,..

Preetham S

Former Member
0 Kudos

Hi Preetham,

Thanks for the reply. I am postin here some extract from SAP Note 711983 - Server Driven Implementation:

The Server Driven SyncBO is an enhanced synchronization type of the Timed

2-way (T01). Synchronization process is exactly the same as T01, but the

replication mechanism is different.

Following is the main feature of the Server Driven data replication.

<b>o Backend initiates the data replication</b>

o Only the delta objects are handled during the replication

The Timed 2-way data replication is triggered from the Middleware. Since

the replication is triggered from the middleware, a temporary inconsistency

may occur between the database on the middleware and the backend in case

the replication is not executed frequently. <b>If the replication is triggered

from the backend system whenever data is updated, the inconsistency should

not happen and the Replica DB in the middleware will always be up to date.</b>

The second point is that the comparison of whole data (as in Timed 2-way)

will not be performed to identify the delta objects. The Server Driven data

replication will replicate (update the Replica DB) for only the delta

objects received from the backend.

I can see your point of Delta data management, but still I am confused about the first point. It has been mentioned in the SAP Note clearly - <b>When any data change is detected in the backend system, the backend system

should initiate the data replication by calling a function module to the

middleware system remotely.......!</b>

I dont know about the BTEs (and neither I can use them in my current scenario) but surely one must do something for a Report to trigger automatically.

Any clarifications will be welcome.

Thanks, Ankur

Former Member
0 Kudos

Hi Preetham,

And if you can tell me Where the other timestamp can be maintained, It will be a great help.

Thanks,

Ankur

Former Member
0 Kudos

Hi Ankur,

You could maintain the time stamp in some other DB table may be ZTIME_LASTRUN...then in the report when you running fetch all the sales orders which have created date and modified date greater than the one stored in the table ZTIME_LASTRUN. This should give only the changed data.

Reward points if useful ;)....

Thanks...

Preetham S

Former Member
0 Kudos

Hi Preetham,

Any response about my previous post about Automatic Triggering..

And you mean I have to create another DB table to maintain a timestamp?

How will this timestamp be updated? By the application which is modifyin data?

Can there be a case when I am simply using SE16 to modify data in a custom table and this time stamp gets updated?

And do we have different dates are created date and modified date?

And how do we handle the deleted data?

And in GetLlist Bapiwrapper, a field Me_Action must be exported with the values as 'M', 'D' and so on. Can you help on how to achieve it.

Any sample codes will be welcome.

And points will be awarded in good time.

Thanks, Ankur.

Former Member
0 Kudos

Hi Ankur,

Any response about my previous post about Automatic Triggering..

<b>Ans: As earlier mentioned there is nothing like Automatic Triggering. When the Backend calls the MEREP_DELTABO table by passing keys to it and replication job is scheduled by MEREP_DELTABO Function module in the middleware. The method of passing of keys is wat needs to be developed in the backend</b>

And you mean I have to create another DB table to maintain a timestamp?

How will this timestamp be updated? By the application which is modifyin data?

<b>Ans: Yes you will have to create one. By the report which is created in the backend so when the report is run this table in the backend must be updated.</b>

Can there be a case when I am simply using SE16 to modify data in a custom table and this time stamp gets updated?

<b>Ans: Not any i can think of</b>

And do we have different dates are created date and modified date?

<b>Ans: Suppose new sales order is created after the report has been run, then in such cases we need to replicate the same. Also old data may get modified after the report has been run and hence the date</b>

And how do we handle the deleted data?

<b>Ans: Track the ones that are deleted and pass the same to the middleware with action 'D'.Tracking needs to be done by the backend.</b>

And in GetLlist Bapiwrapper, a field Me_Action must be exported with the values as 'M', 'D' and so on. Can you help on how to achieve it.

Any sample codes will be welcome.

<b>Ans: In the backend when maintain a table with fields haveing the key field and the me_action field. When data is created or modified or deleted, populate this table with C M or D repectivley. The pass this data to MEREP_DELTABO function module</b>

Thanks...

Preetham S

Former Member
0 Kudos

Hi Preetham,

Thanks for puttin all this time of yours to answer my queries.

Still, I am a lot confused.

What do you think about a UserExit for some Custom Table which contains all the logic of your Replication Report? Will it be triggered automatically when some data is changed or created in that Custom table? Do you think of it as a possibility? If yes, how can we implement it? What user exit to use and other stuff?

And How to handle deleted data is still unclear.

"Track the ones that are deleted and pass the same to the middleware with action 'D'.Tracking needs to be done by the backend" is fine. But how exactly to do it? How to know which have been deleted and how to pass a action 'D' with that fields?

Also you said -

In the backend when maintain a table with fields haveing the key field and the me_action field. When data is created or modified or deleted, populate this table with C M or D repectivley. The pass this data to MEREP_DELTABO function module.

Can you tell me how will this happen? How will these the field Me_Action will get different values whenever data is created or modified or deleted? By the application who is modifyin the data?

How, when any data is created or modified or deleted, does the population of Me_Action field happen with values as 'A', 'M' or 'D'?

You can take a look at the sample report provided by one person in this thread.

I really think, I am tryin to go a lil deep into all this and tryin to ask everything. Even my questions sometimes seem non sensical to me. If you think the same, you can ignore them.

Thanks, Ankur

Former Member
0 Kudos

I think people are really ignoring my questions. Or may be they(my questions) deserve to be ignored.

Well, thanks to all who have offered all this help to me. It really helped me a lot.

Thanks Again,

Ankur

Answers (1)

Answers (1)

former_member304703
Contributor
0 Kudos

Hi Ankur,

you might want to take a look at the document

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

which is published on mobile SDN.

Document describes SDs for Mobile Asset management application but it gives a general picture as well.

Regards,

Larissa Limarova