IS-OIL - Invalid ROLLBACK WORK in an update function module

[Former Member]

Hi,

I am getting this dump which points to CL_PO_HEADER_HANDLE_MM========CP.

In the system Update Records (SM13) there is an error for transaction O4NM for custom function ZOIJ_UPDATE_RELATED_DOCS.

I have no experience with OIL module so any advice on how to go about tracing the cause of this error would be appreciated.

Regards,

Warren.

[christian_wohlfahrt]

Hi Warren!

This is nothing module specific, it's only bad coding.

You seem to be in a BADI, which is called in update task. There the FM ZOIJ_UPDATE_RELATED_DOCS is called (if I get you right). Somewhere there a rollback work was triggered - which is not allowed in update task -> shortdump.

You should not trigger any (even implicit) commit work (or rollback work). So no call transaction, call screen, call function remotely...

Maybe you have to split your task in writing some to do list into a Z-table (without commit) and later a report, which can make the update of the related docs (including a commit).

Regards,

Christian

[Former Member]

Hi Christian,

Thank you for the help. The error occurs when they run O4NM so am trying to get the documents they are using on Prod replicated in QA to debug.

Cheers,

Warren.

[christian_wohlfahrt]

Hi Warren!

I thought you have short dumps, linked to update termination (SM13). Just have a look inside the short dump, the 'wrong' statement should be pointed at in the source code extract. No need for difficult debugging, simple code analysis of the dump should be enough.

Regards,

Christian

[Former Member]

Hi Christian,

The dump points to method PO_POST in class CL_PO_HEADER_HANDLE_MM, i.e.;

000540 IF l_result <> 0.

000550 IF l_result EQ 1.

000560 MESSAGE a816(me) WITH 'po_post'.

000570 ELSE.

000580 *

000590 * a desaster occured: rollback work

000600 *

> ROLLBACK WORK.

000620 ENDIF.

000630 RAISE failure.

000640 ENDIF.

000650

000660 ENDMETHOD.

The SM13 is as follows:

OIJ_STAGES_WRITE_DOCUMENT V1 NORMAL OK

OIJ_NOMST_UPDATE V1 NORMAL OK

ZOIJ_UPDATE_RELATED_DOCS V2 NORMAL Err

Regards,

Warren.

[christian_wohlfahrt]

Hi,

I found identical coding in my (non IS-OIL) system, so this is pure standard SAP coding. Would be something for an OSS message call, but on the other hand, your SM13 looks like you have a process, where in an update task a Z-function module tries to change some data with standard functions in a buggy way.

Option 1): you can re-produce the error without the Z-function in a different way -> OSS message

Option 2): whatever the Z-function is trying to do, in this circumstance (update task) it's not OK -> program design change. Obviously in an update task, a rollback work is to late - update tasks are only <i>started</i> after a commit work. The different sessions run independently, so no consistent way back is possible.

What is done in ZOIJ_UPDATE_RELATED_DOCS? Can it be performed in a different way?

Regards,

Christian

[Former Member]

Hi,

ZOIJ_UPDATE_RELATED_DOCS is doing an Update of related documents.

I think I need to get hold of the actual documents and try and replicate this on QA?

Weird thing is that there is a Update error message today (exactly the same error for the same function module) for transaction VA03 which is simply to display Sales Orders?

The FM, ZOIJ_UPDATE_RELATED_DOCS, gets the document data using standard functions OIJNOMH_SINGLE_READ and OIJNOMI_ARRAY_READ. Then it performs various data checks followed by the updates. I think I will have to include additional checks at this point to exclude certain documents from being included in the update. Does this sound correct to you?

Regards,

Warren.

[christian_wohlfahrt]

Hi Warren,

Your problem in VA03 only tells, the same enhancement was done in exits of VA0x (and maybe no check for 'is this creation / change / display' was included!).

Your reading functions should have no effect for the update. If you have to reduce the number of found documents - it's a business question, not a technical question.

The question is: how is this update done? Even if you have some standard FM for this - this function might be desinged to run in a dialog session - then you can't use it in an update task exit.

Slowly I begin to understand, your dump occurs only rarely, not every time. Then it's perhaps indeed a special situation of the documents, where the document update is not possible, an internal error message get's raised, which is followed later with the rollback work -> dump. But it's not just a simple invalid call, there is a serious problem.

