VRC derivation

If a user starts a software component, for example a session, the Virtual Machine (VM) searches from the outside to the inside, as shown in the following figure. The Virtual Machine (VM) searches for any customizations on the component made by the customer in the own customization. If no own customizations exist, the Virtual Machine (VM) searches for a customer-specific customization, and so on.

The following figure shows how the Virtual Machine (VM) navigates through the customizations on a component.
Navigation of the Virtual Machine (VM) through the VRC structure
Navigation of the Virtual Machine (VM) through the VRC structure

The search path also depends on the package combination and company to which the user is linked. For example, the package VRCs in a development package combination are derived from the VRCs in the run-time package combination, these run-time package combinations were, in turn, derived from standard package VRCs.

The following figure shows the derivation structure of the development package combination.
Package VRC derivation structure
Package VRC derivation structure

In this previous figure, the VRCs with customer extension dev are derived from the VRCs with the cus extension, which themselves are derived from standard VRCs. If a user works with package combination b61O_a_cus and starts a software component, the Virtual Machine (VM) searches for a customization in the VRC with the cus extension. If such a customization is found, this customized component is started. If no such customization exists, the component in the standard VRC is started.

If a user works with package combination b61O_a_dev and starts a software component, the Virtual Machine (VM) searches for a customization in the VRC with the dev extension. If no such customization is found, the Virtual Machine (VM) continues the search in the cus VRC. If this VRC also does not contain a customized version of the component, the Virtual Machine (VM) starts the component in the standard VRC.

If you create many package VRCs, derived from each other, the derivation structure can get complicated.

The consequences of a cluttered and complicated VRC derivation structure are:

  • A decrease in system performance due to the longer derivation structure
  • A cluttered directory structure due to a large number of newly-created package VRCs

For this reason, you must regularly purge the VRC derivation structure. Before you can purge a package VRC, you must make sure that the VRC is not connected to a package combination. You can disconnect the package VRC from a package combination with the Packages by Package Combination (ttaad1121m000) session.

Hinweis

If you purge a package VRC, the derived-from structure changes. The user files and fd6.2 files, for the involved users and package combinations, are automatically regenerated so that they contain the new derived-from structure.

The following figure provides an example of a package VRC derivation structure before and after the purge:
Package VRC derivation structure before and after the purge procedure
Package VRC derivation structure before and after the purge procedure

Typically, only customer-defined VRCs are purged that contain customized software components that do not belong to a package combination. However, you can also purge the package VRCs that contain the standard software.

For example, the following figure shows the derivation structure of the package VRCs that contain the standard software of the LN Common package. A new standard can contain new functionality, feature packs, bug fixes, and so on.

A new standard is put on top of its predecessor, so software components can be duplicated. Therefore, you must purge the standard package VRCs regularly to remove the duplications.

Derivation structure of the LN Common package
Derivation structure of the LN Common package

The maximum VRC depth, in other words, the number of VRC that you can stack on top of each other, is 40 VRCs. However, for best results, keep the maximum VRC depth as low as possible.