This version of the Dodeca Framework uses the .NET Framework, version 2.0, Service Pack 1 and higher on the desktop. The components used in this version of Dodeca are SpreadsheetGear 2012 (7.4.2.102)*, NetAdvantage 2011, Volume 1 (11.1.20111.2042), Aspose.Cells 8.2.0.0, Syncfusion Essential Studio 11.3035.0.30, and GdPicture.NET 11.0.6.
*Upgraded from SpreadsheetGear 2012 7.1.2.150 to SpreadsheetGear 2012 7.4.2.102.
This version of Dodeca has two server-side services that run inside a Java Application Server. The Dodeca service is supported and tested on Java 1.6. The Dodeca-Essbase service for all Essbase versions prior to, and including, Essbase 11.1.1.3 are supported and tested on Java 1.5. The Dodeca-Essbase service for all Essbase versions 11.1.1.4 and higher are supported and tested on Java 1.6. Both services are known to run on Java 1.7, although extensive testing has not been performed on that Java version.
The Dodeca metadata database repository contains not only the table that stores metadata instances, such as views, selector lists, view templates, etc. The database also contains tables that store comments, audit logging and performance logging entries, shared view access information, and the binary artifact usage history.
Additional tables have been added for this release to support user
tracking, native user roles, and view usage logging. These tables
include the following: USERS
, USER_ROLES
, USER_ROLE_MAPPINGS
, and
VIEW_USAGE_LOG
.
In addition to the new tables, indexes have been added to three of the existing tables in order to improve performance. An index has been added to the COMMENTS.COMMENT_KEY_HASH, COMMENT_KEY_ITEMS.KEY_ITEM_VALUE, and DATA_AUDIT_LOG_DATAPOINTS.DATAPOINT_MEMBER and DATAPOINT_ALIAS columns.
The Application Setup Utility is used to create the database schema. If you are upgrading from a previous version of Dodeca, do not use the Application Setup Utility to update your database schema as you may risk the loss of data. Instead, contact us at support@appliedolap.com for assistance. We can provide the appropriate DDL (Data Definition Language) for your database type.
The Key Features in this release include the following:
User Management – Track, monitor, and control user access on an application-by-application basis, including the ability to monitor the number of active Dodeca users relative to the number of licensed users
User Roles – Built-in support for user role definition
Enhanced Application Security – Explicitly control access to an Admin application
Application Session Timeout – Prevent users from keeping a Dodeca session open indefinitely based on either a specified inactivity timeout or designated time
View Usage Logging – Gather statistics about view usage, including performance
Client-side Request and Response XML Logging – Provides easier access to request and response XML logging by writing the files to the client machine instead of the server
Enhanced Essbase Selector Treeview Member Expansion and Selection Filtering – Control which members can be expanded to and which members can be selected based on one or more specified filters, including Generation Number, Level Number, Member Name, Alias, or Shared Status
Enhanced SQLPassthroughDataSet Query Editing – Ability to define test token values, which are used by the Test Data Set utility to replace the tokens before executing the query
Relational Point-of-View Selector Tree – Build the hierarchy of selector items based on the results of a relational query
Improved Token Editor – View and edit the tokens and token values in a grid layout
View Selector Hierarchy Item Access Filters – Control which view hierarchy items are presented in the view selector based on the current user’s roles
View Selector Relational Hierarchy Generation – Populate the entire view selector hierarchy (or one or more branches) based on the results of a relational query
New events: BeforeBuildExecute, BeforeRefreshExecute, Shown
New Methods: ExportToExcel, SetSelectorConfiguration
Enhanced Methods: CallWebService, SendEmail, SetEntry, SetFill
New Functions: ColumnWidth, RowHeight, DataPointHasCellNote, IsInCharacterRange
Enhanced Functions: SheetCount
The release notes for this version contain the following sections:
The ApplicationIcon application setting controls the icon displayed on the task bar and title bar for a given application. The default setting, "(none)", utilizes Dodeca’s default icon.
The InternetExplorerEmulationMode application setting controls the version of Internet Explorer that will be emulated by instances of the WebBrowser view type.
The default splash screen has changed.
For any application that uses the default splash screen, the SplashProgressTextColor, which is a new setting, should preferably be set to White. By default, the color of the progress status text is Black to be consistent with previous releases.
With this version, information about each Dodeca user is captured and
retained in the Dodeca relational database repository in the USERS
table. The information is captured on an application-by-application
basis, such that for each application a user has access to (or has
accessed), a separate entry exists. An application can be configured,
using the UserAccessPolicy setting, either to automatically create an
entry for each new user or to require that an entry exists before a new
user is allowed to start the application. If the latter, it is the
responsibility of a Dodeca administrator to manually add users using the
User Manager.
When the UserAccessPolicy is set to RequireUserEntriesForStartup, a
message box can optionally be displayed when a user, who does not exist
in the USERS
table, attempts to start the application. The message box
caption and text are controlled by the
MessageCaptionForNonExistentUser and MessageTextForNonExistentUser,
respectively.
The AllowContextMenuNavigationInMetadataEditors setting controls whether users can navigate between Metadata Editors via the metadata instance context menu.
The User Manager provides an interface for Dodeca administrators to
view the contents of the USERS
table and do the following:
The following information is retained for each user entry:
USERS
table.Prior to this release, authentication services were the only means of enforcing role-based access to an application, of controlling which view hierarchies are presented in the view selector based on a user’s roles, and of allowing more extensive view sharing options. Authentication services continue to provide a way to leverage the user role (or user group) capabilities supported by third-party user security platforms, such as LDAP and Essbase.
With this release, another option for defining and associating roles
with users is being provided. This capability leverages the USERS
table, and two additional tables, USER_ROLES
and USER_ROLE_MAPPINGS
.
The User Roles editor is used to define roles and is accessed from the Admin menu. A role is defined within the context of a Tenant and may be used by any application within the tenant.
Roles are assigned to users in the User Manager. The roles for a given user may be added or removed from the dropdown list in the Roles column. Or, to expedite role assignment, the Edit Assigned Roles dialog may be used to edit the roles for all the selected users.
Application – Security
This release includes enhanced application-level security settings, which include the following:
When an authentication service is active and the setting is true, a user’s Dodeca user roles are merged into the roles returned by the authentication service. This setting can be used to allow an administrator to more easily test the view selector’s HierarchyToRoleMapping setting without having to create test users in the authentication service’s native repository, such as Shared Services for an Essbase authentication service or the database table(s) for a relational database authentication service. Similarly, it provides the ability to add Dodeca-specific roles for users without having to modify a user’s groups within Essbase or LDAP.
When no authentication service is configured, the defaults provided by the .NET framework for role-based security are used.
Refer to the Application – User Access, User Manager and User Roles section for information on how to define roles, and for information on how to assign defined roles to a user, including how to grant admin privileges to a user.
As a way for administrators to prevent users from keeping a Dodeca session open indefinitely, a session timeout capability has been implemented for this release. One of the reasons cited by customers as to why this is a needed feature is related to the use of Essbase filtered security to control when data is locked for changes. Unless a user closes and restarts a Dodeca session, the user is unaffected by the security changes.
The capability is supported as an application-level policy, which is controlled by the SessionTimeoutPolicy setting. By default, the policy is None, which allows a session to run indefinitely.
The other two options include InactivityBased and Scheduled.
With the InactivityBased option, a session timeout is applied. The application will close after a designated period of inactivity.
The following settings are used to configure the InactivityBased option:
"{0}" can be used in the message text to represent the InactivityTimeout or ScheduledCloseTime.
"{1}" can be used in the message text to represent a new line.
For example, when the InactivityTimout is set to 15 and the MessageTextForClosingSession is set to "Your Dodeca session has timed out after {0} minutes of inactivity.{1}{1}The application will now exit.", the following message will be shown:
With the Scheduled option, a session timeout will occur at a designated time. The application will close at that time.
The following settings are used to configure the Scheduled option:
The Dodeca Spreadsheet Management System Smart Client now requires a server license. For existing customers, a license file is obtained by contacting support@appliedolap.com. The license file is imported (or replaced/updated) using the Application Setup Utility.
If no license file is installed, the following message is presented when a user attempts to start the Smart Client:
If no license file has been imported, start the Application Setup Utility and advance to the Import a Dodeca License page. The page will indicate that the Dodeca license could not be validated.
To import a license file, open the file by clicking the Select License File button and locate the file using the Open File dialog. If the license is successfully validated, the message is updated to reflect the status.
The next and final step is to import the Dodeca server license by clicking the Import Dodeca License button.
The caption and message will reflect the updated license status. The same steps can be used to update or replace an existing license.
Two new authentication services are provided in this version. The DodecaUserRoles authentication service leverages native Dodeca User Roles assigned via the User Manager when evaluating whether to grant access to a Dodeca application, as well as when evaluating view sharing options. The EssbaseSimpleAuthentication authentication service provides a simple, role-less requirement for valid Essbase credentials upon application startup. This functionality can be used in conjunction with an EssbaseConnectionID that contains a valid credential-set for scheduled report generation.
The DodecaUserRoles authentication service provides a set of properties common to the other "native" authentication services, EssbaseUserRolesFromGroupNames and LDAPUserRolesFromGroupNames. These properties control access to the application, as well as roles and users with whom view sharing is allowed.
For information about authentication services and view sharing, refer to the EssbaseUserRolesFromGroupNames Authentication Service Enhancements section of the version 6.7.0.4294, February 4, 2014. And, additional information can be found by searching this document for EssbaseUserRolesFromGroupNames and for LDAPUserRolesFromGroupNames.
The EssbaseSimpleAuthentication authentication service provides a limited set of properties that specify the EssbaseConnectionID and EssbaseLoginServiceObjectTypeID against which the user will be prompted to authenticate. Limited access control can be employed using the AllowStartupForUserWithoutCredentials property.
In version 6.0.0.3106, released September 19, 2011, a configurable logging functionality was added to both the dodeca metadata and the dodeca-essbase servers using the industry standard log4j logging utility. The level of logged detail is a configurable setting, which can be specified in the dodeca-essbase log4j.properties file. Changing the setting in the configuration file requires restarting the application server.
There are times when it may be useful to change the level during a given session while trouble-shooting an issue or to gain insight into performance, etc. The log level can now be set from the client using the Log Level for Current Session tool. The level options include: INFO, which provides summary level information; DEBUG, which gives additional detailed information; and TRACE, which is the most detailed. #1346
Refer to the version 6.0.0.3106 section titled Dodeca Metadata Server and dodeca-essbase Server Logging for further information on this logging capability.
Up until this release, the ability to restrict which members within a hierarchy are represented in an Essbase selector tree and which members are selectable could only be controlled by the MaxGenExpandable and MaxLevelSelectable selector control settings, respectively. To briefly review these settings, the MaxGenExpandable setting controls the maximum (or highest) generation that a hierarchy can be expanded to.
The MaxLevelSelectable setting controls the maximum (or highest) member level that can be selected in the tree. This is particularly useful when only level 0 members should be selected. If set to 1, then both level 0 and level 1 members are selectable.
While these settings are often adequate, a more robust capability is sometimes needed. Two new settings are being introduced with this release to provide more flexibility through a finer grained level of control: MemberExpansionFilters controls which members can be expanded to, and MemberSelectionFilters controls which members are selectable.
With these filters, complex rules can be constructed to limit the expansion and the selection of members in the tree, respectively. Some performance overhead can be expected with the use of the filters, and the existing settings discussed above should be used when appropriate.
Multiple filters may be defined for each setting, and a given filter either includes or excludes members based on the specified filter definition. The filter types include the following: Generation Number, Level Number, Member Name, Alias, or Shared Status.
A Generation Number or Level Number filter string may specify one or more numbers. A Member Name or Member Alias filter string may specify a single member name (or alias), but may also include a wildcard, which could result in filtering multiple members. A Shared member filter string is either True or False to indicate a user’s shared member status.
In this simple example, the MemberExpansionFilters excludes level 0 members, with the exception of the level 0 member Stands, which is explicitly included. In addition, the Others member is excluded.
Issue: When the member hierarchy displayed by the selector tree represents a shared member rollup and only a single selection is allowed, attempting to select a member from the Find results fails.
Resolution: The Shared Members checkbox is displayed and checked by default. When checked, the Select button can be used to find and select a shared member from the search results. #1429
Fixed Issue – When an Essbase selector treeview has a base node member, whose generation is greater than the generation specified as the MaxGenExpandable, the following error is generated: Unable to show selector control. Object reference not set to an instance of an object.
Resolution: The error was replaced with more descriptive error message. For example: "Unable to show selector control. Select or List "3_Product" has a base node member with a generation that is greater than the MaxGenExpandable value of 1." #1357
Essbase Options Dialog – In previous versions, the Essbase Options dialog presented the Essbase Options in an expandable tree with the three option categories (Display, Operations, and Global) represented by root nodes in the tree. In this release, there is an alternative user-interface, which presents each of the categories of options on a separate tab. #1358
The new user-interface is the default, but the Essbase Options tool can be configured to use the previous user-interface if preferred. To change the control type:
The "Show Empty Grid Error" option has been added as an Essbase Option. The option controls whether the empty grid error is generated when the Suppress Missing and/or Suppress Zeros options are enabled and an Essbase operation results in no data rows. The error is similar to the following depending on the current settings for the suppress rows options:
No data was generated: Suppress Missing - [FALSE], Zeros = [TRUE]. Sheet not overwritten. #1425
By default, the option is False. This option would typically only be set to True for an ad hoc view, or for a drill-through sheet in an Essbase Excel view.
Fixed Issue with Zoom In – When the "zoomed in" member belongs to a dimension whose dimension number is 32 or higher and the member name is indented with spaces (i.e. the indent style is not equal to None), the following error occurs:
Unable to zoom in. Unable to perform Essbase Zoom In operation. [<member name>] is an invalid member name in database [<cube name>]. #1393
Fixed Issue with the Undo/Redo Essbase Operation tools, which display the following error when associated with a non-adhoc Essbase view:
Unable to refresh tool controller "EssbaseAdhocOperationUndoMenu". Object reference not set to an instance of an object." #1426
The undo/redo functionality is only supported for the AdhocEssbase view type.
In version 5.0.0.2260, released June 17, 2010, request and response XML server-side logging was introduced. This capability was described as follows in the release notes:
The logging functionality captures all, or selected xml transactions between the Smart Client and server tiers. The transactions are then stored in files in a given directory on the server. The files may then be used to better understand how the Dodeca tiers communicate with each other and are very useful in debugging operations.
While this capability has proven to be invaluable, the disadvantage of server-side logging is that the configured directory on the server must exist (and, if not, the application server service must be restarted after the directory is created), and a Dodeca administrator/developer must have access to the server to view the logged XML files. To address these hindrances, the ability to log the request and response XML to a directory on the client is now supported.
As with the server-side capability, the client-side logging is supported for application requests and responses as well as Essbase requests and responses.
The logging path must be specified for the application XML files and for the Essbase XML files. The same directory can be used for both, or a different directory can be specified for each. Once specified, the logging path setting is cached and used in subsequent sessions.
If you attempt to enable logging by clicking the Log Application Request and Response XML to Client tool before a logging path is specified, the folder dialog is automatically displayed to allow you to select a directory.
Unlike the server-side Essbase logging capability, client-side logging is enabled for all Essbase connections instead of on a connection-by-connection basis.
The logging capability is not intended to be used at all times, but rather on an as needed basis to capture the information entering and leaving the server primarily for debugging services. Logging can quickly generate a large number of files.
The new tools are included in the default admin toolbars, but may be added to other toolbars as needed.
The SQLPassthroughDataSet Editor has been enhanced to provide color coding for the SQL constructs, such as displaying keywords in blue, comments in green, and strings in red. In addition, tokens that use the standand token format, which begins with "[T." and ends with "]", such as [T.Market], are displayed in magenta.
The SQL Passthrough DataSets Editor now supports the ability to define test token values, which are used by the Test Data Set utility to replace the tokens within the SelectSQL statements before executing the queries. In previous releases, it was necessary to define the query (or queries), and then open and build the related view in order to test the validity of the statements. The test tokens are persisted as a part of the SQLPassthroughDataSet metadata to allow for easy re-use.
The SQL TestTokens Editor supports adding, removing, or modifying SQL test tokens.
The SQL TestTokens Editor can be accessed from the SQLPassthroughDataSet Editor by clicking the Open Editor button, "…", for a SQLPassthroughDataSet’s TestTokens setting.
The SQL TestTokens Editor can also be accessed from a Query’s SelectSQL Editor. First, open the SelectSQL Editor:
From the SelectSQL editor, the SQL TestTokens Editor is accessed by clicking the "Edit Test Tokens" button at the lower right…
…or from the context menu, which is displayed by right clicking on a token, and then selecting the "Edit Token" option.
The "Show TestToken Values" checkbox, located at the lower left of the SelectSQL editor, provides a preview of the query by replacing the tokens within the statement with the defined test token values. While in preview mode, the editor is read-only.
The Test Data Set dialog has also been enhanced to display a read-only preview of the SelectSQL statement with the tokens replaced by the test token values. This allows the executed query to be previewed along with the query results.
This release features a new SelectorControl type and corresponding SelectorList type that allow the records returned by a SQLPassthroughDataSet to be organized into a hierarchy for display in a tree. The SQLSelectorTreeView control and SQLPassthroughDataSetHierarchy selector list are available for use with SQL selectors, and they empower users by providing an accurate visual representation of structured datasets.
The SelectorControlProperties for the SQLSelectorTreeView are similar to the properties utilized by the EssbaseSelectorTreeView, and they contain only a few notable differences. In keeping with the EssbaseSelectorTree, expansion of parent items is dictated by the MaxGenExpandable property. Root nodes are assigned a generation of 1, and the generation increases with each generation of descendants. The default value of 0 allows all generations to be expanded. The MinGenSelectable property controls how far up the tree a selection can be made. The default value of 0 allows all generations to be selected.
The ItemToolTipContentOptions property controls the information that is displayed in the tooltip when hovering over an item in the tree. Available content options include the Display Name, Value, ID, Generation, Parent Display Name, Parent ID, and Ancestry.
The SelectorListProperties for the SQLPassthroughDatasetHierarchy control the mechanism by which the selector list items are obtained and the tree is constructed, as well as the token format and the policy that determines the default selection. The HierarchyPolicy property corresponds to the structure of the dataset returned by the SQLPassthroughDataSetID. The default policy option is ParentIDBased, which relies on the following properties for organizing the hierarchy: ItemIDColumnName, ItemDisplayNameColumnName, ItemIDParentIDColumnName, ItemValueColumnName, ListRootNodeIDs, ListDelimiter, and ItemIDColumnType.
For the preceding dataset, we might use the following SQLPassthroughDatasetHierarchy property values to organize the tree:
In this case, the "AREA_ID" column will be used to represent the ID and value of each selector item, and the "PARENT_ID" column will be used to represent the parent ID. The 'PREFERRED_NAME" column will be used to represent the display name for the items that will be visible to users when navigating the tree. If the ItemValueColumnName and/or ItemDisplayNameColumnName properties are not used, the selector item ID will be used for the value and/or display name. If no ListRootNodeIDs are specified, the root nodes will be any records which have no value in the "PARENT_ID" column, but we can choose the RootNodeIDs that we would like to use in order to select only a slice of the returned dataset, starting at any generational depth in the structured dataset.
The SortOrder of the root and child nodes can be set to Ascending, Descending, or DataSetOrder, and the TokenValueDelimiter, TokenValueFormat, and TokenValueItemFormat properties are used to structure the resulting selector Token for use by the view. In this case, the nodes will be sorted in ascending alphabetical order, and the selector token will be structured "AREA_ID = [item value]" for a single selection and "AREA_ID = [item value] OR AREA_ID = [item value]" when multiple selections are allowed.
The Token Editor has been revamped to present the tokens and associated values in a grid layout to provide a more user-friendly interface for viewing and editing tokens.
Two new properties have been added to all hierarchy items to support the ability to limit access to a hierarchy item based on the current user’s authenticated roles, or on the basis of Dodeca roles if no authentication service is utilized. This capability allows an administrator to determine which users will have access to a given hierarchy item without the complexity of merging multiple hierarchies.
For example, access to the "Input" Category can be limited to users who have any of the roles specified using the AccessFilter setting’s "AnySpecificRole" policy. Then, roles and/or users can be specified using the AccessFilter_SpecificRoles setting.
You will be prompted to choose from the Dodeca applications in the tenant that utilize an authentication service, or, you can simply dismiss the window to utilize only native Dodeca Users and Roles.
Once a user or role has been assigned as an access filter for the hierarchy item and the hierarchy has been selected. Only users with the chosen role will have access to the hierarchy item and its children.
This user is not a member of the Dodeca "Finance" role, and so the hierarchy category "Input" and all of its child views are no longer accessible.
View Selectors – SQLPassthroughDataSetExpandableItem
A new hierarchy item type, SQLPassthroughDataSetExpandableItem, has been added to support the ability to populate the view selector with the results of a relational query. This capability allows for either the entire view hierarchy or one or more groups (for a ViewSelectorExplorerBar) or branches (for a ViewSelectorTree) of a view hierarchy to be generated based on the query results.
In this example, the SQL Tree Hierarchy contains a single SQLPassthroughDataSetExpandableItem.
The SQLPassthroughDataSet associated with the tree contains the following query:
which returns the following rows:
And this is the ViewSelectorTree as resolved at runtime:
The table structure and query may be designed as appropriate for the environment. Some of the SQLPassthroughDataSetExpandableItem settings are used to identify which of the columns returned by the SQLPassthroughDataSet represent the values used to populate the view selector. The settings include the following:
AuthenticatedUserNameVariable Optional – To filter the hierarchy items presented in the view selector based on the name of the authenticated user, the query’s SELECT statement can include a WHERE clause that contains the AuthenticatedUserNameVariable value within a condition.
The variable serves as a placeholder, which is replaced at runtime with
the name of the authenticated user. For example, if the
AuthenticatedUserNameVariable is %USERNAME% and the name of the column
that represents the user name is UserName, the WHERE clause would be
WHERE UserName = '%USERNAME%'
.
AuthenticatedUserRolesVariable Optional – To filter the hierarchy items presented in the view selector based on the authenticated user’s role(s), the query’s SELECT statement can include a WHERE (or WHERE IN) clause that contains the AuthenticatedUserRolesVariable value within a condition.
The variable serves as a placeholder, which is replaced at runtime with the roles assigned to the authenticated user. For example, if the AuthenticatedUserRolesVariable is %USERROLES% and the name of the column that contains the roles is Role, the WHERE IN clause would be WHERE Role IN (%USERNAME%).
When the user is assigned multiple roles, the variable is replaced with a comma-delimited string of the user’s roles each enclosed in single quotes.
If no column name is specified, the display name of a category is the category’s ID, and the display name of a view is the view’s name as defined in the view metadata.
Similarly, if a column name is specified, but a value is NULL for a given hierarchy item, the name of the hierarchy item is derived as described above.
ItemTypeColumn Optional – The name of the data table column returned by the SQLPassthroughDataSet that contains the item type for the hierarchy items.
If no column name is specified, all hierarchy item rows returned by the query are assumed to represent views.
If a column name is specified, the value indicates whether the row represents a category or a view: "category" or "1" for a category, and "view" or "2" for a view. If neither value is specified, the row is ignored.
ParentItemIdColumn Optional – The name of the data table column returned by the SQLPassthroughDataSet that contains the parent item ID for the hierarchy items.
If no column name is specified, all hierarchy items returned by the query are added to the hierarchy at the same level as the SQLPassthroughDataSetExpandableItem.
If a column name is specified, a NULL value for a given hierarchy item row indicates the item should be added to the hierarchy at the same level as the SQLPassthroughDataSetExpandableItem. A non-NULL value should be the ItemID of a hierarchy item, which represents a category.
SortOrderColumn Optional – The name of the data table column returned by the SQLPassthroughDataSet that contains the sort order for the hierarchy items.
If no column name is specified, the items are ordered in the same order as the rows returned by the query.
If a column name is specified, a value represents the one-based relative order of the hierarchy item within the group of hierarchy items that have the same parent.
SQLPassthroughDataSetID Required – The ID of the SQLPassthroughDataSet metadata instance that defines the query or queries used to generate the hierarchy items. If multiple queries are defined by the SQLPassthroughDataSet, each query is executed and the combined results are used as the hierarchy items.
The queries can be tokenized. Tokens are replaced at runtime with the Application tokens.
To add a SQLPassthroughDataSetExpandableItem item to a hierarchy, select from the Item Object Type dropdown list when adding an item to the hierarchy.
As a means of gathering statistics about view usage, including performance, "view usage logging" is provided with this release. Logging is enabled and configured on an application-by-application basis. The logged view usage information is retained in the Dodeca metadata relational database repository. The log entries can be viewed from the client using the View Usage Viewer, which supports filtering and sorting as well as the ability to select specific views to report on.
Two application metadata settings are used to enable and configure view usage logging: CollectViewUsageInfo, which enables or disables logging for the application, and CollectViewUsageInfoPolicy, which controls whether the application collects view usage info for all view builds or only failed builds. View usage logging is enabled by default for all view builds.
The View Usage Viewer is accessed from the Admin menu.
The logged information includes the tenant, application, a unique usage ID, view ID, user ID, connected user ID (for an Essbase view), the time the view build was initiated, whether the view build succeeded or failed, the build duration in seconds, any build errors, and a concatenated list the token values. Both the build errors and token values strings are limited to 2000 characters.
To restrict the view usage information retrieved from the database to only the view or views of interest, the View IDs dropdown list can be used to select specific views. The Query View Usages button retrieves the related view usage information from the server and updates the list of items based on the selected view(s).
The logging information is retained in the Dodeca metadata database
table, VIEW_USAGE_LOG
.
Refer to the Dodeca Metadata (Repository) Database for additional information on adding the table to the database.
When first opened, a view is always covered. The BeforeBuildExecute event is raised on the first build and every subsequent build. (#1363)