CX_HRPA_VIOLATED_PRECONDITION using HR_INFOTYPE_OPERATION to insert record

[Former Member]

I was trying to insert a record into IT0168 using HR_INFOTYPE_OPERATION and received this exception in a shortdump. I've no idea what it means. Any takers?

[Former Member]

hello

use HR_MAINTAIN_MASTERDATA

this function module work better than HR_INFOTYPE_OPERATION.

U can run this FM in display mode to check what is the exact probelm u are facing...

hope this will solve ur problem....

[Former Member]

Thanks.

According to the online documentation for this FM, although "the same validation checks take place as would in the individual maintenance screens for the infotypes" the developer is "responsible for making sure that the data is consistent". What does "consistent" mean and what does this translate into when programming using this FM?

Thanks.

[Sm1tje]

try to catch the exception and read the message from the exception object. Might give you additional info.

[Former Member]

The exact error is as follows:

The exception 'CX_HRPA_VIOLATED_PRECONDITION' was raised, but it was not caught               

     anywhere along                                                                                
the call hierarchy.                                                                                
Since exceptions represent error situations and this error was not                            

    adequately responded to, the running ABAP program                                             

     'CL_HRPA_INFOTYPE_FACTORY======CP' has to be                                                 

    terminated.

The error analysis is as follows:

An exception occurred that is explained in detail below.                                      

    The exception, which is assigned to class 'CX_HRPA_VIOLATED_PRECONDITION', was                

     not caught in                                                                                
procedure "INITIALIZE_PS_ADAPTER" "(FORM)", nor was it propagated by a RAISING                

     clause.                                                                                
Since the caller of the procedure could not have anticipated that the                         

    exception would occur, the current program is terminated.                                     

    The reason for the exception is:                                                              

    Precondition Violated

[Sm1tje]

That's the error message of the short dump. But the exception object probably has its own message which you should try and catch like this before you are calling subroutine function module or...

lr_error type ref to CX_HRPA_VIOLATED_PRECONDITION.

lv_message type string.

try

catch CX_HRPA_VIOLATED_PRECONDITION into lr_error.

lv_message = lr_error->get_message( ).

endtry.

[Former Member]

OK. Very strange. I put the code in place like this:

<code>

TRY.

CALL FUNCTION 'HR_INFOTYPE_OPERATION'

EXPORTING

infty = lc_infty

number = p_record_in-pernr

subtype = p_record_in-subty

validityend = p_record_in-endda

validitybegin = p_record_in-begda

record = p_record_in

operation = 'MOD'

tclas = 'A'

dialog_mode = '0'

nocommit = ''

IMPORTING

return = lstr_bapireturn

key = lstr_bapikey.

CATCH cx_hrpa_violated_precondition INTO lo_error.

lv_errmsg = 'Testin'.

ENDTRY.

</code>

And I still get a shortdump. This time, however, I ran the debugger from the shortdump screen and am seeing that the error is generated in a method called set_context of class CX_HRPA_INFOTYPE_FACTORY.

[Sm1tje]

is there any exception assigned to this method. If yes, try and catch this one as well.

[Former Member]

OK. I tried every exception I could find and nada - it still does a shortdump. Even the exception from "set_context".

TRY.
      CALL FUNCTION 'HR_INFOTYPE_OPERATION'
        EXPORTING
          infty         = lc_infty
          number        = p_record_in-pernr
          subtype       = p_record_in-subty
          validityend   = p_record_in-endda
          validitybegin = p_record_in-begda
          record        = p_record_in
          operation     = 'MOD'
          tclas         = 'A'
          dialog_mode   = '0'
          nocommit      = ''
        IMPORTING
          return        = lstr_bapireturn
          key           = lstr_bapikey.
    CATCH cx_hrpa_invalid_parameter INTO lo_error1.
      lv_errmsg = 'Testing'.
    CATCH cx_hrpa_violated_precondition INTO lo_error2.
      lv_errmsg = 'Testing'.
    CATCH cx_hrpa_violated_assertion INTO lo_error0.
      lv_errmsg = 'Testing'.
  ENDTRY.

[RichHeilman]

You can not catch exceptions like that, by simply wrapping the function module with a TRY... CATCH. The TRY..CATCH needs to be wrapped around the specific method in which it is being raised. It is too late to try to catch it at the function module call level.

Regards,

Rich Heilman

[Former Member]

OK. Well, I can't very well add that code to the SAP base code so I guess I'm just stuck.

I noticed that the when I put a breakpoint on the "set_context" method (below) after the third execution the program shortdumps.

FP50PE11

FORM initialize_ps_adapter.
...
	*cl_hrpa_infotype_factory=>set_context( cl_hrpa_infotype_factory=>context_legacy )*

[RichHeilman]

That's right.... so basically you need to find out why the exception is being raised in the first place, so the first thing is to debug, and find exactly where it is being raised, why it is being raised, and if there is something that you can do about it when calling your function, such as setting some parameter when calling the function. You can also do a where-used to see where else this function is used, and see how it is being called there and compare. Lastly, if you problem persists, I suggest opening an OSS note for your issue.

SAP Code = SAP's Problem

Right?

Regards,

Rich Heilman

[Former Member]

LOL. Good point. Thanks.

[Former Member]

In case anyone is still reading this I (sort of) found the issue. I found a spanish blog site searching for this error and I made out (my spanish is not so good) that there was a recommendation to use PNP instead of PNPCE (which I was using). So, I switched LDBs and voila - it worked.

Now i'm trying to figure out why.

Muchas gracias.

[Sm1tje]

Steve,

I was still watching this thread. Good to hear it is solved now.

