Introduction

In a typical scenario a model designer creates a multidimensional spreadsheet ( a model ) and shares it with other (basic) users who fill the model with data. This guide is primarely aimed at model designers, as entering numbers into worksheets is self explanatory.

Creating a model typically involves the following steps:

  1. Create lists and list items to represent business objects and measures of the model. List items can also be imported from a CSV file.
  2. Create multidimensional worksheets using lists from the previous step as its dimensions and measures
  3. Create worksheet formulas to perform computations
  4. Create cell formatting rules and cell color rules to improve readability
  5. Use cell visibility rules in combination with buttons to create workflows and advanced functionality
  6. Share the model with other users
  7. Import existing data into the worksheets using via CSV files

The steps are explained in detail in the following chapters.

Lists

Lists represent important business objects for your model. Lists can be understood as normal relational tables of a database.

Some examples of lists are:

  • Products with items like: Lemonade, Bubble gum, ...
  • Months with items: Jan, Feb, ...
  • Geographic locations with items: Berlin, Paris, ...

List items can have attributes attached to them (like if a product is active or discontinued). The attributes are represented as columns in the list view. Attributes are used to control the area of effect of the formulas, create hierarchies or to logically connect items from two different lists.

Important note: Lists and list items should only be used to store master data which does not change often (in contrast to the worksheet data). Most changes to lists will trigger a full recompute of the model. Lists are also much harder to copy and the data stored in lists cannot be made available in multiple scenarios. A good practice is to keep as much data as possible in the worksheets and as little as possible in the lists.

Lists can be found under the 'Lists' menu. Select a list from the menu to open the list editing screen. New lists can be created using the ListsCreate list menu item.

List editing screen displays a table with list items:

Each list item has a unique identifier (first column). It can be used to reference the item from a formula or to identify it during data import or export. The identifier can be changed. Latin letters, numbers, underscore(_) are allowed. Items's caption (second column) is an optional text which describes the item.

Use the quick access buttons on the left to add or remove items to the list or to create or remove list attributes (columns).

A list can be renamed by clicking on it's title.

Hierarchies

List items can be organized in a hierarchy. A list of cities can for example be organized by the country of the city.

The following steps explain the process of creating a hierarchy:

  1. Create a list for each level of the hierarchy (f.e. city and country).
  2. Add a reference attribute to the lower level of the hierarchy which points to the higher level. In our example the city list gets a new column COUNTRY of type country.
  3. Assign values for the new attribute to each list item.
  4. Use the Hierarchy key column dropdown from the List settings dialog to set up the hierarchy. In our example we select the COUNTRY column in the Hierarchy key column dropdown of the city list.

After following the above steps the cities will be displayed as a hierarchy tree in all of the worksheets and in the list screen.

Hierarchy settings only affect the (default) ad-hoc aggregation and the way the list items are displayed. It does not affect the formulas, because formulas use the list item attributes directly. This allows aggregation over multiple hierarchies using formulas.

Link lists form a many-to-many relation between two other lists. As an example a store and product lists form a many-to-many relation, because each store can sell many products and a product can be sold in multiple stores.

The following steps explain the process of creating a link lists for a many-to-many relation:

  1. Create both base lists first (f.e. store and product).
  2. Create a list to connect the first two lists. Let's call it store-product in our example.
  3. Add a reference attribute to the link list which points to the first part of the relation. In our example the store-product list gets a new column STORE of type store.
  4. Add a second reference attribute to the link list which points to the second part of the relation. In our example the store-product list gets a new column PRODUCT of type product.
  5. Assign values for the new attributes to each list item of the link list.
  6. Now select one attribute in the Hierarchy key column dropdown and the other one in the Link key column dropdown from the List settings dialog. In our example we select the STORE column as the hierarchy key and the PRODUCT column as the link key.
  7. Optionally tick the Autogenerate identifiers and Caption from linked items checkboxes.

