ActiveVOS Central is a client application that contains Process Request Forms, Tasks, and Reports. Users of ActiveVOS Central can start a process, work on tasks, and view reports.
Current version of Central has the following feature applications accessible by selecting the appropriate 'accordion' control in the user interface:
Tasks:
Displays list of tasks available to the current user. Once a task is selected,
the user is presented with the task form and a set of action UI controls
to operate on the task (such as claim, save, and complete).
Requests:
The Requests section displays a list of forms that can be used to invoke processes.
The list of tasks that is shown in this section is based on configurations done
on the ActiveVOS server.
Reports:
Displays a list of reports to the user.
The Central web application is built on using services exposed by the ActiveVOS Server.
The primary component (web browser, ActiveVOS Central and ActiveVOS Server) interaction of ActiveVOS Central
is depicted in the following figure. ActiveVOS Central relies primarily on the AvosCentralApi
service (for configuration) and the WS-HumanTask (WSHT) taskClient services (for tasks) along with access to
resources from the ActiveVOS Catalog via HTTP GETs.
The AvosCentralApi is an ActiveVOS system service that exposes a few operations to provide
ActiveVOS Central configuration information based on the current users' role.
Process invokes made by the browser (nearly all AJAX requests) are sent to the server via a proxy servlet.
This is required to support cross-domain asynchronous requests by the browser in cases where ActiveVOS Central
and ActiveVOS Server are installed on separate hosts
When a user (with a role of abTaskClient) logs into ActiveVOS Central, the login code makes an
JSON service invoke to the AvosCentralApi service at endpoint /services/JSON/AvosCentralApi.
Because the endpoint /services/JSON/AvosCentralApi (in the server) is secured the application server
(e.g. Tomcat) intercepts the request to authenticate the user. Once the user is authenticated and authorized
(has role abTaskClient), access to the /services/JSON/AvosCentralApi service is granted.
Once authenticated the login operation uses the ActiveVOS Identity system service
When the user logs in the main page displays the Tasks, Requests and Reports sections. For example, in the case of the Requests section the list of available requests organized by category as folders are displayed. The configuration containing the list of requests and categories are obtained from the ActiveVOS Server using the AvosCentralApi service. The Request configuration (for example) list includes location of the Request HTML form in the server catalog.
When a user selects a Request (for example) the browser’s JavaScript code makes an HTTP GET request to
ActiveVOS Central to download the HTML form content (e.g: project:/path/form.html). If the form
is not available locally, then ActiveVOS Central will retrieve it from ActiveVOS Server catalog (via HTTP GET).
Before returning the HTML form content to the browser, ActiveVOS Central may (if translation is available)
replace internationalization (I18N) tokens contained in the form after downloading the appropriate
I18N bundle from the server’s catalog. The $ID suffix in HTML element names, attributes or in
avaScript are replaced with a unique string (an integer for Request forms, and taskID for Task forms).
Once the HTML form content is loaded by the JavaScript executing the Request UI the form is inserted into ActiveVOS Central's UI (e.g. the preview area) so that the form is visible and accessible to the end user.
Submitting a Request form consists of creating a JSON request with the form data and sending it the appropriate JSON service endpoint to invoke the process.
ActiveVOS Central obtains all forms from the ActiveVOS server catalog and caches them. If an updated version of a form is redeployed to the server ActiveVOS Central will only request it next time a user logs into ActiveVOS Central. During development you may need to logout and log back in to see the revised form unless you use ActiveVOS Central in debug mode.
Process Request Forms are essentially HTML forms with JavaScript that are used to invoke a process. The skeleton markup of a Request form shown below illustrates various elements used by the form. The actual form may be a little more detailed and is targeted to use with jQuery and jQueryUI.
<html>
<head>
<!-- header content -->
</head>
<body>
<!--
Main DIV that contains all markup
related to this request form UI
-->
<div id="processRequestForm$ID">
<!-- DIV that contains UI related request form and data entry -->
<div id="processRequestForm$ID">
<div>Display Name UI</div>
<!-- container for the form UI controls -->
<div>
<form id="loanApplicationInputForm$ID">
<!-- actual form content, for example: -->
First Name: <input id="firstName$ID" name="firstName" value="" size="50" /> <br/>
Last Name: <input id="lastName$ID" name="lastName" value="" size="50" /> <br/>
</form>
<!-- Send button -->
<input type="button" id="sendRequest$ID" value="Send Request" />
</div>
</div>
<!--
DIV that contains html to show
the results after submitting a form (invoking a process).
Note this DIV is initially hidden, and only shown when
response data needs to be displayed.
-->
<div id="responseContainer$ID" style="display: none;">
</div>
</div>
<!-- Script -->
<script type="text/javascript">
// <![CDATA[
// JavaScript to implement JSON process invoke
// ]]>
</script>
</body>
</html>
Note that all elements used in the form have an id attribute. The id attribute is
used as the primary selector when we need to access various elements within the HTML document.
Also note that the id attribute values that are generated end with the $ID suffix
(for example processRequestForm$ID in <div id="processRequestForm$ID">).
In cases where ActiveVOS Central needs to display the same form more than once, the element id
attribute cannot be duplicated with the same values. When the forms are used with ActiveVOS Central, the
forms server automatically replaces the $ID suffix with a unique value, so that a form can be cloned and
used in the same HTML document. For example, at runtime ActiveVOS Central may have two loan request form
instances <div id="processRequestForm_01"> and <div id="processRequestForm_02">
(note where $ID has been replaced with _01 and _02 in this example).
The JavaScript that is generated with the HTML form (in the <script /> block at the end of
the form), enclosed in a function for scoping and takes the general structure shown below:
// Function that encapsulates the form script.
var AeRequestForm$ID = function() {
// variable defining the name of service
var mServiceName = "humantaskProcessDemoService";
//
// internal functions: psuedo code shown below for brevity
//
// This function is called when the form is loaded.
function documentReady() {
// initialize and populate UI here.
// code to bind the SendButton click event to invoke _submitRequest() function
// also invoke _setupValidation();
}
// function is called (by documentReady() )
function _setupValidation() {
// optional code to setup & initialize your form data validation
}
// Function returns the JSON data structure for this operation
function getInputRequest() {
// code that creates JSON object. For example:
// var json = { "loanProcessRequest": {...} };
// return json;
}
// function called when the Send Request button is pressed.
function _submitRequest() {
// 1. validate the form by calling avcform_validate().
// 2. var jsonReq = getInputRequest();
// 3. get form UI data and populate jsonReq object
// 4. serviceUrl = AE_AJAX_SERVICE_UTIL.getActiveVOSServiceUrl("JSON/" + mServiceName);
// 5. invoke json request via:
// AE_REQUESTS_UTIL.postJSON(serviceUrl, jsonReq, _showResponseCallback, ....);
//
}
// validate the form
function avcform_validate() {
// check form date and validate (e.g. verify required fields have data etc.)
// return true if user submitted data is valid
}
// Called by postJSON(..) code in _submitRequest() function.
function _showResponseCallback(aJsonResponse) {
// called to display response from a json invoke
}
// Called by postJSON(..) code in _submitRequest() function.
function _showFaultCallback(aJsonFault) {
// handle fault
}
// Called by postJSON(..) code in _submitRequest() function.
function _communicationErrorCallback(aStatusCode, aError) {
// error handler code
}
}
// The jQuery 'ready' event is fired once the page (form) is loaded
// and ready for processing.
$(document).ready(function() {
// Create Request Form JavaScript object
var requestForm = new AeRequestForm$ID();
// initialize form
requestForm.documentReady();
});
When the form is downloaded by ActiveVOS Central to be displayed to the user, the browser renders the HTML
form and begins to execute the JavaScript associated with the form (see $(document).ready(..)).
The entry point is documentReady() function in the form JavaScript object which is responsible
for initializing and displaying the form.
The HTML forms are deployed to the ActiveVOS resource catalog on the server
and are accessible via URL http://host:port/active-bpel/avccatalog/FORM_LOCATION
where FORM_LOCATION is the location of the form with in the catalog.
(e.g. project:/proj_name/form/request/loanform.html).
In order for ActiveVOS Central to discover these forms, a .avcconfig (ActiveVOS Central)
configuration file must also be deployed to the catalog.
<ns:avosCentralConfiguration
xmlns:ns="http://schemas.active-endpoints.com/avc/2009/07/avoscentral-config.xsd">
<!-- All Requests are defined in requestCategoryDefs element -->
<ns:requestCategoryDefs>
<!--
requestCategoryDef is represented as a Folder in Central.
Add additional requestCategoryDef elements to add more 'Folders'.
-->
<ns:requestCategoryDef id="" name="Loan Applications">
<!--
A folder (category) can have one or more Requests (requestDef).
Each requestDef has a unique id, display name, description and
HTML form location. Central uses this location hint to download
the actual form and display it.
-->
<avccom:requestDef id="loanapp" name="New Car Loans (< $15K)">
<!--
You can restrict who sees this Request by specifying one more roles.
The value should be a group name or a username.
For example, this request is visible only to members of
group 'group_A' and user 'jsmith'.
-->
<avccom:allowedRoles>
<avccom:role>group_A</avccom:role>
<avccom:role>jsmith</avccom:role>
</avccom:allowedRoles>
<avccom:description>Application for a small automobile loans (under US$15,000.00)</avccom:description>
<avccom:formLocation>project:/LoanApproval/form/request/loanForm.html</avccom:formLocation>
</avccom:requestDef>
</ns:requestCategoryDef>
</ns:requestCategoryDefs>
</ns:avosCentralConfiguration>
When a user logs in, Central fetches an aggregate list of Request categories and requests
that are accessible to the current user (based on <avccom:allowedRoles>) and
displays the folders/requests accordingly.
Central uses jQuery and the jQuery Validation plugin to perform form data validation. By default, all text input fields are considered to be string type optional fields. In cases where the input text field is required or is not a string (e.g. a number or date), the generated form will have the input text fields annotated with CSS class names:
| CSS Class | Validation Rule Description |
|---|---|
avc_required_field | Makes a field required.
E.g.: |
avc_type_number | Checks to see if the data represents a number. |
avc_type_date | Validates the text field contains a date string. The format depends on the locale. |
avc_type_time | Checks to see if the input field contains a time value in HH:MM:SS format. |
In addition to the above validation CSS classnames, you can use any of the validation classnames
that are built into the jQuery Validation plugin. For example required (same as avc_required_field),
email, and url.
The two main functions within the Request form JavaScript
that are related to validation are _setupValidation() and avcform_validate().
The _setupValidation() is where the form validation is initialized as well as additional
validation rules are added. For example, if the HTML form contains an element that is a
number with XSD schema minlength and maxlength rules, the set up code may look like:
// Note: this method is auto-generated.
var _setupValidation = function() {
// bind form to the plugin
$("#loanForm$ID").validate();
// limit loan amount input field between 1000 and 5000.
// (see jQuery Validation Plugin for docs).
$("#loanAmount$ID").rules("add", {maxinclusive: 5000, mininclusive: 1000});
// other validation rules ....
}
The setup function and the additional rules in it are normally automatically
generated based on the form's schema (XSD) document.
The avcform_validate() function is called prior to the form's submission
(e.g. when the user presses the Send Request button). The code
in this form should return true if the form is valid and Request should be
sent to the server. The Request is not sent to the server if this method returns false.
// Note: this method is auto-generated.
var avcform_validate = function() {
// let the jQuery form validation plugin first do the basic validation
if(!$("#loanForm$ID").validate().form()) {
// return false if not valid
return false;
}
// do further validation if needed (e.g. if A is selected then B and C is required).
// return t/f
return true;
}
Please refer to jQuery Validation plugin page for further reference.
debug=true QueryStringAt some point during development, there may be a need to debug ActiveVOS Central forms and scripts. To begin debugging, ActiveVOS Central must:
eval() functions and
not visible (or easy to find).
To work around this issue, the browser must load the JavaScript (that is embedded in the form)
as a separate resource (file).
All of the above can be achieved by loading the ActiveVOS Central page with debug=true
in the query-string
(for example http://localhost:8080/activevos-central/avc/avc.jsp?debug=true).
When the page is loaded with debug=true, ActiveVOS Central (1) by-passes the forms cache
and downloads HTML forms from the ActiveVOS server for every single request (i.e. always
fetches the latest copy); (2) serves the JavaScript embedded in form as a separate resource
to the browser. Making available the inline JavaScript as a separate is important is
it allows you to set break points in your code using a script debugger such as FireBug
(for FireFox), Developer Script Console (for Chrome) or Developer Tools (for Internet Explorer 8).
The scripts in FireBug JavaScript debugger are available for debugging via the Script tab. The screenshot below shows a Request form named 'applyForLoan_avc_req1' (which is a runtime name; the actual name in the HTML is applyForLoan$ID) listed in FireBug's script menu. If you do not see the script associated with a specific form, then press the arrow up/down keys (on the FireBug UI) to scroll through the list of available scripts.
If you see too many scripts, (e.g. eval() functions), then
narrow down the list of scripts that is displayed to 'static' files. This option
is available in left drop down menu in FireBug as shown below.
Finally, the following screen shot shows FireBug at a break point in the loan application form JavaScript code.
When Requests (and Task) forms are displayed in ActiveVOS Central, it
uses only the contents of the <body/> in the HTML form.
The HTML elements in the <head/> are not used.
This means any references to <meta/>, <script/>, <link/>
and <style/> elements declared in your HTML <head/>
are not included in Central's main page.
<head>
<!--
Include 3rd party script to show tree control plugin.
This example requires the jQuery treeview script and the css.
-->
<link type="text/css" href="js/treeview/jquery.treeview.css" rel="stylesheet" />
<script type="text/javascript" src="js/treeview/jquery.treeview.js"/>
<!-- Include your custom or common scripts that is shared with other forms -->
<script type="text/javascript" src="js/some_util.js"/>
<!-- Inline CSS -->
<style type="text/css">
p {margin-left: 2em;}
</style>
<!-- Inline common script -->
<script type="text/javascript">
// execute your code. e.g. jQuery
$(document).ready( function() {
// do something
});
</script>
</head>
<body>
</body>
If the HTML form is as shown above, ActiveVOS Central discards
the contents of the <head/>, which means your custom script
and CSS including 3rd party scripts and CSS (e.g. jQuery tree-view) are not loaded
and executed. This is because the page that is displaying Central only deals
with form content (body). In order to inject (or contribute)
custom scripts and style into the main page that is displayed by ActiveVOS Central,
the custom scripts and CSS needs to be specified via ActiveVOS Central Includes
in a .avcconfig file instead of in the normal HTML <head/>.
With Central Includes, all custom scripts, link, styles, and meta elements
contributed by one or more forms are aggregated and dynamically included in
<head/> of the main display page of Central.
The Central Includes for the above sample HTML is shown below in
the <centralIncludes> element (in a .avcconfig file).
<!-- Central Includes in the .avcconfig file -->
<tns:centralIncludes>
<!--
Contents of the xhtml head go here as-is, with xhtml namespace.
The path to resources must be absolute href or relative
to this .avcconfig file. E.g. js/treeview/jquery.treeview.css
-->
<!-- Third party library (jQuery treeview for example) -->
<link xmlns="http://www.w3.org/1999/xhtml" type="text/css" href="js/treeview/jquery.treeview.css" rel="stylesheet" />
<script xmlns="http://www.w3.org/1999/xhtml" type="text/javascript" src="js/treeview/jquery.treeview.js"/>
<!-- Custom scripts -->
<script xmlns="http://www.w3.org/1999/xhtml" type="text/javascript" src="js/some_util.js"/>
<!-- Inline CSS -->
<style xmlns="http://www.w3.org/1999/xhtml" type="text/css">
p {margin-left: 2em;}
</style>
<!-- Inline common script -->
<script xmlns="http://www.w3.org/1999/xhtml" type="text/javascript">
// execute your code. e.g. jQuery
$(document).ready( function() {
// do something
});
</script>
</tns:centralIncludes>
Note: The xhtml elements <meta/>, <script/> , <link/>
and <style/> declared in the <centralIncludes> must be in the
xhtml namespace (http://www.w3.org/1999/xhtml). When deploying the .avcconfig,
all resources referenced in Central Includes (e.g. javascript files, CSS files)
must also be deployed to the server.
Form content can be externalized into standard bundle property files when
the form (Request or Task) is first created by selecting Externalized String
option and providing the file name and path to where the bundle is saved to.
A bundle file (for example messages.properties) is automatically created
when the form is generated.
The generated HTML contains entries in the form ${bundle_key_name}.
For example, in the case of the Loan Approval form, the label for the First Name
is given as
<head>
...
<!-- Specifies the location of the bundle file relative to the HTML form -->
<link rel="i18n" charset="UTF-8" type="text/plain" href="messages.properties" />
...
</head>
<body>
...
<tr>
<!-- bundle entry for first name -->
<th align="right">${firstName}</th>
<td> ... </td>
</tr>
...
</body>
The corresponding entry in the bundle file (e.g. messages.properties) is:
firstName=First Name: lastName=Last Name: loanType=Loan Type:
ActiveVOS links the HTML form with a bundle file by using a HTML <link rel="i18n">
element in the HTML head. Therefore, the bundle file must be deployed to the ActiveVOS server
at the time the HTML form is generated. Additional language bundles can be saved along side
of the default bundle and deployed to server - for example messages.properties (default),
messages_fr.properties and messages_fr_CA.properties.
In this case (with multiple bundles), only the default bundle messages.properties
(one without the language or country) needs to be specified in the <link/>
element.
At runtime, ActiveVOS Central downloads required bundle (based on the bundle referenced in
the <link rel="i18n"> element), and applies the translation before returning
the form content to the web browser. The requested bundle resource depends on the browser's
Accept-Language header information as configured by the user.
A URL parameter can also be used to force the use of a specific language bundle. For example to log in and
use ActiveVOS using the French (fr) language bundle, append ?lang=fr to any ActiveVOS Central URL
(e.g. http://localhost:8080/activevos-central/avc/avc.jsp?lang=fr)
Note: Applicable to ActiveVOS 7.1.2 or later.
In order to support attachments in process request forms the following changes must be made to the form.
Find the input <form> tag and change it to specify
POST as the method and multipart/form-data as the enctype.
Change from:
<form id="DocumentInputForm$ID" name="DocumentInputForm$ID" action="">
to use POST method and multipart/form-data enctype:
<form id="DocumentInputForm$ID" name="DocumentInputForm$ID" action="" method="post" enctype="multipart/form-data">
Note: This example shows form id DocumentInputForm$ID. You should
not change the form id in your HTML file.
On the next line directly below the updated <form> tag add the
following hidden input fields:
<input type="hidden" name="_json" value="" class="_json$ID" /> <input type="hidden" name="responseContentType" value="text/html" /> <input type="hidden" name="responseWrap" value="textarea" />
Add the HTML control for file upload within the HTML form, the following HTML is an example:
<input id="Document_attachment_1$ID" name="Document_attachment_1" value="" size="50" type="file" />
Move the submit button which currently is located outside of the
<form> tags into the form so that it is before </form>.
Change the type of the submit button from type='button' to
type='submit'.
<input type="submit" id="sendRequest$ID" value="Send Request" class="avc_form_instance_save" />
Delete the following two lines of JavaScript from the documentReady function:
// Assign handler for saving form data entered by the user
$("#sendRequest$ID").click(_submitRequest);
Add the following JavaScript to the documentReady function.
$('#DocumentInputForm$ID').submit(function() {
_submitRequest();
// Important always return false to prevent standard browser submit and page navigation
return false;
});
Replace the following JavaScript in _submitRequest() function:
AE_AJAX_SERVICE_UTIL.postJSON(url, request, _showResponseCallback, _showFaultCallback, _communicationErrorCallback);
with:
var jsonString = JSON.stringify(request);
$("._json$ID").val(jsonString);
var options = {
dataType : 'json',
url: url,
success: function(aJsonResponse) {
alert("Success");
$("#sendRequest$ID").attr("disabled", false);
},
error: function(aXMLHttpRequest, aTextStatus, aErrorThrown) {
alert("ERROR");
$("#sendRequest$ID").attr("disabled", false);
}
};
$("#sayHelloInputPartInputForm$ID").ajaxSubmit(options);
Note that when using this methodology (with the jQuery Forms plugin),
the success callback function is used for both - success
and faults. Your code in the success callback function
should examine the JSON result to determine if the response is a fault.
Task forms are similar to Requests where the HTML contains a input section and an output section driven by scripts. Task forms differ from Request:
Task form input is rendered as ready-only (WSHT Input) and the form response area contains editable HTML controls (WSHT Output).
Task forms interact with the WSHT API (instead of directly invoking processes like the Request forms). In Requests, submitting a form consists of POSTing JSON to the appropriate endpoint. In Tasks, 'Saving' a form is equivalent to calling WSHT API setOutput() operation.
Task forms are driven by an ActiveVOS Central task manager JavaScript framework. This framework handles common work such as task operations (claim, save) and managing peripheral data associated with a task such as comments and attachments.
The JavaScript object the models a task form is shown below.
// Function that encapsulates the task form script.
var AeTaskForm$ID = function() {
// the task name
var mTaskName = "ApproveLoan";
// task id
var mTaskId = null;
// task instance (AeTask instance)
var mTask = null;
/**
* Called by the manager to initialize the task form.
*/
this.avcform_initialize = function(aTaskId, aTaskFormContext) {
mTaskId = aTaskId;
mTaskFormContext = aTaskFormContext;
// (equivalent to Request's documentReady() fn )
//
// Initialize your code here. You can populate
// some UI fields, but not the task UI fields.
// (see avcform_onTaskReady())
//
// Set up form validation if needed
}
/**
* Called when the task instance has been loaded from the server.
*/
this.avcform_onTaskReady = function(aTask) {
// Called one time when the task instance (AeTask object)
// is first loaded (via WSHT API). Use this to initialize mTask
// and display input and outdata from the task.
mTask = aTask;
this.showData(); // display task data
}
/**
* Called when the task instance has been updated from the server.
*/
this.avcform_onTaskUpdated = function(aTask) {
// called each time the task has changed. For example, task
// was claimed (state went from READY state to IN_PROGRESS).
mTask = aTask;
}
/**
* Called when loading task instance from the server failed.
*/
this.avcform_onTaskLoadError = function(aMessage) {
// return false to allow AVC system to handle error.
// or return true to indicate that your code handled it.
return false;
}
/**
* Called to enable/disable form input fields
* @param aEnable Indicates if the form should be enabled or disabled
*/
this.avcform_enable = function(aEnable) {
// return false to allow AVC system to handle enable/disabling of form fields
// you can enable/disable your custom controls here.
// normally a form is enabled when its editable (Claimed)
return false;
}
/**
* Called to validate the task form data before the task is saved
*/
this.avcform_validate = function() {
// Called when the form needs to be validated before saving it (WSHT setOutput operation).
// The form is not saved (setOutput not called) if this method returns false.
// return true for relaxed validation on saving a form that isn't 100% complete
return true;
}
/**
* Called to validate the task form data before the task is completed
*/
this.avcform_validateForCompletion = function() {
// Validation function called before completing a task.
// Return true if the form is valid or false to prevent WSHT complete() operation.
return true;
}
/**
* Called when the task needs to be saved.
*/
this.avcform_save = function(aCompleteTask) {
// This function is called when the user presses the "Save" button.
// Code save the form (WSHT setOuput) goes here. (normally generated for you).
}
/**
* Binds data to the UI controls.
*/
this.showData = function() {
// this method is called when the task is loaded. e.g. via avcform_onTaskReady() above.
if(mTask != null) {
// show task data in UI
}
}
}
Note that at the end of the script, you will see script similar to:
$(document).ready(function() {
ACTIVEVOS_TASKFORM_CONTEXT.init(_TASK_INSTANCE_ID_, new AeTaskForm$ID() );
});
The ACTIVEVOS_TASKFORM_CONTEXT is a JavaScript object that
is made available at runtime by the framework. The _TASK_INSTANCE_ID_
is replaced at runtime with string value of the task instance ID. For example:
// runtime
$(document).ready(function() {
ACTIVEVOS_TASKFORM_CONTEXT.init("urn:b4p:123", new AeTaskForm_123() );
});
The ACTIVEVOS_TASKFORM_CONTEXT.init(...) function basically 'registers'
the task form instance with the framework. The framework will then call
back appropriate functions on the task form instance. E.g. avcform_initialize(),
avcform_onTaskReady() and avcform_onTaskUpdated().
Specifically, the task form JavaScript object interacts with Central (framework)
in the following way:
The avcform_initialize(aTaskId, aTaskFormContext) function
is called when the form in loaded. Central will then get the task
data using the Human Task API.
Once the task data is available, Central will call the avcform_onTaskReady(aTask)
function on the form object passing in the task instance.
The form UI is updated at this time to reflect the task's input and output values.
ActiveVOS Central's framework handles user interaction on the tasks operation toolbar
(such as Claim, Save). When the task state has changes due to a user interaction
(e.g. user Claimed a task), the framework will invoke the appropriate WSHT API
and later call the avcform_onTaskUpdated(aTask) function.
The avcform_enable(bool) function is also called to enable (when task is claimed) or disable the form UI.
When the Save button is pressed, the framework invokes the task form
object's avcform_validate() to validate the UI data, followed by invoking
the avcform_save() function. The code in avcform_save()
saves the form by invoking WSHT setOutput() operation.
Request forms deployed to the ActiveVOS resource catalog can also be
accessed outside of ActiveVOS Central by using a iframe.
In this case, point the iframe's src attribute
to the ActiveVOS formsviewer endpoint http://host:port/activevos-central/avc/formviewer/project_path_to_form.
http://localhost/activevos-central/avc/formviewer/project
Please see examples in examples/formviewer/formviewer.html file.