TaskConfigIf

A class that implements this interface becomes a Task’s input. That is, a task that wants to accept inputs for its execution shall depend on a class that implements TaskConfigIf. The class that implements this interface should also contain all the input field definitions appropriately annotated for prompting the user. The class should also have JDO annotations to enable the Platform runtime to persist this object in the database.

A sample Config class is shown in the sample code.

AbstractTask

A task implementation must extend the AbstractTask abstract class and should provide implementation for all the abstract methods. This is the main class where all the business logic pertaining to the task goes. The most important method in this class, where the business logic implementation will be scripted, is executeCustomAction( ). The rest of the methods provide sufficient context to the Platform runtime to enable the task to appear in the Orchestration designer tree and to enable the task to be dragged and dropped in a Workflow.

To develop a task, you must first implement TaskConfigIf. During the process of setting up the task configuration interface, you must determine what data is required to perform your task.

In the following example, EnableSNMPConfig exposes details of the process of developing a TaskConfigIf. The Enable SNMP task is designed to enable SNMP on a Cisco Nexus device.

To proceed, you must have the IP address of the Nexus device, the login, and the password.

You see the annotation at the beginning of EnableSNMPConfig.

@PersistenceCapable(detachable= "true", table = "foo_enable_snmp_config")
public class EnableSNMPConfig implements TaskConfigIf
{

You must provide a PersistenceCapable annotation with a table name that is prefixed with your module ID. You must follow this convention; because Cisco UCS Director prevents a task from being registered if you try to use a table name that is not prefixed with your module ID.

public static finald String HANDLER_NAME = "Enable SNMP for Nexus";

//configEntryId and actionId are mandatory fields
@Persistent
private long   configEntryId
@Persistent
private long   actionId

The handler name is the name of the task. The name should be a unique string; you will create problems if you use the same handler name in multiple tasks.

Each task must have a configEntryId and actionId, exactly as shown above. You must have corresponding getter and setters for these two fields. These two fields are absolutely mandatory; you must have these fields in your config object.

Next, you see the data actually needed to perform the task:

//This is the ip address for the Nexus device on which you want to enable SNMP.
@FormField(label = "Host IP Address", help = "Host AP Address", mandatory = true,
     type = FormFieldDefinition.FIELD_TYPE_EMBEDDED_LOV,
     lovProvider = ModuleConstants.NEXUS_DEVICES_LOV_PROVIDER)
@USerInputField(type = ModuleConstants.NEXUS_DEVICE_LIST)
@Peristent
private String   ipAddress   = "";

@FormField(label = "Login", help = "Login", mandatory = true
@Persistent
private String   login;

@FormField(label = "Password", help = "Password", mandatory = true
@Persistent
private String   password;
   

As you review the code sample above, note that the developer needs the following:

• The IP address of the device.

  In this example, an LOV is used to get this IP address. See Annotations for more information about annotations and LOVs.

• The login and password, which the user must enter.

  To obtain these, use the form field annotations to mark these fields as data that will be provided by the user.

• Getters and setters for each of these fields.

Once the config object is completed, you must mark it for Java Data Object (JDO) enhancement.

AbstractScheduleTask

Your task logic should be placed in the execute() method of this class. Provide your module ID and a string that describes this task to get started. You must provide your own module ID, or the module will not be registered properly.

public DummyScheduleTask(){
super("foo");
}

Adding/Removing Schedule Tasks

addScheduleTask(new DummyScheduleTask());

For more information, refer the FooModule.java class.

You can develop your own input types in Cisco UCS Director. For more information, refer to Cisco UCS Director Orchestration Guide, Release 4.1. However, they must be prefixed with your module ID. See Developing a TaskConfigIf, in which an additional annotation is used to specify a custom workflow input.

public static final String NEXUS_DEVICE_LIST = "foo_nexus_device_list";
@UserInputField(type = ModuleConstants.NEXUS_DEVICE_LIST)

In this example, ModuleConstants.NEXUS_DEVICE_LIST resolves to foo_nexus_device_list.

You can enable a task to add an output.

This section describes how output can be used as input in another task. This section uses some aspects of the example in the previous section. The output definition is defined as follows:

@Override
public TaskOutputDefinition[] get TaskOutputDefinitions() {
    TaskOutputDefinition[] ops = new TaskOutputDefinitions[1};
//NOTE: If you want to use the output of this task as input to another task. Then the second argument
//of the output definition MUST MATCH the type of UserInputField in the config of the task that will
//be recieving this output. Take a look at the HelloWorldConfig as an example.
ops[0] = new TaskOutputDefinition(
      FooConstants.EMAIL_TASK_OUTPUT_NAME,
      FooConstants.FOO_HELLO_WORLD_NAME, 
      "EMAIL IDs");
return ops;
}
,

The example defines an output with the FooConstants.EMAIL_TASK_OUTPUT_NAME name, and with the FooConstants.FOO_HELLO_WORLD_NAME type. To configure another task that can consume the output as input, you must make the types match.

So, in the new task that consumes FooConstants.FOO_HELLO_WORLD_NAME as input, you must enter the following in the configuration object:

//This field is supposed to consume output from the EmailDatacentersTask. 
//You'll see the type in user input field below matches the output type 
//in EmailDatacentersTasks's output definition.
@FormField(label = "name", help = "Name passed in from a previous task", mandatory = true)
@UserInputField(type = FooConstants.FOO_HELLO_WORLD_NAME)
@Persistent
private String     login;

The type in the UserInputField annotation matches the type that is registered in the output definition. With that match in place, when you drag and drop the new task in the Cisco UCS Director Workflow Designer, you can map the output from one task as input to the other task while you are developing the workflow.

This section shows how to consume output from built-in workflow tasks as input to your custom task. This process is similar to setting up custom outputs to be consumed as input in one important way: the configuration object of your task must have a field whose type is exactly the same as the type of the output that you want.

Assuming that your module is working properly, you can verify that the custom task is in place by opening the Cisco UCS Director Task Library and verifying that the task appears in it.