Special 6.4 Virtual Projects

When a 6.4 Diver Solution installation is upgraded to 7.x, two special 6.4 virtual projects are created:

  • 6.4 DiveLine Namespace
  • 6.4 Production Sandbox (only appears if the 6.4 implementation included a DI-Production environment)

These virtual projects allow you to continue working on content from 6.4 projects within Workbench without migrating to the new Spectre engine. Workbench consolidates into one interface all of the previously disparate tools, such as DI-Config, Visual Integrator, Visual Builder, and Production. The 6.4 virtual projects are required to accommodate the differences in how project resource paths are described in scripts for these tools.

TIP: You will most likely have the old "DI Projects" directories in your special 6.4 projects. These are simply folders to Workbench.

NOTE:

  • Organizing work into projects as well as using the Spectre engine are optional features in Workbench (Spectre requires a Platform license). See Migrating to the Spectre Engine for information on migrating existing projects to the Spectre engine.
  • Spectre content (cBases, cPlans, and Dives) does not work in the 6.4 DiveLine Namespace or 6.4 Production Sandbox projects. These virtual projects are designed to facilitate the upgrading of existing 6.4 content to 7.x and are not a jumping-off point for further Spectre development. Spectre development must be done in a new Workbench project.
  • ACLs for 6.4 DiveLine Namespace and 6.4 Production Sandbox projects are maintained using DI-Config.

6.4 DiveLine Namespace

  • This virtual project presents a view equivalent to File > Open in ProDiver 6.4, displaying the content of the dl-dataroot/data area plus any aliases. It is accessed by the other data clients as well: DivePort, NetDiver, and Visual Integrator for tunnel files.
  • In scripts, "/" maps to the dl-dataroot\data directory on disk, but aliases to other system paths are recognized.
  • Markers use DiveLine Namespace paths exclusively.
  • Tunnel scripts use filesystem paths.
  • The 6.4 Diveline Namespace project allows for gradual conversion and migration to the 7.x Spectre engine. The 7.x DiveLine clients will continue to work with the 6.4 models and markers. As new projects are created with Workbench, clients can start to access the new cBases and dives. See Migrating to the Spectre Engine.

NOTE: To hide the 6.4 DiveLine Namespace, delete the entire contents of the dl-dataroot\data folder (including the .project folder) and remove any aliases that are in the 6.4 DiveLine Namespace project settings.

6.4 Production Sandbox

  • This virtual project presents a view equivalent to File > Open in 6.4 DI-Production or Visual Integrator in remote mode. Production Sandbox includes the Production Root and Production Aliases. In Workbench Explorer, the project folders display and you can continue working with the files as you did in 6.4. All the file types now open in the Workbench tabbed interface, but the tools themselves are very familiar.
  • In scripts, "/" maps to the configurable Production Sandbox root, but aliases to other system paths are recognized.
  • Pathing in Production scripts is relative to this production area; pathing in Integrator scripts can be full local file system paths. When you run an Integrator script within this virtual project, all paths are resolved to the full file system paths, not to the new project paths. This allows you to use Workbench without converting your files to Workbench projects. It also allows the Production Service to continue to run old Production scripts without modification.
  • Create an alias to give the ProDiver client access to the contents of your 6.4 Production Sandbox.

NOTE: To hide the 6.4 Production Sandbox:

  1. Go to Server Settings > Projects.

  2. Click the Settings chevron.

  3. Delete the contents of the 6.4 Production Sandbox field.

Notes on Integrator

  • Using these special 6.4 virtual projects in Workbench, existing 6.4 Integrator scripts work as-is, in the way they are currently being executed, either via DI-Production or your own batch-processing methods.
  • Workbench can use both new projects, where Integrator scripts cannot refer to full local file system paths but must use project paths, as well as the existing 6.4 Production Sandbox project area, where Integrator scripts can have full local paths.
  • Existing features of the Integrator language have not been changed in the Workbench implementation. SQL input/output works the same. However, two new object types—cBase Input and cBase Output—were added to support using the Spectre technologies. Again, these are opt-in and optional. See cBase Input Object and cBase Output Object for more details.
  • If you currently use 6.4 versions of Visual Integrator and/or DI-Production, you can use the new Workbench GUI in 7.0 to develop, test, and schedule these scripts. See Visual Integrator Overview and Production Overview.
  • If you choose to migrate your 6.4 scripts to a 7.x project, be aware that full local system paths must be updated to project paths (relative pathing may not require edits). If your 6.4 solution was not using DI-Production, all paths need to be converted to use project paths.
  • Integrator scripts created using Workbench and aliases mean you are not able to execute the script from a command prompt or from an old stand alone (non-Workbench version) of Visual Integrator, since VI does not understand the project aliases.
  • VI Integrator scripts does not run in Workbench if a file references a location outside the project root. Such external locations need to be converted to use aliases. For example:
  • This fails:

    filename = "/di/solution/dl-dataroot-2170/projects/di_ppa/config/master_surveys.cfg"

  • This works:

    alias CONFIG = /di/solution/dl-dataroot-2170/projects/di_ppa/config

    filename = "/CONFIG/master_surveys.cfg"