PMC distributor procedure (OP)

This chapter describes the PMC distributor procedures. This chapter contains the following sections:

  • Setup
  • To create updates
  • Feature Pack development
  • Customizations
Setup

The procedures for the update distributor to set up the PMC administration.

The setup consists of these sections:

  • Setup procedure
  • Parameters
  • Base VRCs
  • Base VRC combinations
Setup procedure

To perform the setup procedure, run these sessions:

  1. Parameters (ttpmc0100s000)
  2. Base VRC's (ttpmc0110m000)
  3. Base VRC Combinations (ttpmc0111m000)

The subsequent sections provide a detailed explanation of the procedure.

Parameters

The very first step in the distributor set-up procedure is to define the PMC parameters.

The following two group boxes are available:

  • Recipient

    Even if you do not use the PMC recipient part of the PMC module, for technical reasons, you must fill in the parameters in this group box.

  • Distributor

    The PMC distributor part of the PMC module uses these parameters, and therefore you must fill in these parameters.

    Most of the parameters are directories on the operating system on which the solution dumps will be stored.

For details, refer to the Parameters (ttpmc0100s000) session.

Hinweis

Because the definition of the parameters is a once only step, you must be aware of the impact if you change the parameters afterwards.

If you change the directories on the operating system, you must move the directories and files according to the new directory specifications.

base VRCs

You must define a base VRC before you can create and link solutions, collections, patches, and Feature Packs to the base VRC.

A base VRC is an administrative identifier for a software product and is not a physical VRC, but must always be connected to a physical VRC, which contains the software components.

The PMC distributor should connect a base VRC to an export VRC, the PMC recipient should connect a base VRC to an update VRC.

Hinweis

A Feature Pack always starts a new base VRC.

For details, refer to the Base VRC's (ttpmc0110m000) session.

base VRC combinations

Base VRC combinations are required to define relations between base VRCs.

Any base VRC must always be a member of a base VRC combination, even if no relations to other base VRCs exist.

If you have not linked a base VRC to a base VRC combination, you cannot create updates.

The following example shows a base VRC combination with two base VRCs with a relation:

[...]

For details refer to the Base VRC Combinations (ttpmc0111m000) session.

To create updates

PMC distributor procedures to create software updates:

  • To create solutions
  • To create collections
  • To create patches
  • To create Feature Packs
To create solutions

To create solutions:

  1. Create the solution.

    Create or maintain solutions in the Solutions (ttpmc1100m000) session.

    This session is the central session from which you can maintain all aspects of solutions.

    The initial status of a solution after creation is In Progress.

  2. Optionally, create defects and connect defects to the solution.

    You can create and connect the defects in the Defects by Solution (ttpmc1110m000) session.

  3. Connect software components to the solution.

    To connect software components to the solution, use the Components by Solution (ttpmc1520m000) session and the Component by Solution (ttpmc1120s000) session.

    You can also connect software components to a solution in the Connect Components to PMC Solution (ttpmc1221m000) session.

  4. Define dependencies between the solutions.

    To define dependencies between solutions, run the Dependencies (ttpmc1140m000) session.

  5. Validate the solution.

    To validate a solution, select Validate Solution on the Zusatzoptionen menu in the Solutions (ttpmc1100m000) session. This option starts the Validate Solution (ttpmc1404s000) session. This session checks, for example, if components are available, or if components are not compiled in debug mode, and so on.

  6. Export the solution.

    To export a solution, use the Export Solution/Patch (ttpmc1200s000) session.

  7. Release the solution.

    To release a solution, you must change the Status from Exported to Released in the Solutions (ttpmc1100m000) session.

    You can only release a solution if the Status of the solution is Exported.

  8. Optionally, publish the solution.

    To publish a solution, select the Published check box in the Solutions (ttpmc1100m000) session.

    You can only publish a solution if the Status of the solution is Released.

Optionally, complete these steps:

To create collections

