The Dashboard project is for the enduser the entrypoint of the application. The dashboard determines which Blueriq sessions should be loaded for the current user, so it ties Blueriq functionality together, and makes sure navigation between pages works. All based on the current dashboard page, and authentication (based on role). It also determines to which pages the user can flow, by determining the menu items.

The most important pages for the DCM Foundation are described below.

MainDashboard

This is the entrypage for the dashboard. When the user loads the dashboard (<url>/Foundation) this page will be loaded. This page contains Case-Lists for different type of users, and also a widget for starting new Cases. 

Since all widgets are separate Blueriq sessions, one refresh will only affect the widget the refresh is triggered from. So when there are more Case-Lists on the page, and the user clicks on "next page", only the widget with the "next" button is changed. This could have a positive impact on the performance on the application. Keep this into account when modelling multiple lists on your page. When the they are modelled in the same widget, all Lists will je refreshed at each page refresh.

CaseType details

When a Case is opened, it will open the Case details page.

In the Foundation it opens the following widgets:

  • Case Details, containing the details which are specific for this case-type. This could contain anything from the dossier, like a subsidy request, or the details of a mutation request on a mortgage.
  • Tasklist, containing the open tasks for the user. This could become slower to load in high load situations. So it might be a good choice to create a separate widget for it, with a separate Blueriq session. Note that any refresh actions from within the other widgets won't effect the tasklist.
  • SidePanel, containing data which is similar for different Case Types, like involved users on a case, or the timeline. 
To keep the amount of sessions to a minimum, you should consider what data belongs to each other. You could make the choice to structure your page in more widgets (for example separate widgets + sessions for the timeline, involved, or even each tab in the details screen). But this will also lead to multiple sessions, with multiple load-case actions. So think of the optimal structure when modelling Dashboard pages.
Another consideration is to limit the session size of the Blueriq sessions. Multiple sessions with a small amount of data might be more efficient in a high load situation than one session with a very large profile. Keep this in mind with modelling your application.

Dashboard communication

The user can request the Dashboard to flow to another page. This can be done by either clicking on a button in the menu (flow to another page without session context), or by ending a widget. The widgets within a Dashboard should be modelled with a flow_type "DcmWidget" (available in the BlueriqLibraries package, in the CaseModelling library. All types of communications:

  • Menu-buttons flow to a new dashboard page
  • Refresh button, restarts all Blueriq sessions on the same page. The same input parameters will be used to restart the widgets.
  • DcmWidget flow ends the possible events to end a widgets are
    • Start Task
    • Start (new) Case
    • Open Case
  • End task execution. The task execution is triggered by a special widget (of type Task). Additional widgets can be modelled on the same start task page. When the task is finished, the open-case page for this case-type is reopened.


  • No labels

Didn't find the answer you were looking for? Try the advanced search!