Skip to main content

Does anyone have a suggestion on how we can track who and when lobbies are being used in apps 10? Or course we can create an API with a get-function that updates a history table when called, but I wonder if anyone came up with something more elegant or had a discussion with IFS on this?

One of the recent updates enables this for quick reports and this is a great tool which can help us identify which reports are important and which could be phased out (we have 2000 reports build over many years). 

@TERKRTI 
Although IFS reporting framework provided the functionality in APPs10 to track the quick reports usage, similar option for lobbies are not yet available in IFS Application.   

Lobby is all about presentation of information in simple, focused and comprehensible manner to end users. Until now there is no option to track who loaded which lobby page or which timestamp a lobby is loaded. 

Lobbies contain not only the data sources, but also the element designers. If you need to track lobby pages you may have to develop that functionality from the scratch to monitor the usage of composite pages. Most probably you may need to do changes to IFS lobby framework. 

Apart from that, I would not think that there is an easy way to achieve your requirement.


Thanks for your reply.

Until Apps 10 Quick reports where our best way to do “presentation of information in simple, focused and comprehensible manner to end users”. Since we now have a better tool for that which seems to be much better for driving end user behaviour we hope to see usage tracking in an update.

We are getting this question from our business managers when we have made lobby pages “Are my employees using it?”


EDIT: Only just read your comment

Or course we can create an API with a get-function that updates a history table when called, but I wonder if anyone came up with something more elegant or had a discussion with IFS on this?

But I will leave it here in case any other user finds it useful

 

Here is a customisation you could do in order to achieve this

 

Step 1:

Create a custom logical unit with 3 attributes (Count, Lobby and User)

 

 

Step 2:

Create a custom API with the following code:

CREATE OR REPLACE PACKAGE LOBBY_LOGGING_API IS

FUNCTION Log_Lobby(lobbyName_ VARCHAR2, userName_ VARCHAR2) RETURN VARCHAR2;

END LOBBY_LOGGING_API;
CREATE OR REPLACE PACKAGE BODY LOBBY_LOGGING_API IS

FUNCTION Log_Lobby(lobbyName_ VARCHAR2, userName_ VARCHAR2) RETURN VARCHAR2 IS

PRAGMA AUTONOMOUS_TRANSACTION;

info_ VARCHAR2(32000);
attr_ VARCHAR2(32000);
objversion_ VARCHAR2(2000);
objkey_ VARCHAR2(50);
count_ NUMBER;

BEGIN

SELECT a.objkey, a.objversion, a.CF$_COUNT into objkey_, objversion_, count_
FROM IFSAPP.LOG_LOBBY_CLV a
WHERE a.CF$_LOBBY = lobbyName_
and a.CF$_USER = userName_;

Client_SYS.Clear_Attr(attr_);
Client_SYS.Add_To_Attr('CF$_COUNT',count_+1,attr_);
IFSAPP.LOG_LOBBY_CLP.Modify__(info_,objkey_,objversion_,attr_,'DO');

COMMIT;

RETURN 'LOGGED';

EXCEPTION
WHEN no_data_found THEN

Client_SYS.Clear_Attr(attr_);
Client_SYS.Add_To_Attr('CF$_LOBBY',lobbyName_,attr_);
Client_SYS.Add_To_Attr('CF$_USER',userName_,attr_);
Client_SYS.Add_To_Attr('CF$_COUNT',1,attr_);
IFSAPP.LOG_LOBBY_CLP.New__(info_,objkey_,objversion_,attr_,'DO');

COMMIT;

RETURN 'LOGGED';

END Log_Lobby;

END LOBBY_LOGGING_API;

 

Step 3: Create a data source

 

Step 4: Create the element

 

Step 5: Place the element in your lobby to show the user their usage count (Note it will only show the user their usage - not every user)

 

 

Step 6: Run SQL query/create a report to show count per user

 

 

 

A few things to note:

  1. If you refresh the page the count will go up (So a user could spam the refresh button to see the count go up)
  2. If you didn’t want to display the count element then you could actually use the API call in an existing lobby data source (Just add IFSAPP.LOBBY_LOGGING_API.Log_Lobby('WarehouseLobby',IFSAPP.FND_SESSION_API.Get_Fnd_User()) = 'LOGGED' to the condition of an existing datasource) - but make sure that datasource isn’t being used by more than one element/lobby
  3.  If the Auto Refresh tickbox is selected on the element then that will also increase the count - (also the same on the lobby page Auto refresh) - So this logging wouldn’t really be useful for those types of lobbies

Some ideas to add to the above…

I don’t have any details, but if you add some unique dummy query + element on each lobby (like “SELECT 'Lobby1' FROM dual”), you should be able to check in Oracle on regular intervals if that query has been executed, and get some kind of idea about the usage.

Another idea, which I am not sure about, would be to check the access logs on the web/application server and see if each lobby access can be seen there. A job for a technician/DBA or similar role, of course.


Some ideas to add to the above…

I don’t have any details, but if you add some unique dummy query + element on each lobby (like “SELECT 'Lobby1' FROM dual”), you should be able to check in Oracle on regular intervals if that query has been executed, and get some kind of idea about the usage.

Another idea, which I am not sure about, would be to check the access logs on the web/application server and see if each lobby access can be seen there. A job for a technician/DBA or similar role, of course.

Update: You CAN see the lobby requests in the access logs. In them you can see something like this:

POST /main/default/plsqlgateway/AccessPlsql/Invoke?Lobby_Refresh_ds=Aurena%20Projects%20-%20Expected%20Shop%20Orders_page=c4e8c8d3-a0b3-4e93-a9f0-7da210294c68

Above, I think the last cryptic ID is the lobby ID, but I am not 100% sure.


We are getting this question from our business managers when we have made lobby pages “Are my employees using it?”


What about adding the specific lobby page to their home screen?

Users will definitely see that when they login to the application. But for this to be applicable, there should be only a one lobby page which presents important information to end users.. 

 


Reply