After following the above steps the store-product list will be hierarchically organized by store. A user will have to select a product each time he adds an item to this list. The system makes sure that every item in the store-product list has values for both the STORE and the PRODUCT columns (the "not null" constraint is enforced). The system also makes sure that no store has the same product more than once (the uniqueness constraint is enforced).

Auto-generated lists

Link lists can be auto-generated from another relation between the parent and the linked list or using the cross join logic (all possible combinations).

Use the Auto-generate list dropdown from the List settings dialog to enable this feature. A relation between the the parent and the linked list is required. Check out the Year-Quarter-Month list from the best practices page or the Store-Product list from the Sales planning sample model to see how this feature works.

Warning: The list items will be completely managed by the system, if the auto-generation feature is enabled. The user will not be able to add or remove items manually. Already existing items (including references to them) will be deleted without a warning if they do not exist in the selected relation.

Measures

Measure (metrics, fact or position) is a quantity which is relevant for your model such as number of units sold, revenue or costs. Measures are represented as a special list inside the system.

Click the the ListsMeasures menu item to access the measures screen. Note: Measures list can be renamed, but it will always be displayed as the first list in the menu. Adding or removing measures works exactly the same way as adding/removing other list items.

Worksheets

Multidimensional worksheets (or multidimensional cubes) are used to store the bulk data of the model. Worksheets also contain formulas and formatting rules.

A normal spreadsheet has two dimensions: rows and columns. A dimension can be seen as an abstraction of the row and column concepts. We use lists to represent dimensions. List items are used to label single rows or columns the same way numbers and letters are used to label rows and columns in a plain spreadsheet.

A worksheet can be created using the WorksheetNew worksheet menu item. You will have to specify a set of lists to use as the worksheet's dimensions and set of measures to be used in the worksheet. Dimensions and measures can also be added or removed at a later time with WorksheetAdd dimension and WorksheetMeasures menu items.

Dimensions of a worksheet can be displayed as rows, columns or filters. The assignment can be changed by dragging and dropping a dimension to a different area of the panel in the left part of the main screen.

The filter icon on row and column dimensions can be used to further reduce the visible part of the worksheet.

Worksheets can be organized into worksheet groups. A worksheet group dropdown will apear at the bottom left corner of the screen if more than one worksheet group is available. Use the WorksheetRename/Move menu item to assign a worksheet to a group or to rename it.

Ad-hoc aggregation

Ad-hoc aggregation feature can be used to quickly compute total rows and columns inside a worksheet. Use the WorksheetAd-hoc aggregation menu item to open the aggregation settings dialog.

Select the dimensions to display the totals for and the default aggregation function. The default aggregation function can be overridden for single measures by setting the value for the AGGREGATEFUNCTION column inside the _ListsMeasures dialog.

Note: Ad-hoc aggregation results are computed online when the worksheet is rendered. The results are not saved and cannot be accessed by formulas. Ad-hoc aggregation over multiple large dimensions can be very slow. Use formulas to hierarchically compute aggregates in complex scenarios.

Formulas

Formulas are used to compute cells of a worksheet based on the content of other cells. Right click on a cell and choose New formula menu item to create a new formula. The formula editor overlay will appear.

The formula syntax is quite similar to common spreadsheet application with the exception of following new concepts:

Area of effect

A major drawback of a common spreadsheet is the necessity to copy formulas as new cells are added. This happends because formulas are normally bound to individual cells. We remove this limitation by attaching the formulas to worksheets instead. We use the area of effect concept to express the part of a worksheet a formula is applied to. The 'area of effect' defines a set of list items a formula is applied to for each dimension of a worksheet. The area of effect can be expressed in a flexible way, so that a formula can be applied to all list items, to a fixed subset, to all but selected items or to items with certain attributes. This way a formula will continue to do its job after new list items are added to lists.

Cell references

The unique cell reference syntax makes formulas very powerful and durable. The easies way to add a cell reference is to select a cell range with a mouse while the formula editor is active. The reference will be added to the current cursor position. While this may be enough for most of the basic cases it is important to understand how cell references work.

