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. Write a routine that generates 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 (usually 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:
^%vcsel("live","CLS.MyClass")
^%vcsel("live","MAC.MyRoutine")
^%vcsel("live","RUL.MyRule")
...
Note: Deltanji comes pre-installed with a template routine - %vc414 - that can be used as a starting point for your own. See the comments in that routine.
3. Save the routine into the namespace where Deltanji is installed.
4. 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
- Routine(s)
- Here you should enter the name of the ^%vcsel list that your routine 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 character to match
- Leave as default (99)
- 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.
- Default system
- Which system the objects will belong to
- Match variant
- The variant name of the new objects