To create collections:

  1. Create the collection.

    Create or maintain collections in the Collections (ttpmc1503m000) session.

    This session is the central session from which you can maintain all aspects of collections.

    The initial status of a collection after creation is In Progress.

  2. Connect solutions to the collection.

    You can connect solutions to a collection in the Solutions by Collection (ttpmc1151m000) session.

  3. Validate the collection.

    Validate collections in the Validate Collection (ttpmc1402s000) session.

  4. Export the collection.

    Export a collection in the Export Collection (ttpmc1210s000) session.

  5. Release the collection.

    To release a collection, change the Collection Status from Exported to Released in the Collections (ttpmc1101s000) session.

    You can only release a collection if the Collection Status is Exported.

  6. Optionally, publish the collection.

    To publish a collection, select the Published check box in the Collections (ttpmc1101s000) session.

    You can only publish a collection if the Collection Status is Released.

Optionally, view the collection history. To view the collection history, use the Maintenance History (ttpmc1560m000) session.

To create patches

To create patches:

  1. Create the patch.

    Create or maintain patches in the Patches (ttpmc1501m000) session.

    This session is the central session from which you can maintain all aspects of patches.

    Clear the New Base VRC check box. Otherwise, the patch is a Feature Pack.

    The initial status of a patch after creation is In Progress.

  2. Connect solutions to the patch.

    To connect solutions to a patch, you must use either the Solutions (ttpmc1100m000) session or the Generate Patch (ttpmc1250s000) session.

  3. Define dependencies between the patches.

    To define dependencies between patches, you must use the Dependencies (ttpmc1140m000) session.

  4. Set a password on the patch.

    To set or change the password of a patch, you must use the Password by Patch (ttpmc1105s000) session.

  5. Validate the patch.

    To validate a patch, you must use the Validate Patch (ttpmc1401s000) session.

  6. Export the patch.

    To export a patch, you must use the Export Solution/Patch (ttpmc1200s000) session.

  7. Release the patch.

    To release a patch, you must change the Status from Exported to Released in the Patches (ttpmc1501m000) session.

    You can only release a patch if the Status is Exported.

  8. Optionally, publish the patch.

    To publish a patch, select the Published check box in the Patches (ttpmc1501m000) session.

    Publish a patch if the Status of the patch is Released.

Optionally, view the patch history. You can view the patch history in the Maintenance History (ttpmc1560m000) session.

To create Feature Packs
Hinweis

The process to create Feature Packs requires a specific setup of your development environment.

The Feature Pack development section describes in detail how the setup must look.

To create Feature Packs:

  1. Create the Feature Pack.

    You can create or maintain Feature Packs in the Patches (ttpmc1501m000) session.

    This session is the central session from which you maintain all aspects of Feature Packs.

    You must select the New Base VRC check box, otherwise, the patch is not a Feature Pack.

    The initial status of a Feature Pack after creation is In progress.

  2. Define dependencies between the Feature Packs.

    Define dependencies between Feature Packs in the Dependencies (ttpmc1140m000) session.

  3. Create the header for the Feature Pack.

    Create the Feature Pack header in the Patch Header (ttpmc1106m000) session.

  4. Generate obsolete solutions for the Feature Pack.

    Generate obsolete solutions for the Feature Pack in the Generate Obsolete Solutions (ttpmc1252s000) session.

  5. Generate the Feature Pack.

    Generate a Feature Pack in the Generate Patch for New Base VRC (ttpmc1253s000) session.

  6. Validate the Feature Pack.

    Validate a Feature Pack in the Validate Patch (ttpmc1401s000) session.

  7. Export the Feature Pack.

    Export a Feature Pack in the Export Solution/Patch (ttpmc1200s000) session.

  8. Release the Feature Pack.

    To release a Feature Pack, change the Status from Exported to Released in the Patches (ttpmc1501m000) session.

    You can only release a Feature Pack if the Status of the Feature Pack is Exported.

  9. Optionally, publish the Feature Pack.

    To publish a Feature Pack, you must select the Published check box in the Patches (ttpmc1501m000) session.

    You can only publish a Feature Pack if the Status of the Feature Pack is Release.

Optionally, view the Feature Pack history. You can view the Feature Pack history in the Maintenance History (ttpmc1560m000) session.

Feature Pack development

This section describes various aspects applicable to the Feature Pack development and build process.

This section describes the following topics:

  • System setup for standard products
  • System setup for derived products
  • Rules for upgrading derived products
  • To build Feature Packs and the Infor Installation Wizard
System setup for standard products

The subsequent setup assumes that the distributor side includes a combined development/maintenance environment. This combined environment supports the maintenance of already released Feature Packs, development of a new Feature Pack, and the physical creation of solutions and Feature Packs.

Hinweis

