weblike wrote
Testing this further:
Disabled the SP_process (no Stored Procedure to load when VP is called).
Left menu-> "Dashboard" button-> as process "DISPLAY Perspective 'AdminDashboard' -->loading time aprox 8-9 seconds.
Left menu ->"Dashboard" button -> as HomePage -> loading time 2-3 seconds.
hmmm....
One of the challenges with using the LIRU is that if you have large objects attached to it there have been reports that it becomes slow to use, especially when the BO that are attached have rules being triggered through cross references - look at your log and check for unexpected rules being triggered on BO that you wouldn't expect when you are running your dashboard.
When creating dashboards I have taken the approach of creating a grid of custom queries that use EXEC_SP and return their results to a BO that is created specifically for receiving number based items (SP_Count BO).
My queries look like:
EXEC_SP 'CON_GetItemCount' WITH '@TenantID'=LoggedInRegularUser.ob_Tenant.ID RETURN SP_Count
The @TenantID is because I am using a multi tenant environment.
The SP_Count BO has four attributes as I have worked out that my dashboard queries pick up a maximum of four results, you could increase this as you need. The attributes are SPCount1, SPCount2 etc. Going down this route you will need to populate BASVERSION, BASTIMESTAMP and ID in order for AIM to accept the BO.
This negates the need to manage OUT variables as this is all handled within the SP
CREATE DEFINER=`awareserver`@`%` PROCEDURE `CON_GetItemCount`(IN TenantID INT)
BEGIN
SELECT
1 AS `BASVERSION`,
CURRENT_TIMESTAMP AS `BASTIMESTAMP`,
1 AS `ID`,
(SELECT COUNT( `CONTACT`.`ID` )
FROM `REF_CONTACT_ROLESUBCLASS`
RIGHT OUTER JOIN `CONTACT` ON `REF_CONTACT_ROLESUBCLASS`.`ID` = `CONTACT`.`ps_RoleSubClass_RID`
WHERE ( `REF_CONTACT_ROLESUBCLASS`.`Code` = 1110 ) AND ( `CONTACT`.`ob_Tenant_RID` = TenantID )) AS `SPCount1`,
(SELECT COUNT( `CONTACT`.`ID` )
FROM `REF_CONTACT_ROLESUBCLASS`
RIGHT OUTER JOIN `CONTACT` ON `REF_CONTACT_ROLESUBCLASS`.`ID` = `CONTACT`.`ps_RoleSubClass_RID`
WHERE ( `REF_CONTACT_ROLESUBCLASS`.`Code` = 1110 ) AND ( `CONTACT`.`q_Proprietor` = 1 ) AND ( `CONTACT`.`ob_Tenant_RID` = TenantID )) AS `SPCount2`,
(SELECT COUNT( `CONTACT`.`ID` )
FROM `REF_CONTACT_ROLESUBCLASS`
RIGHT OUTER JOIN `CONTACT` ON `REF_CONTACT_ROLESUBCLASS`.`ID` = `CONTACT`.`ps_RoleSubClass_RID`
WHERE ( `REF_CONTACT_ROLESUBCLASS`.`Code` = 1210 )AND ( `CONTACT`.`ob_Tenant_RID` = TenantID )) AS `SPCount3`
;
END
This is a query that looks for a specific type of Contact record then different classes within that type but the relevant point is that it is returning an object for the purposes of AIM by building up the attributes of the BO in AIM and when the EXEC_SP runs it is formalising this by saying 'stick the results from this SP into a BO that looks like this.' and because all the attributes have been defined in the SP it works.
You could use any other BO that exists in your BSV, but be mindful of the implications of using these BO - do they have references, do they have rules that may try to trigger.
I tend to avoid using the LIRU to store anything if I can (i.e. unless I need it to be in context for some later process that cannot be predicted)
As for this point:
weblike wroteIn Left menu I have "Home" button which is a process which calls this:
- Process with several EXEC_SP
- SHOW PERSPECTIVE 'Dashboard'
This will take longer than SHOW PERSPECTIVE loading a VP with a series of custom queries. Because you are EXEC_SP before you do anything you are creating a bigger perceptible lag for the user as the logic is
1 - go find information (user waits while AIM goes figures out the answers)
2 - show the VP (which then loads the information)
The end user is sitting waiting for the VP to show.
If you instead SHOW PERSPECTIVE the page loads immediately while the queries all populate once the VP loads. The user is being shown the page immediately which for me seems faster than press button wait then show page, but I appreciate that this is a perceptions issue.
