Web Forms - WF

Web forms are a way to create a simple interface with a Workflow model directly (and BusinessPlus tables indirectly) for the casual users or users that require a simpler interface.

Class Structure

The basic functions of the Workflow Web forms are handled by a base class called Workflow. It wraps all of the functionality that was originally required by multiple ASP include files into a class that the Web form page is based on. The Workflow Base Class in turn inherits the Portal Page Base Class. The hierarchical class structure is as follows:

• Namespace: IFAS.Portal.Workflow.Form

• Web Form Page: IFAS.Portal.Workflow.Form.Webform

• Base Class: IFAS.Portal.Workflow.WorkflowForm based on Portal Page class

The Base Class wraps the functionality of the page to perform as a BusinessPlus form. This includes the following components:

• Workflow infrastructure variables

• Workflow connectivity functions

• Workflow helper methods

Templates

Web forms are not based on BusinessPlus tables like the BusinessPlus pages; they are ASP pages that are built from an existing Workflow form template that contains the infrastructure required by Workflow. The templates are located within the BusinessPlus directory on the Web server in the <Ifas7>/WorkFlow/Custom directory and are titled WebSample1.asp and WebSample2.asp.

There are three minimum requirements when adapting a template to a client-specific Workflow form:

1. The ASP page must have the same name as the Workflow model.

2. The FORM must have the same name as the ASP page.

3. All INPUT fields must be contained within the FORM definition.

Processing Web Forms

When input is accepted on a Web form, the information is passed through BusinessPlus processing services to the Workflow form handler. A Workflow queue record is created and placed into the Workflow queue table. When the Workflow engine wakes up, the information is passed on to the Workflow model with the same name as the ASP page.

Definitions

Since a Workflow form model does not have any data passed to it, it must define the information ahead of time. This can be done in several ways.

Data Elements

For an extremely simple Workflow form model, the user can define a data element (variable) for each input field on the form. Transitions, Many conditions, and VBScript activities can then access the information and make decisions. The information can be formatted using a model-specific style sheet for use on a Task List or Email (Response Required) activity.

When the BusinessPlus administrator selects to use data elements to define the INPUT fields coming in from the ASP Page, the administrator must create a data element for every field. If not, the field is not visible to the Workflow model. However, the configuration can result in many data elements when the ASP page has many input fields. The ASP page is defined for repeating rows since each input field in each row must have an accompanying Data Element.

DBCustom.xml

The second option for defining information in a Workflow form model is creating an entry in the Workflow table relationship file: DBCustom.xml. The DBCustom file exists in the <Ifas7>/XML/Schema directory on the Web server. It is an XML document that is used to define both tables and Web forms.

The following nodes may be used:

Table: For Web form Workflow models, the table node is used to define the definition as being for a table and the particular Web form that the definition is for.

ID: This attribute represents the name of the Web form and Workflow model that the information is being defined for.

Object: This attribute will always have the value of "Webform" to indicate to Workflow that this is a Web form definition.

Property: Each piece of information that is being predefined in this definition will consist of a property node.

Type: Optional field that allows the user the ability to define the type data. This can be used when defining condition-based activities in a Web form Workflow model.

Date: When the type is defined as a date value, condition-based activities will treat all conditions as date-based.

String: When the type is defined as a string value, condition-based activities will treat all conditions as string-based.

Numeric: When the type is defined as a numeric value, condition-based activities will treat all conditions as numeric.

Row: This is an optional node that is used to define multiple instances of the same data. This is useful when the Web Form is using multiple rows to describe the same type of data (i.e., account information for a travel reimbursement Web Form).

Data elements can still be defined for Web form information. In addition, Workflow supports the mixture of both data elements and predefined Web form data in the same Web form Workflow model.

Standard DBCustom Definitions

Workflow has a defined standard set of table trigger relationship definitions for the most frequently used tables in table-triggered Workflow models. In each case, the most complete set of associated information has been defined within the relationship definition.

Table definitions are used by Workflow in defining transitions, many conditions (activities), condition-based activities, table filtering and data filtering. When a Workflow instance is processed by the Workflow engine (State Machine), this information is loaded and stored in the Workflow instance record for the purpose of evaluation.

The standard DBCustom.xml file should never be altered since the file is under configuration control and is part of the deliverables. Subsequent releases can wipe out any client changes.

Custom DBCustom Definitions

Users may want to create their own DBCustom file for the following reasons:

• Customized DBCustom definition for an existing table relationship

• Add a new table relationship not already defined in the standard DBCustom.xml file

• Create a Web form definition

A custom DBCustom.xml file can be created and placed into the Custom directory under the <Ifas7>/XML/Schema directory. The client can redefine an existing table relationship, add a new one or define a Web form in the custom DBCustom.xml file. When the standard DBCustom.xml file is loaded, if a custom DBCustom.xml file exists, its entries will be merged with the standard file. Pre-existing table relationship definitions in the standard file will be replaced with the custom definition. Any new custom definition will be added.

To install a custom DBCustom.xml file into the Custom directory, the following steps are necessary:

• If a custom subdirectory does not already exist in the Schema directory, create one with the same security permissions as the Schema directory.

• Copy the standard DBCustom.xml file into the custom subdirectory.

• Open the new custom DBCustom.xml file with a XML editor. This ensures that any changes that take place result in a well-formed XML document. Malformed XML documents will not load and will result in the custom definitions not being recognized.

• Change the reference to the cXML's attribute in the table schema from "x-schema:TableRelationshipSchema.xml" to "../x-schema:TableRelationshipSchema.xml." This needs to be done so that the schema file for the DBCustom.xml can be found correctly. If this is not done, the custom DBCustom.xml will not load.

• Remove all the child nodes. This is necessary since the DBCustom.xml files are merged when they are loaded. Keeping the standard definitions is redundant and will result in more work for Workflow Designer and the Workflow engine.
  <?xml version="1.0"?>
  <table_schema hfs="0007" xmlns="../x-schema:TableRelationshipSchema.xml">
  </table_schema>

• Add any custom or new table relationship definitions and save the custom DBCustom.xml file.