OpenMake Meister

Custom Workflow Activity Plug-ins

When setting up your Workflows, you may find that there are activities that you run frequently, but they do not come pre-packaged. When this happens, you may need to create a reusable template for common activities that you run in Workflow Explorer called an Activity Descriptor.  Activity Descriptors are templates for activities that you run in your Workflows. They integrate with the Workflow framework and can be run as dependencies of each other. You can do this by creating your own Activity Descriptor.

In addition, you can also use the Mojo Execute Shell Command Workflow Activity Plug-in to execute any custom script that you have developed.  Should your script be used by multiple individuals and needs the ability to easily parameterize options, writing your own Workflow Activity Plug-in may be useful.

Activity Descriptors are stored as metadata files in XML format on the Knowledge Base Server under the following installation directory:

tomcat\webapps\openmake.ear\openmake.war\kb\activity descriptor

Each element in the Activity Descriptor file maps to an object on the Knowledge Base server, and the data in the XML file are structured in a very specific way.

You may need to edit the following tags to create a custom Activity Descriptor:

<ActivityDescriptor> denotes that the XML file is an Activity Descriptor metadata file. This tag is the parent tag for all elements within the document. Do not edit this tag.

<Name> is the name of the Workflow Activity as it will appear in the General Information field of the Overview Tab screen.

<Adapter> functions as the plug-in, or category, that the Activity Descriptor will exist under. You can reference existing plug-ins by typing in the plug-in name here, or you can create a new plug-in in which to place your Activity Descriptor. You can assign multiple plug-ins to an Activity Descriptor by delimiting each plug-in type with a vertical pipe |.

<Command> denotes how the final command will be resolved. The command box contains both hard-coded elements and dynamic elements/replace patterns that are defined in each text field/text box at the Workflow Activity level. Hard-coded elements, such as the executable name, and any standard or required flags that do not change between Workflows are typed "as is". Elements that are defined at the Workflow Activity level are denoted by single quotes.

For example, if you want to define a command for running a Perl Script, you would set up the <Command> tag as follows:

<Command>perl –S 'script_location'</Command>

In the above example, perl –S is the hard-coded command, and 'script_location' is the replace pattern that you will define in the Workflow Activity level.

You must define each replace pattern in the <replacePattern> child element in the <GUIComponents> tag for the value that you want to change.

<DefaultLabel> denotes what the default label for the Workflow Activity will be. This label is editable.

<DefaultView> denotes what the default view for the Workflow Activity will be. This name is editable.

<GUIComponents> denotes individual components in the GUI for the Activity Descriptor. All attributes of GUI components are nested within the <GUIComponents> tag.

<type> denotes the type of GUI component that you want to create, as shown in Table AP-1.

Table AP-1.  GUI Component Types

*Resolved Command contains the values of all component fields (text boxes, masked text boxes) of the GUI resolved into the final command as it will be passed to the Command Line. This field is not editable.

<label> is the label for the GUI component. It displays above the field that you are labeling.

<replacePattern> denotes the pattern in the Command that the selected GUI component will replace. For example, in our Perl Script example above, you would mark a text field as 'script_location' to replace the 'script_location' element in the <Command> tag.

<editable> accepts values of either "true" or "false", which denotes whether the field is editable or not.

<required> accepts values of either "true" or "false", which denotes whether the field is required or not.

<value> will pre-populate the field with whatever value you type inside this tag. This will function as a "default" value for this field.

The following is a sample Activity Descriptor XML for a SAMPLE Workflow Activity:

<?xml version="1.0" encoding="UTF-8"?>

<ActivityDescriptor>

   <Name>Update from scm</Name>

   <Adapter>SAMPLE</Adapter> 

   <Command>scmcli Get -pr'project' 'options' 'entity'</Command>

   <DefaultLabel>Update from SAMPLE-SCM for $(JOB_NAME)</DefaultLabel>

   <DefaultView>2</DefaultView>

   <GUIComponents>

     <type>2</type>

     <label>Project:</label>

     <replacePattern>'project'</replacePattern>

     <editable>true</editable>

     <required>false</required>

     <value></value>

   </GUIComponents>

   <GUIComponents>

     <type>2</type>

     <label>Options:</label>

     <replacePattern>'options'</replacePattern>

     <editable>true</editable>

     <required>false</required>

     <value></value>

   </GUIComponents>

   <GUIComponents>

     <type>32</type>

     <label>Resolved Command:</label>

     <replacePattern></replacePattern>

     <editable>false</editable>

     <required>true</required>

     <value></value>

   </GUIComponents>  

</ActivityDescriptor>