Cells can be accessed statically using list item identifiers, dynamically based on the order of the list items (previos, next) and dynamically based on relations between list items (through attributes).

Here is an example of a cell reference: ['List A':3, Year.prev()]

A cell reference is a comma separated list of directives which is enclosed in square brackets. Each directive defines the targeted list item(s) along a single dimension. There are two types of directives: static and dynamic.

Static directives have the syntax <list id>:<list item id> or <list id>:(<list item id1>, <list item id2>, ...) and reference a fixed set of list items. The directive 'List A':3 will always refer to the item with the id 3 inside the 'List A'.

A dynamic directive has the form <source list id>.<function>(<parameters>). The directive Year.prev() uses the function prev() which will refer to the list item located just before the list item which is currently beeing computed.

Below is the complete list of the functions for dynamic references:

  • next(), prev(): functions will return the next or previous item in the list order
  • offset(<index>, <window size>) function is a generalisation of the next and prev functions. It will select a continuous range of window size list items that starts index items before or after the current item. If index is negative the range will start before the current item. If window size is negative the selection window will go backwards and the items will be selected in the reverse order. Examples:
    • YEAR.offset(1,2) will select years 2021, 2022 if the current year is 2020
    • YEAR.offset(-1,-3) will select years 2019, 2018, 2017 if the current year is 2020
    • YEAR.offset(-1,3) will select years 2019, 2020, 2021 if the current year is 2020
  • all() function will return all the items of a list
  • join(<list id>,<attribute_name>) function will return the items of the list list id associated with the source list via the column attribute_name. If the optional parameter attribute_name is missing the first reference attribute of the respective type will be used. This function is mostly used when accessing cells from a different worksheet based on a relation. Examples:
    • sum('Sheet 2'.[Region.join(Country)]) - will sum up all the cells from worksheet Sheet 2 which are associated with the current region
    • 'Sheet 1'.[Country.join(Region),Measures:02] - will lookup the cell corresponding to the region of the current country from worksheet Sheet 1
  • joinr is the same as join, but will force attribute traversal in the reverese order. Useful only when an attribute connects a list to itself in a parent/child relation.

A cell from a different worksheet can be referenced by prepending a cell reference with the worksheets identifier: 'Sheet 2'.['List A':3].

Identifiers containing spaces or non-latin letters must be quoted: 'Sheet 2'.['List A':3] or 'Лист 1'.['Продукт':3].

Conditions

Functions like sumif or countif expect a condition as one of the arguments. CubeWeaver variants of these functions accept a boolean conditional expression instead of a fixed value. The cell value can be referenced using the $cell variable inside these conditions. $cell returns a cell object, which can directly be used for computations (like $cell + 2 > 3). It can also be used to access cell dimensions like $cell.YEAR (returns a list item). Some examples are:

  • sumif([Measures:03, Year.all()], value($cell.Year) > [Measures:04]) - sum Measures:3 for years greater than the value stored in [Measures:4]
  • countif([Measures:03, Year.all()], and($cell > 3, $cell < 6)) - count all values between 3 and 6

Functions that apply a condition to a value and not to a cell directly (like validate) use the $value variable. $value returns a number and can only be used for computations (like $value > 34). Example:

  • validate([Measures:03] - [Measures:04], $value > 0, "positive result expected") - compute the cell as [Measures:3] - [Measures:4] and display an error if the result is negative

Formula errors

Each computed cell is either valid or invalid. Invalid cells are marked with a red triangle at the top left corner. Placing the mouse over an invalid cell will show an error message:

Validation state of cells is propagated over the computations. This means that any computed cell which references invalid cells will also become invalid with an error message: "Error in a precedent cell(s)". This way any error which occurs in worksheets on a lower level of hierarcy will be visible in aggregated cells on higher levels.

