Hi All,
We have a couple of lobby elements that are running from Live IAL’s and for some users they are timing out.
We have found restarting the IFS MW and DB fixes the issues for some users but not all, is anyone able to suggest how I could found or resolve the root cause of this issue? Thank you.
+30
Hi
Could you kindly attach a screenshot of the error that you encounter along with any other errors in written (on the time out issue). Exact error and screens would narrow down the scope of the analysis and would give a better background.
Also are the lobby elements created recently and have they never worked well for the specific set of users ?
Best Regards,
Yasas
Hi Yasas, thank you for replying.
We don’t really get an error message it just eventually times out and you get the X on the lobby element. If you hover over the element it just said ‘Operation timed out’.
We have been using the same lobby elements the last 2 years with no problems but just recently this has started happening. We moved from apps9 to apps10 back in July last year. Its strange how it is happening only on some users.
I have experienced it myself on my PC but after a reboot of the MW and DB it solved the issue for me.
Regards Nikki
What does the IAL look like? I’m assuming that it shows different data depending on the user who opens the lobby (judging by the element title). Could it be that the query fetches too much data for some, or uses some function calls that are not optimal?
This is correct it does bring back data depending on the user. I don’t think it is fetching too much data as we have other users who have more staff reporting to them and that is working ok.
This is the select statement I am running in my IAL:
SELECT cpa.assignment_seq_no, cpa.company_id, cpa.emp_no,
ifsapp.Company_Person_API.Get_Name (cpa.company_id, cpa.emp_no) emp_name,
cpa.pos_code, cpa.org_code, cpa.struct_bu_id,
ifsapp.Company_Job_API.Get_Job_Title (
cpa.company_id,
ifsapp.Emp_Job_Assign_API.Get_Job_Id (cpa.company_id, cpa.emp_no)
) job_title,
cpa.primary, cpa.valid_from, cpa.valid_to, cpa.altkey
FROM ifsapp.company_pers_assign cpa
Then within the element data source I am adding the following where clause:
EXISTS (
SELECT 1
FROM table(ifsapp.Mcl_Lobby_Util_API.Emp_Schedule_Access ('$SUBORDINATE$', '$COMPANY_ID$')) i
WHERE i.alt_key = lobby_pos_access.altkey
)
This is correct it does bring back data depending on the user. I don’t think it is fetching too much data as we have other users who have more staff reporting to them and that is working ok.
This is the select statement I am running in my IAL:
SELECT cpa.assignment_seq_no, cpa.company_id, cpa.emp_no,
ifsapp.Company_Person_API.Get_Name (cpa.company_id, cpa.emp_no) emp_name,
cpa.pos_code, cpa.org_code, cpa.struct_bu_id,
ifsapp.Company_Job_API.Get_Job_Title (
cpa.company_id,
ifsapp.Emp_Job_Assign_API.Get_Job_Id (cpa.company_id, cpa.emp_no)
) job_title,
cpa.primary, cpa.valid_from, cpa.valid_to, cpa.altkey
FROM ifsapp.company_pers_assign cpa
Then within the element data source I am adding the following where clause:
EXISTS (
SELECT 1
FROM table(ifsapp.Mcl_Lobby_Util_API.Emp_Schedule_Access ('$SUBORDINATE$', '$COMPANY_ID$')) i
WHERE i.alt_key = lobby_pos_access.altkey
)
Does it run OK if you remove the where clause? That’s a custom package you guys have created?
You can also test to do an IN instead of EXISTS to see if that is better. It depends on what the customized method does/returns and how much data you have:
lobby_pos_access.altkey IN
(SELECT i.alt_key
FROM table(ifsapp.Mcl_Lobby_Util_API.Emp_Schedule_Access('$SUBORDINATE$', '$COMPANY_ID$')) i)
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.