Novell is now a part of Micro Focus

Solution Development Guide


We've now covered the major development tasks involved in writing a Solution Pack and making it work in a deployment environment. There are a few additional tasks that developers typically do to wrap the Solution Pack up as a nice package, which is what we'll cover in this section.

Solution Metadata

The file contains properties related to the current release of the Solution Pack, many of which are set based on prompts at the time the plug-in is created. But you can edit this file to update some of these values as needed, but note that you should not edit some of them. Here are the properties:

This specifies a description of the plug-in; edit this to describe what the primary purpose of the Solution is. This information is presented in the documentation.
The unique ID for this plug-in (autogenerated, DO NOT EDIT). When you create a new version of one of your Solution Packs, if for some reason you decide to "start fresh" and create a brand new Solution Pack but want the new one to replace the old when imported into Sentinel, then you can copy the UUID from the old Solution Pack to the new one.
This is used internally at NetIQ only.

Solution Documentation

Although the Solution Pack categories and controls are themselves self-documenting, that documentation tends to be a bit technical and lacks formatting capabilities. For this reason, each Solution Pack plug-in also includes a document template that you can use to provide an overview of your Solution. The template resides in the doc subdirectory within the Solution Pack and can be edited with the free LibreOffice word processor. Note that the documentation template that you see only includes the sections that we expect Solution Pack developers to edit; that material is then merged with some boilerplate sections to generate an output PDF.

The documentation template and the expected documentation should be pretty self-explanatory once you open the document. There are some special features, however, which are common to all SDK documentation and are described here.

Solution Pack Versioning

Solution Packs are versioned using a hybrid scheme that describes not only the version of that particular Solution Pack but also the version of the SDK against which the Solution Pack is built. A 2011.1r4 Solution Pack, for example, represents the fourth version of a particular Solution Pack built against the 2011.1 SDK template.

Each time you release a new version of a Solution Pack that you maintain, you should increment its release number to indicate to consumers that it is a new Solution Pack, that they should replace their old ones. Doing so is very simple: just edit the file in the Solution Pack directory and set the number to the new version. In fact, a production build currently prompts you to increment this automatically; it assumes that if you are doing a final production build then maybe the next build should be a new version.


This is the end of our Solution Development Guide, we hope you've found it useful. Thanks!

Solution Development Guide

© Micro Focus