NetIQ recommends that you try to adhere as closely as possible to the following best practices when developing custom packages:
Do not create objects in a custom base package. A base package should be as lean as possible and should contain only the following:
Information the base package’s relationship to other packages
If you have objects that are used by multiple drivers, store those items in a driver set package. You can create a driver set package, then store any often-reused objects in the package where any driver in the driver set can access the objects.
The standard package name is separated into two sections: [Package Group] [Package Type]. For example, if you have a base package for MySQL, the package name could be MySQL Base.
Short names must be unique and cannot be longer than 12 characters.
The standard short name for a package is separated into three sections of four characters: [Vendor][Target system][What package does]. For example, if you have a base Active Directory package created by NetIQ, the package short name could be NTIQADIRBASE.
When creating a brand-new package, we recommend you begin numbering the package at version 0.0.1. After you finish creating and testing the package and are ready to release, then you can change the version to 1.0.0.
Before you provide a custom package to a customer or other user, ensure you release the package. This helps ensure that if the user modifies the package, you do not have two different packages with different content but the same version number.
You should release only the package with the most recent time stamp.
You should configure Package A to be dependent upon another package, Package B, in the following situations:
One of the policies in Package A is dependent on a package item in Package B. This includes policies, GCVs, notification templates, and ECMAScripts.
Package A depends on some functionality included in Package B. For example, the Active Directory Password Sync package depends on the common password sync package, which defines all the necessary ECMAScript functionality.
A mandatory feature relationship is a hard-coded dependency. You should avoid using mandatory features where possible.
Instead, we recommend you configure any feature packages to be optional and then selected by default, using the selected XML attribute. Users can then deselect a feature if they do not want to install that feature. For information about configuring mandatory and optional feature packages, see Configuring Mandatory and Optional Feature Packages.
NetIQ recommends that you use policy weights or the First/Last option while assigning linkages to policies in a package. Otherwise, policies without weights are moved after policies with weights and randomly sorted in packages.
If you use the policy weights option, ensure that the weights of adjacent policies vary significantly. As a best practice, use a policy weight ending with 5 or 0. This will ensure you have enough unique numbers for assigning weights to policies while adding them to packages.
When you create a new version of a custom package, you should use the package Readme to provide customers and users information on any changes from previous versions.
To add change information to a package Readme, right-click the version of the package in the Outline view and select. Click , then click to include any changes made since the previous version of the package. Click to exit.
Policies, Entitlements, ECMAScripts, and XSLTs: The standard name for these types of package items consists of four parts separated by hyphens: [Package Short Name]-[Channel Name (Optional)]-[Policy Set and Item Type]-[Item Name]. The item name parts should be used as follows:
Package Short Name: This part should specify the short name of the package to which the item belongs.
Channel Name: This part should specify if the item belongs to either the Publisher (pub) or Subscriber (sub) channel. If the item does not belong to either channel, do not include this part in the item name.
Policy Set and Item Type: The first one or two characters of this part should refer to the policy set to which the item refers, including input transformation (ip), event transformation (et), creation (c), or matching (m). The last character in this part should be the item type, including policy (p), entitlement (e), ECMAScript (c), or XSLT (s).
Item Name: This part should specify the job done by the package item.
For example, the name of a policy in an eDirectory package that belongs to the Publisher channel could be NOVLEDIRATRK-pub-ctp-WriteAccountsOnAdds.
Filters, Schema Maps, and Global Configuration Values: The standard name for these types of package items consists of two parts separated by hyphens: [Package Short Name]-[Item Type]. The first part should specify the short name of the package to which the item belongs. The second part should specify the type of the item, whether filter (Filter), schema map (smp), or global configuration value (GCVs).
For example, the name of a filter in an LDAP package could be NOVLLDAPENT-Filter.
WARNING:You can only specify a name with a maximum number of 64 characters for any object in a package. If you add an object with a name that is 65 or more characters long to a package, you cannot deploy the object.
If a package can be used by all driver sets in the Identity Vault, set the package type as Identity Vault when you create the package. For example, if you create a default notification template package, you must create that package as an Identity Vault package.
For more information about creating Identity Vault packages, see Creating Identity Vault and Driver Set Packages.
If a package can be used by all drivers in a particular driver set, set the package type as DriverSet when you create the package. For example, if you create a common settings package, you can create that package as a driver set package.
For more information about creating driver set packages, see Creating Identity Vault and Driver Set Packages.