Skip to main content

Performing the Initial Setup

This chapter describes setup activities to perform before you create cubes. It discusses the following topics:

Setting Up the Web Applications

In order to use DeepSee in a web application, it is necessary to configure that web application so that it is DeepSee-enabled. Specifically, a web application is DeepSee-enabled if you select the DeepSee option when you configure the application; this option enables your application to use the %DeepSee classes. Similarly, if you select the iKnow option, the application can use the iKnow/DeepSee classes. For details on configuring web applications, see the chapter “Applications” in the Caché Security Administration Guide.

The application name has an effect on how the application can be accessed; see the table below.

Web Application Configuration In the Management Portal, the DeepSee menus link to this web application
  • Name is /csp/namespace

  • Namespace is namespace

  • DeepSee is selected

YES (note that the DeepSee menus always try to access this web application — even if another web application is configured as the default, via the Namespace Default Application option)
  • Name is any name other than /csp/namespace

  • Namespace is namespace

  • DeepSee is selected

NO (you can still access the web application by entering its URL in the browser)

Note that the sample web application /csp/samples is already configured to provide access to DeepSee and iKnow.

Placing the DeepSee Globals in a Separate Database

When you use DeepSee in a given namespace, that increases the amount of data stored in the database (or databases) used by that namespace. If the source table is large, DeepSee correspondingly stores a large amount of its own data. The DeepSee caches further increase the storage needs. As a consequence, it is generally a good idea to map some of the DeepSee globals to different databases. You can map all the DeepSee globals to a single database or you can define multiple mappings. As an example, the following steps describe how to place all the DeepSee globals in a single separate database:

  1. Create the database.

    When you do so, you might consider pre-expanding the database (that is, setting its initial size), to avoid disk fragmentation created by runtime expansion.

  2. Add a global mapping in the namespace that contains the classes that you plan to use with DeepSee. When you do so:

    • For Global Database Location, select the database that you just created.

    • For Global Name, type DeepSee.*

    Also see the next section for more specific mappings you might use.


    For the SAMPLES namespace, this step also affects where the DeepSee Patients sample is stored. In this case, you can also create an additional mapping for ^DeepSee.Study.* as in the following example:

    generated description: samples namespace global mappings

  3. Recompile all cube, subject area, and KPI classes in this namespace.

    Also rebuild all cubes.

For details on creating databases and mapping globals, see the chapter “Configuring Caché” in the Caché System Administration Guide.

Alternative Mappings for the Globals

In some cases, you might want to separately map the DeepSee and related globals to separate databases. The following table lists the key globals:

Items Globals Comments
Fact tables and their indices
  • ^DeepSee.Fact

  • ^DeepSee.FactRelation

  • ^DeepSee.Index

When you initially build the cube, you might disable journaling for the database that contains these globals. After that, enable journaling for the databases.
Globals used to keep cube synchronized with the source table

  • ^DeepSee.Update

See the chapter “Keeping the Cubes Current.”
Cube internals
  • ^DeepSee.Cubes

  • ^DeepSee.Dimension

  • ^DeepSee.DimensionI

Cube Manager
  • ^DeepSee.CubeManager

  • ^DeepSee.CubeManager.CubeEventD

  • ^DeepSee.CubeManager.CubeEventI

  • ^DeepSee.CubeManager.CubeRegistr

See “Using the Cube Manager” in “Keeping the Cubes Current.”
Listing groups ^DeepSee.ListingGroups See “Defining Listing Groups” in Defining DeepSee Models.
Result cache (for large data sets)
  • ^DeepSee.BucketList

  • ^DeepSee.Cache.*

  • ^DeepSee.JoinIndex

  • ^DeepSee.UpdateCounter

  • ^DeepSee.Listing

You can disable journaling for the database that contains these globals. For information on the result cache, see “Cube Updates and the Result Cache,” later in this book.
Items created in the Analyzer and in the Dashboard Designer
  • ^DeepSee.Filters

  • ^DeepSee.Folder*

  • ^DeepSee.FolderItem*

See Using the DeepSee Analyzer and Creating DeepSee Dashboards.

Term lists
  • ^DeepSee.TermList

See the Advanced DeepSee Modeling Guide.
Quality measures
  • ^DeepSee.QMsrs

See the Advanced DeepSee Modeling Guide.
Pivot variables
  • ^DeepSee.Variables

See “Defining and Using Pivot Variables” in Using the DeepSee Analyzer.
Other portal options
  • ^DeepSee.DashboardSettings (user-specific dashboard settings)

  • ^DeepSee.User.SendTo (user email addresses)

  • ^DeepSee.User.Settings (runtime variables)

  • ^DeepSee.User.Icons (custom icons)

  • ^DeepSee.UserPortalSettings (general settings and worklist settings)

  • ^DeepSee.UserPreferences (recent items, per user)

  • ^DeepSee.PaperSizes (see “Adding Paper Sizes,” later in this book)

For most of these, see the chapter “Configuring Settings.”
Custom code
  • ^DeepSee.InitCode

  • ^DeepSee.AuditCode

See the chapter “Other Development Work.”
Recent history and logs
  • ^DeepSee.AgentLog

  • ^DeepSee.Last*

  • ^DeepSee.PivotError

  • ^DeepSee.QueryLog

  • ^DeepSee.Session

  • ^DeepSee.SQLError

  • ^ISC.IK.*

Internals used for processing
  • ^DeepSee.ActiveTasks

  • ^DeepSee.Agents

  • ^DeepSee.Build

  • ^DeepSee.Cancel

  • ^DeepSee.ComputedSQL

  • ^DeepSee.Functions

  • ^DeepSee.IDList

  • ^DeepSee.Pivot

  • ^DeepSee.Shell

  • ^DeepSee.TaskGroups

  • ^DeepSee.Tasks

  • ^DeepSee.UI.Charts


This is not a comprehensive list; DeepSee uses additional globals with names that start ^DeepSee. Globals not listed here typically contain only small amounts of data or are typically defined only briefly.

Adjusting the CSP Timeout Period

The User Portal is based on ZEN and thus respects the CSP session timeout period for the namespace you are working in. The default session timeout period is 15 minutes, which might not be long enough.

To increase the CSP timeout period:

  1. Go to the Management Portal.

  2. Click System > System Administration> Security > Applications > Web Application.

  3. Click Edit in the row for the namespace in which you are using DeepSee.

  4. Change the value of Session Timeout, which specifies the default timeout period for the CSP session, in seconds.

  5. Click Save.

FeedbackOpens in a new tab