Update tasks - Transfer Order creation.

[Former Member]

I have an issue in our production environment where in some situations a Transfer Order (TO) is created with missing storage handling unit information. This only happens intermittently, and when the TO is cancelled and re-created, it is created with the correct storage unit information.

I have looked at the TO creation function l_to_create_int and it is called from within an update function module l_communication_to_create. The l_to_create_int function is not called within an update task. The function within l_to_create_int which creates the storage handling unit is an update function module (function L_TA_HINZUFUEGEN).

So my question is, what happens when you have a combination of function modules called as an update and function modules called normally? Will the updates in the function called normally update outside of the update task commit? I'm beginning to think that the problem may be caused by inconsistencies in when updates are completed by the program.

I'd greatly appreciate any help or guidance regarding this issue.

Kind regards,

James Mandikos.

[Former Member]

I have an issue in our production environment where in some situations a Transfer Order (TO) is created with missing storage handling unit information. This only happens intermittently, and when the TO is cancelled and re-created, it is created with the correct storage unit information.

I have looked at the TO creation function l_to_create_int and it is called from within an update function module l_communication_to_create. The l_to_create_int function is not called within an update task. The function within l_to_create_int which creates the storage handling unit is an update function module (function L_TA_HINZUFUEGEN).

So my question is, what happens when you have a combination of function modules called as an update and function modules called normally? Will the updates in the function called normally update outside of the update task commit? I'm beginning to think that the problem may be caused by inconsistencies in when updates are completed by the program.

I'd greatly appreciate any help or guidance regarding this issue.

Kind regards,

James Mandikos.

[Former Member]

Hi James,

I can answer your question, but I am not really sure that it points to the solution to your overall problem.

Function modules called in update task will begin execution only once a 'COMMIT WORK' is issued either implicitly or explicitly by the calling program. Function modules called without the 'IN UPDATE TASK' addition are executed synchronously within the context of the calling program (regardless of whether or not they are updating database tables).

Thus if a program attempts to update data using both function modules called normally and function modules called in update task, then you may get problems where the function modules called normally attempt to update data which relies on the existance of data which has not yet been updated by the update task function modules (which as they run in a seperate work process, can be considered to have an indeterminate starting/finishing execution time relative to the calling program).

I can't really see, however, how this could cause a storage handling unit to go missing?

Hope that helps.

Cheers,

Brad

[Former Member]

Brad,

Thanks you for your response. Originally, I thought that a function module created with the 'update module' processing type enabled, by default was processed in an update task. I don't think this is correct. From what I understand to be the case, a function module created as an update module, will process in a V1 or V2 update when called in an update task. If it is set as 'Start immed' it will process in a V2 or if set to 'Immediate start, no restart' it will process in a V1.

With the above in mind, I have noticed that a TO is created by a V2 update (L_TO_CREATE_INIT). The Storage HU is created by a V1 update (function L_TA_HINZUFUEGEN). If in times where update processes are heavily loaded (this problem does only occur intermittently) and the system attempted to processes V1 update first, I'm concerned that this may create an inconsitency that causes the storage HU to not be created. It's only a theory and I have not idea how on earth I'm going to force this scenario if indeed it is a valid scenario.

Do you have any thoughts on this?

Best regards and thanks again for your first response.

James.

[Former Member]

Hi James,

You are correct, a function module must be explicitly be called in 'UPDATE TASK' for it to be executed in the update task (regardless of the settings flagged in SE37).

If, however, it is called in UPDATE TASK there are four possible settings you can have in SE37 which each behave differently (as of the release I am looking at at the moment - R/3 4.7).

Here is my understanding of how the settings behave:

<b>Start immed.</b>

Will run in a V1 update process together with all other update functions called in the same LUW with Start immed. flagged.

<b>Immediate start, no restart</b>

As above, but cannot be reprocessed via transaction SM13 in the case of error (but can be viewed).

<b>Start delayed</b>

Will run in a V2 update process individually.

<b>Coll.run</b>

Will run in a V2 update process toegether with all other update functions called in the same LUW with Coll.run flagged.

So given the data you have provided both your function modules should be running in a collective V1 process, and therefore if one failed then the whole transaction should have been rolled back (and hence this does not explain your problem).

<b>BUT</b> what may be happening is that for whatever reason the transaction fails (maybe due to heavy system load) and either your system admin (or an autmated job) is pushing through the error in SM13. As the function L_TA_HINZUFUEGEN is flagged as immediate start, no restart then it will not be processed and the L_TO_CREATE_INIT will be. This could exactly explain your problem.

Hope that makes things clearer.

Cheers,

Brad

[Former Member]

Thanks Brad,

You are indeed correct. Both the 'Start Immed' and 'Immediate start, no restart' option are processed in a V1. I tested this by creating a test function and forcing an update termination. In SM13 the module type was defined as V1 when terminate using either option.

Your earlier recommendation about restarts is a good one, but I have checked with our basis team and there are no automated restarts of terminations. Furthermore, we had several failures today and there are no update terminations.

I'm fresh out of ideas, so I think I might raise an OSS to get SAP to look at this.

Thanks for you help Brad, let me know if I can return the favour.

Best regards,

James Mandikos.

[email protected]