<< Click to Display Table of Contents >> RayQC > 7.3 u2 > User Guide > Plug-ins > External Plug-ins  Structure of a Plug-in

Each external plug-in consists of a logic part, which has to be written in Powershell, and a declarative part, provided as XML manifest file. These file types always have to be considered as a dynamic duo that should never fall apart. Therefore, it is usually required to update both files when the plug-in function is changed, e. g. by adding a new function or modifying function signatures.

 

There are some properties that have to be defined clean and clear for each plug-in, in order to allow RayQC to recognize the plug-in resource bundle and integrate it into the checklist workflows:

 

Plug-in Name

Each external plug-in must have a name that is unique within the current plug-in context. The plug-in name is also the name of the directory which contains the plug-in script logic and manifest files. RayQC searches for these resource structures to build the set of available plug-ins for a specific checklist when it is opened for evaluation within the Checklist Viewer or for structural manipulations within the Checklist Editor.

 

Plug-in Context

The plug-in context is the environment within reach of the RayQC application instance used to build or evaluate plug-in augmented checklists. Usually it is limited to the local plug-ins sub-directory for a checklist template, along with the global plug-ins sub-directory within the RayQC application instance root folder (usually something like C:\Program Files (x86)\RayQC\).

Since RayQC is able to work with shared checklist resources from spread network locations, this context scope is quite dynamical and can be changed with every checklist transfer operation.

 

Plug-in Version

Another important plug-in property is the version, which has to be incremented whenever the plug-in sources are updated. It is documented within the manifest file, and used by RayQC to determine if a copy of the parsed plug-in logic that resides within the session memory is still up to date compared to the plug-in version stored on the physical file system.

 

Even though it is not demanded by technical restrictions, it is highly recommended to work with versions with different level indicators regarding their update status. Simply increasing version numbers as 1, 2, 3, 4 may surely do. However, providing additional information regarding the grade of manipulation may help to keep plug-in resources easily maintainable. The suggested plug-in version structure is [Major Upgrade].[Minor Update].[Small Revision].

Especially in extended QA teams it is very handy to provide this kind of meta information for shared resources if they are not explicitly managed by software versioning and revision control systems.

 

Plug-in Signature

This signature is built by the combination of plug-in name and version. Regarded as a clear identifier for a specific plug-in state, the context wide Best Practice constraint for unique plug-in signatures may save from severe maintenance troubles that might occur if plug-ins are not well aligned.

 

Just imagine the confusion caused by different version states and identical copies of the same plug-in stored in varying local and global \plug-ins\ directories: What happens to a checklist that is copied from one repository branch to another? Will the local version of the plug-in provided within the new context situation match the version that has been used in the former context? Or does the user have to copy the plug-in resources along? What if a plug-in with the same name but different version already exists in the new context?