Performing the Initial Setup
This chapter describes setup activities to perform before you create cubes. It discusses the following topics:
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|
||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)|
||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.
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:
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.
Add a global mapping in the namespace that contains the classes that you plan to use with DeepSee. When you do so:
Also see the next section for more specific mappings you might use.Note: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:
For Global Database Location, select the database that you just created.
For Global Name, typeDeepSee.*
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.
In some cases, you might want to separately map the DeepSee and related globals to separate databases. The following table lists the key globals:
|Fact tables and their indices||
||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||
||See the chapter “Keeping the Cubes Current.”|
||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)||
||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||
||See the Advanced DeepSee Modeling Guide.|
||See the Advanced DeepSee Modeling Guide.|
||See “Defining and Using Pivot Variables” in Using the DeepSee Analyzer.|
|Other portal options||
||For most of these, see the chapter “Configuring Settings.”|
||See the chapter “Other Development Work.”|
|Recent history and logs||
|Internals used for processing||
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.
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:
Go to the Management Portal.
Click System > System Administration> Security > Applications > Web Application.
Click Edit in the row for the namespace in which you are using DeepSee.
Change the value of Session Timeout, which specifies the default timeout period for the CSP session, in seconds.