· Dec 21, 2015

DS deployment architecture, which globals should be mapped where?

To deploy a DeepSee solution, the docs recommend that you define a namespace on the reporting (mirror) server, and "define mappings to access the application data, application code, DeepSee cube definitions, and DeepSee data on this server".  (

This implies that for an ideal deployment architecture, globals should be split into four separate databases (app data, app code, DS cubes, DS data).  How exactly should the DeepSee-related globals be split?  A table in the docs outlines all of the key globals (, but is there an optimal way to split those into 'code' and 'data'?




Discussion (3)1
Log in or sign up to continue

For one customer we use this solution which works fine for them:

DATA database which contains the end customer data and is the default mapping

CODE database which contains the cubes (package mapping) and Pivots and Dashboards (^DeepSee.Folder en ^DeepSee.FolderItem global mapping)

IDX database which contains all the other DS stuff (^DeepSee global mapping)

This works fine so far as we can replace the end-customer data easily and keep it seperate, and we can also update a new batch of cubes and dashboards easily by replacing the CODE database with a new version. IDX can be rebuild by compiling/building the cubes so that’s easy too.

This works fine because currently they create all dashboard for their customers.

We foresee that some end customers need some custom pivot/dashboards, which we then would like to map to a 4th database; we don’t want it in CODE because we want to keep that the same at all end-customers. Maybe we  should we do a subscript type mapping of ^DeepSee.Folder(Item), and is that sustainable among Cache versions? I have not looked into it further as both their DS customers are happy with the current solution and don't create any dashboards or pivots themselves.