BTW: sorry for the misunderstanding regarding catching the exception. I didn't read your reply too well, and overlooked the fact that you were using a FM and not a class (method from class).

[Former Member]

hi,

i Created RFC to Update (0006,0002) infotype.

I Used same function module HR_INFOTYPE_OPERATION in my

RFC to Update (0006,0002) infotype.

I used that RFC in Webdynpro ABAP. Im also Getting same error.

Plz help me, how to solve this problem. Its very urgent

Thanks,

Hemachandran.R

Edited by: hemachandran R on Oct 13, 2008 4:29 PM

Edited by: hemachandran R on Oct 13, 2008 4:29 PM

[Former Member]

Hi Steve,

I am still having issues on this one. I am a new ABAPER and not sure the following:

Is this a logic database?

Could you tell me how to use PNP instead of PNPCE? How to switch LDBs and voila?

Thanks for your help!

AS

[Former Member]

Look at SAP note : 716914 , 640328

These might be useful ...

[Former Member]

Hello

Not sure if this issue solution was posted anywhere or not, but I recently was getting the error and referred to some input given by others..

I added the following code in my program

*********************************************

*LOAD-OF-PROGRAM.

*********************************************

LOAD-OF-PROGRAM.

• an event to avoid a short dump due to CE framework

• refer to SAP NOTES: 0000611782 / 0000716914

PERFORM do_nothing(sapfp50p).

this seemed to avoid the reinitialization of the object and that worked for me.

Let me know if anyone had a better solution

Regards

Prasant

[Former Member]

Hello, I have the same problem than you using the HR_INFOTYPE_OPERATION function, I have try to use the differents solutions exposed in the post but it´s not working.

¿ Could anyone give me another idea ?

Thanks.

Antonio.

[former_member185795]

The trick is to ensure that the infotype factory class is not loaded more than once in a session. One option would be to execute the function module in a new task. This would ensure that the class CL_HRPA_INFOTYPE_FACTORY is not loaded more than once.

Thanks,

Anjan

[Former Member]

It's worked for me

[Former Member]

Incase the issue was not resolved. here is the answer. Just do what is said in the note

493984. and it works !!. if are using this FM in classes, just make sure that u do what is said in the note in the constructor or in the class-constructor.

Regards,

Raghavendra Prabhu

[Former Member]

I have faced the same problem while uploading Infotype 0009. This problem is because of CE switches mainly CCURE MAINS and CCURE PC_UI switches in T77S0.

If this switches are ON then make sure that any FM like HR_ECM_GET_HIRE_DATE should not be used in combination with HR_INFOTYPE_OPERATION. Recently there was a requrement
to get hire date and compare sy-datum with it . If Hire date is in current
month we are creating record from hire date other wise from starting of the
month.In this regard I am getting Hire date using one FM HR_ECM_GET_HIRE_DATE.

This FM is checking the switches
and instanciating the class CL_HRPA_INFOTYPE_FACTORY.

Again when I call HR_INFOTYPE_OPERATION or HR_PSBUFFER_INITIALIZE same is getting instanciated.So it is giving that dump saying CX_HRPA_VOILATED_PRECONDITION.

When replaced that FM HR_ECM_GET_HIRE_DATE with another FM RP_GET_HIRE_DATE.

I have tested when the switches
are ON.

[Former Member]

The problem is that FM HR_INFOTYPE_OPERATION is using the class CL_HRPA_MASTERDATA_FACTORY which is also used by other FMs like, for example, HR_PAD_HIRE_EMPLOYEE. However, the HR_PAD_HIRE_EMPLOYEE does not call forms in SAPFP50P, which actually makes the short dump because it assumes that it is being loaded only once. So, if we call HR_PAD_HIRE_EMPLOYEE then it sets the CONTEXT variable in the class and then calling HR_INFOTYPE_OPERATION or HR_MAINTAIN_MASTERDATA cause the short dump because CONTEXT is just set but it should not. If we first call the form DO_NOTHING(SAPFP50P) and then HR_PAD_HIRE_EMPLOYEE then other short dumps appear.

What I could recommend, that works for me, is like this. Set a break point in class constructor CL_HRPA_MASTERDATA_FACTORY - it is empty but is defined just to put breakpoints there. Also set a break point in CL_HRPA_INFOTYPE_FACTORY=>SET_CONTEXT. Run your report and observe what is calling the constructor before the SET_CONTEXT method is being called. In my case, it is HR_PAD_HIRE_EMPLOYEE. Then prepare another report and put there your function, here HR_PAD_HIRE_EMPLOYEE. Write a form and a selection screen so that you can provide parameters for the function. In your original report instead of calling the function call the report using SUBMIT ... AND RETURN. If you need some return values use EXPORT ... TO MEMORY and IMPORT ... FROM MEMORY. In this way both functions are called in different sessions and do not make short dumps with each other.

It should work also if you put HR_INFOTYPE_OPERATION in a separate report and call it with SUBMIT. Please, write a comment if anyone tests it.

I hope it helps you to some extend.

[Former Member]

Thanks Pradeep!!

your resolution helped n saved my time from debugging the SAP code...

[sreekanthreddy_bommu]

I had had a similar issue when trying to call HR_PAD_HIRE_EMPLOYEE FM and BAPI_BASICPAY_CHANGE BAPI in the same program. So, I had had to make a tweak in my program to make it work.

REPORT zsree.

CALL FUNCTION 'HR_PAD_HIRE_EMPLOYEE'

IF successful,

SUBMIT zsree0 AND RETURN.

___________________________________________________________

REPORT zsree0.

CALL FUNCTION 'BAPI_BASICPAY_CREATE'

The above code works perfectly fine without any runtime error.

Thanks for your input Roman Pozarlik!