cancel
Showing results for 
Search instead for 
Did you mean: 

HR: "secure" direct update of infofypes?

Former Member
0 Kudos

Hi

I have some performace issues regarding Batch Input of HR-infotypes. Does anyones know of at good why to speed up performance (direct update) without compromising the screen validations? I have heard of HR_INFOTYPE_OPERATION - is this the answer to my problems? Any other ideas are more than welcome.

Thanks in advance

Peter Michael

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi,

Harald is correct. I am successfully using this to create/update and delete info type 2003.

This ensure the change log is also updated at the sam time as if you were doing a call transaction.

If you need a snippet of code as an example then let me know and I will post a bit for you.

Cheers

Colin.

Former Member
0 Kudos

I would really be glad for any code-snips concerning this issue.

Thanks

Peter

Former Member
0 Kudos

Hi Peter,

Seems HR_INFOTYPE_OPERATION is the way to go for master data employees and applicants. Read the documentation.

The only other way to update record secure is via batch input. Note if you're mass updating records you may be able to run several BIM sessions at once.

What is the exact problem?

Best Regards,

Harald Kastelijn

Former Member
0 Kudos

We have a SAP-system that continuosly must be able to receive a huge number of HR-infotypes (IDOC'S). Even when using several BIM's will not do the tast on time. A Batch Input typically takes 0,5 sec pr. infotype og we should be able to update/insert much more than 2 IT/sec.

/Peterr

Former Member
0 Kudos

I am back at work tomorrow so will post somme code for you then.

Word of advice - when this function is first called in the session it seems to be run slowly but everything is buffered in memory after that so it gets a lot quicker.

Cheers

Colin.

Former Member
0 Kudos

If you find this too slow for you needs, I have something else you can try.

Still using the function, I have some code that allows parallel processing within the same program so this will mean you will be processing a number of infotypes at once.

The code is clever enough to work out the number of dialog processes free on an app server and use as many as you specify. You will need to run this past yor Basis team as they may not be happy running this way in a productive environment. Does this sounds of interest to you because I will post code for this as well.

Cheers

Colin.

Former Member
0 Kudos

Hi again Collin

I would be very glad to see what you have got. It sound like something I could use perhaps overnight when we sometimes convert huge amount of data.

Thanks in advance

Peter

ssimsekler
Active Contributor
0 Kudos

Hi to all

Here is an example for the function module "HR_INFOTYPE_OPERATION". But I am curious about the program Colin has told about.

DATA ls_data LIKE p0015 .

DATA ls_return LIKE bapireturn1 .

<i>*--Fill "ls_data" as required here

*- Be careful about the checks that will be done during

  • execution of the function module. The checks it will

*do, will be more or less like when you insert the

*record using the tcode "PA30". e.g. you must fill

*obligatory fields</i>

CALL FUNCTION 'ENQUEUE_EPPRELE'

EXPORTING

mode_prel = 'E'

mandt = sy-mandt

pernr = ls_data-pernr

infty = '0015'

subty = '1650'

endda = ls_data-endda

begda = ls_data-begda

_scope = '1'

EXCEPTIONS

foreign_lock = 1

system_failure = 2

OTHERS = 3.

IF sy-subrc NE 0 .

*...

EXIT.

ENDIF.

CALL FUNCTION 'HR_INFOTYPE_OPERATION'

EXPORTING

infty = '0015'

number = ls_data-pernr

subtype = ls_data-subty

validityend = ls_data-endda

validitybegin = ls_data-begda

record = ls_data

operation = 'INS'

tclas = 'A'

nocommit = space

IMPORTING

return = ls_return .

CALL FUNCTION 'DEQUEUE_EPPRELE'

EXPORTING

mode_prel = 'E'

mandt = sy-mandt

pernr = ls_data-pernr

infty = '0015'

subty = '1650'

endda = ls_data-endda

begda = ls_data-begda.

<u>Some Basics:</u>

i. You may wonder why I locked the personel but as far as I remember, there is a problem in the FM "HR_INFOTYPE_OPERATION" about this. Locking the personel overcomes the problem. But it may have been solved. So, if you want first try without locking.

ii. The FM calls the dialog module for the program MPXXXX00 (XXXX: Infotype number, here MP001500) of the infotype.

iii. "ls_data" which is passed to the parameter "record" should be type "PXXXX" (here P0015).

iv. If the infotype has subtypes, pass the subtype you want ( in our case 1650) to the parameter "subtype" .

v. You must give the validity period to the parameters "validityend" and "validitybegin".

vi. The operation type you need is "INS" if you want to insert an infotype record. You can see other values from the fixed values of the domain of the parameter "operation".

vii. Since some infotypes are common for both employee an applicants data, you should pass 'A' to the parameter "tclas". This way the record is inserted to the table PAXXXX. In case of 'B', it behaves your record as to be an applicant data.

viii. You have the option to force the FM not to commit at the end.

ix. The exporting parameter "return" of the FM is of type "BAPIRETURN1". That is, it can be used like other BAPI returns. You can analyze the result of the execution from this table.

Former Member
0 Kudos

And here is the code to satisfy everyone's curiosity to allow parallel processing within the same program to use any available dialog processes :

Use function <b>TH_GET_WPINFO</b> to get number of dialog processes available on application server

<i>The number of free dialog processes have wp_itype = '1' and wp_istatus = '2'.</i>

Set up a constant for the maximum number of processes you wish to use (try 5 as a starter)

Finally,

<b>Create a wrapper function</b> that calls HR_INFOTYPE_OPERATION provding the same parameters etc that are needed by the SAP standard funcction

Call the wrapper function as follows in a loop of processing your IDOCS:

<i>Increment a job counter by 1 for each call. This will be used at the end to check everything has completed ok.</i>

<b>CALL FUNCTION 'WRAPPER_FUNCTION'

STARTING NEW TASK w_name (w_name = unique name for each call)

DESTINATION NONE

PERFORMING CAPTURE_RESULT ON END OF TASK</b>

with all of your import/export parameters as well.....

After this function call check the return code. If SY-SUBRC EQ 0 then the parallel process creation worked ok and so increment an active sessions counter by one.

To control the number of active jobs add the statement

<b>WAIT UNTIL ACTIVE_COUNTER LT MAX_SESSIONS</b> you defined earlier

This is all the code you need to add in your loop of IDOCS

You will need to create a <b>FORM CAPTURE_RESULT</b> to capture your data back from the function call as follows :

To receive the data back from the aRFC call add the statement:

<b>RECEIVE RESULTS FROM FUNCTION 'WRAPPER_FUNCTION'</b> (do not forget to add the export and tables parameter of the function to capture the data)

You will now be able to process the detail passed back from the function.

In this form, also remember to increment a COMPLETED counter by 1 and reduce the ACTIVE counter by 1

Finally, when out of your loop process, add the following statement

wait until COMPLETED >= JOB_COUNTER.

When I have used this method, I have noticed a 5x improvement on runtime. Just be careful you do not run this at peak times because this uses dialog processes up so only really use overnight but this will work for you by the sounds of your issue. Also you will look like a superstar if it improves your throughput.

Having said that, this is quite involved so if you have any issues, let me know ....

Happy coding.

Cheers

colin.

Former Member
0 Kudos

I am calling HR_INFOTYPE_OPERATION in a function module that is triggered by a workflow event. When the HR_MAINTAIN_MASTER_DATA dialog is called I am getting a return code of 1001 with error number 344. I think this is because the pernr is still locked by the user that triggered the workflow event. Is there a way to make this function pause until the pernr is unlocked?

Thanks,

Ken Gray