Location Types
All locations in a Deltanji environment should fall into one of the following categories: working location, library-view location, virtual location, generic location and NEW location. Each location type serves its own particular purpose, which affects how users interact with those locations.
Working Locations and Library-View Locations
These two location types are the most common, and can be described in contrast to each other.
A working location can be identified by its yellow folder icon: 
. When an object exists at this kind of location, the user is able to access its
components, execute them, and perhaps modify them too. Essentially, this kind of location
is designed to let the user do something to the objects. More specifically, this kind of location maps at least
some of its objects' components to a physical storage space that isn't the library.
In contrast, a library-view location only maps its objects' components to the library. As such, this kind of location is designed to let the user know something about the objects it contains. They can be identified by their blue folder
icon: 
.
For example, five locations have been grouped into a location class called 'Dev1':
- 'RefreshSandbox1' is a library-view location because it is designed to show the user a list of objects that other developers have modified.
- 'NextRelease' is a library-view location because it is designed to show the user a list of objects that comprise the next software release.
- 'Sandbox1' is a working location because it maps onto a physical storage space that this developer can access. It is set up so that the user can check objects out to it, at which point they can modify and execute them.
- 'ForTesting' is a library-view location because it is designed to show the user a list of objects that they have worked on but that have not been tested yet.
- 'Failed' is a library-view location because it is designed to show the user a list of objects that they have worked on and that have failed testing.
Note: It is important to note that object versions can exist at multiple locations. Just because an object version is at a library-view location does not mean that it cannot be executed, because it may also exist at a working location.
Virtual Locations
A virtual location does not map to any physical storage spaces. They can be identified
by their white folder icon: 
.
When an object version is transferred to it, no components will physically be transferred. However, the statuses of the object version will be updated in accordance with the transfer route. This kind of location cannot, of course, be used as the source location for a transfer route if the components must physically be transferred to the destination location.
This kind of location is suitable for transfers which indicate the next step in the development cycle, without the need for components to be retrievable from the location. An example is a transfer from a 'ready for testing' step to 'accepted'.
While virtual locations share commonalities with library-view locations, it is recommended that library-view locations are used unless there is a particular reason for using virtual locations instead. When objects are in a library-view location, their components' contents can be viewed, which means they can be diffed. Users cannot view the contents of an object's components if it only exists at a virtual location because the components do not map to any physical storage space.
Generic Locations
Generic locations are built-in entities which can be used to simplify the setting up of transfer routes, particularly when a route is likely to be copied or replicated. They are pre-defined during the installation of Deltanji and should not be modified or deleted. There are three generic locations that can be used:
- %ANY - a generic location which functions as a wildcard for all existing locations. It can be used in the 'from location' and the 'to location' field of a transfer route.
- %FROM - a generic location which represents the 'from location' of a transfer route. It can be used in the dependent locations, new active locations and message fields of a transfer route.
- %TO - a generic location which represents the 'to location' of the transfer route. It can be used in the dependent locations, new active locations, new master location and message fields of a transfer route.
%FROM and %TO can be used in the definition of any transfer route. However, they are particularly useful when %ANY is used in either the 'from location' or the 'to location' field.
They can be identified by the location names listed above, and by their white folder
icon: .
The NEW Location
This location is necessary for registering components in the terminal interface. Most users are unlikely to encounter it, and by default it is hidden using the NOBODY access right.
For more information, see the system manager guide article on managing locations.
See Also: Locations, Transfer Routes, Managing Locations, Physical Storage, The Library