CenterView 2.x to CenterView 3.0 Post-Migration and Conversion Issues

Before you can use a CenterView 2.x dashboard with CenterView 3.0, you must complete these processes: migration, conversion, modernization.

• To migrate CenterView 2.x settings and resources (including dashboards) to CenterView 3.0, you can use CenterViewMigrator, which is a program included with CenterView 3.0. For information about running CenterViewMigrator, refer to the product documentation and the CenterViewMigrator Help.

• After running CenterViewMigrator, to convert a CenterView 2.x dashboard you must open the CenterView 2.x dashboard in CenterView 3.0. (To convert a jar file, you must open the archive in CenterView Builder. Note that you can save a dashboard as a jar file from CenterView Builder.) When you open a CenterView 2.x dashboard in CenterView 3.0, you are prompted to convert the dashboard to CenterView 3.0 format. (As part of the conversion process, CenterView Builder creates a backup copy of the original dashboard.)

  Once converted, a dashboard is fully editable in CenterView 3.0 but may not yet be fully usable in a production environment, given the product changes of CenterView 3.0.

• After converting a dashboard, to modernize a dashboard you must assess the impact of the following issues on your dashboard, then edit your dashboard accordingly.

General Issues

• If/Else tags in Builder

  CenterView Builder now processes If/Else tags differently. By default, the If tag is enabled. If you select a different tag, that tag is enabled. CenterView Builder does not evaluate the actual conditions, which lets you view conditional paths easier. When viewing the dashboard in a browser, the browser evaluates the conditions and display the condition that is true. In CenterView Builder, if you select a path that requires variables to be set, error messages may display in the preview area. To get around this problem, you can add default values inside each condition. Note that enabled paths are reset each time the dashboard is opened.

• HTML Datafunnels

  The Datafunnel handler that converts HTML to data has been modified. As necessary, modifiy datafunnels to collect data from different tables, as well as different rows and columns.

• SQL in datafunnel queries

  In CenterView 3.0, there are reserved SQL keywords, which, if used, could cause datafunnel queries (dfqueries) to stop working. These reserved keywords may or may not be reserved in all databases but are words that should probably not be used as column names. (To get queries to work that have keywords in their datasources, those columns will need to change, such as adding "CV_" as a prefix to the name. For a list of the reserved SQL keywords, refer to the product documentation.

  In CenterView 3.0, the default database used by datafunnel queries has changed from HSQL to PostgreSQL. The SQL syntax used by these two databases differs slightly, so you should verify that each datafunnel behaves as intended.

  • PostgreSQL and HSQL have different reserved words so a table column name that worked in HSQL (colname) may be converted to _colname in CenterView 3.0.
  • HSQL uses CONCAT or + to accomplish string concatenation, whereas PostgreSQL uses ||. When present, this difference causes datafunnels that work in CenterView 2.x to fail in CenterView 3.0.
  • PostgreSQL requires the keyword "AS" when creating column aliases (even though the SQL92 standard is that "AS" is optional in this situation). This means that if you convert a dfquery datafunnel from CenterView 2.x to CenterView 3.0 that did not use the keyword "AS", the datafunnel will not work.
• Theme Style Changes

  Due to changes to the structure and implementation of themes in CenterView 3.0, existing themes in converted dashboards may not appear as they did previously. As part of the update to CenterView 3.0, there are new display and layout elements, which are built on the EXT-JS framework. Additionally, some style names have changed. For details, see Style Changes from CenterView 2.x to CenterView 3.0.

• Drop-down placement next to label

  In CenterView 2.1, you could have a label and a drop-down in the same cell, and they would appear next to each other in the dashboard. In CenterView 3.0, a label and a drop-down in the same cell appear on different lines because of the "advanced-form-controls" (which are set to false by default). In a converted dashboard, you can have these two items appear next to each other on a single line either by placing each item in its own cell or by disabling the advanced-form-controls attributes for the dashboard object.

• Layout Spacing of 0

  CenterView 2.1 incorrectly ignored a "0" value for the layout spacing, treating it as a NULL. As a result, CenterView 2.1 would evenly space the cells based on the available width. In CenterView 3.0, this bug was fixed. If in a converted dashboard, you see content in cells aligned right next to each other with no space in between, check the layout object's spacing attribute. If you see a "0" for the spacing, change the spacing to a specific width, or change them to NULL (clear the spacing setting). NULL will automatically set spacing based on the available width. Note that this action, could make different layouts look unevenly spaced, based on the content in the layout so you may want to choose a consistent layout spacing and use it in all layouts.

• Popup KPI titles

  In CenterView 2.1, the window for popup KPIs (from a drilldown) used the URL as a title. In CenterView 3.0, the window for popup KPIs (from a drilldown) now has a title. In CenterView 3.0, by default the window title is the popup-name of the drilldown object but you can specify an alternate title in the popup-options of the drilldown object as "title=My Window Title Here". (Note that titles can contain spaces whereas drilldown object names cannot.)

• ../ in relative path for images

  In versions prior to CenterView 3.0, pages and kpis were loaded into iframes when displayed in the normal dashboard navigation layout. In an iframe, a relative path for the images directory was the parent of the current page. In datafunnels, to display images in kpi tables, you could use an image reference such as "../images/imagename.gif".

  CenterView 3.0 loads pages and kpis using "ajax" without iframes so all relative paths are now evaluated against the dashboard directory. CenterView 3.0 makes requests for resources in the /kpis/images and /pages/images directories load from the dashboardName/images directory.

  In a converted dashboard, you must remove the ../ in requests for resources in the relative path to images/, so the references are relative to the path they are requested from (kpis or pages).

• Auth Plugin Configurations

  In CenterView 3.0, authentication plugins are tied to the dashboard rather than the server. In previous versions, authentication plugins were configured in the dashboardserver.properties file (or in the CenterView Administrator general configurations pages). In CenterView 3.0, authentication configurations can be managed in CenterView Administrator on the Dashboards page by selecting the Manage button. (Note that changing an authentication plugin configuration no longer requires restarting CenterView Server. Additionally, to use multiple authentication plugins you must have a license key that allows using multiple authentication plugins.)

• Auth Plugin Migration

  Custom Authentication Plugins developed for previous versions of CenterView must be, at a minimum, recompiled before they can be used with CenterView 3.0 because class files are not migrated. (Note that recompiling an authentication plugin requires restarting CenterView Server.)

• Auth Plugin Group Membership

  In previous CenterView versions, an authentication plugin did not have to provide for group membership but could rely on CenterView Server to manage user to group mappings. In CenterView 3.0, CenterView Server does not manage user to group mappings for an authentication plugin. Instead, the authentication plugin must manage user to group mappings.

  In CenterView 3.0, user access to dashboards or dashboard kpis and pages can be restricted by group membership. Thus, if using an authentication plugin, if you want to restrict access to dashboards or dashboard kpis and pages by group membership, your authentication plugin must provide user to group mappings.

• KPI Sizing

  In previous CenterView versions, KPI height and width attributes were used as minimum sizes. In CenterView 3.0, they are used as absolute sizes. In the conversion process, KPI height attributes are removed; KPI width attributes with no value (null) are set to "250" and width-type is set to "min-width" (a preferred minimum width); and KPI width attributes with a value are set to the same value and width-type is set to "min-width". In CenterView 3.0, KPIs without with and height attributes are sized to fit their content.

• "use" tag

  The use tag is a means to pre-define objects and then reuse them by referencing them. In CenterView 3.0, the use tag doesn't let direct manipulation work in the header/banner/footer (it does work in the body/content section). In a converted dashboard, you can still use the Object Browser to locate the objects but you cannot use direct manipulation to locate the objects. If desired, you can convert the use tag manually.

• kpi-ref referencing variables set in Server Script in the KPI

  In CenterView 2.1, server script in the kpixml was processed with the page. In CenterView 3.0, server script in the kpixml is processed after the AJAX call to the server to get the KPI—which happens after the entire page is processed. Thus, if the server script updates any variables which affect visual elements on the page (such as a KPI title), those elements are not updated immediately and do not display correctly until the next time the page is displayed.

• Table conversion

  If you decide to convert your existing tables to the new table styles (right-click on the table and choose Convert to table groups), then you will want to be aware of these things:

  • Table conversion will not format a table group with no datasource correctly because it does not know how many columns there are. You may need to decide how you want to format the table going forward.
• KPI Toolbars

  In CV 2.x, all icons were visible in the KPI toolbar. With CV 3.0, by default KPI toolbar icons are hidden and are displayed in a dropdown list when the single triangle icon on the toolbar is selected. However, the dashboard setting kpi-toolbar-shade can be set to false to cause the KPI toolbar icons to be displayed as was the case with CV 2.x.

Style Changes from CenterView 2.x to CenterView 3.0

Name Changes

To update style names, in a text editor, open <product_root>\Server\doc_root\themes\[your dashboard directory]\theme.csx, then search for the CenterView 2.x name and replace it with the CenterView 3.0 name.

Name in CenterView 2.x	Name in CenterView 3.0
body.banner	table.banner
body.topnav	.x-tabs-strip-wrap
body	.body
.layout	tr.layout; used to set spacing on page edges
p.kpiblock (or div.kpiblock)	.kpiblock; in addition, remove "float: left;" from .kpiblock
body.dashboardcontrols	#dashboardcontrols - Dashboard controls content area
body.dashboardcontrols td	#dashboardcontrols td - Dashboard controls individual items

Added

• #west - Margin on left side of dashboard (when dashboard width < 100% and alignment is 'center')
• #east - Margin on right side of dashboard (when dashboard width < 100%)
• #wrapper - The Dashboard
• #north - Dashboard Banner (inside the 'wrapper'; includes horizontal tabs)
• #center - Body of the Dashboard. (all the pages, kpis, etc.) Wraps #content ID.
• #content - The page (content) area - both #content and .page refer to the same element. If you have things declared in #content, they will override attributes defined in .page because of style specificity (ID=100 points, class=10 points)
• .kpitoolbarspacer
• .kpitoolbartitle
• .kpitoolbaroptions (could be an error)
• .kpicontent table

Removed

• iframe: Used for KPI iframe containers; they are now embedded using DIVs instead of iFrames.
• body.kpi
• body.gap and body.gaphastop: Used to be used in the rectangular area left when there is both a left & top nav, but no longer necessary. If you need to override what EXT is doing, use .x-layout-title-west.
• table.kpitable (or div.kpicontent)
• .foottext: Was used for text within primary footer. Use .footer1 instead.
• .urltoolbartable - Was used when a kpi was loaded by referencing a URL.
• .urltoolbartitle - Was used when a kpi was loaded by referencing a URL.
• .urltoolbaroptions - Was used when a kpi was loaded by referencing a URL.
• .bannerlabel - Unknown what this was for.
• .layout td - Was used to make the KPI fit in the iFrame without scrolling. DIVs are now used instead of iFrames.

Deprecated

The following are obsolete and may be unsupported in a future release.

• All the classes for the 2.x version tables: for example, td.table1xxx, td.table2xxx, etc. These are included in current themes and supported by CenterView 3.0, but will be removed in a future release.