Extension activities reference

This article provides a collection of activities that are useful in common cases.

An extension activity is defined by associating an XML element definition with an implementation handler. The implementation handler accesses the parsed XML for the activity from the global context, extracts the needed information for configuration, then extracts the data input specified by the input elements and finally runs the activity.

The symbols in the activity description can be found in the flow language behavior and syntax.

Assemble flow provides a number of useful activities for feed and XML manipulation, accessing REST services, and conversational flow among multiple people.

See the feed operators reference for feed manipulation and the XML operators reference for XML manipulation.

This article provides the following sections:

sendMail
script
template
invoke
webUI

sendMail

The sendMail activity sends the data of the flow context as e-mail. The <input> is the mail body.

<sendMail name="NCName" subject="string" address="email-exp" view="view"? >
  control*
  input
</sendMail>

Feed data is rendered as hypertext by a template.

XML data is attached as a result.xml file.

The content type of the e-mail body depends on:

The global context key /request/headers/out#Content-Type if the view attribute is specified. See the global context information for details.
The content type of the input data. You can explicitly specify the content type attribute of input.
The default is text/plain, which means that the mail body is text.

Attributes
Name	Description	Required
address	Recipient e-mail addresses. Use a comma to separate multiple e-mail addresses.	Yes
cc	Carbon copy. Use a comma to separate multiple e-mail addresses.	No
bcc	Blind carbon copy. Use a comma to separate multiple e-mail addresses.	No
subject	E-mail subject.	Yes
view	View for output. See the ReplyPOST article for details.	No

The following example shows zero.config configuration:

# Change the value of /config/connection/defaults/smtp/hostname to point to your local smtp server
# Change the value of /config/connection/flow/smtp/from to specify the default e-mail sender
/config/connection/defaults/smtp/hostname = "smtp.hursley.ibm.com"
/config/assemble/flow/smtp/from = "zeroflow@us.ibm.com"

The sendMail activity is shown in the tooling as in the following example:

sendMail-in-tooling

Script

The script activity allows the use of a Groovy script to process input data in the flow. A script file must be placed under the scripts directory {app_root}/app/scripts of the virtual directories. The <input> is bound as a variable in the Groovy script, which means input(s) must have the name attribute, and the output variable value is the return value of the last line of the Groovy script.

<script name="NCName" file="script-file-name" >
  <control>*
  <input>*
</script>

Attributes
Name	Description	Required
file	Groovy file name	Yes

Scripts are allowed to access input data with the global context. See the global context convention of extension activity information for more details.

The following example shows the script activity in the tooling:

script-activity-in-tooling

For example, if you have a flow located in /samples/hello.flow, use the following example:

<process name="testScript">
	<receiveGET name="start"/>
	<script name="sampleScript" file="hello.groovy" >
		<control source="start"/>
		<input name="when" value="Morning"/>
		<input name="who" value="John"/>
	</script>
	<replyGET name="end">
		<input value="${sampleScript}" content-type="text/plain"/>
	</replyGET>
</process>

The following example shows the {app_root}/app/scripts/hello.groovy Groovy file that you would also use:

// placed code will be output variable
"Good " + when + ", " + who + "!"

You can then access the http://localhost:8080/samples/hello.flow location and get Good Morning, John! on your screen.

template

The template activity is a complement to the script activity and allows the use of a Groovy template to process input data in flow. A template file must be placed under the views directory ({app_root}/app/views) of the virtual directories. The <input> is then bound as a variable in the Groovy template, which means that the input (or inputs) must have the name attribute, and the output variable value is the output of the Groovy template.

<template name="NCName" file="template-file-name" >
  <control>*
  <input>*
</template>

Attributes
Name	Description	Required
file	Groovy template file name	Yes

Templates can access input data using the global context. See the Global context convention of extension activity article for more information.

The following example shows the template activity in thetooling:

template-activity-in-tooling

In the following example, there is a flow at /samples/hello.flow:

<process name="testScript">
	<receiveGET name="start"/>
	<template name="sampleTemplate" file="hello.gt" >
		<control source="start"/>
		<input name="when" value="Morning"/>
		<input name="who" value="John"/>
	</template>
	<replyGET name="end">
		<inputvalue="${sampleTemplate}" content-type="text/plain"/>
	</replyGET>
</process>

This example also includes the Groovy template file {app_root}/app/views/hello.gt:

// placed code will be output variable
print "Good " + ${when} + ", " + ${who} + "!"

You can access the http://localhost:8080/samples/hello.flow location to get Good Morning, John! on your screen.

For more advanced scenarios using template and script activities, the flow tooling provides support for models that describes a set of inputs for a particular activity. See the advanced features of the Assemble Web-based visual tooling information for details about models.

invoke

The <invoke> activity invokes the REST service as shown in the following example.

<invoke name="NCNAME" service="NCNAME" format="FORMAT"? outputVariable="NCNAME"? />
	control*
	<input name="NAME" value="VALUE"/>*
</invoke>

See the REST service invocation article for more usage information.

Attributes
Name	Description	Required
service	The service description file name (without extended name) under the `/app/assemble/services` directory. For example, if the AmazonSearch.xml file is in that directory, then you can specify the `service` value as `AmazonSearch` to invoke the service.	Yes
format	Identifies the transformation.	No
`outputVariable`	Output variable	No

The <input> link in the invoke activity requires both the name and value attributes to indicate the parameter.

The following example shows the activity invoked in the tooling:

invoke-activity-in-tooling

You can find the <invoke> activity under the All services category of the tooling palette. It is listed with the name of service description, where developers could drag and drop to create the <invoke> activity for certain services.
See the Tooling support of REST service invocation article for information about invoking an activity.

webUI

The <webUI> activity works as a unit of human-system interaction in a flow. See the Simple collaboration in Assemble flow article for usage information.

<webUI name="NCName" title="notification-message-title"? assignTo="email-address"? view="view-uri"? >
	control*
	input?
</webUI>

Attributes
Name	Description	Required
`view`	View the URI for rendering activity data and user input.	No
`assignTo`	The assignee ID (usually an e-mail address)	No
`title`	Notification message title.	No

The following example shows the webUI activity in the tooling:

webUI-activity-in-tooling