Once you have created a new iManager plug-in, you should test the plug-in against the various iManager features to make sure it functions properly. Often, plug-in developers focus only on making the plug-in available through iManager’s navigation frame in the Roles and Tasks view when there are other integration points that should be considered as well.
Consider testing your plug-in in the following ways to make sure it performs properly:
You should test your plug-in installation and upgrade capabilities both during the iManager installation process, and after iManager is installed. Additionally, you should test installing your plug-in by downloading it and by installing it from a local drive.
Furthermore, if you bundle multiple plug-ins together into a single .npm for delivery, make sure to test the plug-in both as part of the parent installation (installing all plug-ins as a group), and as an individual (installing a single plug-in from the group) installation if that option is available.
NOTE:Linux is a good testing platform because of its file name case-sensitivity. Windows and NetWare do not use case-sensitive file names.
This section includes the following topics:
To test your plug-in installation or upgrade as part of the iManager install, you should both install a new iManager server, and upgrade an existing iManager server. As part of the install or upgrade process, users can install plug-ins from Novell’s download site or from the local file system.
To ensure your plug-in installs properly during a new iManager installation (not an upgrade), do the following:
Test downloading and installing your plug-in. For more information, see Creating a Test Download.xml File.
Install your plug-in from a local directory specified during the iManager installation routine.
To ensure your plug-in installs properly during an iManager upgrade (from iManager 2.6 to 2.7, for example), do the following:
Test downloading and installing your plug-in. For more information, see Creating a Test Download.xml File.
Test installing your plug-in from a local directory specified during the iManager installation routine.
Test upgrading iManager with a previous version of your plug-in installed. If a new plug-in is available on Novell’s download site during the iManager upgrade, it should be checked automatically and notify the user that the plug-in update is available.
Test upgrading iManager without a previous version of your plug-in installed. Unless the download.xml file specifies selected=true, your plug-in is not checked by default. For example, <moduleID selected="true">pwdpolicy</moduleID>.
To test your plug-in installation or upgrade after installing iManager, use iManager Workstation. This lets you shutdown and restart iManager as needed during the testing process. You can also easily re-install iManager Workstation, if necessary.
Once you install iManager, you can install a plug-in three different ways. You should test your plug-in using each of these installation scenarios:
Manually copy the plug-in to <TOMCAT_HOME>/webapps/nps/packages. This makes the plug-in available from > in the Configure view. Make sure you refresh the page to see the new plug-in listing.
Select Add from the > in the Configure view. This uploads the plug-in to <TOMCAT_HOME>/webapps/nps/packages.
Download the plug-in (see the steps below on how to set this up for testing). For more information, see Creating a Test Download.xml File.
During the iManager installation, the installation routine displays a URL to an XML file on the plug-in download page. Once you install iManager, you can modify the config.xml file to point to a custom XML file for downloading plug-ins.
Once you create a custom download.xml, instruct iManager, or the iManager installation routine, to use this file for downloading plug-ins by modifying the following setting in iManager’s <TOMCAT_HOME>\webapps\nps\WEB-INF\config.xml. Restart Tomcat after making the change.
<setting>
<name><![CDATA[ModuleDownloadDescriptorURL]]></name>
<value><![CDATA[http://<IP_Address>/iManager_plugins/test.xml]]></value>
<!--<value><![CDATA[file:///D:\builds\iManager\test\test.xml]]></value>-->
</setting>
The <value> tag can specify either an HTTP or file location. The default URL for downloading iManager plug-ins is:
http://www.novell.com/products/consoles/imanager/iman_mod_desc.xml
NOTE:Once you create a custom download.xml file, test that it is syntactically correct by opening it in a Web browser.
The download.xml looks similar to the following:
<modules> <module> <moduleID>CaseSensitivePassword</moduleID> <filename>CSP.npm</filename> <version>2.5.20050908</version> <min-required-version>2.6</min-required-version> <url type="zip"><![CDATA[file:///D:\builds\iManager\test\eDir_88_iMan26_Plugins.npm]]></url> <description>Case Sensitive Password Plugin</description> </module> <module> <moduleID>novell_imanager_plugins</moduleID> <filename>identity_manager_plugins.npm</filename> <version>10.0.20060302</version> <min-required-version>2.5</min-required-version> <url><![CDATA[file:///D:\builds\iManager\test\identity_manager_plugins.npm]]></url> <description>Novell Identity Manager 3 Plugins</description> </module> <module> <moduleID selected="true">pwdpolicy</moduleID> <filename>pwdpolicy.npm</filename> <version>10.0.20060302</version> <min-required-version>2.5</min-required-version> <url type="zip"><![CDATA[file:///D:\builds\iManager\test\identity_manager_plugins.npm]]></url> <description>Universal Password Management Plugin (requires IDM - Common Utilities Plugin)</description> </module> <module> <moduleID selected="true">DirXMLCommon</moduleID> <filename>DirXMLCommon.npm</filename> <version>10.0.20060302</version> <min-required-version>2.5</min-required-version> <url type="zip"><![CDATA[file:///D:\builds\iManager\test\identity_manager_plugins.npm]]></url> <description>IDM - Common Utilities Plugin (needed for Universal Password Plugin)</description> </module> <module> <moduleID>SecretStore</moduleID> <filename>secretstore.npm</filename> <version>10.0.20051209</version> <min-required-version>2.5</min-required-version> <url>http://137.65.135.100/secretstore.npm</url> <description>Secret Store Administration Plugin</description> </module>
NOTE:The download.xml file includes a <url> tag with a conditional type definition. The type definition is required for any plug-in that is part of a plug-in bundle, but that you want to be able to install separately. It specifies the type of compression (zip or targz) used with the individual plug-in files.
iManager’s Plug-in Studio lets you create additional tasks or property book pages (see Section 5.0, Using the Plug-In Studio.) Plug-in Studio is often used to create custom tasks or property book pages that simplify or limit the set of task available in an existing plug-in, or combine certain tasks from multiple plug-ins into a single interface. Because of this, newly created tasks or property book pages can contain attributes from your plug-in or product.
To test your plug-in functionality with Plug-In Studio:
Launch iManager and make sure that RBS is installed (see Setting Up Role-Based Services.)
From the Configure view, select > .
Click to open the Create iManager Task Wizard.
Create a custom task that includes attributes from your plug-in.
For information about using Plug-in Studio, see Creating a Custom Plug-In.
Test the new Plug-in Studio task to make sure it can properly access attributes from your plug-in.
A plug-in can contain multiple roles with multiple tasks. Each task in a plug-in can set specific RBS rights that allows the assigned user to perform the task. If you are assigned a role that contains more than one task, your RBS rights for that role are the combined rights for all of the tasks associated with the role.Testing your plug-in only with default role and task assignments can mask mask rights issues with individual tasks.
To test individual tasks within your plug-in:
Create a custom RBS role.
Assign one of your plug-ins individual tasks to the role.
Assign the custom RBS role to a user that does not have any rights granted via trustee assignments or through any other roles assignments.
Login as the user and verify that you can use the task without any rights issues.
You can also check the rights RBS assigns to a task by opening the Configure view and selecting > .
The Object view lets you drill down to a specific eDirectory object first, then select the task you want to perform. You should test your plug-in to make sure it functions properly when users access plug-in tasks through the Object view.
In most cases, any task available from the Roles and Tasks view should be accessible from the Object view. The name of the selected object should be passed to the task’s object name field (if this is part of the tasks functionality.) Additionally, Object view supports a multi-select mode that you should test with your plug-in. Some tasks don’t make sense in a multi-select scenario, so there might be a smaller list of available tasks for your plug-in in that case.
The Directory Administration role contains the tasks used with any object type: Create Object, Copy Object, Modify Object, Rename Object, Move Object, and Delete Object. Because of this, it is possible for these generic tasks to interact with objects improperly. For example, a generic copy operation copies all attributes of an existing object to a new object, even if some of those attributes are instance-specific and not appropriate to copy.Test the interaction of all object types specific to your plug-in against iManager’s generic task operations to make sure the generic tasks don’t corrupt the objects or cause any other unwanted issues.