keeping track last time interface run

[Former Member]

Hi guys,

I'm working on a program that's supposed to run every Monday (weekly), so, I found a scenario here, if the program runs on that last monday of the month which is 28th, and the last day of that month is wednesday which is 30th (in the same last week of that month),

Then I will have to go back and pick up whatever it was left on monday (28th) and tuesday (28th) and wednesday (30th) by setting up the program to run one more time on the last day of the month (every month), to make sure I pick up data since the last run. So the program runs every week and 1 more time every month....

My potentially solution for this is creating a custom table, every time my program runs, it will update the sy-datum info into that table, so next time, the program will read the system date to know what was the last time it runs to determine what data to grab since the last time run. I'm looking for a better solution or any other alternate way to solve it, any idea here will be highly appreciated...

Also, since this program is set up for batch run, sometimes my client needs to run it manually, so if it runs manually, should it update the custom table or not, so next time the batch run only pick up everything from the last manual run. my answer is no but still open up to you guys to discuss, THANKS!

[Former Member]

Hi guys,

I'm working on a program that's supposed to run every Monday (weekly), so, I found a scenario here, if the program runs on that last monday of the month which is 28th, and the last day of that month is wednesday which is 30th (in the same last week of that month),

Then I will have to go back and pick up whatever it was left on monday (28th) and tuesday (28th) and wednesday (30th) by setting up the program to run one more time on the last day of the month (every month), to make sure I pick up data since the last run. So the program runs every week and 1 more time every month....

My potentially solution for this is creating a custom table, every time my program runs, it will update the sy-datum info into that table, so next time, the program will read the system date to know what was the last time it runs to determine what data to grab since the last time run. I'm looking for a better solution or any other alternate way to solve it, any idea here will be highly appreciated...

Also, since this program is set up for batch run, sometimes my client needs to run it manually, so if it runs manually, should it update the custom table or not, so next time the batch run only pick up everything from the last manual run. my answer is no but still open up to you guys to discuss, THANKS!

[Former Member]

I think, the solution you have describe above is quite OK, because of the transparency: In case you realize it that way it also very easy to get to know the time span, that was processed by the last run and the time span that will be processed during the next run.

Why don´t you think your solution is not good enough?

[Former Member]

Hi Mike, thanks for your answer, I'm still seeking for any other better idea because in case of manual run, somebody may screw up the Ztable, if the run fails or has error, manual run may be repeated many times, meanwhile I'm still thinking about that case...

[ThomasZloch]

Hi,

I also find this solution OK, I have seen several of these running well in productive systems.

You must make sure that you are updating the timestamp at the very end of the interface run, when everything has been processed successfully. In case of errors the run can be repeated as many times as needed and will still pick up the data since the last successful run.

Cheers

Thomas

[Former Member]

Hi,

You can find background job last execute run time in the TBTCP or TBTCO table.

And if the interface method is IDoc,

you can get the last sucessful execution time in EDIDC table.

You can use this time to pick the data from the data base table.

Regards,

[Former Member]

Thanks all, I will try to look up these tables, all answer got points, all future answers are still very appreciated!

[Former Member]

right now another idea comes into my mind:

what about checking some kind of special authorization right at the beginning of the processing of that report? Only the user executing the report as background job should have this authorization. In case the report ist executed by a user not having this authorization, the report will be executed, but the timestamp in you Z-table will not be updated... ??!

just an idea...

[Former Member]

@Bhanu thanks for your reply, I checked these 2 tables already, it's a good idea too, but I got information form Basis team that they will not keep the log file in these table for any schedule record after 8 days since they have thousands of schedule runs, so that may not be possible to keep track

@Mike, thanks much for your idea, I'm checking on it now...