Cisco Active Network Abstraction Customization User Guide, 3.6.3
Customizing the Workflow Editor

Table Of Contents

Customizing the Workflow Editor

Extending the Workflow Engine With Custom Tasks and Workflow Editor Callbacks

Coding

Custom Tasks

Custom Task Panel Factories

Workflow Editor Callbacks Class

Packaging For Deployment

Custom Tasks

Custom Task Panel Factories

Workflow Editor Callbacks Class

Deploying


Customizing the Workflow Editor


This chapter explains how to extend the Workflow Engine with custom tasks and Workflow Editor callbacks.

Extending the Workflow Engine With Custom Tasks and Workflow Editor Callbacks

This section describes customizing tasks and Workflow Editor callbacks.

Coding

Custom Tasks

The procedure for developing custom tasks is explained in the Dralasoft documentation.

For example, here is the definition of a simple task class:

package samples;

import com.dralasoft.workflow.Key;
import com.dralasoft.workflow.SynchronousTask;

public class CustomTask1 extends SynchronousTask {
public CustomTask1(Key _key) {
super(_key);
}

public void perform() {
System.err.println("Hello from CustomTask1");
}
}

Custom Task Panel Factories

A TaskPanelFactory implementation class can also be assigned to each custom task class. This allows for creating custom property sheets for the custom class. This factory class should implement the interface com.dralasoft.gui.common.ext.TaskPanelFactory. A simple way to do this is to extend com.dralasoft.gui.common.ext.DefaultPanelFactory and override some of its methods.

Workflow Editor Callbacks Class

It is possible to develop a class that implements the workflow editor callbacks. This class should implement the interface com.sheer.client.workflowstudio.IWorkflowEditorCallbacks, which includes the following methods:

/**
* Called before the deploy template action
* @param templateName
* @return true if deploy template action should proceed
*/
public boolean preDeployTemplate(String templateName);

/**
* Called after the deploy template action
* @param templateName
*/
public void postDeployTemplate(String templateName);

/**
* Called before the delete template action
* @param templateName
* @return true if delete template action should proceed
*/
public boolean preDeleteTemplate(String templateName);

/**
* Called after the delete template action
* @param templateName
*/
public void postDeleteTemplate(String templateName);

/**
* @param templateName
* @return true if this template should be displayed, false if not
*/
public boolean shouldDisplayTemplate(String templateName);

Packaging For Deployment

Classes and resources must be packaged into JARs to be deployed on the server. A JAR can contain multiple tasks and an optional workflow editor callbacks implementation.

In addition to the class files, each JAR must contain a descriptor file named extension-config.xml. This file contains the XML block or blocks that define the tasks' appearance in the task palette, the tasks' custom panel factories, and, optionally, the workflow editor callbacks implementation.

Custom Tasks

In addition to the custom tasks class files, task icons should be included in the JAR.

Task icons should measure 16 by 16 pixels and must be placed in the JAR in the subdirectory, com/dralasoft/gui/common/images/16x16.

Custom Task Panel Factories

The full class name of the task panel factory should be added in an element called task-panel-factory-class inside the custom-task element. If this element were not specified, com.dralasoft.gui.common.ext.DefaultPanelFactory would be used for the custom task.

Workflow Editor Callbacks Class

Adding an editor-callbacks-class element to the extension-config element configures a class that implements the workflow editor callbacks. This element should be added to the extension-config.xml file in only one of the JAR files (if the element is present in more then one descriptor, one element's value would be used arbitrarily).

Here is an example of the contents of a task descriptor file that defines two task types, one of which has a task panel factory, and an editor callback implementation:

<extension-config>
<editor-callbacks-class>
samples.EditorCallbacksImpl
</editor-callbacks-class>

<custom-task>
<class-name>samples.CustomTask1</class-name>
<label>Custom Task 1</label>
<icon>task1.png</icon>
<tooltip>Custom Task 1</tooltip>
<menu-display>true</menu-display>
<toolbar-display>true</toolbar-display>
<task-panel-factory-class>
    com.sheer.client.workflowstudio.TestTaskPanelFactory
</task-panel-factory-class>
</custom-task>

<custom-task>
<class-name>samples.CustomTask2</class-name>
<label>Custom Task 2</label>
<icon>task2.png</icon>
<tooltip>Custom Task 2</tooltip>
<menu-display>true</menu-display>
<toolbar-display>true</toolbar-display>
</custom-task>
</extension-config>

Deploying

The procedure below describes deploying JARs:


Step 1 On the Cisco ANA gateway, copy the JARs to the following directory:

/export/home/sheer/dralasoft_extensions


Note Create the Cisco ANA gateway if necessary.


Step 2 Run the script:

/export/home/sheer/Main/scripts/
installDralasoftExtensions.pl 


Note Run this script every time you want to add or remove a JAR, or replace an existing JAR with a new version


The script installs and uninstalls JARs so that the set of installed JARs is the same as the contents of the directory /export/home/sheer/dralasoft_extensions. It is therefore recommended that you keep your extension JARs here even after they have been deployed.


Note The script also restarts the Workflow engine, so it is best to note if there are currently running workflows in the engine.


Step 3 When the script is done, run the Workflow Editor again. The deployed JARs are automatically downloaded, and the new tasks are included in the task toolbar.