Dodeca Version 7.0.0

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:

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.

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.11The 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.

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.

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 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:

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.

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.