Hi experts,
I have a very strange situation and this might take a few passes to actually understand what I mean and what the problem is before any answers are forthcoming. Unless it's something simple, fingers crossed 😉
Consider the following 2 scenarios.
Call HR_MAINTAIN_MASTERDATA to delete a it2002 record from a web service.
Scenario 1.
A web service class is called directly to delete the 2002 attendance record
WEB_SERVICE_CLASS_DELETE -> CREATE CLASS INSTANCE OF REQUESTED DELETE -> DELETE METHOD PASSING DATA
The data passed gets to the delete call and calls HR_INFOTYPE_OPERATION like so:
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
EXPORTING
INFTY = '2002'
NUMBER = me->pernr
SUBTYPE = im_p2002-subty
VALIDITYEND = im_p2002-endda
VALIDITYBEGIN = im_p2002-begda
RECORD = im_p2002
RECORDNUMBER = im_p2002-seqnr
OPERATION = 'DEL'
NOCOMMIT = 'X'
IMPORTING
RETURN = ls_return.
Which in turn, calls HR_MAINTAIN_MASTERDATA which then calls HR_MAINTAIN_MASTERDATA in dialog mode:
Line (324) of HR_MAINTAIN_MASTERDATA
CALL DIALOG 'HR_MAINTAIN_MASTERDATA' using BDCDATA mode 'N'
EXPORTING
PSPAR
PROPOSED_VALUES
LUW_MOD
PS
PSINFO
PREFTAB
This works fine and never fails.
Scenario 2
A web service class is called directly to update some records and involves deleting the 2002 record attendance record before then creating a new record
WEB_SERVICE_CLASS_UPDATE -> CREATE CLASS INSTANCE OF REQUESTED UPDATE -> DELETE METHOD PASSING DATA
The data passed gets to the delete call and calls HR_INFOTYPE_OPERATION like so:
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
EXPORTING
INFTY = '2002'
NUMBER = me->pernr
SUBTYPE = im_p2002-subty
VALIDITYEND = im_p2002-endda
VALIDITYBEGIN = im_p2002-begda
RECORD = im_p2002
RECORDNUMBER = im_p2002-seqnr
OPERATION = 'DEL'
NOCOMMIT = 'X'
IMPORTING
RETURN = ls_return.
Which in turn, calls HR_MAINTAIN_MASTERDATA which then calls HR_MAINTAIN_MASTERDATA in dialog mode:
Line (324) of HR_MAINTAIN_MASTERDATA
CALL DIALOG 'HR_MAINTAIN_MASTERDATA' using BDCDATA mode 'N'
EXPORTING
PSPAR
PROPOSED_VALUES
LUW_MOD
PS
PSINFO
PREFTAB
This fails every time without no apparent reason.
Debugging takes me all the way to the line 324 of HR_MAINTAIN_MASTERDATA and the difference is, when stepping through the code, F5 step into the CALL DIALOG line fails without an error, the debugger simply bombs out.
When the operation works in Scenario 1 it works every time and stepping into the dialog call works fine.
I compared the data going into the dialog call and it is byte for byte identical, no difference in the data. The user matches and no auth errors occur.
With testing, I did something quite strange which shouldn't really be done, I populated the LOCKINDICATOR flag on the original creation of the it2002 record, doing that allowed the delete to work every time in EVERY single scenario I could test, but then payroll will fail to process properly so that isn't an option. The question is why, why if adding the LOCKINDICATOR flag does everything work fine yet remove it and the delete fails but ONLY in scenario 2, scenario 1 always works regardless.
In scenario 2, as I mentioned, the debugger literally bombs out on pressing step into, no errors, no warnings, just vanishes (and the delete never happens obviously).
I am guessing some clarification will be needed here, any ideas no matter how silly appreciated, if this can be understood then i would like to be able to!
Thanks,
Malcolm