The following examples use the following conventions for VRC naming:

  • Version: B61<X>
    X = M aintenance, D evelopment
  • Release: a<Y>
    Y = Feature Pack number
  • Customer: <zzzz>
    zzzz = extension/localization code

The following diagrams illustrate the results over time:

[...]

As soon as the initial master product, B61_a, which for the sake of simplicity is referred to simply as Feature Pack 0 in the remainder of this document, is released, the maintenance starts for B61_a in the maintenance VRC B61M_a. The development of the new Feature Pack is carried out in B61D_a1. All fixes in B61M_a are ported to B61D_a1. In the PMC registry of B61D_a1, these fixes are registered as obsolete solutions. After B61D_a1 is frozen, a final Feature Pack is created for the Feature Pack and installed in the same environment to enable you to perform maintenance on the Feature Pack.

Hinweis

The SCM revision data is not available in the Feature Pack VRC B61_a1, because the export/import software does not support the transfer of revisions. Because the original development VRC B61D_a1 is still present, you can still view revisions.

[...]

Currently, you can maintain B61M_a and B61M_a1, Feature Pack 0 and Feature Pack 1, in parallel. You must port bug fixes that are created for Feature Pack 0 between the freeze moment and the time of installation of Feature Pack 1 first. Feature Pack 2, B61D_a2, is currently in development.

You can repeat this cycle unlimited times for each new Feature Pack.

System setup for derived products

The setup becomes a bit more complex if derived products such as localizations or extensions enter the scope.

Hinweis

Customizations are also a type of derived products. For customizations, the situation differs somewhat. The section Customizations describes how to deal with customizations.

Suppose you must create a localization on top of Feature Pack 1.

A new VRC is created on top of Feature Pack 1, B61D_a1_loc1:

[...]

The localization is built on top of the standard Feature Pack and is delivered as a Feature Pack in PMC. Therefore, you must not create master media for derived products. As soon as Feature Pack 0 for the localization is available, the Feature Pack is installed in the maintenance VRC, B61M_a1_loc1.

The localization is also copied to a development VRC B61D_a2_loc1:

[...]

The first action that you must perform is to merge all bug-fixes of the standard VRC B61M_a1 into the localization maintenance VRC B61M_a1_loc1 and to create PMC solutions for the localization.

In addition, you must merge the B61D_a2 functional enhancements to B61D_a2_loc1.

From this moment on, the localization follows the same Feature Pack cycle as the standard software.

Repeat the same approach for Feature Pack 2.

The physical Feature Packs for the standard software and the localization are created and installed in a separate VRC tree B61_a2 and B61L_a2_loc1. New maintenance and development VRCs are created.

The maintenance and development VRC for the localization are populated with the components from the installed Feature Pack B61L_a2_loc1.

[...]
Rules to upgrade derived products

The following rules apply with respect to the creation of Feature Packs for derived products:

  • You must only build Feature Packs for derived products on top of Feature Packs of the parent product. Do not build Feature Packs on top of a Feature Pack plus a number of individual solutions of the parent product. The reason for this is because you can only define PMC dependencies between the Feature Pack of the standard and the derived products. You cannot define PMC dependencies from the Feature Pack of the derived product to individual solutions of the parent product.
  • The Feature Pack frequency of derived products can be greater than the Feature Pack frequency of the parent product. Therefore, you can build multiple derived Feature Packs on top of a single Feature Pack of the parent product.
  • The Feature Pack frequency of derived products cannot be lower than the Feature Pack frequency of the parent product. If you do not update a derived product in time, you will most likely face various compatibility issues between the parent and the derived product.
Building Feature Packs and the Infor Installation Wizard

PMC Feature Packs are installable units that you can install by means of the Infor Installation Wizard. Metadata that is included in a Feature Pack controls the behavior of the Infor Installation Wizard. The following aspects are relevant if you want to make your Feature Pack suitable for installation with the Infor Installation Wizard:

  • Before you build a Feature Pack, be sure to fill in the installable unit key, name, and version are filled at your PMC base VRC. If you do not fill in these values, the Infor Installation Wizard will not recognize the installable unit. For more details, refer to the Base VRC's (ttpmc0110m000) session.
  • Before you export a Feature Pack, be sure that the Feature Pack header contains the correct properties. Based on the properties defined in the Feature Pack header, the Infor Installation Wizard can automatically perform particular actions at a recipient system, such as create new package combinations, create new update VRCs, and link new update VRCs to an existing or new package combination. For more details, refer to the Patch Header (ttpmc1106m000) session.
