questions regarding update function module

[JerryWang]

Hello experts,

I am on customer site to help them investigate one issue: they have a background job which runs periodically.

In the report database table A is changed firstly ( new entries are inserted ), then a update function module is called via keyword CALL FUNCTION ... IN UPDATE TASK.

Inside the function module database table B is updated. ( existing entries are updated )

Customer issue:

• sometimes they find A is updated as expected, however B remains unchanged at the same time.
• customer could not find exact steps to reproduce the issue. However the issue does exist there and occur from time to time.
• the issue could only be reproduced in their production system, but works perfectly well in dev & Q system. It is difficult to debug in their production system for trouble shooting.

After analyzing related code, I have one doubt: according to ABAP help on CALL FUNCTION aaa IN UPDATE TASK, I know the function module aaa is called in a new update work process. I wonder whether there is any possibility there this issue might be caused because the update function module fails to get called at all? ( perhaps due to heavy system load so no free update function module could serve the table B update ? )

If update function module fails to execute, is there any system utility to record this? That is to say, will it be recorded in such as SM13 or SM21?

Looking forward to your expertise on this topic!

Best regards,

Jerry

[Former Member]

Hi Jerry,

It sounds like a typical COMMIT WORK timing issue (or a missing commit in that case?).

Regarding you question, update tasks are always triggered after commit work is executed. I have never run into "not executed" update task. As you stated, queued/failed update requests can be monitored in SM13.

Why not both DB updates are executed in update task?

[JerryWang]

Hello Shai,

thank you very much for your reply. I can ensure there is no missing COMMIT WORK AND WAIT.

After the line 321 is executed, the update function module is called which update database table B.

Since this behavior( table A is updated in normal work process, and table B is updated in update work process ) is implemented in SAP standard function module CMS_LO_DOC_MAINTAIN, for me I don't know why the original design of SAP did not choose to put both table into the same update task.

Best regards,

Jerry

[Former Member]

Hi Jerry,

Something we can get detailed information from system log(SM21), if any update termination yes, will be from SM13. Did you get the Workload monitoring report? are you facing when the system load is high or sometimes you are getting this issue, can you please reschedule the job in non-peak hours?

Please let us know the solutions if you resolved your issue, will be helpful for others.

Regards,

Vadamalai A

[JerryWang]

Hello Vadamalai,

Thanks a lot for your help. I promise once I have found the root cause, will post it here.

Best regards,

Jerry

[nabheetscn]

Hi Jerry

Do you have commit work in the report under certain clauses...? Secondly you should be able to find errored one etc in SM13.

Please provide commit work details if any

Nabheet

[JerryWang]

Hello Nabheet,

The normal processing is described as below:

entry point is function call of CMS_LO_DOC_MAINTAIN, which has iv_commit set as abap_true.

then in line 54 table A is updated.

Update task is called here: ( callstack 18 )

commit work called in callstack 13:

click F6, the update function module will be in debugging mode in another update work process:

In my opinion, I could not find any place where the iv_commit is overwritten to abap_false, so I would assume there is always COMMIT WORK AND WAIT in callstack 13.

Best regards,

Jerry

[yogesh_sharma2789]

hi jerry,

whether commit work is executing first and then you are calling the update function module?????

If a COMMIT WORK statement is not executed after registration of a function module during execution of the current program, the function module is not executed and is deleted from table VBLOG at the end of the program.............

[JerryWang]

Hello Yogesh,

Thank you for your answer. From my screenshot above I ensure that the update function module is called, and then COMMIT WORK AND WAIT.

Best regards,

Jerry

[Former Member]

Hi Jerry,

Two things:

1. Are you sure that COMMIT WORK is always executed?

As far as I've seen, FM CMS_LO_DOC_MAINTAIN_IL is being called from tens of programs.

2. FM CMS_LO_STATUS_UPDATE_DB is being called in update task, as you stated. However, I'm not sure that the preapre step  (CMS_LO_STATUS_PREPARE_UPD_DB) is.

If this preapre step relies on previous DB updates (without commit work and wait), it might return incorrect results.

Regards,

Shai

[JerryWang]

Hello Guys,

thank you so much for your answers and interests on this issue so far. Your answers are really helpful. I have also discussed with our German experts. This issue occurs in SAP CRM CMS ( Channel Management Solution ). I have not yet managed to find the CMS architect to check why the original design behaves like this( not to put both table update into the update function modules ).

We came into conclusion that this issue might be caused either the update FM is not called at all, or some exception occurred during the call. I have listed four possibilities why it could happen to my colleagues. I also pasted them here in case you are interested. I think it could take some time before we can find the root cause.

Best regards,

Jerry

[Former Member]

Hi Jerry,

Please try using 'Commit work and Wait' statement after each updation of database table.

Thanks,

Pratima.

[JerryWang]

Hello friends,

Thanks a lot for your interests on this issue. I update all my findings:

1. issue background: this issue occurs in SAP CRM Channel manageement Solution, software component CRM-CHM-POS.

2. due to some limitations, the table CMSD_CI_HISTORY and history table are not updated in the same LUW. Instead the first one is updated in normal work process while the other is done in update work process. Since I am not the original developer I didn't know the whole complex scenario ( I did see this is done delibrately in note 1764006 - CMS:Sell In Release creating PB with zero available quantity ).

So for the moment we have to accept this design.

3. during our testing ,we ensure COMMIT WORK is always called.

4. So why sometimes the first table update fails, however there is no hint at all for this failure in the system like ST22 and SM21 ?? ( forget SM13, since it is updated in normal work process ).

The root cause is the flaw of SAP code below.

The code has planned to raise exception if insertion failed due to duplicate records to be inserted.

Unfortunately, the fact is if we use "INSERT db FROM TABLE xxx" to insert records into database and some record already exists with the same key, it will result in a termination but SY-SUBRC is STILL 0; Just compare it with single insertion using "INSERT db FROM <work area>", in the same error situation, processing does not terminate, and SY-SUBRC is set to 4.

As a result in this case even the insertion fails, line 29 will never be executed as sy-subrc is always 0. Since the insertion fails and the exception is caught without any notification, so customer sufferred because they do not know what has happened.

Best regards,

Jerry