The validate(<value>, <condition>, <message>) function can be used to mark a cell invalid based on a boolean condition. The value parameter is the result of the computation and will be returned by the validate function unchanged. The condition is a boolean condition which must be true for the cell to remain valid. The message is an error message for the invalid cells. The validate function can be chained to check for multiple conditions. Example:

  • validate([Measures:01]-[Measures:02], $value <= 5, "the difference must be less than 5") - will compute the current cell as [Measures:01]-[Measures:02] and mark it invalid if the result is greater than 5
  • validate(validate([Measures:01]-[Measures:02], $value <= 5, "the difference must be less than 5"), $value>=0, "the result must be positive") - will compute the current cell as [Measures:01]-[Measures:02] and mark it invalid if the result is greater than 5 or less than 0

User functions

Note: User defined functions are only available in the on-premise version of CubeWeaver at the moment.

Functions for CubeWeaver can be written in any .NET language (like C# or VB.NET). To add new functions a .NET Core assembly with functions implementation must be added to the CubeWeaver directory. Following conventions must be met:

  • The assembly name must start with functions_. For example: functions_math.dll.
  • The assembly must contain at least one static class called FunctionLibrary. All public static methods of this class will be added to the function library.
  • Function parameters and return value types must be one of the following:
    • decimal - number
    • IEnumberable<decimal> - cell range
    • string - string
    • bool - boolean
    • Func<decimal, bool> - boolean condition
  • System.ComponentModel.Description attribute can be used to add context help to a function. Three slashes (///) are used to separate the description text and the example text. For example: [Description("Square sum///sqsum([A:(1,2,3)])")]

The function names will be prepended with an ext_ prefix to avoid conflicts with the standard functions. The function gcd(a,b) will for example be accessible as ext_gcd(a,b).

A sample implementation is on GitHub.

Cell formatting

Cell formatting rules uses the same area of effect concept as formulas. It means we do not format single cells, but create formatting rules with an area of effect. A formatting rule can be created by right clicking on a cell and selecting the Format cell menu item.

Possible cell formats are:

  • Number: a numeric/date/time cell with standard spreadsheet cell formatting syntax
  • Boolean: a checkbox for switching the value between 0 and 1
  • Text: a text comment string which cannot be used in formulas
  • Dropdown: a dropdown with list items as options. Values are accessible from formulas using the element(range) function.
  • Slider: only accessible using the formatrange(min, max, step) function
  • Button: only accessible using the formatbutton(...) function

Cell format can either be defined statically, by selecting a respective option in a listbox or dynamically with a formula by checking the dynamic checkbox on the right side of the screen. A dynamic formatting formula must return a format object, which can be created using one the format...() functions. Some format types (like buttons and sliders) are only available through the respective format functions (like formatbutton(...)). See the function docs for more information on formatting functions.

Cell colors

Cell color rules are very similar to the formatting rules and use the same area of effect concept. Cell color rules can be created by right clicking on a cell and selecting the Cell color... menu item. Depending on the state of the dynamic checkbox (on right side of the screen) the rules are either static or dynamic:

  • Static color rules specify three static colors: foreground text color, background cell color and background cell color for readonly cells.
  • Dynamic color rules specify a formula which returns a string with up to three valid CSS colors separated by ;. The colors are interpreted as <text color>;<background color>;<readonly background color>. The second color will be used for readonly cells if only two colors are available. Empty values will be ignored.

Some examples:

  • if([] >= 0, "green", "red") Red text for negative numbers. Green text for positive numbers.
  • if([] >= 0, ";green", ";red") Red background for negative numbers. Green background for positive numbers.
  • concatenate("red;hsl(0,0%,", text(median([],0,100)), "%)") The text is red. The background is gray with lightness taken from the cell value (between 0 for black and 100 for white).

Note: Standard spreadsheet cell format color syntax (like [red][<100]0;0) is also available using the cell formatting rules.

Buttons and workflows

CubeWeaver cells can be formatted to display a button. A click on the button triggers a single computation of a set of formulas on a designated cell range. The cell range is specified relative to the cell where the button was clicked. This simple mechanism can be used to model various one-way operations:

  • Workflows (submitting a range of cells): A click on a button changes the content of a cell in a hidden worksheet from 0 to 1. A cell visibility rule can be used to make a cell range read-only depending on the content of the changed cell. The submit logic can be as complex as needed with multiple submit/approve buttons visible to specific groups of users.
  • Onetime bulk changes to input values like increasing a range of input values by a certain percentage or distributing certain costs among input values.
  • Copy a range of values from one element to another like rolling forward the planning values from the previous to the next year. Or copying results of a simulation to a certain scenario.

Buttons can be created using the dynamic cell formatting (context menu → Format cell than check the dynamic checkbox on the right). The formatbutton(label, updates...) function is used to specify the button parameters. The first parameter is the label for the button. The label is followed by one or more update operations. An update is specified by the update(destination, value) function, where destination is a cell range and the value is a formula expression evaluated for each of the destination cells.

Note: Keep in mind that references in the second argument of the update function are specified relatively to a cell from the first argument and not relatively to the button. If in doubt qualify every cell range with the worksheet name.

The button labels can contain additional tags to customize the appearence of a button. Following tags are supported:

  • [confirm:<message>]: asks for a confirmation before an operation is started
  • [style:<button style>]: changes the color of the button. Following styles are supported: success - green button, danger - red button, warning - yellow button.

Some examples:

  • formatbutton("[style:success]Submit", update([Account:19], 1)) - will display a green button labeled "Submit" which will save the value 1 into the cell [Account:19] relative to the cell where the button was clicked.
  • formatbutton("[confirm:Adjust values?]Apply %", update([Measures:(1,2,3)], [] * (1 + [Measures:4])), update([Measures:4], 0)) - will display a button labeled "Apply %" which will change values in cells Measures:1, Measures:2, Measures:3 by the percentage stored in the cell Measures:4 and delete the value stored in the cell Measures:4 afterwards. The user will see a confirmation dialog with the "Adjust values?" message if he clicks the button.
  • formatbutton("Fill from previous year", update('Sheet 1'.[], [Year.prev()])) - will copy the values from the previous year to the current one (the year where the button was clicked) in the worksheet Sheet 1. The worksheet where the button is located must have a year dimension for this to work.

Cell visibility

Cell visibility rules can be used to conditionally hide a cell range or make it read-only. For example certain measures can be hidden for certain list item types. Cell visibility rules can also be used for advanced data access scenarios, when cells are dynamically hidden based on user's privileges or the values of other cells. A cell visibility rule can be created by right clicking on a cell and selecting the Cell visibility menu item.

Cell visibility rules can either be static (always hide the area of effect) or dynamic. A dynamic rule must specify a formula which returns a number as a result. The result is interpreted as follows:

  • 1 - hide cell content
  • 2 - make the cell read only
  • 3 - make the cell editable
  • 4 - do not change cell access (can be used in an if() for example)

Cell visibility rules use the same area of effect concept as formulas.

Formula comments

A formula can contain C-style comments. For example: /* this is a comment */

Share a model

Worksheets can be filled with data by multiple users simultaneously. Perform the following steps to share your model:

  1. Click FileShare menu item to open the sharing dialog.
  2. Create a new share with Share by link or Share with user buttons.
    • Use Share by link button to create a share which is accessible anonymously by anyone in possession of a secret link.
    • Use Share with user button to share the data with a single registered user. You will be asked for the user's email. Please make sure that the email is typed correctly. The user will NOT be notified by the system. Please notify the user manually.
  3. Share settings will appear on the screen. Go through the following steps to select which parts of the model should be shared:
    1. Select the system privileges: System privileges are required to perform special tasks like exporting data or sharing the model with others. Certain privileges let users access all worksheet or all lists (even those which do not exist yet).
    2. Select the worksheets the user should access. You can share a worksheet in read-only or editable mode.
    3. Select additional worksheet access limits for each dimension if necessary. Setting this option will limit worksheet access to certain measures or list items.
    4. Select which lists should be shared with the user. You can share a list in read-only or editable mode.

Spreadsheet export

A multidimensional model can be exported as a flat spreadsheet .XLSX file using the FileExport as .XLSX menu option.

The default saved view (WorksheetSave view as default) of each worksheet will be used to determine the row and column dimensions. All filters will be translated to rows.

The formulas will be translated to standard Excel formulas. Non-standard spreadsheet functions will produce errors in cells of the exported file. Don't use CubeWeaver-specific functions with variables (like with or sumif([], $cell > 3)) if you would like to export the model to Excel.

Only formatting for the standard numberic/date/time cells can be exported correctly. Buttons, dropdowns and other interactive elements are not supported by Excel.

CubeWeaver does not yet validate the number format strings. Invalid format strings can produce errors when opening the Excel file.

Data exchange

Worksheet content and list items can be transferred between CubeWeaver and 3rd party tools via files (.CSV or .XLSX) or using the ODATA protocol. A developer API is available to directly connect a model to a database system.

CSV import (row based)

Follow these steps to import worksheet content or list items from a .CSV file:

  1. Click the FileImport data menu item to open the import file dialog.
  2. Select a worksheet or a list to import data to. Than select a file using the 'Choose file' button.
  3. Choose the columns to use for import:
    • A list item file must contain one line for each item. At least the identifier or the caption column is mandatory. If the identifier column is missing the caption is used instead of the id to identify rows.
    • A worksheet file must contain an identifier or a caption column for each dimension of the worksheet. There are two import options for the worksheet measures:
      1. If the Measures as columns checkbox is checked each measure is expected in it's own column.
      2. If the Measures as columns checkbox is unchecked a signle VALUE column which contains the measure value is expected along with the Measure column which designates the measure.
  4. Click the 'Start import' button and wait until the import process has finished.
  5. Check the import log for errors.

You can use the FileExport data menu item to generate a sample .CSV file with worksheet values.

NOTE: List items and worksheet data must be imported separately. To import one large denormalized file import each dimension first into it's list. After that you will be able to import the measures. Each hierarchy level of a hierarchical list must also be imported separately.

CSV export (row based)

Use the FileExport data menu item to export data in the relational form as .CSV or .XLSX. An export dialog will apper. There are two options to export data:

  • denormalized: list item data is injected into every worksheet table
  • normalized: list items and worksheets are exported into separate sheets/files

When Measures on columns checkbox is checked a separate column will be created for each measure in the worksheet tables. If the checkbox is unchecked all the measures will end up in a single VALUE column and a separate Measure column will designate the measure.

ODATA export

ODATA protocol can be used to export model data to 3rd party tools like dashboards or databases.

To export data via the ODATA protocol create a new link-based share (FileShareShare by link), check the Export any table user privilege and save the share. Click the Show API/ODATA links button to display the ODATA access urls and password.

Developer API

Developer REST API lets you transfer the data between CubeWeaver and 3rd party systems. Developer API key and an access URL is created automtically when a link-based share is created (see ODATA export for more info). At least export or import privileges are requiered to access the data via the API. Following methods are available at the moment:

Data import:

Following methods expect a valid CSV file to be uploaded with a POST request. The CSV file must have a header in the first line with column names exactly matching the column names found in the import dialog or in an exported file. Some of the columns are optional. For example a column with header PRODUCT_ID is an identifier column for the list with the id PRODUCT. The easiest way to create a valid file is to use a file obtained from an export call as a template.

  • api/{model_id}/import_values/{worksheet_id} - import worksheet values for a worksheet with the id worksheet_id
  • api/{model_id}/import_metadata/{list_id} - import list items for a list with the id list_id

Example:

curl -L -u ACCESS_KEY: -F "test=@test.csv" "https://cubeweaver.com/api/MODEL_ID/import_metadata/LIST_ID"

Data export:

Following methods can be used to export CubeWeaver data as a CSV file.

  • api/{model_id}/export_values/{worksheet_id} - export worksheet values for a worksheet with the id worksheet_id
  • api/{model_id}/export_metadata/{list_id} - export list items for a list with the id list_id
  • api/{model_id}/export_full - export the complete model (all lists and worksheets) as a ZIP archive

Example:

curl -L -u ACCESS_KEY: -o test.csv "https://cubeweaver.com/api/MODEL_ID/export_metadata/LIST_ID"

Some examples of API usage (with Python and Pentaho ETL) are available on GitHub.

Note: the CubeWeaver website will redirect API requests. That is why the -L key is needed for the curl command. On-premise installation does not have this behavior, so the -L key can be removed.

Note: SSL certificate validation can fail (primarely on Windows) if the certificate store for the curl command has not been setup correctly. The -k key can be used to skip the certificate validation.

Note: Please contact support if you feel like your scenario is not covered by the available API.

Hosting on-premises

Installation

Cubeweaver is a web application. The server packages available for download contain prebuilt binaries and all the required dependecies. CubeWeaver.exe (or CubeWeaver on Linux) is the main executable file. A local web server and a browser window will be started automatically if you start CubeWeaver without parameters.

We recommend using Docker to host CubeWeaver on Linux. Sample docker-compose files and a readme.txt with explanations are available inside the linux archive. At least the --remote option is required to make the server accessible from remote hosts.

The following command line parameters are available:

--db-type (Default: sqlite) Database type to use. Currently supported: 'sqlite' or 'mysql'

--db-conn ADO.NET database connection string. For example: 'Data Source=c:\mydb.db;'

-p, --port (Default: 8080) HTTP server port. Must be reserved manually under windows via the netsh utility.

-b, --base Base url for the web interface (when hosting behind a reverse-proxy).

--db-name Optional database name for mysql database.

--ssl-cert-file Server certificate file in PKCS12 (PFX) format.

--ssl-cert-pass Server certificate file password.

--remote (Default: false) Allow remote access (don't forget to open the port in your firewall).

--no-browser (Default: false) Don't start the browser.

--maintenance (Default: false) Allow remote access to (encrypted) log files.

--import-model Import a model file and exit.

--user Owner for the import operation.

--help Display this help screen.

--version Display version information.

User administration

A built-in admin user is created when the system starts for the first time. Admin's password must be changed before the first login. On linux the admin's initial password is logged by the server on every start until it has been changed. Check the readme.txt for instructions on how to access the log.

Other users can be added using ToolsManage user accounts menu item. Click the New button to add a user account. The accounts initial password will be displayed at the top of the screen until it has been changed by the user. The password can be reset by an administrator using the Reset password button.

A user can have following privileges on the server (apart from access right he will get on individual models):

  • Create models: create new models on the server
  • Manage user accounts: create or delete other user accounts and reset their passwords

Troubleshooting

Below is a list of common error messages and pitfalls with explanations on how to solve them:

Error messages

  • Cannot delete item(s) X. Following items still reference it: A, B, C: A list at the end of the error message contains objects which still reference the item to be deleted. Those references must be removed first. Here is a list with preconditions, for deleting an object:

    • List item: to delete a list item it must be remove from all the formulas which reference it first. The list item must not be referenced by other list items via a Reference-type column.
    • Measure: to delete a measure it must be remove from all the formulas and from all the worksheets (WorksheetMeasures menu item).
  • A formula must reference cells: This limitation is introduced to efficiently evaluate formulas in very large sparse cubes. Each cell is either an input cell or a computed one. Computed cells must reference other non-empty cells to produce a non-zero result. Formulas without cell references are prohibited completely. In certain cases cell range references may return 0 cells (f.e. [MONTH.prev()] if the first month is computed). A formula which effectively references 0 cells (like [MONTH.prev()] + 2 for January, but NOT [MONTH.prev()] + [Measures:03]) will evaluate to 0. Though this behavior does not impose any limitation in most of the real world scenarios a workaround exists for certain edge cases: reference a non empty input cell and multiply it by zero to ignore it (like [MONTH.prev()] + 2 + 'Sheet 2'.[Measures:11] * 0).