Customizations

This section describes various aspects relevant to the development and maintenance process of customizations.

Customizations are, in most cases, built by organizations other than the producer of the related parent standard product.

The vendor who builds customizations installs the standard parent product in an update VRC.

The customization is built on top of the installed parent standard product.

This situation is specific in the sense that PMC serves both as recipient and distributor in such a development environment.

The following sections describe best practices how to develop and maintain customizations.

  • Patches and customizations
  • Feature Packs and customizations
  • Dependencies for customizations
  • Other
Patches and customizations

In some cases, the vendor of the standard parent product applies patches rather than Feature Packs as a method to provide incremental updates to the market. As opposed to Feature Packs, patches are not cumulative. The installation of a patch in an update VRC requires that you also install all preceding update VRCs in the same update VRC. This issue has consequences for the VRC setup at the distributor.

In most cases, you use a single environment to develop and to maintain multiple customizations. You build every customization on a specific patch. In addition, you must periodically upgrade existing customizations to a newer patch. As a result, you must have multiple Feature Packs of the standard parent product installed in separate VRCs. The following method is the best way to achieve this:

Install patch 1 of the standard parent product in update VRC P10U_a1_stnd. When patch 2 is available, install the patch in a new, separate update VRC P10U_a2_stnd, which is derived from P10U_a1_stnd. Patch 2 will have patch 1 as a prerequisite. You cannot install patch 2 in the new update VRC P10U_a2_stnd because patch 1 is not installed in this new update VRC. Therefore, run the Copy Solution Registry to Derived Update VRC (ttpmc2290m000) session and copy the registry of update VRC P10_a1_stnd into P10_a2_stnd. After you perform this step, you can install patch 2 directly in the P10U_a2_stnd update VRC. You can then repeat this same process for subsequent patches. The P10U_a<n>_stnd VRCs must only contain net patches. No additional solutions must be installed in these VRCs that do not belong to the relevant patch.

At this point, you have a VRC tree in which the net patches are installed in separate VRCs. In general, customizations are developed based on a net patch. However, in some cases customizations are not derived from a net patch, or a customer might want to install parent standard product solutions that have components which overlap with the customization. As a result, the customer must have the option to derive the customization VRC from any possible maintenance stage of the parent standard product. The P10U_a<n>_std update VRCs are introduced to achieve this. For every customization an intermediate VRC layer is introduced in which standard solutions can be installed that do not belong to the underlying patch. You can again use the Copy Solution Registry to Derived Update VRC (ttpmc2290m000) session to populate the PMC registry for the P10U_a<n>_std update VRCs.

The customization VRCs P10C_a_cusA, P10C_a_cusB, and P10C_a_cusC represent various customizations that are derived from various patches. Suppose customization P10C_a_cusA is developed based on the net patch 1. During development of the customization, the P10U_a1_stdA VRC will still be empty. After the customization is released and the customer installs the customization, the customer might want to install solutions of the standard parent product that also require an update of the customization. In this case, the customization vendor can install the solutions of the parent standard product in the P10U_a1_stdA VRC, port the solution to the P10C_a_cusA and provide a corresponding solution for the customization VRC. Installation of solutions in the P10U_a1_stdA VRC will only have impact on the P10C_a_cusA customization and will not impact the other customizations in the environment.

[...]
Feature Packs and Customizations

To a certain extent, the system setup is comparable to the setup described for localizations and extensions described in the section Feature Pack development. The main difference lies in the fact that Feature Packs for the parent standard product are now installed in an update VRC by means of PMC. Another differentiator is the fact that Feature Packs are cumulative, which means that Feature Packs also contain all preceding Feature Packs. To upgrade a customization to a higher Feature Pack level, having a VRC available that only contains the net changes of a Feature Pack of the standard parent product can be useful. Suppose you must create a customization on top of Feature Pack 1 for a parent standard product. Feature Pack 1 is installed in the B61U_a1_stnd update VRC and a new VRC B61W_a1_cusA is developed on top of the Feature Pack.

[...]

