Copyright © Cloud Software Group, Inc. All Rights Reserved

Overview

The GI Forms interface allows you to create forms using TIBCO® General Interface Builder, then use those forms for work item steps in the iProcess Workspace (Browser). This allows you to take advantage of the advanced form-building capabilities of the TIBCO® General Interface Builder.

The GI Forms interface allows your custom forms to utilize the existing iProcess Workspace (Browser) communication methods to perform the following functions:

•	start a case

•	lock a work item

•	get field data to display in the form

•	keep or release the work item

When a user either starts a case of a procedure or opens an existing work item, the TIBCO iProcess Workspace (Browser) will check to see if there is a GI form specified for that step in the <Forms> element of the client’s config.xml file:

•	If there is a GI form specified for the step:

−	The iProcess Workspace (Browser) instantiates the custom GI form class that is specified in the <Forms> element in the iProcess Workspace (Browser) configuration file (config.xml). This is described in more detail later.

−	Field data is requested from the Action Processor (applicable only when opening a work item, not when starting a case).

−	The custom GI form (prototype) is displayed within the GI context in the iProcess Workspace (Browser).

−	A keep or release request is sent to the Action Processor when the user initiates one of those actions.

•	If there is no GI form definition for the step:

−	The normal iProcess Workspace (Browser) open work item actions are performed, i.e., a new browser window is opened pointing to the Action Processor URL to handle the form action. This delegates control to the external form handling process.

For information about the version of TIBCO® General Interface Builder that must be used if you are developing your own GI forms to use with the iProcess Workspace (Browser), see the Release Notes for the iProcess Workspace (Browser).

Base Class

The GI Forms interface provides the following base class that is extended for each custom GI form created:

•	com.tibco.bpm.ipc.Form

Each custom form consists of two files:

−	<FormClassName>.js - This class extends the com.tibco.bpm.ipc.Form base class, adding any form-specific logic.

−	<FormClassName>.xml - This defines the GUI prototype for the form component layout.

Sample Implementation

A sample subclass implementation of the GI Forms interface base class is provided in the FormTemplate subdirectory.

The FormTemplate.js file is a sample implementation class (com.tibco.bpm.ipc.FormTemplate), which you can use by replacing “FormTemplate” with your custom form class name, then modifying the methods in the class to fit your custom form needs. The com.tibco.bpm.ipc.FormTemplate class extends the base class (com.tibco.bpm.ipc.Form). For information about the properties and methods available in the base class, see Interface Properties and Methods. (Note that at a minimum, the custom class that extends the com.tibco.bpm.ipc.Form base class must override the postLoadInit, doKeep, and doRelease methods; it can also optionally override the init and doCancel methods.)

Multiple prototypes can be defined for each custom form. During the implementation phase, you will specify which prototype to use. (The prototype can also be specified using the prototypePath attribute of the <Form> element in the config.xml file.)

The sample implementation also contains a showFormDetails function (which is called by the Form Details button on the sample template). This function provides details about the messages sent to and returned by the Action Processor, which may be useful during development. It uses the FormDetails.xml prototype.

Copyright © Cloud Software Group, Inc. All Rights Reserved