DSViewer

The DSViewer Widget allows you to create What-If scenarios for direct datastore changes and manipulations. With this widget, you can add, remove and update rows in datastores, plus extract snapshots.

You can view each modification's effect on measures in an existing or new branch using standard ActivePivot views.

To open the DS Viewer, from the widget list, select WhatIf Simulations > DSViewer

The DSViewer widget comprises two sections:

Section Actions

Control Panel: This is the ribbon running across the top.

Use this section to set the criteria for loading data

Managing Branches

Managing Stores

Limiting results per page

Loading and committing data

Reset your current workspace

Workspace: This is the tabbed section beneath the control panel

Visualize your changes and collect snapshots of the datastores. Use tabs to switch between each table:

Loading Data

The initial store names and store headers are provided, but you need to manually load all data

We recommend you do not load the entire datastore at once and only load the data you wish to manipulate based on your necessary criteria.

To load data:

  1. If required, set any criteria and filters to reduce how much data is loaded. See Header Manipulation.

  2. On the Query Results tab, click Load Data.

Loading data from the Datastore will only make changes to the Query ResultsQuery ResultsQuery Results table to any other table will stay there regardless of whether that same row currently exists in the Query Results table.

Committing Data

Once you have all of your row additions, removals and changes ready, you can commit them to your workspace to update the datastore.

To commit your row updates:

  1. Click Commit

    This button is only enabled if additions, removals or changes are present in any of the three tables

  2. Acknowledge the warning message to confirm your changes.

Result:

  • If a table has any row to commit, then the WhatIf DSViewer generates a definition for that table to apply the commit. There are a maximum of three definitions for each WhatIf DSViewer submission and each definition takes effect in the order Create, Update, Delete.

  • Various restrictions are in place in the widget to make sure changes made in one definition do not get overwritten by changes made to another (for example, preventing the Update table and Delete table having the same rows).

  • When a commit is successful, all tables are automatically reset. This includes the Query Results table as it might have stale data that needs to be reloaded.

  • If a commit is unsuccessful, then an error message is displayed indicating that the server could not complete the action and does not trigger a table reset.

In this widget you do not actually create a new branch in the Accelerator until you commit your workspace.

To manage your branches and the simulations on them, use the widgets in the WhatIf Management category:

  • Branch Manager: View and manage your branches

  • WhatIf Manager: Set the refresh frequency on your simulations

Switching Between Branches

When you open the widget for the first time, it populates the Branch fields with the list of all existing branches on the datastore. You can then use the dropdown list to switch between them.

When you select a particular branch, before the widget loads any data it first performs a workspace-wide table reset. This avoids branches having stale or inconsistent data

 

Creating Branches

To create a branch:

  1. Click Commit As…

    This creates a new branch in the datastore, regardless of whether you are making any updates, creations or deletions to the datastore

    This button is only enabled when on the master branch. Any new branch created with this button will be branched off the datastore's master.

  2. Acknowledge the warning message to confirm your changes.

When you open the widget for the first time, it populates the Store Name field with the list of all store. You can then use the dropdown list to switch between stores.

As with the Branch dropdown, when you select a particular store before the widget loads any data it first performs a workspace-wide table reset. This avoids stores having inconsistent fields.

The number of rows that are loaded does not exceed the number defined in the Results Per Page section of the control panel. By default, this parameter is set to 100 but you can change it to any integer. If you use a non-integer value, this results in an empty table being loaded.

  • To reset a specific table, click Clear Rows.

  • For a workspace-wide reset for all tables, click Clear All.

Working with the tables

The workspace contains four tables on separate tabs for manipulating the datastores. Query Results, Create, Update and Delete.

Use the tabs to switch between the tables.

After you click Load Data, the Query Results table provides a small "snapshot" of the loaded data based on the criteria you previously defined in the control panel. Snapshots in this table do not automatically update and can become stale over time.

Header Manipulation

You can define some header-specific criteria for the query results before loading the data from a datastore

Filter type

Action

Completely remove a specific field from being loaded from the datastore

  • Right-click the field in the table's header and select Remove Field(s). To remove multiple headers select them all at once.

    Note: This action is disabled for primary key fields

Set conditions for each field to filter on when data is loaded

  1. Click Filter Columns

    The popup displays any active filters that currently exist on the table

  2. For non-numeric fields set a label and text. The widget uses these to add a datastore "like" condition on that field. If the text is blank it will be ignored.

  3. For numeric fields (double, float, Integer, and so on), select the operand from the dropdown list.

  4. Click Submit. The filters are displayed in the headers of the Query Results table. Each field with a filter has a string ": xxxx" appended to it, where xxxx represents the value for the condition applied. 

To understand more about conditions and how they work in datastore queries, refer to the ICondition documentation:

https://support.activeviam.com/confluence/display/COMP/ICondition

 

Removing filters

 

  • Click Filter Columns and delete the filters manually. 

    Note: Because setting filters can be time-consuming and complex (depending on the conditions you set), resetting the Query Results table does NOT reset filters. This is to avoid you losing complex filtering logic that you may have set and want to lock.

Row Actions

You cannot manipulate the data in the Query Results table. Instead, you can move specific rows that you want to either remove or manipulate to the Delete and Update tables respectively.

  • Click the edit icon to copy to the Update table.

  • Click the X icon to copy to the Deletetable.

Copying a row to the Update or Deletetable locks it there based on its primary keys and can not be done twice.

For example, if you already copied a row from the Query Results table to the Update table, and tried to add it again to the Update table or to the Deletetable, the action will be ignored.

Use the Createtable if you want to add new rows to a datastore.

Row Actions

  • Click Create Row to produce a new blanked-out row which you can edit by left-clicking on the cells of the table.

  • To modify any cell in the Createtable just double-click it. The widget takes the contents of all the row cells for each field to try and create the content in the datastore when committed. If you commit blank cells, the widget attempts to commit them as though they are a blank string.

  • Click Clear Rows to remove the row.

After you copy a row from the Query Results table to the Update table, you can then make modifications to the row within the Update table.

Unlike the Create table, which allows you to make cell modifications to all cells, the Update table restricts modifications to non-primary-key fields only. Primary keys are used to uniquely identify rows to modify so they cannot be edited in the datastore without first removing and then adding them back into the datastore.

Since the Update table has "original" data for each cell (not necessarily the same data as in the datastore if the snapshot data is stale) then any modification made to a cell in the Update table will show both the 'before' and 'after’ of that cell. Any modifications to the cell that return it to its "original" value will not result in a "before and after" display for the cell and will return to a non-modified state. In the special scenario where you modified a cell that did not load data (because in the Query Results table the field was removed from the headers of that table before loading) then the 'before' section of the cell will display "???" as the original value.

You must be cautious when committing modifications because regardless of the "Before" or "Original" value in the cell, committing any modified cell in the Update table will attempt to change the rows cell to the value in the After section without regard to the current value of the cell in the datastore at transaction time

Row Actions

  • Click Clear Rows to remove the row.

After you copy a row from the Query Results table to the Deletetable, you cannot make modifications to the row within the Delete table. Technically the only fields that matter for the Delete table are the primary key fields, because these are used to uniquely identify rows. Once committed, the widget removes the rows in this table (based on those primary keys).

Row Actions

  • Click Clear Rows to remove the row.