The customization is built on top of the standard Feature Pack and will be delivered as a Feature Pack in PMC, so no master media must be created for the customization. As soon as Feature Pack 0 for the customization is available, the Feature Pack is installed in the maintenance VRC B61M_a1_cusA.

Hinweis

In theory, you can also skip the installation of the FP in the B61M_a1_cus1 VRC and start maintenance immediately in the B61D_a1_cus1 VRC. However, best practice is to install and maintain the official build that customers also receive.

[...]

Solutions for Feature Pack 1 of the parent standard product will be installed in the B61U_a1_stnd VRC. When you scan solutions for the parent standard product, you can also print a customization report. The customization report provides an overview of which components must be updated in the B61M_a1_cusA VRC. As soon as you install the standard solution, you can merge the changes to the B61M_a1_cusA VRC and create a corresponding PMC solution for the customization.

The approach for subsequent Feature Packs is as follows: Install Feature Pack 2 for the parent standard product in the B61U_a2_stnd VRC, which is derived from B61_a VRC. Copy the contents of the B61M_a1_cusA VRC to the B61W_a2_cusA VRC. As a result, all maintenance changes you create on top of Feature Pack 0 of the customization until the moment of the copy action immediately become available in the B61W_a2_cusA VRC. After the copy, you must also port all maintenance changes in the B61M_a1_cusA VRC to the B61W_a2_cusA VRC. Feature Pack 2 for the standard product is cumulative, which means that all changes implemented in Feature Pack 1 are also present in Feature Pack 2. Therefore, you must create an overview of all components that were changed in Feature Pack 2 as compared to Feature Pack 1, and these components also must be present in the customization. To achieve this, you can use the Compare Package VRC's (ttadv6450m000) session. In this session, specify values in the following fields as follows:

VRC 1B61U_a1_stnd
VRC 2B61U_a2_stnd
Where Software Components present in VRCB61W_a2_cusA

 

Using these settings enable you to create a net overview of customized components that must be updated to be compatible with the Feature Pack 2 of the parent standard product. You can then merge all changes implemented in Feature Pack 2 of the standard product from the B61U_2_stnd VRC into the B61W_a2_cusA VRC. You can then build Feature Pack 1 for the customization, based on the contents of the B61D_a2_cusA VRC.

[...]

You can repeat this procedure for an unlimited number of Feature Packs. In addition, you can develop and maintain multiple customizations in parallel on various levels of the standard parent product.

If multiple customization VRCs are derived from, for example, the B61U_a1_stnd VRC, then for every customization, an additional update VRC layer B61U_a1_std is required between the customization VRC and the B61U_a2_stnd VRC. You can use the additional update VRC layer to install additional solutions of the parent product, which you must port to the customization. You must use the Copy Solution Registry to Derived Update VRC (ttpmc2290m000) session to populate the PMC registry for the B61U_a1_std update VRCs. Installation of additional solutions in the B61U_a1_stdA update VRC only impacts the B61M_a_cusA VRC and does not influence the B61M_a1_cusB VRC.

[...]
Dependencies for customizations

Individual solutions, patches and/or Feature Packs for customizations must have dependencies to corresponding updates of the parent standard product. Not having these types of dependencies can result in runtime compatibility problems if only a solution for the standard parent product is installed, while installation of an update for the customizations was also required.

The best way to establish these dependencies is to define co-requisite dependencies between the updates of the parent product and the corresponding updates for the customized product. The co-requisite dependencies are generated automatically if the customization uses the same solution numbers that were also used in the parent standard product. Of course this method only works if the base VRC of the customization, together with the base VRC of the standard parent product, are part of the same base VRC combination at the distributor side. At the recipient side, the update VRCs for the parent standard product and the customization must also be included in a VRC combination.

The co-requisite relationship will only be in one direction: from the customization to the standard parent product. This one-directional co-requisite makes it impossible to install a solution for the customization without simultaneously installing the corresponding standard solution for the parent product. However, as long as you have not scanned the customized solution, you can still install a solution for the standard parent product without simultaneously installing the corresponding solution of the customization. This can result in run time compatibility problems. The customization report solves this problem. When you check standard solutions in a customized environment, you can optionally print a customization report, which signals customized components and informs the recipient that, together with the standard solution, an update for the customization must also be installed.

Other

The facts described in the sections Rules to upgrade derived products and Building Feature Packs and the Infor Installation Wizard are also applicable to the development and maintenance of customizations.