ISR_PROCESS_EVENT assert fails

[Former Member]

I'm trying to call ISR_PROCESS_EVENT as an RFC, passing in the data for a form, and trying to validate the fields. To do this i first call ISR_PROCESS_EVENT with mode "CREATE" and get back the fields I need. So far so good.

Later, I call the same RFC, this time passing in parameters mode = "CREATE" and event = "CHECK". When calling the RFC this second time i get an assert failed error in the code pasted below.

Is it a requirement that the "check" variation must be called from the same abap session as the initial create call? I ask this because I've been able to make it work if i write a custom function module which calls first ISR_PROCESS_EVENT CREATE with event space and then immediately call ISR_PROCESS_EVENT CREATE CHECK int he same RFC, but with the same input tables it fails if called separately. My only working assumption at this point is that it relies on the function to be initialized with CREATE first in the same session, and since I'm doing this via RFC call in two steps, this isn't the case.

Please help!

The "data_containers" are initial in class CL_IM_HRASR00ISR=>GET_PROCESS_OBJECT_HANDLER

• Get all data containers from all scenarios

IF data_containers IS REQUESTED.

CALL METHOD process_object_handler->get_all_data_containers

EXPORTING

message_handler = message_handler

IMPORTING

data_containers = data_containers_xml

is_ok = is_ok.

IF is_ok EQ false.

EXIT.

ENDIF.

LOOP AT data_containers_xml INTO data_container_xml.

• Create a new data container if XML is not empty

• (This happens if the BAdI is called from the glue step)

IF data_container_xml-data_container IS NOT INITIAL.

CREATE OBJECT data_container

EXPORTING

xml = data_container_xml-data_container.

APPEND data_container TO data_containers.

data_container_pair-data_container = data_container.

data_container_pair-data_container_xml = data_container_xml

APPEND data_container_pair TO data_container_pairs.

ENDIF.

ENDLOOP.

ASSERT data_containers IS NOT INITIAL.

ENDIF.

Edited by: Chris Hesse on Jun 30, 2010 8:13 PM

Edited by: Chris Hesse on Jun 30, 2010 8:14 PM

[Matt_Fraser]

We're having a similar issue, not quite identical, after upgrading from EhP3 to EhP4 with a form we developed. Upon 'submit' of the form we are getting an ASSERTION_FAILED short dump in CL_IM_HRASR00ISR in method GET_EXTERNAL_DATA_VALUE. I'm not entirely certain, but I think the failure is due to the ASSERT statement not being assigned any checkpoint group. I'm still troubleshooting the issue, but it seemed similar enough to your problem that I thought I'd piggyback on your thread in case any answers you get might be applicable to me, too. Hope you don't mind. The form worked without errors prior to upgrade (i.e., it still works in production, as the upgrade is only in DEV and QA at this point).

Thanks and regards,

Matt

[Former Member]

We are also on Ehp4, although I never tried this before this version.

I have also reproduced this behavior on a standard SAP scenario, STN1. I have an open customer message, but no progress so far.

[Matt_Fraser]

Chris,

I have resolved the issue in our system, so maybe the same resolution will work for you. The answer is in Note [1440741|http://service.sap.com/sap/support/notes/1440741]. In our system we are on HR SP 23, which contains all the code corrections from earlier versions of this Note, but does not contain the manual corrections described (essentially creating the characteristic or data type for ASYNC_BACKGROUND_SAVE). I just had to set up the characteristic as described and our form now submits just fine. I found this only by running the ABAP debugger on Method GET_EXTERNAL_DATA_VALUE of Class CL_IM_HRASR00ISR with a breakpoint set on the line "ASSERT sy-subrc EQ 0." I just stepped through until I saw the return code turn to something other than 0, and made a note that it was looking for a fieldvalue of ASYNC_BACKGROUND_SAVE. A search of Notes for this fieldvalue turned up 1440741, and that appears to have resolved the problem. The problem was not so much with the form itself, but with the asynchronous background save in the workflow step.

Hope this helps you!

--Matt