Plug-ins ins and outs

[Slava Savitsky]

As I was preparing a demo instance for one of the customers last week, I realized how tedious plug-in activation could be. Activating a single plug-in is a piece of cake. But what about a dozen? Waiting for each process to complete before launching the next one is counter-productive. On the other hand, activating several plug-ins in parallel is risky due to increased performance impact and possible conflicts resulting from plug-in dependencies. Moreover, what if you needed to activate a plug-in at a specific time out of business hours?

The obvious answer is scripting, and it did not take me long to find the out-of-box script include that triggers activation of a plug-in when you press Activate button in the dialog window. With the following piece of code, you can launch plug-in activation from any server-side script or even schedule it to take place on a Christmas night without running the risk of missing the family reunion:

var worker = new GlidePluginManagerWorker();
worker.setProgressName('plugin_name');               // any descriptive name will do
worker.setPluginId('plugin_id');                           // must match the ID of the plugin
worker.setBackground(true);
worker.start();

In this example, setPluginId() method tells the system which plug-in to activate while setProgressName() simply assigns a name to the corresponding progress worker. You would typically use the Name of the plug-in here but any descriptive name will do. Should any other plug-ins be required, they will be activated automatically and within the same progress worker.

If you are not familiar with progress workers, they are a means of tracking the status of certain types of background processes. When you preview or commit an update set, import data using import sets, or even clone a Service Catalog request, there is a record in sys_progress_worker table that displays the current status of the activity and is constantly updated as the process progresses. Progress workers are available from the System Diagnostics application menu.

GlidePluginManagerWorker class also has a couple of optional methods for working with plug-in demo data. Depending on your needs, include one of these statements before worker.start() command:

worker.setIncludeDemoData(true);           // load demo data during activation of a plug-in
worker.setLoadDemoDataOnly(true);         // load demo data for a previously activated plug-in

And last but not least — there is a method for grabbing the sys_id of the relevant progress worker record.

var pw = worker.getProgressID();

You can have your script query the progress worker record to determine whether activation has completed and trigger subsequent actions such as activation of the next plug-in, an e-mail notification or closure of the corresponding change request.

Now that you are fully equipped, give it a try and share your experience and use cases in the comments.