The intention of the UX Toolkit app is to make administering your UX application and Content Store much easier. Especially for the initial configuration and making sure nothing gets missed. Both from the point of view of administrators (e.g. automated backups), and things with high added value for end users such as setting Homepage and default elements for key point of view dimensions.

The app is split into 3 parts:

1. Application Setup (Wizard) :- once off configuration tasks
2. Maintenance (Wizard) :- regular maintenance tasks
3. Review & Analysis (Folder) :- reporting

Each part will be covered in more detail in the following sections.

The app makes use of common UX components to make using the app as easy and straightforward as possible. The same features which are available to you when creating planning and reporting applications for your own users:

• Wizards : to step through a logical progression or workflow of a business process
• Info text : to provide tooltip hints to guide what certain steps do or provide additional context
• Help PopUps : to provide additional instruction on each screen

Each screen makes abundant usage of info tooltip text and help PopUps for additional context and instructions.

As per the demo application, you can use the UX Toolkit app as a source of worked examples of how to implement some more advanced features. For example:

The application setup app walks the administrator through the process of the initial Content Store configuration and configuring the metadata syncing service done by the UX Toolkit utility.

This workflow takes the user through initial Content Store configuration, such as setting the dependency to 7-zip for automated backups and setting the path to the Content Store data directory and default import and export folders, and then the setup for the UX Toolkit utility to sync metadata from reporting instances to the content store.

Most if not all of the tasks covered in this workflow are once off initial configuration and will not need to be repeated. (Although it is highly recommended to regularly schedule the metadata syncing once it is set up and working!)

The 1^st half of this workflow concerns setting up the metadata syncing service. This is a key component for minimizing manual maintenance of the content store by facilitating the automation of user and group creation.

In the screen below the “Fetch Users & Groups” button (marked step #1) calls the metadata syncing service and copies all reporting instance users, groups and group membership relationships to an intermediate staging area in the Content Store (the }APQ UX Instance ClientGroups cube.) The UX administrator then has the option to flag whether to automatically import users and groups into the content store. Typically you would import all users (step #2 left). However, you would probably opt to only import groups to the content store which are relevant to Content Store security (step #2 right). (You may decide not to import any groups.)

The button “Sync to Content Store” (step #3) will “push” all flagged users and groups from the staging area to the Content Store security model. (After initial configuration both these processes can be scheduled with no need to use the UI screens for this purpose).

The setting service is a core component of Apliqo UX. During the configuration workflow the administrator can select dimensions which will have pre-set default member values for controlling the initial point of view when users log in. (This feature in turn relies on the metadata syncing service).

In the screen below in the demo application only the Currency and Department dimensions have been flagged to have default values set. When users log in the context of these dimensions will be set to the default values.

Users can choose to overwrite the default member values via the “User default settings” should they choose to.

The last step of the application setup workflow concerns the setup of reporting instances. There is a screen to guide the user through setting cube and dimension captions and another to automate UX attribute creation. Many advanced features in Apliqo UX can be managed in a very familiar way to TM1 developers, as much sophisticated behavior in the front end UI can be managed by creating attributes and assigning attribute values to elements in the reporting model. Some examples of attributes which control the behavior of the UX front end are:

• CellType : This attribute is most commonly applied to measure dimensions used on column or rows in Apliqo UX applications. Common cell types are "Checkbox" which applies a table cell class of checkbox (as used on this screen) and "Date" which signals the cell value should be entered via data picker modal
• Color : if an attribute is set with a standard color name or HexCode this will be recognized by Apliqo UX and all data series will be automatically plotted in the selected color consistently in all reports
• ibcs-class : this attribute can be used in version or scenario dimensions but also in continuous time dimensions for consistent formatting in both table column headers and chart series. The use case is similar to the Color attribute, for example to ensure that Budget, Actual and Last Year are always formatted consistently
• Group : If a group attribute is set this is used on column dimensions of views to automatically "nest" elements and allow whole groups to be displayed or hidden with a single click.
• Renderer : The renderer attribute is to support "Scorecard Metrics" KPI reports with the same formatting as supported by standard IBM Cognos interfaces
• TargetView: Is used to define the target for hyperlink navigation when “drilling” from one screen to another

This workflow takes the user through tasks that are more likely to be classified as "regular maintenance". Although it could be that some of these tasks are also once off initial configuration only depending on how the application is maintained and degree of automation.

The screen you are likely to use most often in this workflow is the screen to set app security. Although by default the APQ User group has read access to all public apps available in the appLauncher and appBar and the APQ PUser group has write access to all public apps (including admin apps), this does not have to be the case. The groups define the roles of “end user” and “report builder” and don’t have any requirement to be linked to app security (that is element security of the UX App dimension). You are free to define your own groups for app security if you require a more granular app security.

You would still use this screen to set the security per group. Security is inherited from the app level to folders, wizards, views and dashboards underneath. In order to be able to navigate to a screen the user must have read access to the app ancestor. Note that you can also “override” the inheritance. An override could either promote or demote the level. Using this concept you can have very granular security even within an app with some groups having access to some screens but not others for example.

By clicking the “Update App Security” button all app security changes are pushed from the staging area to the element security model of the UX App dimension.

These are apps which don't fit in a workflow. Currently there are 2 screens in this section: