Platform Migration Checklist

• Start with a copy of the live environment
• Watch out for different system paths for DI files
• DI software: E:\DI_Solution versus D:\di\solution\dev (standard varies by version)
• ETL scripts: Integrator, Production, DIAL
• Search and replace paths using Workbench, unless you already parameterized your scripts
• Watch out for scripts dependent on system PATH variable, for example
• Integrator scripts calling integ without a specific path
• Execute nodes in Production scripts

6.4 DiveLine Namespace

• Accessed by data clients (ProDiver, DivePort, NetDiver), and VI for tunnel scripts
• Forward slash (“/”) maps to the dl-dataroot\data directory on disk
• Supports aliases to “mount” other system paths
• Markers use DiveLine Namespace paths exclusively
• Tunnel scripts use file system paths

6.4 Production Sandbox

• Accessed by development tools (DI-Production, Visual Integrator)
• Forward slash (“/”) maps to the configurable Production Sandbox root
• Supports aliases to “mount” other system paths
• Production scripts use Production Sandbox paths
• Integrator scripts use file system paths

Projects

• Accessed by all DI clients
• Forward slash (“/”) maps to a particular root directory on disk (project root)
• Supports system aliases to “mount” other system paths
• Supports project aliases to “mount” paths from other projects
• All files use project paths to refer to other files, but there are exceptions
• You can escape the project via Execute node and Execrow objects, if enabled
• You can escape the project via Production Extensions
• Functions in DIAL that save files to disk use local file system paths
• Paths inside Integrator scripts can be problematic, unless they use relative or parameterized paths
• Use the home project feature to manage end-user access

Access Control in 6.4 DiveLine Namespace

• For each file or directory:
• Search for an ACL for the current user
• If none found, search for ACLs for the user’s groups
• If none found, search for the ACL for the “*” user
• Limits combine both the rule and the data values
• Group X: Limit Dimension “Region” to “North” and “South”
• Group Y: Limit Dimension “Region” to “West” and “East”
• Deletes name columns to remove
• Group Z: Delete column “Cost”

Access Control in 7.x Projects

• Directory-level only—see About Access Control
• Rules can be conditional or unconditional—available conditions are:
• User—if-user in script,
• Group—if-group in script,
• Property—if-property in script
• All Users—nothing added to script (no condition set—equivalent to all users allowed)
• Possible and important to separate rule from data values (best practice):
• User and group properties assign values for properties defined on the server
• Single rule: Limit column Region to values in the AllowedRegions user property assignments
• Assign group X the values North and South for AllowedRegions
• Assign group Y the values East and West for AllowedRegions
• Can also assign the special All Values (any decision based on limiting the property will always succeed)—see Assigning Default Property Values

• Row-limiting rules are converted to expressions internally and then AND'ed together

• You can write your own expressions to achieve a UNION access rule, such as:

• The value Regions in the AllowedRegions property OR the value Products in the ManagedProducts property

• The restrict-column tag is used to list columns with restrictions—so they are gone for all non-admin users

• Restore access with a conditional rule (for user, group, or property)

• Best practice is to avoid rules about specific users or groups—make the rules about properties so you can separate the rules from the data values—see Properties: Separating Access Control Rules from Data Values

• Data processing engine designed for in-memory use—see What's New for 7.0?
• Column-oriented data storage; no dimensions limit—see Spectre Overview
• Generate Spectre Build—input from text, cBase, or ODBC—see Creating cBases with Spectre Build Scripts
• Over 200 functions for in-memory calculations—see Alphabetized Functions for Spectre
• Syntax-Aware text editors—see Syntax-Aware Text Editor
• Spectre Expression editor—see Spectre Expressions Editor

• Spectre cBases can only exist in Workbench projects (7.x)
• Existing models can be used in the classic DiveLine Namespace
• Do you migrate everything or start with a single project?
• Side-by-side models and cBases
• Incremental approach
• Possible to leave models in DiveLine Namespace (or move to project and update access control)
• Clients like ProDiver and DivePort can access a combination of models and cBases
• Configure a Start Project to cope with multiple Projects

• Fix paths when moving Integrator scripts into a project (use project paths rather than system paths)—see Project Paths
• Rewrite any scripts (int, tnl, dsc) that use dependency expressions (that is #if...#endif)—see Visual Integrator Object Types
• Convert Builder objects to cBase Output—see Creating cBases with Visual Integrator Scripts
• Examine consolidated multimodels: Build single cBase when structurally the same—see What is a cBase?
• cBase data can be pulled back into your Integrator script with filtering applied—see VI cBase Input Object
• Differences to note and watch for are:
• All fields nullable in a cBase—see Null Values in Spectre
• Strict types in Spectre calc language—see Spectre Data Types
• Extra step to convert date numbers—see Date and Time Functions
• Custom calendars for periods—see About Spectre Calendars
• Data sorts differently—see cBase versus Model Sorting
• New filter functionality—see What is a QuickView Set?
• cBases lists columns alphabetically while classic model lists columns in the order in the INTEG OUTP object—see Dimensions and Categories
• Lookups can be done at build time (recommended) or in a dive—see Build Code Lookup Samples
• ProDiver cumulative columns used for rank behave differently with cBases than with Models—Using Cumulative Columns to Rank Values
• Create cPlans—see What is a cPlan?
• Can be simple: Referencing a single cBase—gives you a place to add calcs later without impacting markers
• Can be complex: Filter data set different ways (which years to include, which facilities), replaces sub-consolidation
• Multilevel also available in cPlans—see Multilevel cPlans
• Convert 6.4 DivePort portals to 7.0—see Converting DivePort 6.4 to to 7.x

• Create build scripts for Spectre Build—see What is a Spectre Build?
• Full control and more power compared to cBase Output object
• Build-time lookups
• Parallel building an option to maximize hardware usage
• Perform calcs, sorting, filtering
• Select subset of all diveable fields for ProDiver console
• Store interim data in cBase repositories (saves repeated text parsing)
• Concatenate cBases (last year’s cBase—unchanged—plus this year’s)

• Replace “use this Model” or “merge these Models” with “use this cPlan”
• Difficulty increases if markers refer to models directly rather than to a user DivePlan
• Use of search paths adds a complication

• Originally intended to help move to client-server

• Lazily put sales.mdl in a models directory; markers figure it out

• Annoying when lots of search paths to check

• Problematic when multiple matches, differing only by access control

• Will need a single cBase, with access rules

• Filtering in a cPlan using username/properties also possible, but complicates understanding of access control

• Evaluate and understand existing strategy—see DiveLine Security: 6.x versus 7.x
• Watch out for file and model-specific ACL rules
• Identify what property/value pairs are needed
• Write rules in terms of properties (best practice)
• Consider conditional rules if appropriate
• Assign property values in terms of groups

• Decide if assignments will be managed in Workbench or externally

• Run through the testing plan:
• Automated and manual testing
• Verify that the results are the same for 6.4 and 7.x
• Developers to test back-end processing:
• Extracts, processing, cBase builds
• Successful nightly processing
• Users to test presentation side:
• ProDiver reports
• DIAL reports emailed
• DivePort page displays and functions