Leave request - response time

Hi group,

We are experiencing a very long response time both for opening leave request application and for sending a leave request. We notice that the application reads eg HRP1001 several times. This I guess we cannot do anything about. However, since we see that response time is increasingly getting worse, I wonder if there is some house-keeping that we should do?

We have run the LEA application in ERP6/EHP4 since april 2010, and in EHP5 since march 2012.

Any hints are appreciated

Kirsten

SAP Managed Tags:
HCM Employee Self-Service

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (0)

Answers (1)

which version of leave request you are using? i thought you are already on WD ABAP ?

Did you arvchive some of the leave request tables?

opening the application from portal?

st12 trace would be helpful, it should be apart from hrp1001.

please let us know

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Siddharth,

Yes - we are on 6.05 WDA.

No - we have not archieced the leave request tables, and I suspect this is part of the problem (since you now indicate that there is an archive mechanism).

Before I to the trace - could you please tell me how we archive the Leave request tables?

Thanks

Kirsten

there is no archiving still for these tables, you can just delete the data using rptarqdbdel for very old leave requests which you dont need it

check size of these tables PA2001 and PTQUODED

so a trace would nail down the issue, where most time is spent

Thanks, Siddharth.

I don't think we can delete these data, as our accounting could ask for documentation behind leaves for many years. I checked one of our production clients:

PA2001 -> 539.338 records
PTQUOEDED -> 2.009.370 records

I will do trace later on.

oh entries are not that large, its fine. It shouldnt hinder performance, there might be wrong indexes on these tables?

I ll await the trace results. maybe you can paste it here.

Must admit I have never used ST12 before. Is it OK to start this in production when I give a username - it won't affect any other aspects of production? I assume I should run the performance trace, not the ABAP trace?

I ran a trace in test where response time is also slow. I paste the images of top consumers for opening and sending. Don't know if this is enough to give a hint or if you need me to run in production and then give you more of the trace-file?

Thanks for valuable help, Siddharth.

Opening

Sending

Message was edited by: Kirsten B

I checked our indexes. They are the ones that are set by SAP (standard).

PTREQ_ATTABSDATA

MANDT INFOTYPE PERNR SUBTY BEGDA

PTQUOEDED (3 indexes)

DOCNR DATUM
PERNR DATUM
QUONR DATUM

From the trace I wonder if PTQUOEDED should have an index with MANDT PERNR, or maybe include MANDT in the index PERNR DATUM. If so - I wonder why SAP hasn't suggested these indexes as standard?

I would really appreciate your thought on this, Siddharth (or others).

Best regards, Kirsten

sorry for the later reply

clearly in the traces I see these tables.

we need to check two types of traces abap and performance.

In ABAP trace, you ll see major time on RFC and here is the issue which needs to be rectified as this is major time.

You need to raise a OSS ticket and allow us to access system to identify root cause of time lag here. We can do a holistic check on it, raise it for SV BO performance team and they would need this trace.

Now for indexes we have this note 1330997 , check here

Select the index with the ID PIT

This is what we delivered.

Thank you Siddharth,

I have raised an OSS. They are investigating testsystem right now but I think they need to move to Production where the response time is considerably worse. I hope the OSS will give result. We have some fairly frustraded users amongst Our 60.000 portal-users.

definitely I think you should provide production access then if you think performance is slower there

Just give them the traces and we ll investigate further.

its not good when 60 K employees suffer ;0

SAP is investigating now via my OSS-ticket. (You can probably see the ticket). I have asked the handler if he needs more information/access. There seems to be a significance regarding how many records exsist in PA2001. Thanks for all your valuable input. We sincerely hope there will be a fix here - as you say, it's not good to have 60 K dissatisfied employees/customers.

pa2001 plays a significance as seen from the trace, and also pa2006, ptquoded.

We ll check in the blop if anything can be improved here

IF_EX_PT_ABS_REQ~SIMULATE_VIA_BLOP.

SAPLHRTIM00_TMWBUFFER

we ll update you in the message

PS :

Also, We had given this change earlier, you can try this in your test system

NOTE THIS IS A modification

Older leave requests pose issue when they are not in posted and

in other status.

The issue comes from
function module HR_BLP_MAINTAIN_TIMEDATA;

When you create an absence with quota deduction in PA30
all future dated absence records will be untouched. Within transaction
PTMW (and also ESS Leave Request) all future dated absences will be
rolled back and processed internally again chronologically. The only possibility
is to introduce a small modification in your system. In the method
GET_FUTURE_RECORDS of class CL_PT_BLP_ITATTABS you could do the
following change:

*selto = cl_pt_tmw_const=>high_date. < DELETE
selto = irec-endda. < INSERT

This should solve the performance issue in your system

Hope this helps

Hi Siddharth,

At first thanks for your good reply.

I am an ABAP and know not much about the HR module.

The situation is in our portal sap system, it is really slow when user approving leave request.

And I have some questions for BADI "pt_abs_req" class interface "CL_PT_ARQ_REQ_EXIT" method "IF_EX_PT_ABS_REQ~SIMULATE_VIA_BLOP."

the worst performance place are line 98~104.

*---Call BLoP to fill TMW buffer and - if requested - add messages to message handler

CALL METHOD CL_PT_ARQ_BADI=>BLOP_MAINTAIN_TIMEDATA

EXPORTING

IM_CHECK_MODE = SPACE

IM_COLLECT_MESSAGES = IM_COLLECT_MESSAGES

CHANGING

CH_BLOP_TAB = LT_BLOP_TAB.

Questions:

1. Is there any way that we can know whether the user are [approving] leave request or [creating] leave request by portal? Because I commented the line 98~104 and it is run very fast when approving, but no more error check when user creating leave request.

2. I searched the notes but did not find some note about the code change.

So do I need the SAP change object key to do this?


Siddharth Rajora wrote:

pa2001 plays a significance as seen from the trace, and also pa2006, ptquoded.
We ll check in the blop if anything can be improved here

IF_EX_PT_ABS_REQ~SIMULATE_VIA_BLOP.
SAPLHRTIM00_TMWBUFFER
we ll update you in the message

PS :

Also, We had given this change earlier, you can try this in your test system
NOTE THIS IS A modification

Older leave requests pose issue when they are not in posted and
in other status.
The issue comes from
function module HR_BLP_MAINTAIN_TIMEDATA;
When you create an absence with quota deduction in PA30
all future dated absence records will be untouched. Within transaction
PTMW (and also ESS Leave Request) all future dated absences will be
rolled back and processed internally again chronologically.  The only possibility 
is to introduce a small modification in your system. In the method
GET_FUTURE_RECORDS of class CL_PT_BLP_ITATTABS you could do the
following change:
*selto   = cl_pt_tmw_const=>high_date.                      <   DELETE
selto   = irec-endda.                                       <   INSERT

This should solve the performance issue in your system

Hope this helps

Regards

Feiyun

Ask a Question

Top Q&A Solution Author

User

Count