Wadaco and BrowseLicenseFile service problem

If this customer have a lot of finished Data Capture Sessions it might be good to remove them by activating the Task Remove Data Capture Sessions, see example here 

Maybe that can help the performance when calling the license method since it checks for active sessions.

I cannot say that I have heard about issues like this before. 

The methods you mention are connected to the License framework that we are using in wadaco.
They have been prone to be sensitive to issues with extended server or PL/SQL Access provider (see link below about license issues).

If the license check hangs it almost sounds like a table lock on one of the session tables. There have been some rare cases of table locks on the session tables but they have been very hard to re-create. I have some vague memory of lock issues connected to Windows Mobile framework that caused issues in wadaco, but that was a long time ago, it should have been fixed if you are on IFS9 UPD17.

If its Apps9 I'm not sure if it can have any connection to the Oracle RAC issues for Apps10 that is mentioned in these 2 links before:

https://community.ifs.com/technology-infrastructure-cloud-integration-dev-tools-50/wadaco-not-failing-over-even-though-ifs-does-with-oracle-rac-4654

https://community.ifs.com/products-manufacturing-products-engineering-wadaco-40/warehouse-data-collection-rac-time-sync-6463

Then we have this collection of tips for all licenses are in use issues:

https://community.ifs.com/ifs-supply-chain-employees-partners-only-105/wadaco-all-warehouse-data-collection-licenses-are-in-use-error-7172

I'm guessing this customer is not having several users with the same oracle user trying to access wadaco at the same time?  Not sure if that would cause a table lock, but it could be possible maybe.

How many licenses do they have and how many users are running wadaco when this happens? 
Are they perhaps using the Prioritized Users functionality? 
Having too many prioritized users might cause problems since they will park other users sessions all the time.

Adding this link here also since it might be connected a bit.

Hi again,

Ok. So the main problem is still connected to the license check according to your findings? There are no table locks in the session tables when this happens or anything like that? I would guess that table locks on the session table could affect the license check since it checks for number of active sessions to compare that to number of licenses the customer have.

There is no other more generic or specific performance issues you or the customer have noticed?  Like some LOV is slow to open or some process execution takes a very long time.

Thanks for the findings in Get_Latest_Data_Item_Settings by the way, small changes like that always helps.

Does this customer have any customer adapted/created processes? The only similar case I have heard was with a customer that had a couple of processes not made by us, that did a lot extra stuff during the execution phase of the process that could sometimes cause time outs in the mobile clients, during peak hours during a couple of peak days every year. So the only thing that could be done there is change how does processes work and try and trim the execution to be faster or they have to run the execution as a background job instead (its a feature introduced in Apps10 Update8 or something like that).

When did this problem start, already since the first installation or did it work fine in the beginning and have been a gradual problem that appears more and more often? Or did it appear after some specific upgrade/patch?

The thing with 4 mln records in session line table feels a bit too much, have they tried to run the clean up job more often?

How many users/licenses are we talking about here for this customer?

Are they using the prioritized user functionality? Since that is triggered during the license check and parks users that are not on that prio-list, so maybe that could add some extra time to the license check that could explain while its only some checks that takes extra long time.

Hi Dario Zani

I prepared below procedure as o copy of license check using by wadaco.
Then I noticed that when I open new test window in PLSQL Developer first every launch of anonymous block on IFSAPP account BEGIN Get_Custom_License_Info(); END;
takes about 20-60 seconds. It waits on:
  Plsqlap_Server_API.Invoke_Record_Impersonate('BrowseLicenseFile', 'GetCustomLicense', record_);

My conclusion is that there are no any table lock in session tables.
Customer is using AD authentication so maybe here is the problem. As I know Invoke_Record_Impersonate procedure is using IFSPLSQLAP user for authentication. I have got confirmation that this user is not used in AD confirmation.
I heard beside this application firstly tring find this user on LDAP server and this could take much time.

Max capture_session_id = 4 630 831

CREATE OR REPLACE PROCEDURE Get_Custom_License_Info IS
  license_name_     VARCHAR2(200);
  number_of_users_  NUMBER;
  usage_view_       VARCHAR2(200) := 'ACTIVE_DATA_CAPTURE_SESSIONS';
  record_ Plsqlap_Record_API.type_record_;
BEGIN
  dbms_output.put_line('1. '||to_char(sysdate, 'hh24:mi:ss'));
  record_ := Plsqlap_Record_API.New_record('CUSTOM_LICENSE');
--
  dbms_output.put_line('2. '||to_char(sysdate, 'hh24:mi:ss'));
  Plsqlap_Record_API.Set_Value(record_, 'VIEW',  usage_view_, Plsqlap_Record_API.dt_Text_Key, FALSE);
--
  dbms_output.put_line('3. '||to_char(sysdate, 'hh24:mi:ss')||' - '||record_.Name_||' - '||record_.buffer_);
  Plsqlap_Server_API.Invoke_Record_Impersonate('BrowseLicenseFile', 'GetCustomLicense', record_);
--
  dbms_output.put_line('4. '||to_char(sysdate, 'hh24:mi:ss'));
  license_name_    := Plsqlap_Record_API.Get_Value(record_, 'NAME');
  dbms_output.put_line('5. '||to_char(sysdate, 'hh24:mi:ss')||' - '||license_name_);
--  
  number_of_users_ := Plsqlap_Record_API.Get_Value(record_, 'NUMBER_OF_USERS');
  dbms_output.put_line('6. '||to_char(sysdate, 'hh24:mi:ss')||' - '||number_of_users_);
END Get_Custom_License_Info;

Best Regards
Piotr