Component and Object Take-On

Once your Deltanji environment has been setup, your codebase needs to be registered, bringing it under the control of Deltanji.

In the unlikely case that your codebase is small enough to register each component by hand, it may be easier to follow the Developer Guide instructions for Creating Objects / Registering Components.

However, it is likely that your codebase is too large for this to be practical. As such, Deltanji has a Bulk Component Registration function that automates this process, allowing you to run a routine with rules that specify where to register your components.

Example: A Simple LIVE/DEV Environment

Deltanji environments vary widely in their structure, so it may help to explain the loading process using a simple example.

In this example configuration, our Deltanji environment consists of two working locations - LIVE and DEV - which each map to a namespace with the same name, a 'Library' location, and a library-view location called 'Next'. The LIVE namespace contains the codebase for the live system, and the DEV namespace contains the codebase with that is currently being developed. The location called 'Next' is where finished development work builds up before a new version of the application is released to the LIVE location.

In order to bring your codebase under Deltanji's control, Deltanji needs to know what components to register, which locations to register them to, and what to do with components that have multiple versions across different namespaces.

To manage all of this, we need to perform a load for each namespace, starting with the least developed and ending with the most developed. The reason for this is because each namespace is likely to contain different versions of the same object, so the oldest versions should be loaded first. With each load, Deltanji checks to see if the component has already been loaded into the library.

  • If the contents of the component that is being loaded matches the latest version of an object that already exists in the library, that object version will simply be activated at the load location.
  • If there is an object in the library with the same name but their components don't match, Deltanji create a new version of the object at the load location and loads the component into it.
  • If there is no object in the library with the same name, Deltanji simply registers that component as a version 0 of a new object at the load location.

The Load Process

Start by identifying each namespace that contains a different copy of the codebase. For example, you may have two namespaces:

For each namespace you have identified, follow these steps:

1. Create a change request. Your Deltanji environment may have been configured with a change request type that is used for loading and registering.

2. Create a ^%vcsel list of the components that are to be loaded from this namespace. Each list entry should contain two subscripts, the first being the name of the list (perhaps named after the namespace from which the components are being loaded) and the second being the name of the component itself. As such, the list that the routine generates should contain entries that look something like this:


One way of creating the ^%vcsel list is to use InterSystems Studio to define a project that contains the components you want to load. Do this in the namespace you are loading from. Save the Studio project. Choose a short name, e.g. "Load", because the generated ^%vcsel list name must be less than 30 characters long. Then at a terminal prompt in the same namespace: d BuildFromProject^%vc414("Load")

Alternatively, create a local copy of %vc414 under a site-specific name (e.g. %vcmzYourSiteload) and amend it. See the comments in that routine.

3. Open Deltanji's terminal interface. Navigate to Manager -> Load and choose 'Show'. You will be prompted with the following screen:

Change request
For entering name of the change request you made in step 1.

Load from location
The name of the location that the components are being loaded from.

Here you should enter the name of the ^%vcsel list that you generated in step 2, preceded by an @ character and without any quotation marks. In the case of the example given, the value given in this field would be @live .

Number of prefix characters to group on
Leave as default (999).

Load to location
The name of the location to which the master version of each object should be registered. This may be the same as the 'Load from location' field, but not necessarily. For example, when loading from a LIVE location, the master version would typically be loaded to the Library location and activated at the LIVE namespace (see below).

Active locations
The names of locations where the registered objects should be activated. This should include the name of the location specified in the 'Load to location' field. Location lists can be used by prefixing their code with the '@' symbol.

Which system the new objects will belong to.

The variant name of the new objects.