In case it's VA03, try to find the sales doc number somewhere in the variable value display of the dump. Then you should be able to reproduce the error, maybe even find a sales doc in QA system of same kind (and problem).

Then even update debugging with breakpoints at statement 'raise' (and maybe 'message', too) can help you, if you don't have any other idea.

Regards,

Christian

[Former Member]

Hi Christian,

I am not sure how the update is being done. Am trying to hold of the documents that caused the error so that I can replicate it.

You are correct, the dump only occurs occassionally and not every time.

I have tried to find the sales doc number but unfortunately this is not in the dump.

I did a where used list on the function and found one where it is called in update task which I think is where it is falling over:

CODE:

• in cases where the nomination update is called

• from a CT contract, sales order etc

• we dont want to update the related document

• or it will cause locking issues and

• circular reference

• flag can be set in BAPI header

*

• Further to this

• there are cases where there are many nomination Idocs

• entering the system,

• the nomination update calls the

• OIJU_RD_UPDATE_OBJ_ENTRIES function

• the related document update calls the same function

• this is normally not a problem as the V2 update will

• not intefere with the normal V1 update

• but in the case of multiple nomiantions, even when called

• synchronously, the V2 update from the first related doc\

• update is causing issues with the secon nomination V1 update

• deadlocks ensue

• therefore - setting the flag to '1' in the BAPI header will e

• ensure the related document update is called in the same task

• in cases = '1' the update is called from validation

• routine in order for message handling

CASE is_nom_header-zz_no_rel_upd.

WHEN space.

**>>> lock CT contracts to be updated in update task "SD1K952062

**--- exported in method DATABASE_UPDATE_PREPROCESSING

import ZOIJ_EVENT to ct_nom_event from memory id 'ZOIJCTLOCK'

.

delete ct_nom_event

where cre_name eq space

and updkz eq space.

**>>> field changes which also need to be updated

• into the related document (STO/PO/SO) will be

• updted into CT via the related doc i.e.

• BAPI update to STO/PO/SO

• other changes i.e. the event dates are updated

• directly from NOMI into the CT contract

• for those cases we need to lock the CT contract

• here

**>>> check how the CT contract needs to be updated

• Nothing changed = from NOMI directly

• Data changed = via related document

call function 'ZOIJ_CHECK_DATA_CHANGED'

EXPORTING nomtk = is_nom_header-nomtk

i_nomh = is_cd_oijnomh_new

i_nomi = lt_nomi

CHANGING chg_flag = chg_flag

EXCEPTIONS nothing_changed = 4

data_changed = 8

others = 12.

if sy-subrc eq 4 and

chg_flag is initial.

**--- direct update from NOMI if event dates have changed

• check if such changes and lock the CT contract

call function 'ZOIJ_LOCK_RELATED_CONTRACTS'

tables it_oijnomi = lt_nomi

it_oijne = ct_nom_event.

endif.

**<<< end

CALL FUNCTION 'ZOIJ_UPDATE_RELATED_DOCS' IN UPDATE TASK

EXPORTING

nomtk = is_nom_header-nomtk

mem_tab = mem_tab

i_nomh = is_cd_oijnomh_new

i_nomi = lt_nomi

TABLES

it_oijne = lt_oijne

EXCEPTIONS

error = 1

OTHERS = 2.

[christian_wohlfahrt]

Hi,

here the last FM should use an update task, that's not necessarily the place, where it is already in update task. But the parameter 'in update task' is ignored, when the coding is already in update task.

In the comments already problems with locking and circular references are mentioned - seems like there is another person, which knows a little bit more about it.

Otherwise you need an example and you have to find out, what causes the error in the update inside of ZOIJ_LOCK_RELATED_CONTRACTS.

[Former Member]

Hi Christian,

I have an example which I am debugging. The nomination still dumps but with a different message this time SAPSQL_ARRAY_INSERT_DUPREC. Which means there are duplicate records on a database table somewhere! Possibly the logon id I have been assigned causes a different dump message? There is only one nomination causing dumps, the rest are fine. Any ideas?

[Former Member]

Error was in contract.

[Former Member]

What was wrong with the contract?