Problem with employee dequeue

[former_member245847]

Hi,

In a customer report there is a sequence of function modules callings in the loop:

CALL FUNCTION 'BAPI_EMPLOYEE_ENQUEUE'

CALL FUNCTION 'HR_PSBUFFER_INITIALIZE'.

CALL FUNCTION 'HR_INFOTYPE_OPERATION'

CALL FUNCTION 'BAPI_EMPLOYEE_DEQUEUE'

We use the report to register data in infotypes 0014, 0015, 0267 etc from customer table, which is loaded from file in previous step. When registering different wage types on different days for one personnel number, we observe, that in some loop steps the fm BAPI_EMPLOYEE_ENQUEUE returns that employee number is still locked, in spite fm BAPI_EMPLOYEE_DEQUEUE was executed in previous step. In some cases it could happen that another user has locked the employee in meantime. But the problem is also on test or quality system, where it is impossible that another user locks the employee. The fm BAPI_EMPLOYEE_DEQUEUE does not return any return code or exception, because it is not filled at all, so I cannot be sure, that the personnel number is really unlocked.

The problem does not exist while debugging, that is with time delay. I have prepared test log in SM12 and I have noticed that in the next step of loop employee is locked when there is no locking code "DeqAll" in previous step (compare the attached file SM12.png and data for IT0015 DATA_IT0015.png - red lines are those with locked pernr error). I assume, that this action is initialized by fm BAPI_EMPLOYEE_DEQUEUE, but, as I mentioned above, there is no possibility to check return code, because it is not filled.

The report worked fine for 2 years, but 3-4 months ago it begun to fail constantly. I know how to improve the report to avoid error of locked employee. I want to find out what is the reason the lock remains after BAPI_EMPLOYEE_DEQUEUE. Any suggestion what possibly may I check?

Best regards,

Renata

[RaymondGiuseppi]

Did you check return-type in both BAPI_EMPLOYEE_ENQUEUE, HR_INFOTYPE_OPERATION and BAPI_EMPLOYEE_DEQUEUE?

Hint: HR_MAINTAIN_MASTERDATA and similar called FM will execute a COMMIT WORK without the WAIT option, so sometimes the update task will not be completed before the next Lock Request, only the current LUW lock will be released, no the update task. So consider using the NOCOMMIT parameter and then use a COMMIT WORK AND WAIT statement.

Regards,

Raymond

[raghug]

Raymond,

The synchronous COMMIT WORK AND WAIT does work a lot better than the standard aysnchronous COMMIT statement, but I found that eventually this also stops working when server and database loads are just right. I have just posted a blog ( ) about using the ENQUEUE function module to check and wait for locks to finish their DEQUEUE operation. So far, this method has not let me down.

I am not familiar with these HR functions enough to know if this can replace BAPI_EMPLOYEE_DEQUEUE or not. However adding another ENQUEUE_EPPRELE at the end - after the COMMIT WORK AND WAIT - with Mode 'U' or 'V' and a _WAIT = 'X' should help. It will check for lock collisions and wait when needed.

Hope this is useful.

Raghu

[former_member245847]

Raymond,

Your hint is the solution. Thanks for Your help.

Regards,

Renata