Forum Discussion

calvincoffeen's avatar
calvincoffeen
New Contributor II
3 years ago

Button Highlighting Business Rule - "Load Dashboard Server Task (Once)" running twice?

Hello,

I have a problem with a couple business rules running at the wrong times from within a dashboard. 

The background: I have a business rule that changes the formatting of the buttons on a dashboard to show which one was clicked last. The buttons function as "tabs," each linking to a report; the button linking to the currently selected report shows itself as highlighted.

To do this, I have the name of the current active button stored in a literal parameter.

When a button is clicked to launch a report, a business rule rewrites the value of this literal parameter. (An XFBR String rule then reads this parameter to determine how to format the buttons, and is output to button - formatting - display format).

The problem: When I launch the dashboard from OnePlace, the highlighting works correctly, showing a set of buttons with the first button highlighted.

When I click another button, the button works correctly by launching a report, but the first button remains highlighted. The literal parameter does not update with the name of the newly clicked button as it should. BUT if I click any other button a second time, the highlighting starts working correctly, and the literal parameter is rewritten by the BR.

So what's happening? When I launch the DB from OnePlace,  a Load Dashboard Server Task runs (DashboardExtenderFunctionType.LoadDashboard).

When I click a button within the dashboard,  a Selection Changed Server Task runs (DashboardExtenderFunctionType.ComponentSelectionChanged).

It looks like the first time a button is pushed, either the Load DB server task is running a second time or the Selection Changed server task is not running. I don't know why a second push of the button changes its behavior.

I don't know how to track the problem any further and would love your thoughts if you've read this far; any ideas?

 

Rewrite literal parameter BR:

 

 

 

 

Namespace OneStream.BusinessRule.DashboardExtender.Button_Format
	Public Class MainClass
		Public Function Main(ByVal si As SessionInfo, ByVal globals As BRGlobals, ByVal api As Object, ByVal args As DashboardExtenderArgs) As Object
			Try
				Dim bda = New OneStream.BusinessRule.Finance.BDA_BRFramework.MainClass(si, globals)
				Select Case args.FunctionType
										
					Case Is = DashboardExtenderFunctionType.LoadDashboard
						If args.FunctionName.XFEqualsIgnoreCase("ActiveButton_Launch") Then
							
							'Implement Load Dashboard logic here.
							Dim strButtonName As String = args.NameValuePairs("ButtonName")
							
							BRApi.Dashboards.Parameters.SetLiteralParameterValue(si, False, "param_active_Btn", strButtonName)
													
							Dim loadDashResult As New XFLoadDashboardTaskResult()
							Return loadDashResult
							
						End If
						
					Case Is = DashboardExtenderFunctionType.ComponentSelectionChanged
						If args.FunctionName.XFEqualsIgnoreCase("ActiveButton") Then
							
							'Implement Dashboard Component Selection Changed logic here.
							Dim strButtonName As String = args.NameValuePairs("ButtonName")
							
							BRApi.Dashboards.Parameters.SetLiteralParameterValue(si, False, "param_active_Btn", strButtonName)
													
							Dim selectionChangedTaskResult As New XFSelectionChangedTaskResult()
							Return selectionChangedTaskResult
						
						End If
						
				End Select

 

 

 

 

  • Calvin,

    Just a side comment: I wouldn't use a literal parameter to store the value of what button was pressed. The literal parameter is shared with all your users  and you will run into a problem where one user session overwrites the parameter value while another user session will eventually read the updated value but it doesn't reflect what the user should be seeing.

    A workaround would be to setup a runtime parameter that you then save to the dashboard parameter dictionary (i.e. args.LoadDashboardTaskInfo.CustomSubstVarsFromPriorRun in LoadDashboard section and args.SelectionChangedTaskInfo.CustomSubstVars in ComponentSelectionChanged section).

     

    Also that db_pdx said: have you tried "Tabs"

  • db_pdx's avatar
    db_pdx
    Valued Contributor

    Hi calvincoffen: is the button set to redraw/refresh the dashboard component (frame) that holds the buttons?  Hopefully its as simple as that.

    Cheers,     -DB

    Edit: have you tried the standard 'Tabs' Layout Type?

    • calvincoffeen's avatar
      calvincoffeen
      New Contributor II

      The button is set to refresh, don't think that's the problem. I tested further by turning off the .LoadDashboard part of the BR, and the buttons work correctly (except for when the DB is first launched of course). This makes it seem to me that the .LoadDashboard is actually running a second time when a button is first pressed, as if the dashboard is relaunched after the first button press.

      But I have never used tabs and that was an amazingly helpful recommendation, thank you!

  • We get around the repetitive execution of BRs assigned to the "Load Dashboard Server Task (Once)"  by using the  args.LoadDashboardTaskInfo.Reason function. This function returns zero the first time the dashboard is launched and adds "1" on every subsequent refresh. So the following code lets the BR execute only on the initial DB load:

    Public Function Initiate_EXD(ByVal si As SessionInfo, ByVal globals As BRGlobals, ByVal api As Object, ByVal args As DashboardExtenderArgs) As XFSelectionChangedTaskResult
    			
       Try	
         'Run the Initiation code only on the initial launch of the dashboard
          If args.LoadDashboardTaskInfo.Reason > 0 Then GoTo GetOut
    
    'Do stuff here for the first time the Dashboard is loaded
    
    GetOut:
          Catch ex As Exception
           Throw ErrorHandler.LogWrite(si, New XFException(si, ex))
       End Try
    End Function	

    Here are the steps:

    Call the Set the Load Dashboard Server Task BR to run Once:

     

    Call the function from Main:

     

    At the top of the function, check to see if the Reason is more than zero. If it is, skip all the code and get out:

     

     

     

     

     

  • Cosimo's avatar
    Cosimo
    Contributor II

    Calvin,

    Just a side comment: I wouldn't use a literal parameter to store the value of what button was pressed. The literal parameter is shared with all your users  and you will run into a problem where one user session overwrites the parameter value while another user session will eventually read the updated value but it doesn't reflect what the user should be seeing.

    A workaround would be to setup a runtime parameter that you then save to the dashboard parameter dictionary (i.e. args.LoadDashboardTaskInfo.CustomSubstVarsFromPriorRun in LoadDashboard section and args.SelectionChangedTaskInfo.CustomSubstVars in ComponentSelectionChanged section).

     

    Also that db_pdx said: have you tried "Tabs"

    • calvincoffeen's avatar
      calvincoffeen
      New Contributor II

      That makes good sense, I hadn't thought of it - thank you! I'll try that workaround if needed, but I'm going to try tabs first.

  • I do get why you are going with buttons rather than tabs. I've done it. However, I wouldn't do it as a literal parameter. I would save it as a session value and use that to change the color of the button. 

    • calvincoffeen's avatar
      calvincoffeen
      New Contributor II

      We used buttons because we use supplied parameters in a linked CV we use as a custom drill-down; we were concerned that could cause problems. However, I'm testing using tabs instead and haven't found an issue yet. Do you have any resources or forum posts you could recommend for me to learn more about session values? I don't quite know how to implement. Thanks!

      • ckattookaran's avatar
        ckattookaran
        VIP

        Not sure if there is enough out there about Session State or User States. Maybe that is a good blog topic. 

  • We are also seeing the "Load Dashboard Server Task (Once)" running each time the dashboard is refreshed. Is this  a known issue? or is it by design?