Tib Ip Workspace Browser Config

TIBCO iProcess™ Workspace (Browser)
Configuration and Customization

Software Release 10.6
September 2007
Important Information
SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED
OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED
ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED
SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR
ANY OTHER PURPOSE.
USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A
LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE
AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER
LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE
SOFTWARE (AND WHICH IS DUPLICATED IN THE TIBCO IPROCESS WORKSPACE (BROWSER)
INSTALLATION GUIDE) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP
END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OF THE
SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR
USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE
SAME.
This document contains confidential information that is subject to U.S. and international copyright laws and
treaties. No part of this document may be reproduced in any form without the written authorization of TIBCO
Software Inc.
TIB, TIBCO, Information Bus, The Power of Now, TIBCO Adapter, TIBCO iProcess, TIBCO BusinessWorks,
TIBCO FormBuilder, and TIBCO General Interface are either registered trademarks or trademarks of TIBCO
Software Inc. in the United States and/or other countries.
EJB, Java EE, J2EE, JMS and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the U.S. and other countries.
All other product and company names and marks mentioned in this document are the property of their
respective owners and are mentioned for identification purposes only.
THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL
OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME
TIME. PLEASE SEE THE README.TXT FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON
A SPECIFIC OPERATING SYSTEM PLATFORM.
THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS.
CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE
INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE
IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN
THIS DOCUMENT AT ANY TIME.
THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR
INDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING
BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.
Copyright © 2006-2007 TIBCO Software Inc. ALL RIGHTS RESERVED.
TIBCO Software Inc. Confidential Information
|i
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Configurations and Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
TIBCO iProcess Workspace (Browser) Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Other TIBCO Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
How to Contact TIBCO Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1 Configuring the iProcess Workspace (Browser) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
User Access Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Using a Single Profile for Multiple User Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Access Profile ‘name’ Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Creating Custom User Access Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Server Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Action Processor URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
TIBCO iProcess Workspace (Browser) Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
iProcess Workspace Application Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
iProcess Workspace Application Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Remember Login Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Customizing the Browser Window Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Releasing Resources On Logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
User Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Font and Image Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Adding Custom Menu Items and Toolbar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Callout Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Callout Method Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Chapter 2 Configuring the Action Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Log Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
XML Response Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
TIBCO iProcess Workspace (Browser) Configuration and Customization

ii
| Contents
Return Request Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
External Form URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Server Factories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
XML Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Action Processor Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Chapter 3 GI Forms Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Base Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Sample Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Interface Properties and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Base Class Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Base Class Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
closeForm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
confirmUserMessage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
createFieldDefsRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
createKeepRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
createLockRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
createReleaseRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
doCancel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
doClose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
doKeep. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
doRelease . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
lockWorkItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
onBeforeUnload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
postLoadInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
readFieldDefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
showUserMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
socketRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
transformData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
FieldData Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
FieldData Class Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Requesting Values For Items in an Array Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Date Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Code Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Date Conversion Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Date Format Localization Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Accessing User Options When Using GI Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Contents iii
|
Chapter 4 Application Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Session Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Maximum POST Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Character Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Java Heap Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Chapter 5 ASP Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

ASP Form Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Setting Up the ASP Form Project in IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Configuring iProcess Workspace to Use the ASP Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
ASP Form Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Chapter 6 JSP Forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

JSP Form Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Setting Up the JSP Form Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Configure iProcess Workspace to Use the JSP Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
JSP Form Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Chapter 7 Direct Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Direct Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Enabling Direct Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
On the URL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
In an HTML Form Element Named 'DirectLogin' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
In an HTML Script Element that Defines ‘getDirectLoginArgs’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Chapter 8 Single Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Java Single Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Web Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Authenticator Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
iProcess Workspace (Browser) Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Java Single Authentication Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
.NET Single Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Web Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Authenticator Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
iProcess Workspace (Browser) Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
.NET Single Authentication Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Chapter 9 Localization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Localizing the iProcess Workspace (Browser). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

iv
| Contents
Create a New Localized Language Resource File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Configure the New Localized Language in the iProcess Workspace (Browser) . . . . . . . . . . . . . . . . . . . . . 179
Modify or Create a General Interface System Locale File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Translate User Access Profiles Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Set the New Default Language for the iProcess Workspace (Browser). . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Create a New Folder to Hold Localized Help Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Chapter 10 Customizing iProcess Modeler Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Embedding HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Word Wrap in the Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Pre-Formatting of the Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Disabling Pre-Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Including Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Nesting of HTML Tags with Conditional Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Functions Available for Embedded Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Altering the Style of Various Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Embedded Customization Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
File Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Setting up a Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Structure of the Complete iProcess Modeler Form Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Functions Available for File-Cached Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
HTML for Marking Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
File-Cached Customization Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Common Issues for Embedded and File-Cached Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Chapter 11 Displaying Forms Outside of the iProcess Workspace. . . . . . . . . . . . . . . . . . . . . 213

The LinkForm Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

|v
Preface
This guide provides information about configuring and customizing your TIBCO
iProcess Workspace (Browser).
Topics
• Configurations and Customizations, page vi

• Related Documentation, page ix
• How to Contact TIBCO Support, page xi

vi
| Configurations and Customizations
Configurations and Customizations
The following configuration and customization tasks are described in this guide:
• iProcess Workspace (Browser):
— User Access Profiles - These profiles specify the functions that are available
to each type of user of the iProcess Workspace (Browser).
— Server Nodes - Specifies which TIBCO iProcess Objects Servers the user
can log into.
— Action Processor URL - Specifies the URL to the Action Processor to which
you would like the iProcess Workspace (Browser) to connect.
— iProcess Workspace (Browser) Logs - This provides information about the
three types of logs available: Session Activity Log, Application Log, and the
Application Monitor.
— Remember Login Information - This specifies whether or not to display
the Remember User Id and Server next time I login check box on the
Login dialog.
— Customizing Browser Window Caption - This allows you to customize the
caption that is displayed in the browser window after a user has logged
into the iProcess Workspace (Browser).
— Releasing Resources On Logout - Specifies the level that resources are
released when a user logs out of the TIBCO iProcess Workspace (Browser).
— User Options - These settings allow you to specify default options (list
thresholds, form location and size, etc.) in the iProcess Workspace
(Browser).
— Font and Image Settings - These settings allow you to customize the
appearance of the application, such as changing the images that display for
icons/buttons, font types, sizes, colors, etc.
— Adding Custom Menu Items and Toolbar Buttons - This allows you to
add menu items and toolbar buttons to the existing menus and toolbars in
the TIBCO iProcess Workspace (Browser).
— Callout Interface - The callout interface provides methods that allow you
to set default filters, sorts, columns, etc.

Preface vii
|
• Action Processor:
— Log Settings - These allow you to configure the Action Processor log file
(type of information to write to the log, name of log file, etc.).
— XML Response Compression - This specifies whether or not to compress
the XML response. (Only applicable for the Java Action Processor.)
— Return Request Parameters - This specifies the default setting for
returning input parameters in the XML response.
— External Form URI - This specifies the URI that points to an external forms
package.
— Server Factories - This specifies information about the server factories used
when using RMI. (Only applicable for the Java Action Processor.)
— XML Validation - This specifies whether or not to validate the XML
request sent to the Action Processor.
— Action Processor Version - This specifies whether or not to display the
Action Processor version number in the Action Processor action response
• Using GI Forms - The GI Forms interface allows you to create forms using the
TIBCO General Interface™ Builder, then use those forms for work item steps
in the TIBCO iProcess Workspace (Browser). This allows you to take
advantage of the advanced form-building capabilities of the TIBCO General
Interface Builder.
• Application Server:
— Session Timeout - This specifies the number of minutes in which the
session will time out.
— Maximum POST Size - This specifies the maximum size of HTTP POST
requests.
— Character Encoding - Specifies encoding when using double-byte
characters.
• ASP Forms - A Microsoft Visual Studio .NET 2003 project that defines an
example ASP form is provided with the TIBCO iProcess Workspace (Browser).
• JSP Forms - An IntelliJ project that defines an example JSP form is provided
with the TIBCO iProcess Workspace (Browser).
• Direct Login - This chapter describes how to bypass the TIBCO iProcess
Workspace (Browser) Login screen by passing login credentials directly into
the application.
• Single Authentication - This chapter describes how to configure the TIBCO
iProcess Workspace (Browser) so that users can be authenticated using
credentials they have already entered in another web application.

viii
| Configurations and Customizations
• Localization - This chapter describes how to add a language resource file to

the TIBCO iProcess Workspace (Browser) to display the application in the
desired language.
• Customizing iProcess Modeler Forms - This chapter describes how to
customize TIBCO iProcess Modeler-generated forms using additional HTML
and scripting code.
• Displaying Forms Outside of the iProcess Workspace (Browser) - This
chapter provides an example of how to display iProcess forms outside of the
TIBCO iProcess Workspace (Browser).

Preface ix
|
Related Documentation
This section lists documentation resources you may find useful.
TIBCO iProcess Workspace (Browser) Documentation

The following documents form the TIBCO iProcess Workspace (Browser)
documentation set:
• TIBCO iProcess™ Workspace (Browser) Installation Guide - Read this manual for
information about installing and configuring the TIBCO iProcess Workspace
(Browser).
• TIBCO iProcess™ Workspace (Browser) Release Notes - Read the release notes for
a list of new and changed features. This document also contains lists of known
issues and closed issues for each release.
• TIBCO iProcess™ Workspace (Browser) User’s Guide - Read this manual for
instructions on using the TIBCO iProcess Workspace (Browser) client
application.
• TIBCO iProcess™ Workspace (Browser) Configuration and Customization - This
manual provides information about configuring and customizing the iProcess
Workspace (Browser) and Action Processor.
• TIBCO iProcess™ Workspace (Browser) Components Concepts - This guide
provides an overview of the TIBCO iProcess Workspace (Browser)
Components, and how they work with other TIBCO products, as well as
information about using the Properties and Events Editor to configure
components you’ve added to your application. It also provides a tutorial that
steps you through creating a simple application using the iProcess Workspace
(Browser) Components.
• TIBCO iProcess™ Workspace (Browser) Components Reference - This guide
provides details about each of the components available in the TIBCO iProcess
Workspace (Browser).
• TIBCO iProcess™ Workspace (Browser) Action Processor Reference - This
document provides an overview of the Action Processor, as well as
information about all of the requests that can be sent to the Action Processor
from TIBCO General Interface components.

x
| Related Documentation
Other TIBCO Documentation

You may find it useful to read the documentation for the following TIBCO
products:
• TIBCO iProcess™ Server Objects (Java or .NET) Programmer’s Guide - The TIBCO
iProcess Server Objects (either Java or .NET) are installed as part of the TIBCO
iProcess Workspace (Browser). This guide provides information about
configuring the iProcess Server Objects.
• TIBCO iProcess™ Objects Server Administrator’s Guide - The TIBCO iProcess
Workspace (Browser) communicates with the iProcess Engine through an
iProcess Objects Server. This guide can be used to help configure your
iProcess Objects Server.
• TIBCO PageBus™ Developer’s Guide - This guide provides an introduction to
the PageBus, an Ajax publish/subscribe message delivery hub used by the
TIBCO iProcess Workspace (Browser) components.
• TIBCO iProcess™ Workspace (Windows) Manager's Guide - Read this guide for
information about using the TIBCO iProcess Administrator, which includes the
User Manager. The User Manager is used to add users to the system, who can
then log into the TIBCO iProcess Workspace (Browser) application.
All of these guides are available in the TIBCO Documentation Library.

Preface xi
|
How to Contact TIBCO Support
For comments or problems with this manual or the software it addresses, please
contact TIBCO Support as follows.
• For an overview of TIBCO Support, and information about getting started
with TIBCO Support, visit this site:
http://www.tibco.com/services/support
• If you already have a valid maintenance or support contract, visit this site:
http://support.tibco.com
Entry to this site requires a user name and password. If you do not have a user
name, you can request one.

xii
| How to Contact TIBCO Support

|1
Chapter 1 Configuring the iProcess Workspace

(Browser)
The installation procedure for the TIBCO iProcess Workspace (Browser) steps you
through the configurations that are necessary to get the client application up and
running.
This chapter describes additional options that can be configured after the iProcess
Workspace (Browser) has been installed.
Topics
• User Access Profiles, page 3

• Server Nodes, page 15
• Action Processor URL, page 18
• TIBCO iProcess Workspace (Browser) Logs, page 20
• Remember Login Information, page 24
• Customizing the Browser Window Caption, page 25
• Releasing Resources On Logout, page 27
• User Options, page 28
• Font and Image Settings, page 35
• Adding Custom Menu Items and Toolbar Buttons, page 36
• Callout Interface, page 40

2
| Chapter 1 Configuring the iProcess Workspace (Browser)
Introduction
There are two primary configuration files provided to configure the TIBCO
iProcess Workspace (Browser):
• userAccessProfiles.xml - This is used to specify which users have access to
the functions available in the TIBCO iProcess Workspace (Browser). For
information about configuring user access profiles, see User Access Profiles on
page 3.
• config.xml - This is used to configure many other aspects of the TIBCO
iProcess Workspace (Browser), such as which servers the user can connect to,
default settings in the application, etc. These are described throughout the rest
of this chapter.
The location of these configuration files depends on whether you are using the
example application provided with the iProcess Workspace (Browser), or a
custom application developed with the iProcess Workspace (Browser)
components.
• If you are using the client application, these configuration files are located as
follows:
ClientInstallDir\JSXAPPS\ipc\
where ClientInstallDir is the directory in which the iProcess Workspace
(Browser) is installed.
• If you are using a custom application developed with the iProcess Workspace
(Browser) components, these configuration files are located as follows:
WorkspaceDir\JSXAPPS\ProjectName
where WorkspaceDir is the directory that was designated as your workspace

when TIBCO General Interface (GI) Builder was initially started, and
ProjectName is the name that was given to your GI Builder project when your
application was developed with the components.
The references to these configuration files in this chapter assume you are
configuring the example application provided with the iProcess Workspace
(Browser).
If you are configuring a custom application created with the iProcess Workspace
(Browser) components, substitute the path shown with the appropriate path.

User Access Profiles 3
|
User Access Profiles
User access profiles provide the ability to specify which application functionality
is available to various types of users of the iProcess Workspace (Browser). They
do this by specifying which user interface components (i.e., icons, buttons, and
menu selections) are made available to the logged-in user.
User access profiles only define which user interface components are made
available to the logged-in user — the ability to actually execute the functionality is
determined by the level of security defined on the iProcess Objects Server. For
instance, the user's access profile may grant access to the tool/menu selection for
closing cases, however, if the user does not have system administrative privileges
on the iProcess Objects Server, any attempt to close a case will be rejected.
The user access profiles are defined using the UserAccessProfiles record in the
ClientInstallDir\JSXAPPS\ipc\userAccessProfiles.xml file.
Each profile represents a type of application user and defines the user interface
components available to users of that type. The following shows a collapsed view
of the default user access profiles included in the iProcess Workspace (Browser):
Each user's profile type is stored in the MENUNAME user attribute, the name of
which is specified by the serverUserAttr attribute (for information about the
MENUNAME user attribute, see the TIBCO iProcess Server Objects Programmer’s
Guide or on-line help system). By default, the MENUNAME attribute is used
because it is an inherent attribute of all iProcess users and requires no
customization when the iProcess Workspace (Browser) is installed.

4
The “Default” profile type is assigned to application users that do not have their
iProcess attribute set to one of the defined profile types. In this example, if a user
logs in to the iProcess Workspace (Browser), and the value of their MENUNAME
iProcess attribute is empty, or set to a value other than “Admin”, “User”,
“ProDef”, or “Manager”, the access defined for the “Default” profile type is
assigned. If the MENUNAME value is invalid, and the “Default” profile type has
not been defined in userAccessProfiles.xml, access is automatically limited to
viewing only the list of procedures.
There is also a special “PreLogin” user type specified in the
userAccessProfiles.xml file that represents all users before they login, i.e.,
before the application knows their user name/type. The access profile for the
“PreLogin” user type only contains the elements needed to specify how much
error information will be shown to the user prior to logging in.
If you need additional user profile types, you must create a new user attribute and
assign profile types to that user attribute (rather than assigning new types to the
MENUNAME attribute). For information on how to create custom profiles by
defining a new user attribute, see Creating Custom User Access Profiles on
page 13.
Each user access profile (i.e., each <Profile/> element) specified in the
userAccessProfiles.xml file contains the following attributes:
• The type attribute of each profile represents the user type and corresponds to
the value that is stored in the iProcess attribute of the user. For example:
<Profile type="Admin" description="Access Level: Admin">
Initially, profiles are defined for each of the possible MENUNAME values:
“Admin”, “User”, “ProDef” and “Manager” (as well as a “Default” and
“PreLogin” type, which are described above).
• The description attribute defines a text string that is displayed in the header
area of the iProcess Workspace (Browser) interface, and provides an indication
of the access level of the logged-in user. For example:
<Profile type="Admin" description="Access Level: Admin">
This example would cause the following to be displayed when a user with a
MENUNAME of “Admin” is logged in:

|
Each <Profile/> element contains subordinate <property/> elements, each of

which represents a specific function in the iProcess Workspace (Browser). The
<property/> elements contain the following attributes:
• The name attribute identifies the function for which you can provide or deny
access using the state attribute (see the next bullet item).
<property name="Procedure" state="1">
For a complete list of the allowable name attributes (functions), see the table
in the Access Profile ‘name’ Attributes section on page 6.
• The state attribute specifies whether or not the associated user type has access
to the functionality identified by the name attribute (see the bullet item
above), where “1” means allow access and “0” means deny access.
<property name="Procedure" state="1">
If access to a function is not allowed, the applicable buttons and/or menu

selections are not displayed.
Note that if a <property/> element for a particular function is not present in the
userAccessProfiles.xml file, access to that functionality is not allowed by
default.
Hierarchy
The hierarchy of the <property/> elements is significant, i.e., if a child
<property/> element gives the user type access to a button/menu selection, the
child’s parent <property/> element must also be enabled (by setting its state
attribute to “1”). For example, see the following excerpt from the
userAccessProfiles.xml file. If the user type is given access to open work items
(name=”Open”), it must also be given access to view the work items
(name=”WorkItem”).

6
Likewise, if you give the user type access to “ForwardAnyQueue”, you must also
give access to “Forward”, since “ForwardAnyQueue” is a child of “Forward”.
Using a Single Profile for Multiple User Types

The same access profile can be used for multiple user types by including the
optional <Type/> element. The example shown below for the Admin user
illustrates an example of this — the Admin2 user uses the same profile.
Access Profile ‘name’ Attributes

This section provides a list of all valid values for the name attribute that can be
specified in the <property> element of an access profile.
Note that there are values that can be used multiple times within one access
profile, e.g., SelectColumns. Its placement within the hierarchy structure
determines the interface component to which it applies. Use the Parent column to
determine the interface component it controls.
name Attribute Value Parent Meaning Description

Procedurea N/A Procedures View Provides access to the procedure
list.
Versions Procedure Procedure Versions Provides access to the Procedure

Versions tool.
LoadingChart Procedure Procedure Loading Provides access to the Procedure

Chart Loading Chart tool.
CaseStart Procedure Case Start Provides access to the Start New

Case tool on the procedure list.

|

Case Procedure Case View Provides access to the Show
Case(s) tool.
SelectColumns Procedure Procedure Column Provides access to the Select

Selector Columns... selection on the View
menu on the procedure list.
Activate Procedure Case Activate Provides access to the Activate

Case Case(s) tool.
Close Procedure Case Close Provides access to the Close

Case Case(s) tool.c
Jump Procedure Process Jump Provides access to the Process

Case Jump tool.
DataRead Procedure Process Jump Data Provides read-only access to

Case Read Case Data dialog available
Jump through the Process Jump
dialog.
If DataUpdate access is also
enabled, it overrides this
element, giving the user update
access to case data.
If both this and DataUpdate
access are disabled, the Data
button is not displayed on the
Process Jump dialog.
DataUpdate Procedure Process Jump Data Provides update access to Case

Case Update Data dialog available through
Jump the Process Jump dialog. (This
overrides DataRead if it is also
enabled.)
If both this and DataRead access
are disabled, the Data button is
not displayed on the Process
Jump dialog.

8

SelectColumns Procedure Process Jump Provides access to the Select
Case Column Selector Columns... selection on the View
Jump menu for the outstanding items
list on the Process Jump dialog.
Suspend Procedure Case Suspend Provides access to the Suspend

Case Case(s) tool.
Trigger Procedure Trigger Event Provides access to the Trigger

Case Events tool.
DataRead Procedure Trigger Event Data Provides read-only access to

Case Read Case Data dialog available
Trigger through the Events dialog.
access to case data.
access are disabled, the Data
button is not displayed on the
Events dialog.
DataUpdate Procedure Trigger Event Data Provides update access to Case

Case Update Data dialog available through
Trigger the Events dialog. (This
overrides DataRead if it is also
enabled.)
If both this and DataRead access
are disabled, the Data button is
not displayed on the Events
dialog.
Resurrect Procedure Case Resurrection Provides access to the Trigger

Case Events tool when a closed case is
Trigger selected.
RecalculateDeadlines Procedure Case Deadlines Provides access to the

Case Recalculated Recalculate Deadlines radio
Trigger buttons on the Events dialog.b

|

Purge Procedure Case Purge Provides access to the Purge
Case Case(s) tool. c
Open Procedure Case Open Provides access to the Open

Case Case(s) tool.
Summary Procedure Case Summary Provides access to the case

Case Summary tab.
Open
History Procedure Case History Provides access to the case

Case History tab.
Open
AddHistoryEntry Procedure Case Add History Provides access to the Add Entry
Case Entry tool for adding entries to the
Open history of a case (audit trail).
History
Predict Procedure Case Predict Provides access to the Predict

Case Case tool.
Open
History
GraphicalHistory Procedure Case Graphical Provides access to the Graphical

Case History Case History tool.
Open
History
Outstanding Procedure Case Outstanding Provides access to the case

Case Items Outstanding tab.
Open
SelectColumns Procedure Case Outstanding Provides access to the Select

Case Items Column Columns... selection on the View
Open Selector menu on the case Outstanding
Outstanding tab.

10

DataRead Procedure Case Data Read Provides read-only access to case
Case data on the Data tab.
Open
access to data.
access are disabled, the case Data
tab is hidden.
DataUpdate Procedure Case Data Update Provides update access to the

Case case Data tab (this overrides
Open DataRead if it is also enabled).
If both this and DataRead are
disabled, the case Data tab is
hidden.
SelectColumns Procedure Case List Column Provides access to the Select

Case Selector Columns... selection on the View
menu on the case list.
Filter Procedure Case List Filter Provides access to the Filter

Case icon/dialog for the case list.
Sort Procedure Case List Sort Provides access to the Sort

Case icon/dialog for the case list.
WorkQueuea N/A Work Queue View Provides access to the work

queue list.
LoadingChart WorkQueue Work Queue Provides access to the Work

Loading Chart Queue Loading Chart tool.
Participation WorkQueue Work Queue Provides access to the

Participation Participation tool.
Redirection WorkQueue Work Queue Provides access to the

Redirection Redirection tool.
Supervisors WorkQueue Work Queue Provides access to the

Supervisors Supervisors tool.c

|

WorkItem WorkQueue Work Item View Provides access to the Show
Work Items tool.
SelectColumns WorkQueue Work Queue Provides access to the Select

Column Selector Columns... selection on the View
menu on the work queue list.
Forward WorkQueue Work Item Forward Provides access to the Forward

WorkItem Work Item(s) tool.
ForwardAnyQueue WorkQueue Work Item Forward This is applicable only if the user
WorkItem Any Queue has access to the Forward Work
Forward Item(s) tool.
This causes the list of work
queues on the Forward Selected
Work Items dialog to contain all
work queues on the system.
If disabled, the list of work
queues on the Forward Selected
Work Items dialog will contain
only the work queues of which
the user is a member.
Open WorkQueue Work Item Open Provides access to the Open

WorkItem Selected Work Item(s), Open
First Available Work Item, Open
Next Available Work Item, and
Auto-Repeat Open Work Item
tools.
Release WorkQueue Work Item Release Provides access to the Release

(If disabled, it does not prevent
the user from releasing a work
item via a form.)
Unlock WorkQueue Work Item Unlock Provides access to the Unlock

SelectColumns WorkQueue Work Item List Provides access to the Select

WorkItem Column Selector Columns... selection on the View
menu on the work item list.

12

Filter WorkQueue Work Item List Filter Provides access to the Filter
WorkItem icon/dialog for the work item
list.
Sort WorkQueue Work Item List Sort Provides access to the Sort
WorkItem icon/dialog for the work item
list.
SessionActivity N/A Session Activity Provides access to the Session

Activity button/icon.
ServerInfo N/A Server Info Provides access to the Server

Info button/icon.
ApplicationLog N/A Application Log Provides access to the TIBCO

iProcess Workspace (Browser)
application log by pressing F12.
(For more information, see
TIBCO iProcess Workspace
(Browser) Logs on page 20.)
If disabled, the F12 function key
has no function.
ChangePwdExpired N/A Change password If enabled, causes the Change

expired Password dialog to be displayed
when the user attempts to log in
with an expired password.
Requires password change to log
in.
ChangePwdOption N/A Change password Provides access to Change

option Password button on the Options
dialog.
ShowErrorDetail N/A Show error details If enabled, details about error

conditions are displayed to the
user.
ShowStackTrace ShowErrorDetail Show stack trace If enabled, a stack trace is shown

when error information is
displayed.

|
a. If a user that has neither procedure view access (name=”Procedure”) nor work queue view access
(name=”WorkQueue”) logs into the iProcess Workspace (Browser), a screen is displayed containing the
message: “Access to Procedure and Work Queue data is denied - please contact your system administra-
tor”. The only components available on this screen are the Logout and Help tools.
b. If you are using an older iProcess Objects Server that does not provide recalculate deadline function-
ality, you may want to set state=”0” for RecalculateDeadlines so that the Recalculate Deadline radio
buttons are not displayed on the Events dialog.
c. The case close (name=”Close”), case purge (name=”Purge”), and work queue supervisors (name=”Su-
pervisors”) functions all require system administrative authority. Without system administrative author-
ity, a user cannot perform these functions even if their access profile provides access to the tools/buttons
for these functions. If a user’s access profile causes the buttons/selections to appear, but they don’t have
administrative authority, the buttons/selections are grayed out.
Creating Custom User Access Profiles

Custom user access profiles allow the iProcess Workspace (Browser) application
interface to be tailored for various user categories that exist within an
organization. The simplest form of customization is to modify the state attribute
values for the existing MENUNAME profile types that are defined at installation.
If the existing profile types are not sufficient to reflect the organization's user
types, further customization may be performed. Rather than using the default
MENUNAME attribute to specify the profile of each user, a new iProcess user
attribute must be defined and used to hold the name of customized user profile
types. The customization process is as follows:
1. Define a new iProcess user attribute (e.g., ACCESS) on the server. The new
iProcess attribute must be created by a user with administrative access using
the TIBCO iProcess User Manager (for information about the User Manager,
see the TIBCO iProcess Workspace (Windows) Manager’s Guide).
2. From the userAccessProfiles.xml file, copy the existing user access
profiles, which consists of everything under the <Profiles/> element, and
paste it into the existing UserAccessProfiles record.
3. In the newly pasted <Profiles/> element, set the serverUserAttr attribute to
the name of the new iProcess attribute created in step 1.
4. In the <Profiles/> element, include a <Profile/> element for each user type,
setting the type attribute to the user type name, and the description attribute
to the description you would like displayed on the iProcess Workspace
(Browser) window.
5. For each interface component (<property/> elements) under the <Profile/>
element, set the state attribute to allow access (state=“1”) or deny access
(state=”0”).

14
6. For each iProcess user, set the value of their iProcess attribute to one of the
profile types defined in userAccessProfiles.xml. This must be done by a
user with administrative access using the TIBCO iProcess User Manager (for
information about the User Manager, see the TIBCO iProcess Workspace
(Windows) Manager’s Guide).

Server Nodes 15
|
Server Nodes
When the iProcess Workspace (Browser) Login screen is displayed, the Server
field drop-down list will contain a list of TIBCO iProcess Objects Servers that the
user can log into:
This list of servers is controlled using the ServerNodes record in the iProcess
Workspace (Browser)’s configuration file.
During the iProcess Workspace (Browser) installation process, you enter the
information for one iProcess Objects Server. This section describes how to add
additional entries to the ServerNodes record if you would like more than one
server to appear in the Server field drop-down list.
To configure the server nodes for your installation:
1. Open the ClientInstallDir\JSXAPPS\ipc\config.xml file with an editor.

16
2. Locate the ServerNodes record:
The first record should reflect the entries that were entered during the
installation. The elements in this record can be modified if the information is
no longer correct (for instance, the TCP port has changed for that server).
Placeholders have been provided for two additional iProcess Objects Servers.
3. To configure additional servers, remove or move the appropriate comment
delimiters from the “Server Two” or “Server Three” record, then enter the
appropriate information in the record’s displayNodeName attribute, and the

Server Nodes 17
|
<ComputerName>, <IPAddress>, <TCPPort>, <Name>, and <Director>

elements, as follows:
— displayNodeName: The name that you would like displayed in the
iProcess Workspace (Browser) Login to field drop-down list. This is the
name the user would select when choosing a server to log into.
— <ComputerName>: The name of the machine on which the TIBCO iProcess
Objects Server is installed.
— <IPAddress>: The IP address of the machine on which the TIBCO iProcess
Objects Server is installed. You can enter the name of the host machine in
this field, as long as that name resolves to the IP address of the machine
where the iProcess Objects Server is running. Note, however, that this name
must be able to be resolved by the machine on which the Action Processor
is running.
— <TCPPort>: The TCP port number used by the TIBCO iProcess Objects
Server. (The TCP port used by the server is specified using the iProcess
Objects Server Configuration Utility in Windows systems
(SWDIR\bin\SWEntObjSvCfg.exe), or by editing the iProcess Objects
Server configuration file in UNIX systems
($SWDIR/seo/data/swentobjsv.cfg). For more information, see the
TIBCO iProcess Objects Server Administrator’s Guide.)
— <Name>: The name of the TIBCO iProcess Engine / iProcess Objects Server
to which the user can log in. This is the “nodename” that is assigned to the
iProcess Engine when it is installed.
— <Director>: Specifies whether or not the previous entries actually describe
a TIBCO iProcess Objects Director, which is used to connect the client to a
server). Select “true” if the specifications are for a Director, or “false” if a
TIBCO iProcess Objects Director is not being used.
Additional records can be added if you would like more than three servers to
appear in the Server field drop-down list.

18
Action Processor URL
When the TIBCO iProcess Workspace (Browser) is installed, you must specify the
URL to the Action Processor to which you want the iProcess Workspace (Browser)
to connect when it is started. This URL is written to the iProcess Workspace
(Browser)’s configuration file by the installation program.
You can later modify the Action Processor URL in the configuration file so that the
client connects to a different Action Processor. You can also specify multiple
URLs, and assign each a weighting value, which is used to determine the
percentage of connections given to that URL (Action Processor). This allows load
balancing of the available Action Processors. When the TIBCO iProcess
Workspace (Browser) starts, it randomly selects (with weighting applied) one of
the Action Processor URLs specified in the configuration file.
To configure the Action Processor URL:
2. Locate the ActionProcessors record in the config.xml file. For example:
<record jsxid="ActionProcessors" type="ipc" >

<ActionProcessor weighting="100"
baseUrl="http://austin:90/TIBCOActProc/ActionProcessor.servlet"/>
</record>
3. If you would like multiple Action Processors to be available for connections,

add an additional <ActionProcessor /> element for each Action Processor,
then perform the following steps to configure each of the components of the
<ActionProcessor /> element. (The easiest method is to copy and paste the
existing <ActionProcessor /> element, then modify the weighting and
baseUrl values according to the descriptions in steps 4 and 5.)
If you are just modifying the existing URL or weighting value, proceed to the
following steps.
4. To specify the Action Processor to which the client should connect, modify the
baseUrl attribute string to point to the desired Action Processor(s). This entry
must be in the form:
http://Host:Port/APDir/ActionProcessor.ext
where:
— Host is the name of the machine hosting the Action Processor. (Note that if
you are hosting both the iProcess Workspace (Browser) and the Action
Processor on the same machine, and they are both being hosted by Tomcat,
you can specify Host as “localhost”.)

Action Processor URL 19
|
— Port is the port number used by the Web Application Server (WAS) that is
hosting the Action Processor to communicate with web applications.
— APDir is the directory on Host in which the Action Processor is installed.
— ext is the file name extension. This is “servlet” (for Java servlet) if you are
connecting to a Java Action Processor, or “aspx” (for .NET ASP web
application) if you are connecting to a .NET Action Processor.
The example shown in step 2 specifies that the iProcess Workspace (Browser)
connect to a Java Action Processor (hence the “servlet” extension) on machine
“austin”. The WAS hosting the Action Processor is communicating with web
applications on port 90, and the Action Processor was installed in the
TIBCOActProc directory.
5. Specify a weighting value for each Action Processor by setting the weighting
attribute as follows:
— If you are only specifying a single URL, the weighting attribute can be set
to any value, or it can be left unspecified.
— For multiple URLs, the weighting value determines the percentage of
connections based on the total of all weighting values. For instance, if a
URL’s weighting value is 30% of the total of all weighting values (see the
example below), the client will connect to it 30% of the time:
<record jsxid="ActionProcessors" type="ipc" >

baseUrl="http://austin:70/ActProc1/ActionProcessor.servlet"/>
</record>
Note that the weighting parameter is only for load balancing purposes — it is
not to provide failover. If the Action Processor fails, the application should
return to the Login screen.
The weighting values can total any number, although it’s easier to calculate
the percentage for each if they total 100 as in the example above.
If an Action Processor is not available when the client attempts to connect to
it, the weighting values are recalculated based on the remaining available
Action Processors, and another URL is randomly selected. This process
continues until a connection is made, or no active Action Processor can be
found (in which case, an error is returned — the TIBCO iProcess Workspace
(Browser) must be reloaded to continue).

20
TIBCO iProcess Workspace (Browser) Logs
There are three types of TIBCO iProcess Workspace (Browser) logs available:
• Session Activity Log - This log allows users of the iProcess Workspace
(Browser) to view information about activities they have performed in the
application since they logged in. For information about this log, see the TIBCO
iProcess Workspace (Browser) User’s Guide.
• Application Log - This log provides detailed debug information, as well as
communications between the client and the Action Processor. For more
information, see iProcess Workspace Application Log on page 21.
• Application Monitor - This log provides debug information on error
conditions and exceptions encountered. For more information, see iProcess
Workspace Application Monitor on page 22.

TIBCO iProcess Workspace (Browser) Logs 21
|
iProcess Workspace Application Log

The TIBCO iProcess Workspace (Browser) Application Log is available to assist
with troubleshooting the client application. This log provides detailed debug
information generated by the iProcess Workspace (Browser), as well as
information about communications between the client and Action Processor.
To display the Application Log, press the F12 function key while the TIBCO
iProcess Workspace (Browser) is running. A window similar to the following is
displayed:
Note that this log is available only if the logged-in user has “ApplicationLog”
enabled in their user access profile. For more information, see page 12.
The Application Log can be closed by clicking in the X in the upper right corner of
the Application Log window.

22
iProcess Workspace Application Monitor

The TIBCO iProcess Workspace (Browser) Application Monitor is available to
assist with troubleshooting the client application. This monitor provides debug
information on error conditions and exceptions encountered.
The Application Monitor is displayed in a separate browser window, which
shows details of actions performed in the application. An example is shown
below:
The Application Monitor can be configured using the following configuration file:
ClientInstallDir\logger.xml
where ClientInstallDir is the path to the directory in which the iProcess Workspace
Default settings are specified by the handler element in the logger.xml file, as
shown below:
<handler name="ipcAppMonitorDefault" class="jsx3.app.Monitor" require="true">

<property name="serverNamespace" value="wccApp"/>
<property name="disableInIDE" eval="true" value="true"/>
<property name="activateOnHotKey" eval="true" value="true"/>
<property name="format" value="%t %n (%l) - %M"/>
</handler>

TIBCO iProcess Workspace (Browser) Logs 23
|
A reference to this handler is added under the global logger element:


<logger name="global" level="INFO">
...
<handler-ref name="ipcAppMonitorDefault"/>
</logger>
By default, both the Application Monitor and its hotkeys are enabled.
• To disable the Application Monitor, comment out the entire <handler/>
element, as well as the <handler-ref/> element under the global logger
element. (Note that if you comment out the Application Monitor, you must
comment out both the <handler/> element, as well as the <handler-ref/>
element. If the <handler/> element is commented out, but the <handler-ref/>
element is not commented out, it results in a fatal error — the application will
not load.)
• To disable the Application Monitor hotkeys, change the activateOnHotKey
property’s value attribute to “false”.
When the Application Monitor’s hotkeys are enabled, you can turn the monitor
on and off using the <Ctrl>+<Alt>+<m> key sequence.

24
Remember Login Information
You can configure whether or not to display the Remember User Id and Server
next time I login check box on the Login dialog:
By default, the check box is displayed.

To configure this option:
2. Locate the Login record in the config.xml file:
<record jsxid="Login" type="ipc" useRemember="true" allowDirectLogin="false"/>
3. Modify the useRemember attribute as follows:

— “true” causes the check box to be displayed.
— “false” causes the check box to not be displayed.

Customizing the Browser Window Caption 25
|
Customizing the Browser Window Caption
You can customize the caption that is displayed in the browser window after a
user has logged into the TIBCO iProcess Workspace (Browser).
By default, the caption is set to:

“TIBCO iProcess Workspace (Browser) - <Username> - <ServerNodeName>”
To customize the caption:
2. Locate the postLoginCaption record in the config.xml file:
<record jsxid="postLoginCaption"
pattern="TIBCO iProcess Workspace (Browser) - %username% - %displayNodeName%"
/>

26
3. Modify the pattern attribute for the caption you would like displayed. The
following placeholders can be used in the pattern string to display various
information:
— %username% - This placeholder is replaced with the name of the logged-in
user.
— %usernameDesc% - This placeholder is replaced with the user's
"DESCRIPTION" attribute defined on the server.
— %serverNodeName% - This placeholder is replaced with the node name of
the server the user has logged into. Note that when single authentication is
used (see Single Authentication on page 161), this value is available only if
the logged-in user’s access profile (see User Access Profiles on page 3)
allows access to server information (name=”ServerInfo”).
— %displayNodeName% - This placeholder is replaced with the value of the
displayNodeName attribute of the server the user has logged into (see the
displayNodeName attribute for the ServerNodes element on page 17). If
displayNodeName is null, the server node name is displayed.
Any or all of the placeholders can be specified or omitted.
If a placeholder is specified that is not available, it will be replaced with a
zero-length string.

Releasing Resources On Logout 27
|
Releasing Resources On Logout
You can specify the level that resources are released when a user logs out of the
To configure this option:
2. Locate the Logout record in the config.xml file:
<record jsxid="Logout" releaseAllResources="true"/>
3. Modify the releaseAllResources attribute as follows:

— “false” causes the “user session” to be closed, which closes the TCP
connection between the client and the iProcess Objects Server.
— “true” (the default) causes the “user session” to be closed, which closes the
TCP connection between the client and the iProcess Objects Server. This
also closes the “SAL session”, which releases all lists held on the iProcess
Objects Server — this releases all client-side and server-side resources.

28
User Options
The iProcess Workspace (Browser) contains an Options dialog from which each
user can specify their personal user options. User options establish default settings
for each user who logs into the iProcess Workspace (Browser). These include
things such as the list (procedure or work queue) to display first, the size and
location of forms, the language to display, etc. For information about setting user
options from the Options dialog, see the iProcess Workspace (Browser) User’s Guide.
There are default user options defined in the system that each new user inherits
until they specify their own user options on the Options dialog. These default
user options are defined in the iProcess Workspace (Browser)’s configuration file,
config.xml.
Note that the Options dialog in the iProcess Workspace (Browser) also contains a
Defaults button that sets all of the options for the user to the default user options
specified in the config.xml file.
To configure the default user options:
2. Locate the Options record:
3. Using the information in the following table, change the values of the
appropriate element attributes to the desired default values:

User Options 29
|
Element Attribute Possible Values Meaning

<display /> localeKey Locale key specified Specifies the language in which
in ClientInstallDir\ the iProcess Workspace (Browser)
JSXAPPS\ipc\ is displayed. (For more
locale\locales.xml. information, see Localization on
page 175.)
initialDisplay procs Displays the procedure list upon

login.
workQs Displays the work queue list upon

login.
captionCases name Causes the case name to be

displayed in the case list caption.
description Causes the case description to be

displayed in the case list caption.
captionWorkItems name Causes the work queue name to

be displayed in the work item list
caption.
description Causes the work queue

description to be displayed in the
work item list caption.

30

<filter /> filterCases always The Filter dialog is always
displayed when you open a case
list.
never The Filter dialog is never

displayed when you open a case
list (you can manually display the
Filter dialog).
specify This is used in conjunction with

the thresholdCases attribute. If
this value is specified, the Filter
dialog is automatically displayed
if the number of cases of the
selected procedure exceeds the
number in the thresholdCases
attribute. If the number of cases
does not exceed the threshold, the
case list is displayed without
displaying the Filter dialog.
thresholdCases integer value See the specify value for the

filterCases attribute above.

User Options 31
|

<filter /> filterWorkItems always The Filter dialog is always
displayed when you open a work
(Cont.)
item list.
never The Filter dialog is never

displayed when you open a work
item list (you can manually
display the Filter dialog). The first
page of the work item list is
always displayed. Use caution
with this selection as it can have a
negative impact on performance if
the page size is set to a large value.
specify This is used in conjunction with

the thresholdWorkItems
attribute. If this value is specified,
the first page of the work item list
is downloaded from the iProcess
Engine when you open a work
queue from the work queue list
only if the number of work items
does not exceed the number in the
thresholdWorkItems attribute. If
the number exceeds the threshold,
the Filter dialog is displayed first,
allowing you to apply a filter so a
large number of work items won’t
be downloaded.
thresholdWorkItems integer value See the specify value for the

filterWorkitems attribute above.

32

<layout /> previewCase on The case summary is shown in the
Preview Pane when a case is
selected; case details are shown in
the Preview Pane when a case is
opened.
float The case summary is shown in the

Preview Pane when a case is
selected; case details are shown in
a floating window when a case is
opened.
off Preview Pane is turned off; no

display when a case is selected;
case details are shown in a floating
window when a case is opened.
previewWorkItems on The work Item summary is shown

in the Preview Pane when a work
item is selected; a work item form
is shown in the Preview Pane
when a work item is opened.
float The work Item summary is shown

in the Preview Pane when a work
item is selected; a work item form
is shown in a floating window
when a work item is opened.
off Preview Pane is turned off; no

display when a work item is
selected; a work item form is
shown in a floating window when
a work item is opened.
floatWorkItems dialog Floating windows containing a

work item form are displayed in a
separate dialog.
browser Floating windows containing a

work item form are displayed in a
separate browser window.

User Options 33
|

<layout /> floatLeft integer value The floating window is positioned
this number of pixels from the left.
(Cont.)
(Only applicable if both the
floatFullscreen and floatCenter
attributes are false.)
floatTop integer value The floating window is positioned

this number of pixels from the top.
(Only applicable if both the
floatFullscreen and floatCenter
attributes are false.)
floatWidth integer value The width (in pixels) of the

floating window. (Only applicable
if the floatFullscreen attribute is
false.)
floatHeight integer value The height (in pixels) of the

floating window. (Only applicable
if the floatFullscreen attribute is
false.)
floatFullscreen true The floating window is displayed

full screen.
false The floating window is not

displayed full screen. (Use other
attributes to determine
position/size.)
floatCenter true The floating window is displayed

centered. (Use floatWidth and
floatHeight attributes to
determine size.)
false The floating window is not

displayed centered. (Use other
attributes to determine
position/size.)

34

<layout /> floatRememberPostion true The system remembers the size
and position of the floating
(Cont.)
window if you manually move it
on your screen.
false Future floating windows are

opened in the position and size
specified by the other <layout />
element float attributes.
<outstanding /> recurse true Causes the default setting of the

Recurse sub-cases for
outstanding items check box on
lists of outstanding work items to
be checked. (This check box
determines whether or not the list
should include work items in
sub-cases.)
false Causes the default setting of the

Recurse sub-cases for
outstanding items check box on
lists of outstanding work items to
be unchecked.
<subcase /> precedence swPrecedenceR The precedence in which

sub-procedures are started from
swPrecedenceUR the main procedure:
swPrecedenceMR — swPrecedenceR: Only

released sub-procedures
swPrecedenceUMR are started.
swPrecedenceMUR — swPrecedenceUR:
Unreleased, then released.
— swPrecedenceMR: Model,
then released.
— swPrecedenceUMR:
Unreleased, model, then
released.
— swPrecedenceMUR:
Model, unreleased, then
released.

Font and Image Settings 35
|
Font and Image Settings
A cascading style sheet-like file is provided that allows you to customize the
appearance of the iProcess Workspace (Browser). This file can be modified to
change elements such as:
• icon/button images
• font type, size, color
• background colors
The appearance of these elements is defined in the following file:
ClientInstallDir\JSXAPPS\ipc\jss\ipcCSS.jss
An excerpt from this file is shown below:


<record jsxid="ipcList BGC" type="jsxbgcolor" jsxtext="#fffeff" />

<record jsxid="ipcMenu BG" type="jsxbg" jsxtext="#ececee" />
This file is well-commented, making it easy to find the area you would like to
customize.
To make a change to a font, image, color, etc., modify the value in the jsxtext
attribute.

36
Adding Custom Menu Items and Toolbar Buttons
Custom menus and/or toolbar buttons can be added to the TIBCO iProcess
Workspace (Browser) using configuration settings in the TIBCO iProcess
Workspace (Browser)’s configuration file, config.xml.
The record element that specifies a custom menu or toolbar button has a jsxid
attribute value of customMenus:
<record jsxid="customMenus">

</record>
The <record jsxid="customMenus"> element can have either toolbar or menu

child elements. Both the toolbar and menu elements have three attributes:
• parent - The name of the menu or toolbar location. The following values are
valid:
— “MainAppToolbar”
— “WorkQList”
— "WorkItemList"
— “ProcList”
— “CaseList”
— “CaseSummary’
• width - The display width in pixels.
• prototype - The path to the default prototype XML file. This is the General
Interface prototype that defines the GUI components for the menu or toolbar.
The custom menu files should be added in a directory under the application root:
ClientInstallDir\JSXAPPS\ipc

Adding Custom Menu Items and Toolbar Buttons 37
|
The following example shows a toolbar and a menu element taken from the
samples given in config.xml:
<toolbar parent="MainAppToolbar" width="110"
prototype="JSXAPPS/ipc/custom/prototypes/toolbars/ToolbarSample.xml" />
<menu parent="ProcList" width="110"

prototype="JSXAPPS/ipc/custom/prototypes/menus/MenuSample.xml" />
</record>
Both the toolbar and menu elements may also have optional locale child elements
that define prototype XML files that are localized for specific languages. If a
locale child element exists, and it corresponds to the language and locale
currently selected by the user, the language-specific prototype is loaded,
otherwise the default prototype is loaded. For more information on customizing
the iProcess Workspace (Browser) for language localization, see Localization on
page 175.
Each locale child element has three attributes:
• localeKey - Locale identifier. This value must correspond to one of the
localeKey attributes defined in the Locales element of the
JSXAPPS/ipc/locale/locales.xml configuration file (see <record
jsxid=”Locales” type=”ipc”>). The localeKey attribute values are of the
format: ll or ll_CC, where ll is a lowercase, two- letter ISO 639 language code,
and CC is the optional, uppercase, two-letter ISO 3166 country code. For a list
of codes, visit these web sites:
— International Organization for Standardization (ISO):
http://www.iso.ch/iso/en/ISOOnline.frontpage
— Language codes:
http://www.loc.gov/standards/iso639-2/langhome.html
— Country codes:
http://www.iso.ch/iso/en/prods-services/iso3166ma/
02iso-3166-code-lists/index.html
• width - The display width in pixels.
• prototype - The path to the prototype XML file containing language-specific
data. This is the General Interface prototype that defines the GUI components
for the menu or toolbar.
The custom localized menu files should be added in a directory under the
application root:
ClientInstallDir\JSXAPPS\ipc

38
The following example shows a toolbar and a menu element, with localized
language-specific prototypes, taken from the samples in config.xml:
<toolbar parent="MainAppToolbar" width="110"
prototype="JSXAPPS/ipc/custom/prototypes/toolbars/ToolbarSample.xml" />
<locale localeKey="de_DE" width="200"
prototype="JSXAPPS/ipc/custom/prototypes/toolbars/ToolbarSample_de_DE.xml"/>
</toolbar>
<menu parent="ProcList" width="110"

prototype="JSXAPPS/ipc/custom/prototypes/menus/MenuSample.xml" />
<locale localeKey="de_DE" width="200"
prototype="JSXAPPS/ipc/custom/prototypes/menus/MenuSample_de_DE.xml"/>
</menu>
</record>
There is an example entry in config.xml for each of the valid parent attribute
values. These examples make reference to the sample files that can be found
under the installation home directory:
InstallationHomeDir\iprocessclientbrowser\samples\CustomMenus
where InstallationHomeDir is the directory in which the installer places
administrative files, such as the uninstaller, documentation, and sample code.
This defaults to C:\tibco on Windows systems, and /opt/tibco on UNIX
systems, but can be specified as a different directory when the TIBCO iProcess
Workspace (Browser) is installed.
The files in the ...\CustomMenus directory show examples of how to use both
menu and toolbar prototype XML files and handle the events using a
CustomEventHandler class.
The sample custom menus and toolbars can be installed using the steps listed
below. These same steps can be used to install actual custom menus and toolbars,
substituting the actual custom prototype, JavaScript, and image files and
config.xml entries. See the TIBCO General Interface Builder documentation for
details on creating custom menu or toolbar prototype files.
1. Create a custom directory under the application root:
ClientInstallDir\JSXAPPS\ipc\custom
Any valid directory name can be used. The “custom” directory name is used
in the sample entries shown in config.xml.
2. Copy all of the files from the following directory:
InstallationHomeDir\iprocessclientbrowser\samples\CustomMenus
... to your custom directory:
ClientInstallDir\JSXAPPS\ipc\custom

Adding Custom Menu Items and Toolbar Buttons 39
|
Note that the custom directory structure, and the examples in config.xml,
include samples for localizing the iProcess Workspace (Browser) in German
(locale de_DE). These files provide an example of the structure necessary to
provide language-specific support, however, to utilize these localized files, the
iProcess Workspace (Browser) must be configured for German language
support (see Localization on page 175).
3. In config.xml, add menu or toolbar elements under the <record
jsxid=”customMenus”> element. (Uncomment the samples shown in the
description for <record jsxid=”customMenus”>.)
4. Add a new mapping record in the config.xml file as a child element under
<record jsxid=”includes” type=”array”> for CustomEventHandler.js as
shown below:
<record jsxid="includes" type="array">

...
<record jsxid="someId" type="map">
<record jsxid="id" type="string">CustomEventHandler</record>
<record jsxid="type" type="string">script</record>
<record jsxid="owner" type="string">application</record>
<record jsxid="onLoad" type="boolean">true</record>
<record jsxid="required" type="boolean">true</record>
<record jsxid="src"
type="string">JSXAPPS/ipc/custom/js/CustomEventHandler.js</record>
</record>
</record>
The application should now load with the sample custom menus and toolbars
displayed.

40
Callout Interface
The callout interface provides methods that allow you to:

• Set default filters and sorts on the work item and case lists.
• Specify filters and sorts that can modify any user-defined filters and sorts.
• Specify which columns/fields the user can filter and sort on for work item
and case lists.
• Set default columns to display on the procedure list, work queue list, case list,
work item list, outstanding work item list on the case Outstanding tab, and
the outstanding work item list on the Process Jump dialog.
• Specify which columns are available for a user to display from the Column
Selector dialogs.
Methods in the callout interface can be used in combination with user access
profile settings to control filter, sort, and column display. For example:
• You could use the callout interface methods to set a default filter on the case
list, then use the access profiles to not allow the user to set a filter (i.e., do not
give access to the case list Filter dialog).
• You could use the callout interface methods to display specific columns in the
work item list by default, then use the user access profiles to not allow the
user to change the columns (i.e., do not give access to the Column Selector on
the work item list).
For information about user access profiles, see User Access Profiles on page 3.
Since callout method calls are used to restrict access to data, any exceptions
thrown will prevent the associated list from loading or close an already open list.
An error message will be displayed to the user, logged to the Application Log and
Application Monitor, and the list will be closed.
The callout methods are arranged in three functional groups:
• Filter - These methods control default filters and additional filters to apply to
user-defined filters.
• Sort - These methods control default sorts and additional sorts to apply to
user-defined sorts.
• Column - These methods control default column displays and which columns
the user is allowed to select from the Column Selector.
Basic knowledge of XML, JavaScript, and TIBCO General Interface is necessary to

understand and work with the callout methods.

Callout Interface 41
|
The following tables show the callout methods available:
Filter Methods (Case and Work Item Lists)

Method Description
calloutInitialWorkItemFilter Specifies the filter to be used when the work item list is
opened. The filter that was saved when the list was last closed
can be reused with or without modifications, or it can be
replaced with a default filter. This filter appears on the Filter
dialog after it is applied, and can be changed by the user if
they have access to the Filter dialog.
calloutWorkItemFilter Specifies the filter to apply to the work item list. This may be
used to either modify the user-defined filter, to append
additional criteria, or to override it. This is applied
automatically when the user applies a filter by either clicking
the Apply button on the work item list Filter dialog, or by
applying a server-side find. Any user-defined filter will
appear on the Filter dialog, but any modification applied to
the filter with this method will not be visible to the user.
calloutWorkItemFilterColumns Specifies which fields/columns can be used to filter work

items, i.e., it controls which fields/columns appear in the
Field drop-down list on the Filter dialog.
calloutInitialCaseFilter Specifies the filter to be used when the case list is opened. The
filter that was saved when the list was last closed can be
reused with or without modifications, or it can be replaced
with a default filter. This filter appears on the Filter dialog
after it is applied, and can be changed by the user if they have
access to the Filter dialog.
calloutCaseFilter Specifies the filter to apply to the case list. This may be used
to either modify the user-defined filter, to append additional
criteria, or to override it. This is applied automatically when
the user applies a filter by clicking the Apply button on the
case list Filter dialog. Any user-defined filter will appear on
the Filter dialog, but any modification applied to the filter
with this method will not be visible to the user.
calloutCaseFilterColumns Specifies which fields/columns can be used to filter cases, i.e.,

it controls which fields/columns appear in the Field
drop-down list on the Filter dialog.

42
Sort Methods (Case and Work Item Lists)

Method Description
calloutInitialWorkItemSort Specifies the sort to be used when the work item list is
opened. The sort that was saved when the list was last closed
can be reused with or without modifications, or it can be
replaced with a default sort. This sort appears on the Sort
dialog after it is applied, and can be changed by the user if
they have access to the Sort dialog.
calloutWorkItemSort Specifies the sort to apply to the work item list. This may be
used to either modify the user-defined sort, to append
additional criteria, or to override it. This is applied
automatically when the user applies a sort by clicking the
Apply button on the work item list Sort dialog. Any
user-defined sort will appear on the Sort dialog, but any
modification applied to the sort with this method will not be
visible to the user.
calloutWorkItemSortColumns Specifies which fields/columns can be used to sort work

items, i.e., it controls which fields/columns appear in the
Available Fields list on the Sort dialog.
calloutInitialCaseSort Specifies the sort to be used when the case list is opened. The
sort that was saved when the list was last closed can be
reused with or without modifications, or it can be replaced
with a default sort. This sort appears on the Sort dialog after
it is applied, and can be changed by the user if they have
access to the Sort dialog.
calloutCaseSort Specifies the sort to apply to the case list. This may be used to
either modify the user-defined sort, to append additional
criteria, or to override it. This is applied automatically when
the user applies a sort by clicking the Apply button on the
case list Sort dialog. Any user-defined sort will appear on the
Sort dialog, but any modification applied to the sort with
this method will not be visible to the user.
calloutCaseSortColumns Specifies which fields/columns can be used to sort cases, i.e.,

it controls which fields/columns appear in the Available
Fields list on the Sort dialog.

|
Column Methods (Procedure, Case, Work Queue, Work Item, Outstanding, Outstanding-Jump
Lists)
Method Description
calloutColumns Specifies the default columns to display on the procedure
list, case list, work queue list, work item list, outstanding
work items list on the case Outstanding tab, and the
outstanding work items lists on the Process Jump dialog.
calloutSelectColumns Specifies which columns will be available to the user on the

Column Selector dialog from the procedure list, case list,
work queue list, work item list, outstanding work items list
on the case Outstanding tab, and the outstanding work
items lists on the Process Jump dialog. This controls which
columns the user is able to display on each of the lists.
A custom class can implement one or more of the methods in the tables above.
One or more custom classes may be used to handle these method calls.
If there is no implementation of these methods, there are no restrictions other than
what might be applied through user access profiles.
Additional details about each callout method can be found in Callout Method
Signatures on page 46.
Configuration
The TIBCO iProcess Workspace (Browser) comes with a sample callout handler
that contains sample implementations of all of the callout methods. This sample
callout handler is named ‘SampleCalloutHandler.js’ and is located in the
InstallationHomeDir\iprocessclientbrowser\samples\Callouts directory,
Workspace (Browser) is installed.
Perform the following steps to create a custom handler and configure your TIBCO
iProcess Workspace (Browser) to use the callout methods.
1. Copy the SampleCalloutHandler.js file into a directory you’ve created
under the ClientInstallDir\JSXAPPS\ipc\ directory, where ClientInstallDir is the
path to the directory in which the TIBCO iProcess Workspace (Browser) is
installed. For example, ClientInstallDir\JSXAPPS\ipc\Callouts.

44
You may also want to rename the SampleCalloutHandler.js file to identify

the type of custom handling it performs. For example,
‘ColumnsCalloutHandler.js’.
2. Modify the callout handler (e.g., ColumnsCalloutHandler.js) to fit your
needs.
The original SampleCalloutHandler.js file that you copied contains sample
implementations of each of the available callout methods.
Each callout method receives a data parameter that can be modified by the
method and returned to the application. The following are example data
parameters:
— filterExpression (string)
— sortFields (Array<com.tibco.bpm.ipc.vSortField>)
— columns (jsx3.xml.Entity)
Additional parameters provide information the methods can use to determine
how the filters, sorts, and columns should be modified. For example:
— username (string)
— eventNode (jsx3.xml.Entity)
— listType (string)
— availableFields (jsx3.xml.Entity)
The jsx3.xml.Entity object is a TIBCO General Interface class that is a wrapper
of the native browser XML node class. This class provides methods for
querying, traversing, and creating XML entities (see the TIBCO General
Interface documentation for more information). The object is a Document
Object Model (DOM) class that provides methods to add, find, modify, or
delete XML values in an XML document. Use these methods to modify the
incoming XML so that the desired filter, sort, or columns are displayed.
In each case, the method returns the same type of XML object that was passed
in. This would probably be the same object in most cases, with some
modification applied.
When customizing the callout handler, you must also register the callout
method with the application CalloutController by adding the method to the
init (constructor) method. It must be in the form:
app.getCalloutController().registerHandler(target,arrayOfMethodNames)

|
where:
— target - (Object) The instance or object the method is called on.
— arrayOfMethodNames - (Array<strings>) Array of strings that are the names of
the methods to register.
The following is an example of the init method in which the
calloutColumns method is registered:
ipcClass.prototype.init = function(app) {
this.app = app;
this.controller = this.app.getCalloutController();
this.controller.registerHandler(this,['calloutColumns']);
};
A reference to the application object is passed as the single parameter to the

init (constructor) method.
Note that the application getServer() method can be used to get a reference
to the jsx3.app.Server instance:
app.getServer()
3. Specify the callout handler custom class in the iProcess Workspace (Browser)’s
configuration file, ClientInstallDir\JSXAPPS\ipc\config.xml.
The <record jsxid=”customCallout” element specifies which classes will be
loaded to handle custom callout methods. The <Classes> element can contain
any number of <Class> elements whose class attribute is set to the fully
qualified name of the custom class to load. The class is loaded after the user is
authenticated at login. This gives the custom class access to the logged-in
user's session to query the Action Processor for initialization data, if required.
The following is an example of the customCallout element identifying the
ColumnsCalloutHandler custom class:
<record jsxid="customCallout" type="ipc">

<Classes>
<Class class="com.tibco.bpm.ipc.ColumnsCalloutHandler" />
</Classes>
</record>

46
4. Add a mapping record to the config.xml file that points to the custom
handler. This is added as a child element of the <record jsxid=”includes”
element. The following is an example class mapping element for the custom
callout handler, ColumnsCalloutHandler.js.
<record jsxid="includes" type="array">

...
<record jsxid="90" type="map">
<record jsxid="id" type="string">ColumnsCalloutHandler</record>
<record jsxid="src" type="string">JSXAPPS/ipc/callouts/ColumnsCalloutHandler.js</record>
</record>
</record>
5. Optionally, modify the user access profiles that would be used in conjunction
with the custom handling. For example, if your custom handler is setting the
default columns on the work item list, you may want to deny access to the
Column Selector on the work item list (see SelectColumns on page 11).
Callout Method Signatures

The following are the method signatures from the SampleCalloutHandler.js
file (in JavaDoc format).
Note that the parameter data XML examples shown with the method signatures
are representative samples — they may contain other attributes that are not
shown.
calloutInitialWorkItemFilter
/**
* @param filterExpression (string) The filter string value.
* @param username (string) The logged in user name.
* @param queueNode (jsx3.xml.Entity) The queue node XML for the
* workitem list.
* @param availableFields (jsx3.xml.Entity) XML defining the available
* fields that can be filtered.
*
* @return (string) Modified filter string.
*/
ipcClass.prototype.calloutInitialWorkItemFilter = function(
filterExpression,
username, queueNode,
availableFields) {

|
calloutWorkItemFilter
/**
* workitem list.
*
*/
ipcClass.prototype.calloutWorkItemFilter = function(filterExpression,
availableFields) {
The following is an example filterExpression parameter value used with

calloutWorkItemFilter:
SW_PRONAME = "a*"
The sample above would show only work items whose procedure name starts
with “a”. (For information about filter expression syntax, see the TIBCO iProcess
Server Objects (Java or .NET) Programmer’s Guide.)
calloutWorkItemFilterColumns
/**
* workitem list.
* @return (jsx3.xml.Entity) Modified XML defining the
* available fields that can be
* filtered.
*/
ipcClass.prototype.calloutWorkItemFilterColumns = function(
availableFields,
username,
queueNode) {

48
The following are example availableFields and queueNode parameter values

used with calloutWorkItemFilterColumns:
availableFields (jsx3.xml.Entity)
<data jsxid="jsxroot">
<record jsxid="OCCUPATION" jsxtext="Occupation" fieldType="swText"
fieldLength="20" />
<record jsxid="SW_ARRIVAL" jsxtext="Date and Time Arrived" fieldType="swTimeStamp"
fieldLength="16" />
<record jsxid="SW_ARRIVALDATE" jsxtext="Date Arrived" fieldType="swDate"
fieldLength="10" />
<record jsxid="SW_ARRIVALTIME" jsxtext="Time Arrived" fieldType="swTime"
fieldLength="5" />
...
</data>
queueNode (jsx3.xml.Entity)
<record jsxid="IDA3CHEB"
Name="swadmin"
Description="System Administrator"
HostingNode="i2tagtest"
Tag="i2tagtest|swadmin|R"
IsGroup="false"
IsReleased="true"
FirstDeadline="2006-07-28 10:44:00"
DeadlineCnt="17"
UnopenedCnt="138"
UrgentCnt="2"
WorkItemCnt="267"
WorkQParam1Name="WQ Parameter1"
WorkQParam4Name="WQ Parameter4" >
</record>

|
calloutInitialCaseFilter
/**
* @param procNode (jsx3.xml.Entity) The procedure node XML for
* the case list.
* fields that can be sorted.
*
*/
ipcClass.prototype.calloutInitialCaseFilter = function(
filterExpression,
username, procNode,
availableFields) {
calloutCaseFilter
/**
* the case list.
*
*/
ipcClass.prototype.calloutCaseFilter = function(filterExpression,
username, procNode,
availableFields) {

50
calloutCaseFilterColumns
/**
* @param procNode (jsx3.xml.Entity) The proc node XML for the
* case list.
* filtered.
*/
ipcClass.prototype.calloutCaseFilterColumns = function(availableFields,
username,
procNode) {
calloutInitialWorkItemSort
/**
* @param sortFields (Array) An array of
* com.tibco.bpm.ipc.vSortField
* instances.
* workitem list.
*
* @return (Array) Modified array of
* instances.
*/
ipcClass.prototype.calloutInitialWorkItemSort = function(sortFields,
availableFields) {

|
calloutWorkItemSort
/**
* instances.
* workitem list.
*
* instances.
*/
ipcClass.prototype.calloutWorkItemSort = function(sortFields,
availableFields) {
The following describes the sortFields parameter used with

calloutWorkItemSort:
Each vSortField has three properties with accessors as shown:
— fieldName getFieldName()
— ascending getAscending()
— sortAsType getSortAsType()
For example:
sortFields[0] :
fieldName : SW_CASEDESC
ascending : true
sortAsType: swTextSort
sortFields[1] :
fieldName : SW_CASENUM
ascending : true
sortAsType: swTextSort
Work items will be sorted in the order in which elements are passed in the
vSortField array.
New vSortField values are created by passing the three properties in the
constructor:
var newSortFields = new Array();
newSortFields.push(new com.tibco.bpm.ipc.vSortField('SW_CASEDESC',
true,
'swTextSort'));
newSortFields.push(new com.tibco.bpm.ipc.vSortField('SW_CASENUM',
true,
'swTextSort'));

52
calloutWorkItemSortColumns
/**
* workitem list.
* filtered.
*/
ipcClass.prototype.calloutWorkItemSortColumns = function(
availableFields,
username,
queueNode) {
The following is an example availableFields parameter value used with

calloutWorkItemSortColumns:
<record jsxid="SW_ARRIVAL" jsxtext="Date and Time Arrived"
sorttype="swDateTimeSort" />
<record jsxid="SW_CASEDESC" jsxtext="Case Description"
sorttype="swTextSort" />
<record jsxid="SW_CASENUM" jsxtext="Case Number"
sorttype="swNumericSort" />
...
</data>
calloutInitialCaseSort
/**
* instances.
* the case list.
*
* instances.
*/
ipcClass.prototype.calloutInitialCaseSort = function(sortFields,
username, procNode,
availableFields) {

|
calloutCaseSort
/**
* instances.
* the case list.
*
*
*/
ipcClass.prototype.calloutCaseSort = function(sortFields,
username, procNode,
availableFields) {
calloutCaseSortColumns
/**
* @param procNode (jsx3.xml.Entity) The proc node XML for the
* case list.
* filtered.
*/
ipcClass.prototype.calloutCaseSortColumns = function(availableFields,
username,
procNode) {

54
calloutColumns
/**
* @param columns (jsx3.xml.Entity) The serialized columns for
* the list.
* @param eventNode (jsx3.xml.Entity) The procedure (Cases list),
* workQ (WorkItems list), or
* caseTag data (Outstanding)
* node XML. Null for Proc and
* WorkQ list types:
* fields for column selection.
* @param listType (string) The list type, one of:
* com.tibco.bpm.ipc.ListContainer.PROC
* com.tibco.bpm.ipc.ListContainer.CASE
* com.tibco.bpm.ipc.ListContainer.WORKQ
* com.tibco.bpm.ipc.ListContainer.WORKITEM
* com.tibco.bpm.ipc.ListContainer.OUTSTANDING
* com.tibco.bpm.ipc.ListContainer.OUTSTANDING +
'Jump'
*
* @return (jsx3.xml.Entity) Modified serialized columns
* for the list.
*
*/
ipcClass.prototype.calloutColumns = function(columns,
username, eventNode,
availableFields,
listType) {

|
The following describes the eventNode parameter used with calloutColumns:

The value of eventNode depends on the type of list as shown below:
— Proc list : null
— Case list:
<record
Name="ALLOCATE"
Description="Allcate Resources"
Version="0.2"
Tag="i2tagtest|ALLOCATE|0|2"
ProcNumber="36"
StartStepName="STEP1"
Status="swReleased"
CaseDescOpt="swRequiredDesc"
IsAutoPurge="false"
IsIgnoreBlank="false"
IsNetworked="false"
IsSubProc="false"
IsOrphaned="false"
IsWorkDays="true"
IsPrediction="false"
Owner="swadmin"
Duration="swDurationNone"
Permission="Start / History"
CaseCount="40"
ActiveCount="39"
ClosedCount="1">
</record>
— WorkQ list: null

56
— WorkItem list:
<record
Name="rbTestGroup"
Description="rbTestGroup"
Tag="i2tagtest|rbTestGroup|R"
IsGroup="true"
IsReleased="true"
DeadlineCnt="0"
UnopenedCnt="1"
UrgentCnt="0"
WorkItemCnt="1"
WorkQParam4Name="WQ Parameter4" >
</record>
— Outstanding or Outstanding Jump:
<record
CaseTag="i2tagtest|ALLOCATE|0|2|2453"
NodeName="i2tagtest"
ProcName="ALLOCATE"
MajorVerion="0"
MinorVerion="2"
CaseNumber="2453"/>
</record>
calloutSelectColumns
/**
* @param availableFields (jsx3.xml.Entity) XML defining the fields
* available for column
* selection.
* @param eventNode (jsx3.xml.Entity) The procedure (Cases list),
* workQ (WorkItems list), or
* caseTag data (Outstanding)
* node XML. Null for Proc and
* WorkQ list types:
* @param columns (jsx3.xml.Entity) The serialized columns for
* the list.
* @param listType (string) The list type, one of:
* com.tibco.bpm.ipc.ListContainer.PROC

|
* com.tibco.bpm.ipc.ListContainer.CASE
* com.tibco.bpm.ipc.ListContainer.WORKQ
* com.tibco.bpm.ipc.ListContainer.WORKITEM
* com.tibco.bpm.ipc.ListContainer.OUTSTANDING
* com.tibco.bpm.ipc.ListContainer.OUTSTANDING +
'Jump'
*
* fields available for column
* selection.
*
*/
ipcClass.prototype.calloutSelectColumns = function(availableFields,
username, eventNode,
columns,
listType) {
The following are example availableFields and columns parameter values used
with calloutSelectColumns:
availableFields (jsx3.xml.Entity)
<record jsxid="IsStatusImage" />
<record jsxid="CaseNumber" fieldname="SW_CASENUM" fieldtype="swNumeric"/>
<record jsxid="CaseReference" fieldname="SW_CASEREF" fieldtype="swText"/>
...
</data>
columns (jsx3.xml.Entity)
The columns value contains the serialized columns for the list. The following
sample shows how this can be obtained from a jsx3.gui.List:
var objProperties = new Object();
objProperties['children'] = true;
var serializedXml = jsxList.toXML(objProperties);

58
The following is a sample of the serialized columns:
<serialization xmlns="urn:tibco.com/v3.0">
<unicode></unicode>
<name><![CDATA[]]></name>
<icon><![CDATA[]]></icon>
<description><![CDATA[]]></description>
<onBeforeDeserialize><![CDATA[]]></onBeforeDeserialize>
<onAfterDeserialize><![CDATA[]]></onAfterDeserialize>
<objects>
<object type="jsx3.gui.Column">
<dynamics jsxfontname="ipcList FN" jsxfontsize="ipcList FS" .../>
<variants jsxwidth="23" jsxresize="1"/>
<strings jsxname="colStatusImage" jsxpath="@IsStatusImage" ... />
<children>
</children>
</object>
<dynamics jsxfontname="ipcColHeader FN" jsxfontsize="ipcColHeader FS" .../>
<variants jsxwidth="45"/>
<strings jsxname="colWorkItemCaseNumber" jsxpath="@CaseNumber" .../>
<children>
</children>
</object>
<dynamics jsxtext="txtCaseDesc" jsxfontname="ipcColHeader FN" .../>
<variants jsxwidth="120"/>
<strings jsxname="colWorkItemDesc" jsxpath="@Description" ..."/>
<children>
</children>
</object>
...
</objects>
</serialization>

| 59
Chapter 2 Configuring the Action Processor
The installation procedure for the TIBCO iProcess Workspace (Browser) steps you
through the configurations that are necessary to get the Action Processor up and
running.
This chapter describes additional options that can be configured after the Action
Processor has been installed.
Topics
• Overview, page 60
• Log Settings, page 61
• XML Response Compression, page 62
• Return Request Parameters, page 63
• External Form URI, page 64
• Server Factories, page 65
• XML Validation, page 66
• Action Processor Version, page 67

60
| Chapter 2 Configuring the Action Processor
Overview
All of the Action Processor configuration settings are specified in the Action
Processor’s configuration file, which is located as follows:
APDir\apConfig.xml
where APDir is the directory in which the Action Processor is installed (which
defaults to “TIBCOActProc”). The location of this directory on your system will
depend on which Web Application Server is hosting your Action Processor.
If changes are made to any of the Action Processor configuration settings, you
must restart the Action Processor so it picks up the changes to apConfig.xml. To
restart the Action Processor, stop and restart the Web Application Server.
The Action Processor configuration settings are described in the following
subsections.
Note that Secure Sockets Layer (SSL) can be used to secure communications
between the Action Processor and the client. However, the way in which it is
implemented is specific to the Web Application Server (WAS) you are using. See
the documentation for your WAS.
Also note that if you access the TIBCO iProcess Workspace (Browser) through
HTTPS, you must also access the Action Processor through HTTPS, and vice
versa. In other words, you cannot access one through HTTP and the other one
through HTTPS.

Log Settings 61
|
Log Settings
There are a number of configuration parameters that allow you to specify the type
and amount of information to write to the Action Processor log file. Locate the
following elements in the apConfig.xml file and change the default value to fit
your needs for Action Processor logging:
• <LogLevel> - This specifies the level of information to write to the log. The
valid levels are:
— ERROR - This provides the least amount of information.
— WARN - This provides more information than ERROR, but less than INFO.
— INFO - (The default) This provides more information than WARN, but less
than DEBUG.
— DEBUG - This provides the most amount of information. This setting
should be used only if there is a problem that is being diagnosed.
• <MaxLogFileSize> - This specifies the maximum size of the log file before it is
rolled over. The default is 10 MB. Setting this to 0 (zero) causes the log to
never roll over.
• <LogArchiveCount> - This specifies the number of archived log files. These
are created if the log exceeds the maximum size limit specified with the
<MaxLogFileSize> tag. The default is 5. Note that the naming convention for
these differs between Java and .NET, as follows (assuming you are using the
default log file name specified in the <LogFile> tag):
— Java Action Processor: APLog.log.X, where X starts at 1 and increases as
archive log files are created (e.g., APLog.log.1).
— .NET Action Processor: APLogXXX.log, where XXX starts at 001 and
increases as archive log files are created (e.g., APLog001.log).
• <LogFile> - This specifies the fully qualified path to the log file. If only the
name is specified, the log file is written to the directory specified in the system
property user.home. This defaults to APLog.log.

62
XML Response Compression
This parameter specifies whether or not to compress the XML response from the
Action Processor. (This is only applicable for the Java Action Processor.) This may
be desired if the connection link between the client and Action Processor is slow.
The default is to not compress the response.
To specify the XML response compression setting:
1. Locate the <IsCompressResponse> element in the apConfig.xml file:
<IsCompressResponse>false</IsCompressResponse>
2. Specify a value in this element of “true” to compress the XML response from
the Action Processor, or “false” to not compress.

Return Request Parameters 63
|
Return Request Parameters
This configuration setting specifies whether or not the Action Processor should,
by default, return parameter information to the client (parameter information is
returned to the client in the form of <InParam> elements).
When the Action Processor calls the GetXMLResult method, it passes the value
in this configuration setting in the “WithInput” parameter to specify whether or
not to return input information. This setting defaults to “false”.
To specify the return request parameter setting:
1. Locate the <IsReturnSSOParams> element in the apConfig.xml file:
<IsReturnSSOParams>false</IsReturnSSOParams>
2. Specify a value in this element of “true” to include input parameters by

default, or “false” to exclude input parameters by default.

64
External Form URI
This parameter is used to specify a URI that points to an external forms package
that is used to display forms in the iProcess Workspace. This parameter is used
with the following external forms packages:
• TIBCO BusinessWorks iProcess™ Forms Plug-in - This plug-in allows you
to create a form using TIBCO BusinessWorks™ FormBuilder, then associate
that form with a step in a TIBCO iProcess Engine procedure. For information
about this plug-in, see the TIBCO BusinessWorks iProcess Forms Plug-in User’s
Guide.
• ASP Forms - These forms can be created in a .NET project, then used in a
TIBCO iProcess Engine procedure. For information about using these types of
forms, see ASP Forms on page 137.
• JSP Forms - These forms can be created in a Java development environment,
then used in a TIBCO iProcess Engine procedure. For information about using
these types of forms, see JSP Forms on page 147.
To specify the external form URI setting:
1. Locate the <ExternalFormURI> element in the apConfig.xml file:
<ExternalFormURI>http://localhost:8080/</ExternalFormURI>
2. Replace “localhost” with the name of the computer on which the Formflow
process, ASP form, or JSP form is deployed, and replace “8080” with the port
number used by the Web Application Server that is hosting your external
form. For example:
<ExternalFormURI>http://whisler:90/</ExternalFormURI>
Note that the final slash following the port number is required.

Server Factories 65
|
Server Factories
This parameter specifies the server factories to use when using the Remote
Method Invocation (RMI). (This parameter is only applicable for the Java Action
Processor.)
To specify the server factories to use:
1. Locate the <ServerFactories> element in the apConfig.xml file:
<ServerFactories>
<ServerFactory>
<UniqueId></UniqueId>
<Name></Name>
<IsJRMP></IsJRMP>
<LoadFactor></LoadFactor>
<JNDIEnvs>
<JNDIEnv>
<Name></Name>
<Value></Value>
</JNDIEnv>
</JNDIEnvs>
</ServerFactory>
</ServerFactories>
2. Enter values in these elements to specify information about the server factory:
— <UniqueId>: Used to uniquely identify the server factory.
— <Name>: The name of the server factory.
— <IsJRMP>: This specifies the protocol used to marshall objects. Setting this
to “true” causes the Java Remote Method Protocol (JRMP) to be used;
setting this to “false” causes Internet Inter-ORB Protocol (IIOP) to be used.
(Note that the protocol specified here must be the same protocol used when
constructing xSession objects.)
— <LoadFactor>: This specifies how the load should be dispersed among the
server factories when using multiple server factories. The number specified
here is viewed as a percentage of the total of the load factors specified for
all server factories. For ease of use, the total of all load factors should total
100 (although it’s not required). For example, if three server factories are
used, their load factors might be set to 50, 30, and 20 — the first one will get
50% of the load, the second 30%, and the third 20%.
— <JNDIEnv>: Multiple JNDI environment settings can be specified to use
when creating the context used to locate the server factory. Each of these
will contain a <Name> and <Value> element to provide specifics about the
environment setting.
Multiple <ServerFactory> elements can be configured, one for each server factory
used.

66
XML Validation
This parameter specifies whether or not to validate the XML requests to the
Action Processor using an XSD (apAction.xsd). This is configurable because there
is some overhead incurred when validating requests.
The default is to not validate the requests.
To specify the XML validation setting:
1. Locate the <IsValidateActionXML> element in the apConfig.xml file:
<IsValidateActionXML>false</IsValidateActionXML>
2. Specify a value in this element of “true” to validate the XML requests, or

“false” to not validate.

Action Processor Version 67
|
Action Processor Version
This parameter is used to specify whether or not to display the Action Processor
version number in the Action Processor action response. The version number is
displayed under the <ap:Status> element in the response: For example:
<ap:Status>
<ap:Version>10.6.0</ap:Version>
...
To specify this setting:

1. Locate the <IsReturnVersion> element in the apConfig.xml file:
<IsReturnVersion>true</IsReturnVersion>
2. Specify a value in this element of “true” to return the Action Processor

version, or “false” to not return the version.

68

| 69
Chapter 3 GI Forms Interface
This chapter provides an overview of the TIBCO GI Forms interface, information

about how to implement the interface to display custom GI forms, and a list of the
methods available to handle custom form prototypes.
The intended audience of this information is developers who have a thorough
understanding of the TIBCO General Interface™ Builder and the functionality
available through the TIBCO iProcess Server Objects.
Topics
• Implementation, page 73
• Interface Properties and Methods, page 78
• FieldData Class, page 112
• Date Conversions, page 116
• Accessing User Options When Using GI Forms, page 127

70
| Chapter 3 GI Forms Interface
Overview
The GI Forms interface allows you to create forms using the 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
TIBCO General Interface Builder
Custom Form
Name
Address
City
State
. . .
TIBCO iProcess Client (Browser)
N ame
User Action
A ddress
Form Prototype
C ity
S tate
. . .
- start case (e.g., CustomFormDefault.xml)

- open work item
Custom Form Class

config.xml
(e.g., CustomForm.js)
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

Overview 71
|
(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.

72
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 on page 78. (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.

Implementation 73
|
Implementation
Perform the following steps to implement the GI Forms interface in the TIBCO
1. Copy the entire FormTemplate directory, and paste it into the
.../components/Forms directory.
2. Rename the copied directory to match the class name for your custom form.
For example, assume a custom form with a class name of “CustomForm1”:
3. In the new custom form directory, replace the “FormTemplate” name with the
name of your custom form class. For example:
— Forms/CustomForm1/js/FormTemplate.js
— Forms/CustomForm1/prototype/FormTemplateDefault.xml
... should become:

— Forms/CustomForm1/js/CustomForm1.js
— Forms/CustomForm1/prototype/CustomForm1Default.xml
The following illustrates an example directory/file structure for the new

custom form:
4. Globally replace “FormTemplate” with your class name (“CustomForm1” in

this example) in the CustomForm1.js file.

74
5. Replace the content of CustomForm1Default.xml with the XML that defines

the prototype of your custom form.
Event actions defined in a custom form prototype can get reference to the
custom form class instance by getting the parent of the top level object. The
examples below are taken directly from the FormTemplateDefault.xml
sample prototype file.
The example button object defined below returns a reference to the custom
form class instance, and the doKeep() function defined in the custom class is
called when the jsxexecute event is triggered.
<object type="jsx3.gui.Button">
<variants jsxindex="0" jsxheight="18"/>
<strings jsxname="btnKeep" jsxtext="Keep" jsxmargin="top:6px"/>
<events jsxexecute="this.getAncestorOfName('layoutFormData').getParent().doKeep();"/>
</object>
Note that the name referenced above, layoutFormData, is the name assigned
to the top-level object (using: jsxname=”layoutFormData”) in the form
prototype:
<object type="jsx3.gui.LayoutGrid">
<variants jsxrepeat="2" jsxsizearray="['*','30']" jsxrelativeposition="0" ... />
<strings jsxname="layoutFormData" jsxwidth="100%" jsxheight="100%"/>
<children>
...
See JSXAPPS\ipc\components\Forms\FormTemplate\prototypes
\FormTemplateDefault.xml to see these examples in their complete context.
6. Modify the methods in CustomForm1.js to handle the custom form

prototype. For information about the methods available, see Base Class
Methods on page 81.
7. Update the TIBCO iProcess Workspace (Browser) configuration file
(...\JSXAPPS\ipc\config.xml) to include a <Form> element under the
<Forms> element for each custom form.

Implementation 75
|
The following is an example <Forms> element with a number of sample

<Form> entries:
A sample configuration file (config-sample.xml) is provided in the

JSXAPPS/ipc/components/Forms directory from which you can copy a sample
<Forms> element, then modify it to fit your needs.

76
The following defines the available <Form> element attributes that need to be
specified for each custom form (note that the optional attributes can be either
omitted or set to a zero-length string):
— procName (required) - The name of the procedure in which the custom
form is used.
— stepName (required) - The name of the step to which the custom form is
associated. When this step is reached in the case (procedure instance), the
custom form is displayed.
— class (required) - The name of the class that defines the custom form. This
is the class that is instantiated by the iProcess Workspace (Browser) when
the user starts a case or opens an existing work item. For the example
described earlier, this would be specified as:
class=”com.tibco.bpm.ipc.CustomForm1”
— prototypePath (optional) - The path to a prototype for the custom form,

relative to the forms root directory, specified in
com.tibco.bpm.ipc.Form.DIR (this defaults to
‘JSXAPPS/ipc/components/Forms/’). For the example described earlier,
this would be specified as:
prototypePath=”CustomForm1/prototypes/CustomForm1Default.xml”
If the prototype path is not specified here or explicitly in the class, the
default path is used:
com.tibco.bpm.ipc.Form.DIR + classname + '/prototypes/' +

classname + 'Default.xml'
For example, the default prototype path for the sample FormTemplate is:
“FormTemplate/prototypes/FormTemplateDefault.xml”
— nodeName (optional) - The name of the TIBCO iProcess Objects Server on

which the procedure specified in the procName attribute (see above) is
defined. This attribute is optional. If it is not specified, any server will
match.
— major (optional) - The “major” portion of the procedure version number.
For example, if the procedure version is 3.2, major = “3”.
— minor (optional) - The “minor” portion of the procedure version number.
For example, if the procedure version is 3.2, minor = “2”.
— floatWorkItems (optional) - This attribute is relevant only for custom GI
forms. It specifies whether or not the custom GI form is opened in a
separate browser window. The valid entries are “browser” for open the
form in a separate browser window, or “dialog” for open the form in a
dialog within the browser running the TIBCO iProcess Workspace

Implementation 77
|
(Browser). If omitted or set to any other value, the value selected in the
When opening a floating work item form, open it in option on the
application’s Options dialog is used.
8. Update the TIBCO iProcess Workspace (Browser) configuration file to include
mappings to each custom form class. The configuration file is located at:
...\JSXAPPS\ipc\config.xml
The following is an example map record for the sample form template:
<record jsxid="127" type="map">

<record jsxid="id" type="string">FormTemplate</record>
<record jsxid="src"
type="string">JSXAPPS/ipc/components/Forms/FormTemplate/js/FormTemplate.js</record>
</record>
Locate the existing mapping records (type = “map”) in the config.xml file and
enter a record for each of your custom form classes.
Note that the jsxid value for the map-type record (127 in this example) is
arbitrary, i.e., you can specify any value desired (the jsxid is not used in this
context).
A sample configuration file (config-sample.xml) is provided in the

JSXAPPS/ipc/components/Forms directory from which you can copy sample
mapping records, then modify them to fit your needs.

78
Interface Properties and Methods
This section provides information about the properties and methods available in
the com.tibco.bpm.ipc.Form base class. Since the custom form class extends this
base class, these properties and methods can be accessed directly in your custom
form class.
Base Class Properties

The following accessor methods are available to the subclass to access properties
in the com.tibco.bpm.ipc.Form base class.
Method Returns Property Description

isStartCase() boolean True if form opened for a start case.
getDescription() string Start case or work item description.
getProcName() string The procedure name.
getStepName() string Name of the start step.
getProcTag() string The procedure tag.
getCaseNumber() string The case number.a
getWorkItemTag() string The work item tag.a
getWorkQTag() string The work queue tag.a
getNode() jsx3.xml.Entity The start case or work item node.
a. The case number, work item tag, and work queue tag are null for start case.
Note that any of the values in the node returned by getNode() can be read using
getAttribute('attributeName') as shown below:
var version = this.getNode().getAttribute('Version');
The following samples show node data returned by getNode() (shown

formatted):
For Start Case:
<record
jsxid="IDAOAICE"
jsxtext=""

Interface Properties and Methods 79
|
jsximg=""
IsStatus="true"
IsStatusImage="JSXAPPS/ipc/application/images/ProcReleased.gif"
Name="PROCNAME"
Description="Case Description"
HostingNode="serverNodeName"
Version="0.2"
Tag="serverNodeName|PROCNAME|0|2"
ProcNumber="36"
StartStepName="STEP1"
Status="swReleased"
CaseDescOpt="swRequiredDesc"
IsAutoPurge="false"
IsIgnoreBlank="false"
IsNetworked="false"
IsSubProc="false"
IsSubProcImage="JSXAPPS/ipc/application/images/IsFalse.gif"
IsOrphaned="false"
IsWorkDays="true"
IsPrediction="false"
Owner="username"
Duration="swDurationNone"
Permission="Start / History"
CaseCount="36"
ActiveCount="35"
ClosedCount="1"
jsxselected="1"
ListId="_jsx_ipcNS_102"
IsCustomFormStartCase="true">
</record>
For Work Item:

<record
jsxid="IDAFSZGE"
jsxtext=""
jsximg=""
IsStatus="true"
IsStatusImage="JSXAPPS/ipc/application/images/ItemLockedDesktop.gif"
CaseNumber="4922"
CaseReference="36-4922"
Description="Case Description"
Tag="serverNodeName|PROCNAME|username|R|4922|421916|
serverNodeName|STEP1|0|2"
StartedBy="username@serverNodeName"
Proc_Name="PROCNAME"
Proc_Description="Proc Description"
Proc_HostingNode="serverNodeName"
Version="0.2"
Proc_Tag="serverNodeName|PROCNAME|0|2"
ComputerName="OZQUADLING"
CaseFields=""
MailId="421916|serverNodeName"
CaseTag="serverNodeName|PROCNAME|0|2|4922"
AddrToName="username@serverNodeName"

80
Arrived="2006-08-29 16:22"
IsDeadline="false"
IsDeadlineImage="JSXAPPS/ipc/application/images/IsFalse.gif"
IsDeadlineExp="false"
IsDeadlineExpImage="JSXAPPS/ipc/application/images/IsFalse.gif"
IsKeepOnWithdrawalImage="JSXAPPS/ipc/application/images/IsFalse.gif"
IsKeepOnWithdrawal="false"
IsForwardableImage="JSXAPPS/ipc/application/images/IsFalse.gif"
IsForwardable="false"
IsLocked="false"
IsLockedImage="JSXAPPS/ipc/application/images/IsFalse.gif"
IsLongLocked="true"
IsLongLockedImage="JSXAPPS/ipc/application/images/IsTrue.gif"
IsOrphanedImage="JSXAPPS/ipc/application/images/IsFalse.gif"
IsOrphaned="false"
IsReleasable="false"
IsReleasableImage="JSXAPPS/ipc/application/images/IsFalse.gif"
IsUnopened="false"
IsUnopenedImage="JSXAPPS/ipc/application/images/IsFalse.gif"
IsUrgent="false"
IsUrgentImage="JSXAPPS/ipc/application/images/IsFalse.gif"
IsSuspended="false"
IsSuspendedImage="JSXAPPS/ipc/application/images/IsFalse.gif"
LockedBy="username"
Priority="50"
StepName="STEP1"
StepDescription="First step"
OCCUPATION=""
WorkQParam1=""
WorkQParam2=""
WorkQParam3=""
WorkQParam4=""
DeltaStatus="swNotDeltaItem"
jsxselected="1"
ListId="_jsx_ipcNS_254"
IsCustomFormStartCase="false">
</record>

Interface Properties and Methods 81
|
Base Class Methods

This section provides information about the methods available in the
com.tibco.bpm.ipc.Form base class.
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.
The following is a list of the methods described in this section:
• closeForm, page 82
• confirmUserMessage, page 83
• createFieldDefsRequest, page 84
• createKeepRequest, page 88
• createLockRequest, page 91
• createReleaseRequest, page 95
• doCancel, page 98
• doClose, page 99
• doKeep, page 100
• doRelease, page 101
• init, page 102
• lockWorkItem, page 103
• onBeforeUnload, page 105
• postLoadInit, page 106
• readFieldDefs, page 107
• showUserMessage, page 109
• socketRequest, page 110
• transformData, page 111

82
closeForm
Purpose This method closes the dialog.
Syntax closeForm()
Parameters None
Returns Void
Remarks This method also clears the XML cache data. The XML cache data includes any
XML data stored in cache as a result of a socketRequest or transformData call.
Caches are cleared that have IDs containing the form instance object ID. If names
other than the default cache names have been used, the overriding class should
ensure that all caches have been removed.

confirmUserMessage 83
|
confirmUserMessage
Purpose Displays a confirm dialog with the given message. If this is a child browser
window, the confirm is sent to the child window context to prevent focus being
moved to the parent browser window.
Note - Custom GI forms should call this.confirmUserMessage (vs. confirm) to
prevent window focus from shifting back to the parent window.
Syntax confirmUserMessage(message)
Parameters
Parameter Type Required? Description
message string Yes The message to be displayed in the
confirm dialog.
Returns Boolean — True if the user selects OK from the confirm dialog; False if the user
selects Cancel.

84
createFieldDefsRequest
Purpose This method creates and returns the Action Processor GetFieldDefs request,
which is used to get the field definitions for a procedure for which you are
starting a case or opening a work item.
This method is used if you don’t have knowledge of the fields on the form. The
GetFieldDefs request returns all fields defined for the procedure.
This method only returns the GetFieldDefs request; it does not submit it to the
Action Processor. To submit the request, you must call the socketRequest method
(see page 110).
Syntax createFieldDefsRequest(requestId)
Parameters Parameter Type Required? Description

requestId string No Identifies the request.
If not provided, the xmlCacheIdAp
is used (which can be obtained with
the this.getXmlCacheIdAp
function).
Returns A string — GetFieldDefs request XML.
Remarks This method is called by readFieldDefs. Normally, a developer of a custom form

will have knowledge of the fields that are available on the form. The sample file,
com.tibco.bpm.ipc.FormTemplate, can be applied to any procedure; it calls
readFieldDefs to read the fields that are available.
This method is not required for use with a form that has statically defined fields
on it.
Example XML The following provides example XML for this method.
Field Defs Request:
<?xml version="1.0" encoding="UTF-8"?>

<ap:Action xmlns:ap="http://tibco.com/bpm/actionprocessor"
xmlns:sso="http://tibco.com/bpm/sso/types">
<ap:ProcManager>
<ap:GetFieldDefs Id="_jsx_ipcNS_1394_XML_apfd">
<sso:ProcTag>i2tagtest|ALLOCATE|0|2</sso:ProcTag>
</ap:GetFieldDefs>
</ap:ProcManager>
</ap:Action>

createFieldDefsRequest 85
|
Field Defs Request Result:
<ap:ActionResult xmlns:ap="http://tibco.com/bpm/actionprocessor">
<ap:Status>
<ap:ReturnCode>0</ap:ReturnCode>
<ap:ReturnComment>The Action was processed successfully. Check the individual
Request Results for their status.</ap:ReturnComment>
<ap:ReturnDateTime>2006-02-06T10:43:42.432-0800</ap:ReturnDateTime>
</ap:Status>
<ap:SSO>
<sso:vSSOData xmlns:sso="http://tibco.com/bpm/sso/types">
<sso:Results>
<sso:vResult Id="_jsx_ipcNS_301_XML_apfd">
<sso:FieldDefs>
<sso:vFieldDef>
<sso:Name>LOCATION</sso:Name>
<sso:FieldType>swText</sso:FieldType>
<sso:Value></sso:Value>
<sso:Length>20</sso:Length>
<sso:DecimalPlaceCnt>0</sso:DecimalPlaceCnt>
<sso:IsArrayField>false</sso:IsArrayField>
</sso:vFieldDef>
<sso:vFieldDef>
<sso:Name>MEMO</sso:Name>
<sso:FieldType>swMemo</sso:FieldType>
</sso:vFieldDef>
<sso:vFieldDef>
<sso:Name>NAME</sso:Name>
</sso:vFieldDef>
<sso:vFieldDef>
<sso:Name>NUMERIC</sso:Name>
<sso:FieldType>swNumeric</sso:FieldType>
</sso:vFieldDef>
<sso:vFieldDef>
<sso:Name>REASON</sso:Name>

86
</sso:vFieldDef>

</sso:FieldDefs>
</sso:vResult>
</sso:Results>
</sso:vSSOData>
</ap:SSO>
</ap:ActionResult>
Field Defs Request Transform XSL:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:sso="http://tibco.com/bpm/sso/types"
xmlns:ap="http://tibco.com/bpm/actionprocessor" exclude-result-prefixes="sso ap">
<xsl:output omit-xml-declaration="yes"/>
<xsl:param name="uniqueId"/>
<xsl:output indent="yes"/>
<xsl:template match="/">
<data>
<xsl:apply-templates
select="/ap:ActionResult/ap:SSO/sso:vSSOData/sso:Results/sso:vResult[@Id =
$uniqueId]"/>
</data>
</xsl:template>
<xsl:template match="sso:vResult">
<xsl:apply-templates select="sso:FieldDefs/sso:vFieldDef"/>
</xsl:template>
<xsl:template match="sso:vFieldDef">
<xsl:variable name="fieldName" select="sso:Name"/>
<xsl:if test="not(starts-with($fieldName, 'SW_'))">
<xsl:element name="record">
<xsl:attribute name="jsxid">
<xsl:value-of select="generate-id()"/>
</xsl:attribute>
<xsl:attribute name="ssoName">
<xsl:value-of select="sso:Name"/>
</xsl:attribute>
<xsl:attribute name="ssoFieldType">
<xsl:value-of select="sso:FieldType"/>
</xsl:attribute>
<xsl:attribute name="ssoValue">
<xsl:value-of select="sso:Value"/>
</xsl:attribute>
</xsl:element>
</xsl:if>
</xsl:template>
</xsl:stylesheet>

createFieldDefsRequest 87
|
Field Defs Request CDF:
<data>
<record jsxid="IDARQ4YC" ssoName="LOCATION" ssoFieldType="swText" ssoValue=""/>
<record jsxid="IDAYQ4YC" ssoName="MEMO" ssoFieldType="swMemo" ssoValue=""/>
<record jsxid="IDA5Q4YC" ssoName="NAME" ssoFieldType="swText" ssoValue=""/>
<record jsxid="IDAGR4YC" ssoName="NUMERIC" ssoFieldType="swNumeric" ssoValue=""/>
<record jsxid="IDAMR4YC" ssoName="REASON" ssoFieldType="swText" ssoValue=""/>
<record jsxid="IDA1T4YC" ssoName="TEXT" ssoFieldType="swText" ssoValue=""/>
<record jsxid="IDACU4YC" ssoName="TITLE" ssoFieldType="swText" ssoValue=""/>
</data>

88
createKeepRequest
Purpose If a case is being started, this method creates and returns the Action Processor
StartCase request, with the isRelease flag set to False.
If an existing work item is being kept in the work queue, this method creates and
returns the Action Processor KeepItems request.
This method only returns the StartCase or KeepItems request; it does not submit
it to the Action Processor. To submit the request, you must call the socketRequest
method (see page 110).
Syntax createKeepRequest(fields,
requestId,
validate,
subProcPrecedence)

fields Object or Yes This can be either:
Array of
• An Array of Objects containing
Objects
field data properties: name,
fieldType, value.
• An Object, such as
com.tibco.bpm.ipc.FieldData
that implements
getFieldDataArray(), which
returns an Array (for
information about
com.tibco.bpm.ipc.FieldData,
see FieldData Class on
page 112).

If not provided, xmlCacheIdAp is
used (which can be obtained with
function).

createKeepRequest 89
|

validate boolean No If True, the field values are
validated against the type to which
they are defined (text, date, time,
etc.).
Default = False
subProcPrecedence string No Specifies the precedence of

sub-procedure statuses that are
launched from the procedure.
These are enumerated in
SWSubProcPrecedenceType.
Default = If not specified, the
option set in the application is used
(Options dialog > General tab >
Sub-Case Version Precedence).
Note: The subProcPrecedence
parameter is only applicable for
StartCase.
Returns A string — StartCase or KeepItems request XML
Remarks This method is called by the custom form class doKeep method. The Keep button
on the form triggers the call to the doKeep method. Data is collected from the
form and the XML request is obtained using this method. This request is then
submitted to the Action Processor using the socketRequest method.
Example The following is an example usage from com.tibco.bpm.ipc.FormTemplate:
ipcClass.prototype.doKeep = function() {
var keepRequest = this.createKeepRequest(this.getFormData());
var socket = this.socketRequest(keepRequest);
if (socket.isSuccess() && socket.getSsoErrorMsg() == null) {
this.jsxsuper();
}
};

90
Keep Request:

<ap:WorkQ>
<ap:KeepItems Id="_jsx_ipcNS_1394_XML_ap">
<sso:WorkQTag>i2tagtest|swadmin|R</sso:WorkQTag>
<sso:WIFieldData>
<sso:vWIFieldGroup>
<sso:WorkItemTag>i2tagtest|ALLOCATE|swadmin|R|2708|414137|
i2tagtest|STEP1|0|2</sso:WorkItemTag>
<sso:WorkItemFields>
<sso:vField>
<sso:Value>USA</sso:Value>
</sso:vField>
...
</sso:WorkItemFields>
</sso:vWIFieldGroup>
</sso:WIFieldData>
<sso:ValidateFields/>
</ap:KeepItems>
</ap:WorkQ>
</ap:Action>
Keep Request (Start Case):

<ap:User>
<ap:StartCase Id="_jsx_ipcNS_217_XML_ap">
<sso:Description>Demo</sso:Description>
<sso:ReleaseItem>false</sso:ReleaseItem>
<sso:ValidateFields>false</sso:ValidateFields>
<sso:Fields>
<sso:vField>
</sso:vField>
...
</sso:Fields>
</ap:StartCase>
</ap:User>
</ap:Action>

createLockRequest 91
|
createLockRequest
Purpose This method creates and returns the Action Processor LockItems request.
This method only returns the LockItems request; it does not submit it to the
Action Processor. To submit the request, you must call the socketRequest method
(see page 110).
Note that it is not required that you call this method — it is called by the custom
form class lockWorkItem method. It is available, however, if you want the Action
Processor LockItems request to lock a work item and get field data.
Syntax createLockRequest(fieldNames,
requestId)

fieldNames Array of Yes Fields to include in the lock items
strings request.

If not provided, the xmlCacheIdAp
is used (which can be obtained with
function).
Returns A string — LockItems request XML
Example The following is an example usage from com.tibco.bpm.ipc.Form:
ipcClass.prototype.lockWorkItem = function(
fieldNames, xslPath, apCacheId, cdfCacheId) {
var fieldData = null;
var useApCacheId = apCacheId != null ? apCacheId :
this.getXmlCacheIdAp();
var useXslPath = xslPath != null ? xslPath :
com.tibco.bpm.ipc.Form.DIR + 'xsl/lockItemsToCdf.xsl';
var useCdfCacheId = cdfCacheId != null ? cdfCacheId :
this.getXmlCacheId();
var lockRequest = this.createLockRequest(fieldNames, useApCacheId);
var socket = this.socketRequest(lockRequest, useApCacheId);
this.transformData(useXslPath, useApCacheId, useCdfCacheId);
var doc = this.getApp().getCache().getDocument(useCdfCacheId);
fieldData = new com.tibco.bpm.ipc.FieldData();
fieldData.loadFromCdfDoc(doc);
}
return fieldData;
};

92
Lock Items Request:

<ap:WorkQ>
<ap:LockItems Id="y76R20">
<sso:WorkItemTags>
<sso:string>i2tagtest|ALLOCATE|swadmin|R|2050|408966|i2tagtest|
SUMMARY|0|2</string>
</sso:WorkItemTags>
<sso:WIFGContent>
<sso:WIFieldNames>
<sso:string>LOCATION</sso:string>
<sso:string>MEMO</sso:string>
<sso:string>NAME</sso:string>
<sso:string>NUMERIC</sso:string>
<sso:string>REASON</sso:string>
<sso:string>TEXT</sso:string>
<sso:string>TITLE</sso:string>
</sso:WIFieldNames>
<sso:FieldsOption>ssoAllMarkings</sso:FieldsOption>
</sso:WIFGContent>
</ap:LockItems>
</ap:WorkQ>
</ap:Action>
Lock Items Request Result:
<ap:ActionResult xmlns:ap="http://tibco.com/bpm/actionprocessor">
<ap:Status>
<ap:ReturnCode>0</ap:ReturnCode>
<ap:ReturnComment>The Action was processed successfully. Check the individual
Request Results for their status.</ap:ReturnComment>
<ap:ReturnDateTime>2006-02-06T10:43:42.698-0800</ap:ReturnDateTime>
</ap:Status>
<ap:SSO>
<sso:vSSOData xmlns:sso="http://tibco.com/bpm/sso/types">
<sso:Results>
<sso:vResult Id="_jsx_ipcNS_301_XML_ap">
<sso:WIFieldGroups>
<sso:vWIFieldGroup>
i2tagtest|SUMMARY|0|2</sso:WorkItemTag>
<sso:vField>

createLockRequest 93
|
<sso:Name>TITLE</sso:Name>
<sso:Value>test title 3</sso:Value>
</sso:vField>
<sso:vField>
<sso:Name>TEXT</sso:Name>
<sso:Value>test</sso:Value>
</sso:vField>
<sso:vField>
<sso:Name>REASON</sso:Name>
<sso:Value>test</sso:Value>
</sso:vField>
<sso:vField>
<sso:Name>NUMERIC</sso:Name>
<sso:FieldType>swNumeric</sso:FieldType>
<sso:Value>123.0</sso:Value>
</sso:vField>
<sso:vField>
<sso:Name>NAME</sso:Name>
<sso:Value>test name 3</sso:Value>
</sso:vField>
<sso:vField>
<sso:Name>MEMO</sso:Name>
<sso:FieldType>swMemo</sso:FieldType>
<sso:Value>test memo 4</sso:Value>
</sso:vField>
<sso:vField>
<sso:Value>test 6</sso:Value>
</sso:vField>
</sso:WIFieldGroups>
</sso:vResult>
</sso:Results>
</sso:vSSOData>
</ap:SSO>
</ap:ActionResult>
Lock Items Request Transform XSL:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:sso="http://tibco.com/bpm/sso/types"
xmlns:ap="http://tibco.com/bpm/actionprocessor" exclude-result-prefixes=
"sso ap">
<xsl:output omit-xml-declaration="yes"/>
<xsl:param name="uniqueId" select="'_jsx_ipcNS_264_XML_ap'"/>
<xsl:output indent="yes"/>
<xsl:template match="/">

94
<data>
<xsl:apply-templates select="/ap:ActionResult/ap:SSO/sso:vSSOData/
sso:Results/sso:vResult[@Id = $uniqueId]"/>
</data>
</xsl:template>
<xsl:template match="sso:vResult">
<xsl:apply-templates select="sso:WIFieldGroups/sso:vWIFieldGroup/
sso:WorkItemFields/sso:vField"/>
</xsl:template>
<xsl:template match="sso:vField">
<xsl:element name="record">
<xsl:attribute name="jsxid">
<xsl:value-of select="generate-id()"/>
</xsl:attribute>
<xsl:attribute name="ssoName">
<xsl:value-of select="sso:Name"/>
</xsl:attribute>
<xsl:attribute name="ssoFieldType">
<xsl:value-of select="sso:FieldType"/>
</xsl:attribute>
<xsl:attribute name="ssoValue">
<xsl:value-of select="sso:Value"/>
</xsl:attribute>
</xsl:element>
</xsl:template>
</xsl:stylesheet>
Lock Items Request CDF:
<data>
<record jsxid="IDAF1CZC" ssoName="TITLE" ssoFieldType="swText" ssoValue="test
title 3"/>
<record jsxid="IDAJ1CZC" ssoName="TEXT" ssoFieldType="swText" ssoValue="test"/>
<record jsxid="IDAN1CZC" ssoName="REASON" ssoFieldType="swText"
ssoValue="test"/>
<record jsxid="IDAR1CZC" ssoName="NUMERIC" ssoFieldType="swNumeric"
ssoValue="123.0"/>
<record jsxid="IDAV1CZC" ssoName="NAME" ssoFieldType="swText"
ssoValue="test name 3"/>
<record jsxid="IDAZ1CZC" ssoName="MEMO" ssoFieldType="swMemo"
ssoValue="test memo 4"/>
<record jsxid="IDA31CZC" ssoName="LOCATION" ssoFieldType="swText"
ssoValue="test 6"/>
</data>

createReleaseRequest 95
|
createReleaseRequest
Purpose If a case is being started, this method creates and returns the Action Processor
StartCase request, with the isRelease flag set to True.
If an existing work item is being released from the work queue, this method creates
and returns the Action Processor ReleaseItems request.
This method only returns the StartCase or ReleaseItems request; it does not
submit it to the Action Processor. To submit the request, you must call the
socketRequest method (see page 110).
Syntax createReleaseRequest(fields,
requestId,
validate,
subProcPrecedence)

fields Array of Yes • An Array of Objects containing
objects field data properties: name,
fieldType, value.
• An Object, such as
com.tibco.bpm.ipc.FieldData
that implements
getFieldDataArray(), which
returns an Array (for
information about
com.tibco.bpm.ipc.FieldData,
see FieldData Class on
page 112).

If not provided, xmlCacheIdAp is
used (which can be obtained with
function).
validate boolean No If True, the field values are

validated against the type to which
they are defined (text, date, time,
etc.).
Default = False

96

subProcPrecedence string No Specifies the precedence of
sub-procedure versions that are
launched from the procedure.
These are enumerated in
SWSubProcPrecedenceType.
Default = If not specified, the
option set in the application is used
(Options dialog > General tab >
Sub-Case Version Precedence).
Note: The subProcPrecedence
parameter is only applicable for
StartCase.
Returns A string — StartCase or ReleaseItems request XML.
Remarks This method is called by the custom form class doRelease method. The Release
button on the form triggers the call to the doRelease method. Data is collected
from the form and the XML request is obtained using this method. This request is
then submitted to the Action Processor using the socketRequest method.
ipcClass.prototype.doRelease = function() {
var releaseRequest = this.createReleaseRequest(this.getFormData());
var socket = this.socketRequest(releaseRequest);
this.jsxsuper();
}
};

createReleaseRequest 97
|
Release Request:

<ap:WorkQ>
<ap:ReleaseItems Id="_jsx_ipcNS_1394_XML_ap">
<sso:WIFieldData>
<sso:vWIFieldGroup>
i2tagtest|STEP1|0|2</sso:WorkItemTag>
<sso:vField>
</sso:vField>
...
</sso:WIFieldData>
<sso:ValidateFields/>
</ap:ReleaseItems>
</ap:WorkQ>
</ap:Action>
Release Request (Start Case):

<ap:User>
<ap:StartCase Id="_jsx_ipcNS_217_XML_ap">
<sso:Description>Demo</sso:Description>
<sso:ReleaseItem>true</sso:ReleaseItem>
<sso:ValidateFields>false</sso:ValidateFields>
<sso:Fields>
<sso:vField>
</sso:vField>
...
</sso:Fields>
</ap:StartCase>
</ap:User>
</ap:Action>

98
doCancel
Purpose This method closes the form dialog and unlocks the work item. No field data is
saved. This method also updates the work item list.
Unlock work item and list update are not applicable for case start.
Syntax doCancel()
Parameters None
Returns Void

doClose 99
|
doClose
Purpose This method closes the form dialog and unlocks the work item. No field data is
saved. This method also updates the work item list.
Unlock work item and list update are not applicable for case start.
Syntax doClose()
Parameters None
Returns Void
Remarks This method is called by the close event on the jsx3.Dialog.

This method calls the doCancel method.

100
doKeep
Purpose This method closes the form dialog and updates the work item list. (List update is
not applicable for case start.)
A custom form class that extends the base class must override this method. The
overridden method provides the keep functionality and calls this super class
method (using this.jsxsuper();) upon successful completion, as follows:
• The Keep button on the form triggers the call to the doKeep method.
• Data is collected from the form.
• The XML request is obtained using createKeepRequest. This request is then
submitted to the Action Processor using socketRequest.
• The socket results are checked for success, and if successful, calls this super
class method (using this.jsxsuper();).
Note that the com.tibco.bpm.ipc.Socket class presents the user with a message
dialog if any errors are encountered. The Socket class can be checked for any error
conditions using the methods shown in the example below.
Syntax doKeep()
Parameters None
Returns Void
this.jsxsuper();
}
};

doRelease 101
|
doRelease
Purpose This method closes the form dialog and updates the work item list. (List update is
not applicable for case start.)
A custom form class that extends the base class must override this method. The
overridden method provides the release functionality and calls this super class
method (using this.jsxsuper();) upon successful completion, as follows:
• The Release button on the form triggers the call to the doRelease method.
• Data is collected from the form.
• The XML request is obtained using createReleaseRequest. This request is
then submitted to the Action Processor using socketRequest.
• The socket results are checked for success, and if successful, calls this super
class method (using this.jsxsuper();).
Note that the com.tibco.bpm.ipc.Socket class presents the user with a message
dialog if any errors are encountered. The Socket class can be checked for any error
conditions using the methods shown in the example below.
Syntax doRelease()
Parameters None
Returns Void
ipcClass.prototype.doRelease = function() {
var releaseRequest = this.createReleaseRequest(this.getFormData());
var socket = this.socketRequest(releaseRequest);
this.jsxsuper();
}
};

102
init
Purpose This method is called when a new instance of the class is created. A custom form
class that extends this base class can override this method if required, but must
call the super class init method (using this.jsxsuper();). The init method might be
overridden to set the dialog caption bar (if something other than the default value
is desired) or to explicitly set the prototypePath.
Syntax init(node,
strName,
intWidth,
intHeight,
strCaption)

node jsx3.Entity Yes The XML node record for the
selected list item.
strName string No The jsx name assigned to the object.

Default = “ipc.Form’
intWidth int No The form dialog width.

Default = 800
intHeight int No The form dialog height.

Default = 500
strCaption string No The form dialog caption.

Default = see Remarks below.
Returns Void
Remarks The default dialog caption is as follows:

For a case start:
'Start Case: ' + description + ' - ' + procName + ' - ' + stepName
For a lock work item:

'Work Item: ' + caseNumber + ' - ' + description + ' - ' + procName + ' - ' +
stepName

lockWorkItem 103
|
lockWorkItem
Purpose This method creates an Action Processor LockItems request XML, submits the
request, then applies the specified XSL transform to the result returned.
The lockWorkItem method combines several common actions into a convenient
single method call. This can be used by a custom form class when initializing the
form data, typically called from the custom class postLoadInit method override.
For a code example, see postLoadInit (on page 106).
This method returns an instance of com.tibco.bpm.ipc.FieldData. Each record
element in the transformed CDF is added as a data field in
com.tibco.bpm.ipc.FieldData. The field data is read from the corresponding
attributes in each record: ssoName, ssoFieldType, and ssoValue.
The com.tibco.bpm.ipc.FieldData class provides convenient access to field data,
which can be updated and then passed into the fields parameter of the
createKeepRequest or the createReleaseRequest function.
If an error is encountered processing the request, a null is returned.
Note that if a custom transform is applied, the returned
com.tibco.bpm.ipc.FieldData will contain valid data only if the resulting CDF
conforms to the expected default format shown below:
<data>
<record ssoName="FieldName"
ssoFieldType="swFieldType"
ssoValue="FieldValue"/>
...
</data>
If an expected record attribute is not found, its matching property in the data
object is set to null.
If record elements are not found, no data objects are created.
Syntax lockWorkItem(fieldNames,
xslPath,
apCacheId,
cdfCacheId)

104

fieldNames array of Yes Specifies the fields to return from
strings the server when locking work items.
or single This can be specified as follows:
string
Array of strings: The names of the
fields to return.
Single string: Specifies the fields to
return from the server using one of
the following strings:
• “ssoFormMarkings” - Returns
only visible fields/markings
(based on conditional
statements on the form).
• “ssoAllMarkings” - Returns all
fields/markings, even if not
visible on the form (based on
conditional statements on the
form).
Also see, Requesting Values For
Items in an Array Field on page 114.
xslPath string No A file path or CacheId for the XSL to

transform the fieldDefs result into
CDF.
Default = Use the XSL provided in:
.../JSXAPPS/ipc/components/
Forms/xsl/lockItemsToCdf.xsl
apCacheId string No CacheId for the ActionProcessor

result XML.
Default = Use value returned from:
this.getXmlCacheIdAp().
cdfCacheId string No CacheId for the transform CDF.

this.getXmlCacheId()
Returns Instance of com.tibco.bpm.ipc.FieldData.

Note: If an error is encountered processing the request, a null is returned.

onBeforeUnload 105
|
onBeforeUnload
Purpose This method can be extended by a sub-class to handle any actions to be taken
before the browser window is closed directly using the window close icon. This
only applies if the form is opened in a new external browser window.
Note that this method is not called if the window is closed as a result of a call to
doCancel().
Syntax onBeforeUnload()
Parameters None
Returns Void

106
postLoadInit
Purpose A custom form class that extends the base class must override this method. The
postLoadInit method is called after the form prototype is loaded. The overridden
method first calls this super class method (using this.jsxsuper();), then
implements data loading and GUI initialization code.
Note that this method does not update (refresh) the work item list by sending a
message to the server, although statuses in the list are updated (not applicable for
case start).
Syntax postLoadInit()
Parameters None
Returns Void
ipcClass.prototype.postLoadInit = function() {
this.jsxsuper();
this.readFieldNames();
if (! this.startCase) {
this.fieldData = this.lockWorkItem(this.fieldNames);
if (this.fieldData == null) {
this.showUserMessage(
'Error encountered locking the work item.');
}
}
this.initializeFormData();
};

readFieldDefs 107
|
readFieldDefs
Purpose This method creates an Action Processor GetFieldDefs request XML, submits the
request, then applies the specified XSL transform to the result returned.
The readFieldDefs method combines several common actions into a convenient
single method call. This is called by
com.tibco.bpm.ipc.FormTemplate.readFieldNames. This might be most useful in
development if the values of fields on a procedure are not known or if there is a
need to obtain these dynamically instead of having statically defined fields on a
form.
This method returns an instance of com.tibco.bpm.ipc.FieldData. Each record
element in the transformed CDF is added as a data field in
com.tibco.bpm.ipc.FieldData. The field data is read from the corresponding
attributes in each record: ssoName, ssoFieldType, and ssoValue.
which can be updated and then passed into the fields parameter of the
createKeepRequest or the createReleaseRequest function.
If an error is encountered processing the request, a null is returned.
Note that if a custom transform is applied, the returned
com.tibco.bpm.ipc.FieldData will contain valid data only if the resulting CDF
conforms to the expected default format shown below:
<data>
ssoValue="FieldValue"/>
...
</data>
If an expected record attribute is not found, its matching property in the data
object is set to null.
If record elements are not found, no data objects are created.
Syntax readFieldDefs(xslPath,
apCacheId,
cdfCacheId)

108

xslPath string No A file path or CacheId for the XSL to
transform the fieldDefs result into
CDF.
Default = Use the XSL provided in:
.../JSXAPPS/ipc/components/
Forms/xsl/fieldDefsToCdf.xsl
apCacheId string No CacheId for the ActionProcessor

result XML.
this.getXmlCacheIdAp() + 'fd'
cdfCacheId string No CacheId for the transform CDF.

this.getXmlCacheId() + 'fd'
Returns Instance of com.tibco.bpm.ipc.FieldData

Note: If an error is encountered processing the request, a null is returned.

showUserMessage 109
|
showUserMessage
Purpose Displays an alert dialog with the given message. If this is a child browser window,
the alert is sent to the child window context to prevent focus being moved to the
parent browser window.
Note - Custom GI forms should call this.showUserMessage (vs. alert) to prevent
window focus from shifting back to the parent window.
Syntax showUserMessage(message)
Parameters
message string Yes The message to be displayed in the
alert.
Returns Void
Example The following is an example usage:
this.showUserMessage(
'Invalid format:' +
'\n\n Field name: ' + fieldName +
'\n\n Current value: ' + fieldValue +
'\n\n Expected format: ' + pattern + '.');

110
socketRequest
Purpose This method creates an Action Processor socket for the given request and submits
the request to the Action Processor. This must be called to submit the request after
calling any of the “create...Request” methods (createKeepRequest,
createLockRequest, etc.).
The instance of the Socket class returned can be checked for any error conditions
using the following functions:
• socket.isSuccess - A false value indicates an error occurred communicating
with the Action Processor.
• socket.getSsoErrorMsg - If not null, this will contain a string message
indicating what iProcess Server Object error was returned in the Action
Processor result.
Syntax socketRequest(requestXml,
cacheId)

requestXml string Yes The Action Processor request XML.
CacheId string No The CacheId where the Action

Processor result is stored.
Returns Instance of socket (com.tibco.bpm.ipc.Socket)
Example The following is an example usage:
this.jsxsuper();
}
};
Note - The com.tibco.bpm.ipc.Socket class presents the user with a message

dialog if any errors are encountered.

transformData 111
|
transformData
Purpose This method applies the given XSL transform to the source CacheId XML and
stores the result in the target CacheId XML.
Syntax transformData(xslPath,
sourceCacheId,
targetCacheId)

xslPath string Yes File path or CacheId for the
transform XSL document.
sourceCacheId string No CacheId for the source XML.

targetCacheId string No CacheId for the target XML.

this.getXmlCacheId().
Returns A string — the result of the transform.

112
FieldData Class

which can be updated and then passed in the fields parameter of the
createKeepRequest (see page 88) or the createReleaseRequest (see page 95)
function.
An instance of com.tibco.bpm.ipc.FieldData is returned by the lockWorkItem
(see page 103) and readFieldDefs (see page 107) functions.
The constructor for com.tibco.bpm.ipc.FieldData does not require any
parameters, for example:
var fieldDat = new com.tibco.bpm.ipc.FieldData();
For examples of usage, see FormTemplate.js.

Also note:
• The value of a field can be set to uninitialized by setting the FieldData value
for the field to null.
• For all fields that are not fieldType == 'swText', a zero-length string value will
result in the field being set to an uninitialized state.
• Fields of fieldType == 'swDate' or 'swTime' must be formatted in standard
XML format. See Date Conversions.
FieldData Class Functions

The com.tibco.bpm.ipc.FieldData class contains the following public functions:
• loadFromCdfDoc(cdfDoc)
This function loads fieldDataObject from the CDF document passed in.
where:
— cdfDoc is the CDF document (jsx3.xml.Document) from which to load the
field data.
The CDF is expected to be in the following form:
<data>
ssoValue="FieldValue" ... />
...
</data>

FieldData Class 113
|
The fieldDataObject serves as a map, where each association is:

— property = field name
— value = a field data Object, with properties name, fieldType, and value.
• getFieldValue(name)
This function returns the data value (string) for the specified field name. A
null is returned if name is not found.
where:
— name is the field name (string) whose value you are retrieving.
• getFieldType(name)
This function returns the field type (string) for the specified field name. A null
is returned if name is not found.
where:
— name is the field name (string) whose type you are retrieving.
• setFieldValue(name, value)
This function sets the value of the specified field.
where:
— name is the field name (string) whose value you are setting.
— value is the value (string) to set.
• setFieldType(name, fieldType)
This function sets the field type of the specified field.
where:
— name is the field name (string) whose field type you are setting.
— fieldType is the field type (string) to set.
• addField(name, fieldType, value)
This function adds a new field data Object with name, fieldType, and value
specified. If an Object with the same name already exists, it will be replaced
with the new Object.
where:
— name is the field name (string) to add.
— fieldType is the type (string) of the field to add.
— value is the value (string) to assign to the new field.

114
• removeField(name)
This function removes the field data Object specified by setting it to null.
where:
— name is the field name (string) to remove.
• getFieldDataObject()
This function returns the fieldDataObject, which serves as a map, where each
association is:
— property = field name
— value = a field data Object, with properties name, fieldType, and value.
• getFieldDataArray()
This function returns an array of Objects whose properties contain field data.
These properties are: name, fieldType, and value.
• enableLogging(app, forceLog)
This function enables logging.
where:
— app is the application instance (com.tibco.bpm.ipc.Application) to log to.
— forceLog (boolean) allows you to force logging. If true, the log is written
even if appLogActive = false. This is optional. Default = false.
• log(message)
This function logs the specified message if logging is enabled — see the
enableLogging function.
where:
— message is the message to write to the log.
Requesting Values For Items in an Array Field

You can request the values for items in an array field by including an indexed
string in the lock work item request array. An array field indexed string has the
following syntax:
arrayFieldName + "[" + index + "]"
For example, given an array field named 'IDX_ITEM', the lockWorkItem method
of the GI form class is called:
this.lockWorkItem(this.fieldNames);

FieldData Class 115
|
with the this.fieldNames array set to include:

'IDX_ITEM[0]' , 'IDX_ITEM[1]', 'IDX_ITEM[2]' … etc
Array field values can also be set by including these in the FieldData set when
calling the doKeep or doRelease methods.

116
Date Conversions

com.tibco.bpm.ipc.FormDateHandler class that allow you to convert date
information between the following three formats:
• XML - a string used in standard serialized XML (as described at
http://www.w3.org/TR/xmlschema-2/#dateTime)
• JSDate - a JavaScript Date object
• Local - a localized string as defined by a specified pattern
The formatting patterns use commands similar to those used for formatting in
Java. The following are the date formatting tokens that are supported:
— MM - month, numeric, with leading zero
— M - month, numeric, without leading zero
— MMM - abbreviated month name
— MMMM - full month name
— dd - day number, with leading zero
— d - day number, without leading zero
— yy - year, without century, with leading zero
— yyyy - full year
— a - am/pm designation
— hh (or HH, kk, KK) - hour with leading zero
— h (or H, k, K) - hour without leading zero
— mm - minutes, always with leading zero
— ss - seconds, always with leading zero
Other rules for the formatting pattern:
• Patterns can contain tokens for date information, time information, or both.
• If the am/pm designator is included in the pattern, the hour will be
interpreted as 1-12, otherwise it will be 0-23. Any of the Java-style formatting
tokens for an hour can be specified, but they are all interpreted in this one
manner.
• No other Java-style formatting tokens are supported (e.g., G, w, W, D, E, F, S, z,
Z).

Date Conversions 117
|
• The only alphanumeric characters that can appear in the pattern are those
shown in the list above.
• Quoted, literal text is not supported in the pattern.
• One or more non-alphanumeric characters MUST appear between tokens as
delimiters (spaces, colons, slashes, dashes, etc). There is one exception to this
rule; the am/pm designator can immediately follow another token without a
delimiter between.
The routines are very flexible when interpreting dates and times entered by a
user, so information will not have to be entered exactly like the pattern, character
by character.
• Any number of delimiting characters can be entered between parts of the
date/time. These delimiting characters do not have to match the characters in
the formatting pattern (keeping in mind that alpha characters cannot be used
as delimiters). For instance, all of these values will be interpreted the same:
'12/31/2005', '12-31-2005', '12 31 * 2005', '(12) (31?%$#@2005)'.
• Numeric values can be entered either with or without leading zeros.
• No matter what token is used in the pattern for the month, it can be entered as
either a number or as the abbreviated or full month name.
• When the name or abbreviation for a month is entered, there does not have to
be delimiters around it, and it can be placed out of the expected order.
However, all the remaining elements must appear in the expected order. For
instance, if the pattern is 'dd-MM-yyyy', then 'Sep-10-2005', 'September 10,
2005', '10Sep2005', and even '10 2005Sep' will all be interpreted as the 10th of
September, 2005.
• Time can be entered in either 24-hour or 12-hour format. If seconds or minutes
are left off, they will be set to zero. The AM/PM designator does not have to
appear in the exact position specified in the pattern. For instance, using any of
these formatting patterns: 'h:mm:ssa', 'h:mm:ss', 'h.mm.ss a', cause all of the
following values to be interpreted as 2PM: '2:00pm', '2pm', '2:00:00pm', '14',
'14:00', '14:00:00', and even 'pm2'.
• The sets of characters 'st', 'nd', 'rd', and 'th' when used with day numbers, such
as '1st', '2nd', '3rd', '4th', etc., will be ignored. The fact that these follow a
number will not automatically cause the number to be used as the day,
however. The number must still fall in the proper relative order according to
the pattern. Aside from these pairs of characters, the am/pm designator, and
the full and abbreviated month names, no other alpha characters (a-z and
A-Z) are allowed in the input string, and will cause a conversion to fail. Month
names will, of course, have to be spelled properly, and only the one expected
abbreviation will be valid.
• When 0 through 99 is entered for a year, it will be interpreted as 2000 - 2099.

118
• The user must enter the elements of the date/time in the order specified in the
formatting pattern, but if some elements are left off the end, a suitable value
will be used. For instance, when using the pattern MM-dd-yyyy, if only the
month and day are entered, the current year is used. If only the month is
entered, the first day of the month for the current year is used.
• Relative dates or times can be specified by entering a plus or minus sign
followed by a number:
— If the pattern includes date information, this is interpreted in days. So '+1'
is tomorrow, '-1' is yesterday, '+7' is a week from today, etc. Time is set to
00:00:00.
— For time-only fields, this is interpreted as minutes. So '-30' is thirty minutes
ago, '+90' is an hour and a half from now, etc. Seconds are set to 00.
• All XML dateTime strings will have the fractional seconds values shown with
a decimal followed by six zeros:
2006-06-30T17:14:39.0000000
Note that the JavaScript Date object milliseconds value is truncated.
• No XML dateTime strings will include a timezone value.
• The following range of dates is allowed:
— Any valid JavaScript Date with a year of 100 or greater:
0100-01-01T00:00:00.0000000 to 275760-09-13T01:00:00.0000000
— For a JavaScript date, this range is: 59011430400000 milliseconds (-683002
days) to 8640000000000000 milliseconds (100000000 days) elapsed since
1/1/1970 GMT.
The following are examples of valid patterns:
— MM/dd/yyyy
— dd-MMM-yyyy
— MMMM dd, yyyy
— yyyy-mm-dd
— h:mma

|
The following are examples of invalid patterns (although they are valid in Java
patterns):
— yyyyMMddhhmmss (no delimiters)
— yyyy-mm-dd'T'hh:mm:ss.000z (quoted text and unsupported commands)
— E MMMM dd, yyyy G (unsupported commands)
— 'week:' w 'day:' F 'of' yyyy (quoted text and unsupported commands)
— h 'o''clock' a (quoted text)
Code Example
// Convert from JavaScript date to XML string format
var formDateHandler = new com.tibco.bpm.ipc.FormDateHandler();

var date = new Date(1182738273189);
var xmlDateString = formDateHandler.jsDateToXml(date);
alert('xmlDateString = ' + xmlDateString);
// Result: xmlDateString = 2007-06-24T19:24:33.0000000
// Convert from XML string format to display format
var pattern = 'MM/dd/yyyy h:mma'

var displayString = formDateHandler.xmlToLocal(xmlDateString,
pattern);
alert('displayString = ' + displayString);
// Result: displayString = 06/24/2007 7:24pm
// Convert local string format to XML string format
var localString = '2006-12-31 23:59:59';

var pattern = 'yyyy-MM-dd hh:mm:ss';
var happyNewYear = formDateHandler.localToXml(localString,
pattern);
alert('happyNewYear = ' + happyNewYear);
// Result: happyNewYear = 2006-12-31T23:59:59.0000000

120
Date Conversion Methods

The following is a list of the date conversion methods described in this section:
• jsDateToLocal, page 120
• jsDateToXml, page 120
• localToJSDate, page 121
• localToXml, page 121
• xmlToJSDate, page 122
• xmlToLocal, page 122
jsDateToLocal
Purpose This method converts a JavaScript Date object into a string containing a formatted
local date value.
Syntax jsDateToLocal(jsDate, pattern)
Parameters
jsDate Date Yes JavaScript Date object to be
object converted.
pattern string Yes A valid format pattern — specifies

the format of the date string
returned by this method.
Returns A string containing a formatted date. Returns null if parameters are omitted or
the format pattern is invalid.
Remarks If the date portion of the format pattern is omitted, the resulting date is
12/30/1899. If the time portion of the format pattern is omitted, the resulting time
is 00:00.
jsDateToXml
Purpose This method converts a JavaScript Date object into a standard serialized XML date
string.
Syntax jsDateToXml(jsDate)

|
Parameters
jsDate Date Yes JavaScript Date object to be
object converted.
Returns A string containing a date in standard serialized XML format:

yyyy-MM-ddThh:mm:ss.0000000
Returns null if the jsDate parameter is omitted.
localToJSDate
Purpose This method converts a string containing a formatted local date value into a
JavaScript Date object.
Syntax localToJSDate(strDate, pattern)
Parameters
strDate string Yes Formatted date string.
pattern string Yes Valid format pattern — the format

of strDate parameter.
Returns A JavaScript Date object. Returns null if parameters are omitted or the format
pattern is invalid.
is 00:00.
localToXml
Purpose This method converts a string containing a formatted local date value into a
standard serialized XML date string.
Syntax localToXml(strDate, pattern)
Parameters
strDate string Yes Formatted date string.

122

pattern string Yes Valid format pattern — the format
of strDate parameter.
Returns A string containing a date in standard serialized XML format:

Returns null if parameters are omitted or the format pattern is invalid.
is 00:00.
xmlToJSDate
Purpose This method converts a standard serialized XML date string into a JavaScript Date
object.
Syntax xmlToJSDate(xmlDate)
Parameters
xmlDate string Yes Standard serialized XML date string
in the format:
Returns A JavaScript Date object. Returns null if the xmlDate parameter is omitted or the
format pattern is invalid.
xmlToLocal
Purpose This method converts a standard serialized XML date string into a string
containing a formatted local date value.
Syntax xmlToLocal(xmlDate, pattern)

|
Parameters
xmlDate string Yes Standard serialized XML date string
in the format:
pattern string Yes Valid format pattern - specifies the

format of the date string returned
by this method.
Returns A string containing a formatted date. Returns null if parameters are omitted or
the format pattern is invalid.
is 00:00.
Date Format Localization Methods

com.tibco.bpm.ipc.FormDateHandler class that allow you to customize text
strings representing months and the am/pm designation. These are used when
matching a format pattern converting to or from a local date string format.
• getAbbrMonthNames, page 123
• setAbbrMonthNames, page 124
• getAmPm, page 124
• setAmPm, page 125
• getFullMonthNames, page 125
• setFullMonthNames, page 125
getAbbrMonthNames
Purpose This method returns the abbreviations of the months that are returned when the
abbreviated month name format (MMM) is specified in a pattern parameter to a
date conversion method.
Syntax getAbbrMonthNames()
Parameters None

124
Returns JavaScript array of strings representing the abbreviations for months of the year,
in order from the first month to the twelfth month.
Remarks The default abbreviated month names returned by the date conversion methods
are: 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'.
setAbbrMonthNames
Purpose This method allows you to specify the abbreviations that are returned when the
abbreviated month name format (MMM) is specified in a pattern parameter to a
date conversion method.
Syntax setAbbrMonthNames(monthNames)
Parameters
monthNames JavaScript Yes Array of strings representing the
array abbreviations for the months of
the year, in order from the first
month to the twelfth month.
Returns None
Remarks The default abbreviated month names returned by the date conversion methods
are: 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'.
getAmPm
Purpose This method returns the am/pm designation that is returned when the am/pm
designator (‘a’) is specified in a pattern parameter to a date conversion method.
Syntax getAmPm()
Parameters None
Returns JavaScript array of two strings, the first representing the am, and the second
representing the pm designation.
Remarks The default designations returned by the date conversion methods are: 'am', 'pm'.

|
setAmPm
Purpose This method allows you to specify the am/pm designation that is returned when
the am/pm designator (‘a’) is specified in a pattern parameter to a date
conversion method.
Syntax setAmPm(designators)
Parameters
designators JavaScript Yes Array of strings representing the
array am/pm designators, the first
element represents am, and the
second represents pm.
Returns None
Remarks The default designations returned by the date conversion methods are: 'am', 'pm'.
getFullMonthNames
Purpose This method returns the names of the months that are returned when the full
month name format (MMMM) is specified in a pattern parameter to a date
conversion method.
Syntax getFullMonthNames()
Parameters None
Returns JavaScript array of strings representing the months of the year, in order from the
first month to the twelfth month.
Remarks The default full month names returned by the date conversion methods are:
'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September',
'October', 'November', 'December'.
setFullMonthNames
Purpose This method allows you to specify the names of the months that are returned
when the full month name format (MMMM) is specified in a pattern parameter to
a date conversion method.
Syntax setFullMonthNames(monthNames)

126
Parameters
monthNames JavaScript Yes Array of strings representing the
array months of the year, in order from
the first month to the twelfth
month.
Returns None.
Remarks The default full month names returned by the date conversion methods are:
'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September',
'October', 'November', 'December'.

Accessing User Options When Using GI Forms 127
|
Accessing User Options When Using GI Forms
User options establish default settings for each user who logs into the iProcess
Workspace (Browser). These include things such as the language to display, form
position on the screen, etc. (More information about the options available and
how they can be set from the application can be found in the iProcess Workspace
(Browser) User’s Guide.)
The custom GI form class that extends the com.tibco.bpm.ipc.Form base class can
access the user options for the currently logged in user using:
this.getAppPrefValue(prefName)
where prefName identifies the user option for which you would like the value.
This method returns a string, identifying the current setting of the given user
option. The following table lists the valid prefName values and the possible return
values for each option (note that options were formerly called preferences, hence the
prefName parameter):
prefName Return Values Description

language “language name” Identifies the language in which the iProcess
Workspace (Browser) is displayed. The default is
“English(US)”.
formLeft “integer value” The work item form window is positioned this
number of pixels from the left. (Only applicable if
both formFullscreen and formCenter are false.)
formTop “integer value” The work item form window is positioned this
number of pixels from the top. (Only applicable if
both formFullscreen and formCenter are false.)
formWidth “integer value” The width (in pixels) of the work item form window.
(Only applicable if formFullscreen is false.)
formHeight “integer value” The height (in pixels) of the work item form window.
(Only applicable if formFullscreen is false.)

128
prefName Return Values Description

formFullscreen “true” The work item form window is displayed full screen.
“false” The work item form window is not displayed full

screen. (Other options are used to determine
position/size.)
formCenter “true” The work item form window is displayed centered.

(the formWidth and formHeight options are used to
determine size.)
“false” The work item form window is not displayed

centered. (Other options are used to determine
position/size.)
subProcPrecedence “swPrecedenceR” The precedence in which sub-procedures are started

from the main procedure:
“swPrecedenceUR”
— swPrecedenceR: Only released
“swPrecedenceMR” sub-procedures are started.
— swPrecedenceUR: Unreleased, then released.
“swPrecedenceUMR”
— swPrecedenceMR: Model, then released.
“swPrecedenceMUR”
— swPrecedenceUMR: Unreleased, model, then
released.
— swPrecedenceMUR: Model, unreleased, then
released.

| 129
Chapter 4 Application Server Settings
This chapter describes some configuration settings in Web Application Servers

(WAS) that can be useful when configuring your TIBCO iProcess Workspace
(Browser) system.
For a comprehensive discussion of WAS configuration settings, see the
documentation for your WAS.
Topics
• Session Timeout, page 130

• Maximum POST Size, page 133
• Character Encoding, page 134

130
| Chapter 4 Application Server Settings
Session Timeout
The session timeout specifies the number of minutes in which the communication
session between the WAS and the client will timeout if there is no user activity,
which results in the Action Processor timing out. If the session times out, a
message similar to the following is displayed:
The following subsections describe how to change the session timeout in Tomcat
and IIS. If you are using a different application server, see the documentation for
that server.
Tomcat Session Timeout

By default, the session timeout on Tomcat is 30 minutes. To specify a different
session timeout:
1. Add the <session-timeout> element to the following configuration file:
TomcatDir\webapps\APDir\WEB-INF\web.xml
where TomcatDir is the directory in which Tomcat is installed, and APDir is the
directory in which the Action Processor is installed (which defaults to
TIBCOActProc).
The <session-timeout> element must be added to the <session-config>
element, for example:
<session-config>
<session-timeout>90</session-timeout>
</session-config>
2. Set the value of the <session-timeout> element to the number of minutes for
the timeout. A value of -1 causes the session to never timeout.
You must restart the Action Processor for the change to take effect.

Session Timeout 131
|
WebLogic Session Timeout

By default, the session timeout on WebLogic is 60 minutes. To specify a different
session timeout:
1. Add the <session-timeout> element in the following configuration file:
WebLogicDir\webapps\APDir\WEB-INF\web.xml
where WebLogicDir is the directory in which WebLogic is installed, and APDir is
the directory in which the Action Processor is installed (which defaults to
TIBCOActProc).
The <session-timeout> element must be added to the <session-config>
element, for example:
<session-config>
<session-timeout>90</session-timeout>
</session-config>
2. Set the value of the <session-timeout> element to the number of minutes for
the timeout. A value of -1 causes the session to never timeout.

132
IIS Session Timeout

By default, the session timeout on IIS is 20 minutes. To specify a different session
timeout:
1. Locate the <sessionState> element in the following configuration file:
\Inetpub\wwwroot\APDir\Web.config
where APDir is the directory in which the Action Processor is installed (which
defaults to TIBCOActProc).
For example:
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnetionString="data
source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="20"
/>
2. Set the value of the timeout attribute for the desired number of minutes for
the session timeout.

Maximum POST Size 133
|
Maximum POST Size
This section is applicable only to users of Tomcat.

By default, Tomcat sets a limit on the maximum size for HTTP POST requests it
will accept. In Tomcat version 5, this limit is set to 2097152 (2 MB). If you attempt
to upload files or post forms larger than 2 MB, a “java.lang.IllegalStateException:
Post too large” error is thrown.
To resolve this problem, configure Tomcat to either increase the POST request
size limit, or disable the size limit. To do this:
1. Locate the <Connector> element in the following configuration file:
TomcatDir\conf\server.xml
where TomcatDir is the directory in which Tomcat is installed.
2. Add a maxPostSize attribute and set it to the number of bytes to allow for an
HTTP POST request.
Setting maxPostSize to 0 (zero) disables the size limit.
You must restart Tomcat for the change to take effect.

134
Character Encoding

If you are going to be using any double-byte character encoding, such as the
Japanese character sets, you need to set the URIEncoding attribute in Tomcat’s
server.xml file to “UTF-8”, otherwise data such as the case description will not
be properly encoded. The URIEncoding attribute must be located in the
<Connector> element.
Note that the URIEncoding parameter is not in the server.xml file by default;
you must add it if you are going to be using any double-byte character sets.
To do this:
1. Locate the <Connector> element in the following configuration file:
TomcatDir\conf\server.xml
where TomcatDir is the directory in which Tomcat is installed.
2. Add a URIEncoding attribute and set it to “UTF-8”. See the following
example:
<Connector URIEncoding="UTF-8" port="8080"

maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25"
maxSpareThreads="75" enableLookups="false" redirectPort="8443"
acceptCount="100" connectionTimeout="20000"
disableUploadTimeout="true" maxPostSize="0" />
You must restart Tomcat for the change to take effect.
For more information about configuring your system for character encoding, see
the TIBCO iProcess Server Objects (Java) Programmer’s Guide.

Java Heap Size 135
|
Java Heap Size

If you are running a Java Action Processor in Tomcat, and receive a “Java heap
space” error message when attempting to display a list that contains a large
number of items (10000+), you will need to do one of the following, depending on
your version of Tomcat:
Tomcat Pre-Version 5.5

Modify the EXECJAVA statement in the catalina.bat file (Windows) or catalina.sh
file (UNIX) to include the -Xms and -Xmx parameters. For example:
%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Xms1024m

-Xmx1024m -Djava.library.path="C:\Java\Tomcat55\shared\lib"
-Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath
"%CLASSPATH%" -Dcatalina.base="%CATALINA_BASE%"
-Dcatalina.home="%CATALINA_HOME%"
-Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS%
%ACTION%
This sets the total memory and the maximum memory to 1 GB.
Tomcat Version 5.5/6.0

[For Tomcat 5.5 and 6.0 on UNIX, use the Tomcat Pre-Version 5.5 procedure
above.] Start the Tomcat monitoring/configuration program by executing the
following:
— TomcatDir\bin\tomcat5w.exe [Tomcat 5.5]
or
— TomcatDir\bin\tomcat6w.exe [Tomcat 6.0]
The Apache Tomcat Properties dialog is displayed.
Click on the Java tab and add “-Xms1024m” and “-Xmx1024m” to the Java
Options section. For example:
This sets the total memory and the maximum memory to 1 GB.

136

| 137
Chapter 5 ASP Forms
This chapter describes how to set up the ASP form example that is provided with
the iProcess Workspace.
Topics
• ASP Form Example, page 138

138
| Chapter 5 ASP Forms
ASP Form Example
A Microsoft Visual Studio .NET 2003 project that defines an example ASP form is
provided with the iProcess Workspace. This example can be used as a starting
point to create your own custom ASP form project.
The example .NET project is located in the following directory:
InstallationHomeDir\iprocessclientbrowser\samples\ASPFormExample
Workspace is installed.
The following sections describe how to implement this example.
Setting Up the ASP Form Project in IIS

Perform the following steps to set up the Microsoft Visual Studio .NET 2003 ASP
form project in Microsoft Internet Information Services (IIS):
1. Create a virtual directory in IIS and give it an alias name. In this example, we
will use the name of the example project.

ASP Form Example 139
|
2. Set the physical directory to point to the location of the ASPFormExample

.NET project.
3. Select all permissions for development purposes. The permissions on the

finished production forms can be set to secure settings at a later time.
4. Start IIS if it is not already running.

5. Open Visual Studio .NET 2003 and select File > Open > Project From Web,
then enter the URL to the project. The path will be:
http://Host:Port/ASPFormExample

140
where:
— Host is the name of the machine on which you’ve installed the ASP form
project.
— Port is the port used by IIS to communicate with web applications.
The Open Project dialog is displayed.
6. Select and open the ASPFormExample.csproj file.
7. In Visual Studio, select Build > Rebuild Solution.
You will be prompted to save the solution file (.sln).
8. Save the solution file in the ASPFormExample directory.
9. In Visual Studio, right click on ASPForm.aspx in the Solution Explorer
window and select Set As Start Page.
10. In Visual Studio, select Debug in the Solution Configuration drop-down list,
then click the start arrow to the left of the field.
Visual Studio will connect to IIS, allowing you to develop and debug the
ASPFormExample project. (A browser window may appear with the
ASPForm.aspx page displayed containing an error message — you can ignore
this message and close the browser window.)
Configuring iProcess Workspace to Use the ASP Form

Perform the following steps to configure the iProcess Workspace to use the ASP
form:
1. Set the ExternalFormURI parameter in the Action Processor’s configuration
file, apConfig.xml. This specifies the base URL of the Web Application Server
(IIS in this case) that is hosting your ASP Forms. For information about this
parameter, see External Form URI on page 64.
2. Create a procedure and define a normal step, or import ASPForm.xfr (which
is included in the ASPFormExample project).

|
3. Set the form type of the normal step to “FormFlow Form”.
4. Click the Edit button on the Step Definition dialog. The FormFlow Form
dialog is displayed.

142
5. Enter the location of the ASPForm.aspx file. Don't enter the full URL, as the
base URL location is defined in the ExternalFormURI parameter (see step 1).
Only enter the portion of the URL that is unique to the step.

|
6. Start a case of the procedure. The ASP form example should look as follows.
7. Edit the ASPFormExample example project for the desired form layout and
fields to be displayed.
Define the field names in the fieldNames array, the types in the fieldTypes
array, and the date format in the dateFormat string.
The field names should correspond to the iProcess Engine procedure field
names. The arrays are defined in ASPForm.aspx, as follows:
String [] fieldNames = {"TEXTFLD1", "TEXTFLD2", "TEXTFLD3",

"NUMERIC1", "CNUMERIC1", "DATE1", "TIME1"};
String [] fieldTypes = {"swText", "swText", "swText", "swNumeric",

"swComma", "swDate", "swTime"};
String dateFormat = "MDY";

144
The dateFormat variable can be set to “MDY”, “DMY”, or “YMD”, to indicate the
order of the day, month, and year in date fields. (Time fields will be displayed in
the hh:mm format.)
The position and look of these fields can be defined in the ASPForm.css cascading
style sheet. For example:
#TEXTFLD1marking {
position:relative;
left:75px;
top:0px;
width:240px;
}
ASP Form Interface

The ASPForm.aspx form makes use of the interfaces defined in the
ASPFormLib.cs library in order to do a start case, lock item, release item, keep
item, and undo item. These interfaces construct and make the request to the
Action Processor. The ASPFormLib public interfaces available are as follows:
ASPFormLib Constructor
The constructor initiates the ASPFormLib with the request and field information.
public ASPFormLib (HttpRequest aRequest,

string [] aFieldNames,
string [] aFieldTypes)
getRequestType
This method returns the type of the request.
public int getRequestType()
The getRequestType method returns one of the following constant int values:
• public const int REQUEST_TYPE_UNKNOWN = 0x0;
• public const int REQUEST_TYPE_RENDER_WORK_ITEM_FORM = 0x1;
• public const int REQUEST_TYPE_RENDER_START_CASE_FORM = 0x2;
• public const int REQUEST_TYPE_START_CASE = 0x3;
• public const int REQUEST_TYPE_UNDO = 0x4;
• public const int REQUEST_TYPE_KEEP = 0x5;

|
• public const int REQUEST_TYPE_RELEASE = 0x6;
getInitXML
This method returns the details of the XML generated by an Undo, Keep or
Release button click on the form.
public string getInitXML()
startCase
This method creates and submits an Action Processor StartCase request.
public void startCase()
undoItem
This method creates and submits an Action Processor UndoItems request.
public void undoItem()
lockItem
This method creates and submits an Action Processor LockItems request.
public String [] lockItem()
keepItem
This method creates and submits an Action Processor KeepItems request.
public void keepItem()

146
releaseItem
This method creates and submits an Action Processor ReleaseItems request.
public void releaseItem()

| 147
Chapter 6 JSP Forms
This chapter describes how to set up the JSP form example that is provided with
the iProcess Workspace.
Topics
• JSP Form Example, page 148

148
| Chapter 6 JSP Forms
JSP Form Example
An IntelliJ project that defines an example JSP form is provided with the iProcess
Workspace. This example can be used as a starting point to create your own
custom JSP form project.
Note that this example was developed using IntelliJ IDEA 5.1 and assumes
Tomcat as the Web Application Server.
The example IntelliJ project is located in the following directory:
InstallationHomeDir\iprocessclientbrowser\Samples\JSPFormExample
The following sections describe how to implement this example.
Setting Up the JSP Form Project

1. Open the JSPFormExample.ipr project file in IntelliJ.
2. Select Build > Rebuild Project to build the JSPFormExample.war file.
3. Move the JSPFormExample.war file to the webapps directory on Tomcat and
start Tomcat.
The form example will extract itself into a directory called JSPFormExample
under tomcat\webapps.
Configure iProcess Workspace to Use the JSP Form

1. Set the ExternalFormURI parameter in the Action Processor’s configuration
file, apConfig.xml. This specifies the base URL of the Web Application Server
(Tomcat in this case) that is hosting your JSP Forms. For information about
this parameter, see External Form URI on page 64.
2. Create a procedure and define a normal step, or import JSPForm.xfr (which
is included in the JSPFormExample project).

JSP Form Example 149
|
3. Set the form type of the normal step to “FormFlow Form”.
4. Click the Edit button on the Step Definition dialog. The FormFlow Form
dialog is displayed.

150
5. Enter the location of the JSPForm.jsp file. Don't enter the full URL as the
base URL location is defined in the ExternalFormURI parameter (see step 1).
Only specify the portion of the URL that is unique to the step.

|
6. Start a case of the procedure. The JSP form example should look as follows.
7. Edit the JSPFormExample example project for the desired form layout and
fields to be displayed.
Define the field names in the fieldNames array, the types in the fieldTypes
array, and the date format in the dateFormat string.
The field names should correspond to the iProcess Engine procedure field
names. The arrays are defined in JSPForm.jsp, as follows:
String [] fieldNames = {"TEXTFLD1", "TEXTFLD2", "TEXTFLD3",

"NUMERIC1", "CNUMERIC1", "DATE1", "TIME1"};
String [] fieldTypes = {"swText", "swText", "swText", "swNumeric",

"swComma", "swDate", "swTime"};
String dateFormat = "MDY";

152
The dateFormat variable can be set to “MDY”, “DMY”, or “YMD”, to indicate the
order of the day, month, and year in date fields. (Time fields will be displayed in
the hh:mm format.)
The position and look of these fields can be defined in the JSPForm.css cascading
style sheet. For example:
#TEXTFLD1marking {
position:relative;
left:75px;
top:0px;
width:240px;
}
JSP Form Interface

The JSPForm.jsp form makes use of the interfaces defined in the
JSPFormLib.java library in order to do a start case, lock item, release item, keep
item, and undo item. These interfaces construct and make the request to the
Action Processor. The JSPFormLib public interfaces available are as follows:
JSPFormLib Constructor
The constructor initiates the JSPFormLib with the request and field information.
public JSPFormLib (HttpServletRequest aRequest,

String [] aFieldNames,
String [] aFieldTypes)
getRequestType
This method returns the type of the request.
public int getRequestType()
The getRequestType method returns one of the following static int values:
• public static final int REQUEST_TYPE_UNKNOWN = 0x0;
• public static final int REQUEST_TYPE_RENDER_WORK_ITEM_FORM =
0x1;
• public static final int REQUEST_TYPE_RENDER_START_CASE_FORM =
0x2;
• public static final int REQUEST_TYPE_START_CASE = 0x3;

|
• public static final int REQUEST_TYPE_UNDO = 0x4;

• public static final int REQUEST_TYPE_KEEP = 0x5;
• public static final int REQUEST_TYPE_RELEASE = 0x6;
getInitXML
This method returns the details of the XML generated by an Undo, Keep or
Release button click on the form.
public String getInitXML()
startCase
This method creates and submits an Action Processor StartCase request.
public void startCase()
undoItem
This method creates and submits an Action Processor UndoItems request.
public void undoItem()
lockItem
This method creates and submits an Action Processor LockItems request.
public String [] lockItem()
keepItem
This method creates and submits an Action Processor KeepItems request.
public void keepItem()

154
releaseItem
This method creates and submits an Action Processor ReleaseItems request.
public void releaseItem()

| 155
Chapter 7 Direct Login
This chapter describes methods of bypassing the iProcess Workspace (Browser)

Login screen by passing login credentials directly.
Topics
• Direct Login, page 156

156
| Chapter 7 Direct Login
Direct Login
You can bypass the iProcess Workspace (Browser) Login screen by passing login
credentials directly into the application.
Users can also be authenticated using credentials they have already entered in
another web application by using the single authentication feature. For
information, see Single Authentication on page 161.
Login credentials can be directly passed into the iProcess Workspace (Browser) in
one of the following ways:
• On the URL
• In an HTML form element named ‘DirectLogin’
• In an HTML script element that defines ‘getDirectLoginArgs’
When loading, the application will look for direct login credentials in the order
shown above.
The direct login feature is supported on IIS 5.1 (Windows XP) and IIS 6.0
(Windows Server 2003).
To use any of the methods of direct login listed above, direct login must be
enabled in the iProcess Workspace (Browser) configuration file. This is described
in Enabling Direct Login on page 157.
In all of the methods of direct login, the following case-insensitive parameters can
be specified:
— BaseUrl - The Action Processor base URL.
— Username - The user name of the user logging in.
— Password - The password of the user logging in.
— ServerName - If specified, this will override the other server node values
below. These will be looked up from the config.xml file as specified under
the <record jsxid=”ServerNodes” type=”ipc”> node by a record <record
displayNodeName=”nodename”>, where ServerName matches the
nodename value.
— ComputerName - The computer name for the iProcess Objects Server.
— IPAddress - The IP address of the machine on which the TIBCO iProcess
Objects Server is installed. You can specify the name of the host machine,
as long as that name resolves to the IP address of the machine where the

Direct Login 157
|
iProcess Objects Server is running. Note, however, that this name must be
able to be resolved by the machine on which the Action Processor is
running.
— TCPPort - The TCP Port for the iProcess Objects Server.
— Name - The iProcess Engine node name.
— Director - “true” or “false”, indicating if an iProcess Objects Director is
being used.
The following sections provide examples of each of the three direct login
methods.
Enabling Direct Login

To be able to use any of the methods of direct login, direct login must be enabled
in the iProcess Workspace (Browser).
To enable direct login:
2. Locate the Login record in the config.xml file:
<record jsxid="Login" type="ipc" useRemember="true" allowDirectLogin="false"/>
3. Modify the allowDirectLogin attribute as follows:

— “true” enables the use of the methods of direct login listed on page 156.
— “false” disables direct login.

158
On the URL
The following are examples of passing login credentials on the URL:
Example 1
http://clientServer/ipc/iProcessClient.html?Username=swadmin&Password=&ServerName=
MyServerConfigName
Example 2
http://clientServer/ipc/iProcessClient.html?Username=swadmin&Password=&ComputerName
=ServerComputerName&IPAddress=10.20.30.40&TCPPort=54321&Name=ServerNodeName&
Director=false
Example 3
http://clientServer/ipc/iProcessClient.html?Username=swadmin&Password=&ComputerName
=ServerComputerName&IPAddress=10.20.30.40&TCPPort=54321&Name=ServerNodeName&
Director=false&BaseUrl=https%3A%2F%2Fsummer-heart-0930.chufeiyun1688.workers.dev%3A443%2Fhttp%2FServerComputerName%3A90%2Fipc%2F
ActionProcessor.aspx
Note that if the BaseUrl is passed on the URL, it must be URI encoded as shown
in the last example above.
In an HTML Form Element Named 'DirectLogin'

The following is an example HTML form:
<form name="DirectLogin">
<input type="hidden" name="BaseUrl"
value="http://ServerComputerName:90/ipc/ActionProcessor.aspx">
<input type="hidden" name="Username" value="swadmin">
<input type="hidden" name="Password" value="">


<input type="hidden" name="ComputerName"
value="ServerComputerName">
<input type="hidden" name="IPAddress" value="10.20.30.40">
<input type="hidden" name="TCPPort" value="54321">

Direct Login 159
|
<input type="hidden" name="Name" value="ServerNodeName">
<input type="hidden" name="Director" value="false">
</form>
Add this form to the HTML file used to launch the iProcess Workspace (Browser),
which by default is ClientInstallDir/iProcessClient.html, where ClientInstallDir is
the path to the directory in which the iProcess Workspace (Browser) is installed.
In an HTML Script Element that Defines ‘getDirectLoginArgs’

The following is an example HTML script:
<script language="JavaScript">
function getDirectLoginArgs(nameSpace) {
var args = new Object();
if (nameSpace == 'wccApp') {
args.BaseUrl = "http://ServerComputerName:90/" +
"ipc/ActionProcessor.aspx";
args.Username = "swadmin";
args.Password = "";
//If ServerName is specified, this will override other
//values and will be looked up from the config.xml file.
//args.ServerName = "MyServerConfigName";
args.ComputerName = "ServerComputerName";
args.IPAddress = "10.20.30.40";
args.TCPPort = "54321";
args.Name = "ServerNodeName";
args.Director = "false";
}
return args;
}
</script>
Add this script to the HTML file used to launch the iProcess Workspace
(Browser), which by default is ClientInstallDir/iProcessClient.html, where
ClientInstallDir is the path to the directory in which the iProcess Workspace

160

| 161
Chapter 8 Single Authentication
This chapter describes how to configure the TIBCO iProcess Workspace (Browser)
so that users can be authenticated using credentials they have already entered in
another web application.
Topics
• Introduction, page 162

• Java Single Authentication, page 163
• .NET Single Authentication, page 169

162
| Chapter 8 Single Authentication
Introduction
The single authentication feature allows users to go directly to the iProcess

Workspace (Browser) from another web application without going through the
iProcess Workspace (Browser) Login screen. When configured for this feature, the
system will authenticate the user using the credentials the user has already
entered in the other web application.
The single authentication feature provides a secure method of passing the user’s
credentials to the iProcess Workspace (Browser).
The way in which you implement this feature depends on whether you are using
the Java or .NET Action Processor. Each is described in the following sections.
Other methods of passing login credentials to perform a “direct login” are

described in Direct Login on page 155.

Java Single Authentication 163
|
Java Single Authentication
The Java single authentication feature is used if you are using the Java Action
Processor. It allows users to go directly to the iProcess Workspace (Browser) from
another web application in which they have already been authenticated.
The Java single authentication feature implements a filter to act as a mediator
between the customer’s web application authentication methods and the iProcess
Workspace (Browser) and Java Action Processor.
Web Server Configuration

The single authentication filter is configured by adding the <filter> and
<filter-mapping> elements to the web server’s deployment descriptor file, which
is located as follows:
APInstallDir\WEB-INF\web.xml
where APInstallDir in the installation directory of the Java Action Processor, which
defaults to TIBCOActProc.

164
The following shows the elements that must be added to web.xml:
<filter>
<filter-name>LoginAuthenticator</filter-name>
<filter-class>com.tibco.bpm.ap.filter.AuthenticateFilter</filter-class>
<init-param>
<param-name>AuthenticatorClass</param-name>
<param-value>
com.tibco.bpm.ap.filter.sample.SampleAuthenticator
</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>LoginAuthenticator</filter-name>
<servlet-name>ActionProcessor</servlet-name>
</filter-mapping>
The <init-param> element provides initialization parameters, including the class

name of the authenticator plug-in that the customer must implement. See the next
section for more information about this plug-in.
Authenticator Plug-in
The customer must create a plug-in that implements the Authenticator interface,
as follows:
public interface Authenticator {

public String getUserName();
public String getPassword();
public String getNodeName();
public String getComputerName();
public String getIpAddress();
public int getTcpPort();
public boolean isDirector();
public boolean authenticate (HttpServletRequest);
The authenticate method receives the request object so it can sync its
authentication parameters with the request ID. The authenticate method’s return
value is boolean, indicating either success or failure of the authenticate call.
The Authenticator interface also provides getter methods for the information
required for a successful login to the iProcess Workspace (Browser). The filter uses
these values to construct a Login action request to the Java Action Processor.

|
iProcess Workspace (Browser) Configuration

To use single authentication, you must enable it in the iProcess Workspace
(Browser) configuration file, which is located as follows:
ClientInstallDir\JSXAPPS\ipc\config.xml
Locate the SingleAuthentication record in the configuration file, and set
useSingle to true:
<record jsxid="SingleAuthentication" type="ipc" useSingle="true"
failureUrl="" />
This informs the iProcess Workspace (Browser) that an external application will
be providing the login authentication credentials.
The failureUrl attribute is used to specify a URL to which the user is redirected if
the login fails.
— If there is a value specified in the failureUrl attribute, and the login fails,
an alert dialog is displayed containing the message "User authentication
could not be confirmed. You will be redirected to an appropriate login
page." The browser is then redirected to the specified URL.
— If the value of failureUrl is empty, and the login fails, an alert dialog is
displayed containing the message “User authentication could not be
confirmed. You must successfully log in before using this site."
Java Single Authentication Sample

A sample Java single authentication plug-in is included with the TIBCO iProcess
Workspace (Browser). This section describes how to set up the sample plug-in, as
well as information about how it operates.
The Java single authentication sample is provided in the following two JAR files:
• SingleAuthenticationSample.jar - This JAR file contains the files that make
up the sample authenticator. It includes:
— login.html
— customApplication.html
— WEB-INF/web.xml
— WEB-INF/classes/com/tibco/bpm/ap/filter/sample/Login.class
— WEB-INF/classes/com/tibco/bpm/ap/filter/sample/SampleAuthenticator.class
— src/com/tibco/bpm/ap/filter/sample/Login.java
— src/com/tibco/bpm/ap/filter/sample/SampleAuthenticator.java

166
• SingleAuthentication.jar - This JAR file contains the class files used by the
authenticator plug-in. It includes:
— com/tibco/bpm/ap/filter/Authenticator.class
— com/tibco/bpm/ap/filter/AuthenticateFilter.class
— com/tibco/bpm/ap/filter/AuthenticateRequestWrapper.class
— com/tibco/bpm/ap/filter/xml/Attribute.class
— com/tibco/bpm/ap/filter/xml/Element.class
— com/tibco/bpm/ap/filter/xml/action/Action.class
— com/tibco/bpm/ap/filter/xml/request/Login.class
— com/tibco/bpm/ap/filter/xml/request/Request.class
— com/tibco/bpm/ap/filter/xml/request/UserId.class
— com/tibco/bpm/ap/filter/xml/vobject.NodeId.class
These JAR files are located in the following directory:
InstallationHomeDir\iprocessclientbrowser\samples\
SingleAuthentication\Java
where InstallationHomeDir is the directory in which the installer places administrative

files, such as the uninstaller, documentation, and sample code. This defaults to
C:\tibco on Windows systems, and /opt/tibco on UNIX systems, but can be
specified as a different directory when the TIBCO iProcess Workspace is installed.
Setting Up the Java Single Authentication Sample

To set up the Java single authentication sample, follow these steps:
1. Stop your web application server.
2. Unpack the SingleAuthenticationSample.jar file into a temporary directory.
3. Compare the APInstallDir/WEB-INF/web.xml file to the one supplied in the
SingleAuthenticationSample.jar file. The one provided in the
SingleAuthenticationSample.jar file will contain the following new
sections: <welcome-file-list>, <filter>, <filter-mapping>. It will also contain
additional <servlet> and <servlet-mapping> sections for the Login.do servlet.
Assuming these are the only differences, you can safely replace the
APInstallDir/WEB-INF/web.xml file with the one supplied in the
SingleAuthenticationSample.jar file.
4. Create the following directory:

APInstallDir/WEB-INF/classes/com/tibco/bpm/ap/filter/sample

|
5. From the SingleAuthenticationSample.jar file you unpacked in step 2,

copy the Login.class and SampleAuthenticator.class files to the directory you
created in step 4.
6. From the SingleAuthenticationSample.jar file you unpacked in step 2,
copy the login.html and customerApplication.html files to the Action
Processor installation directory.
7. Copy the SingleAuthentication.jar file to the APInstallDir/WEB-INF/lib
directory.
8. Configure the TIBCO iProcess Workspace to use single authentication — see
iProcess Workspace (Browser) Configuration on page 165.
9. Restart your web application server.
Launching the Java Single Authentication Sample

To launch the Java single authentication sample, follow these steps:
1. Execute the following URL in your browser:
http://Host:Port/APDir/login.html
where:
— Host is the name of the machine hosting the Action Processor.
— Port is the port number used by the WAS that is hosting the Action
Processor to communicate with web applications.
This defaults to TIBCOActProc.
This presents a dialog on which you can enter login credentials. This
represents the outside source from which login credentials are provided.
2. Enter a user name and password, as well as information about the iProcess
Objects Server to log into, then click the Submit button.
This causes the login credentials to be sent to the login.do servlet, which
stores the information in the session using a Java hash map. It then launches
the customerApplication.html file, which represents the customer
application. This page contains the following fields: New window URL,
Window width, and Window height.
3. Enter the URL to the TIBCO iProcess Workspace in the New window URL
field. You can also specify new width and height values, if desired.
The URL must be in the form:
http://Host:Port/iProcessClientDir/iProcessClient.html

168
where:
— Host is the name of the machine hosting the iProcess Workspace (Browser).
— Port is the port number used by the WAS that is hosting the iProcess
Workspace (Browser) to communicate with web applications.
— iProcessClientDir is the directory on Host in which the iProcess Workspace
(Browser) is installed. This defaults to TIBCOiPClnt.
4. Click the Open new window button.
Since the iProcess Workspace (Browser) has been configured to use the single
authentication feature (see step 8 on page 167), it will bypass the normal
iProcess Workspace (Browser) Login screen and send a login request to the
Action Processor.
The filter (AuthenticateFilter), which sits between the iProcess Workspace
(Browser) and the Action Processor (see the illustration on page 163), wraps
each requests in an AuthenticateRequestWrapper object. The wrapper
examines each request for a single-authenticate login request. When it finds
one, it uses the SampleAuthenticator, which implements the Authenticator
interface, calling the authenticate method, and passing the request object. The
authenticate method obtains the login data hash map from the session, and
queries the hash map to populate its login properties. The
AuthenticateRequestWrapper then uses the SampleAuthenticator properties
to construct a login request that is passed to the Action Processor.
If the previously entered credentials are valid, the iProcess Workspace
(Browser) is displayed.

.NET Single Authentication 169
|
.NET Single Authentication
The .NET single authentication feature is used if you are using the .NET Action
Processor. It allows users to go directly to the iProcess Workspace (Browser) from
another web application in which they have already been authenticated.
The .NET single authentication feature implements an HTTP module that is
inserted into the HTTP request pipeline to act as a mediator between the
customer’s web application authentication methods and the iProcess Workspace
(Browser) and .NET Action Processor.
Web Server Configuration

The HTTP module is hooked into the pipeline by configuring it in the web server
configuration file, which is located as follows:
C:\inetpub\wwwroot\APInstallDir\web.config
where APInstallDir in the installation directory of the .NET Action Processor, which
defaults to TIBCOActProc.
The following shows the elements that must be added to web.config:
<configuration>
<appSettings>
<add key=”AuthenticatorAssemblyPath”
value=”D:\\SingleAuthenticationSample.dll” />
<add key=”AuthenticatorAssemblyName”
value=”SingleAuthenticationSample” />
<add key=”AuthenticatorAssemblyImpl”
value=”SingleAuthenticationSample.SampleAuthenticator” />
<add key=”AuthenticatorLogFile”
value=”C:\\temp\\SingleAuthentication.log” />
</appSettings>

170
<system.web
<httpModules>
<add name=”LoginAuthenticator>
type=”SingleAuthentication.AuthenticateFilter, SingleAuthentication” /
</httpModules>
</system.web
</configuration>
where:
• AuthenticatorAssemblyPath is the absolute path to the customer assembly.
• AuthenticatorAssemblyName is the name of the assembly.
• AuthenticatorAssemblyImpl is the name of the IAuthenticator
implementation.
• AuthenticatorLogFile is the absolute path to the log file.
Authenticator Plug-in
The customer must create a plug-in that implements the
SingleAuthentication.IAuthenticator interface, as follows:
using Sysyem;
using System.Web;
namespace SingleAuthentication {
public interface IAuthenticator {

string UserName { get; }
string Password { get; }
string NodeName { get; }
string ComputerName { get; }
string IpAddress { get; }
int TcpPort { get; }
bool Director { get; }
bool Authenticate (HttpContext ctx);
}
The customer plug-in Authenticator module implements an Authenticate

method that receives the HttpContext object so that it can sync its authentication
parameters with the context. The return value of the Authenticate method is a
boolean, indicating success or failure of the authenticate call.

|
The IAuthenticator interface also provides getter methods for the information
required for a successful login to the iProcess Workspace (Browser). The HTTP
module uses these values to construct a Login action request to the .NET Action
Processor.
iProcess Workspace (Browser) Configuration

To use single authentication, you must enable it in the iProcess Workspace
(Browser) configuration file, which is located as follows:
ClientInstallDir\JSXAPPS\ipc\config.xml
Locate the SingleAuthentication record in the configuration file, and set
useSingle to true:
<record jsxid="SingleAuthentication" type="ipc" useSingle="true"
failureUrl="" />
This informs the iProcess Workspace (Browser) that an external application will
be providing the login authentication credentials.
The useSingle parameter can also be passed in the URL, if desired. The following
example URL is telling the client that an outside source is supplying the login
credentials:
http://somedirectory/iProcessClient.html?useSingle=true
The failureUrl attribute is used to specify a URL to which the user is redirected if
the login fails.
— If there is a value specified in the failureUrl attribute, and the login fails, an
alert dialog is displayed containing the message “User authentication
could not be confirmed. You will be redirected to an appropriate login
page.” The browser is then redirected to the specified URL.
— If the value of failureUrl is empty, and the login fails, an alert dialog is
displayed showing the message “User authentication could not be
confirmed. You must successfully log in before using this site."
.NET Single Authentication Sample

A sample .NET single authentication plug-in is included with the TIBCO iProcess
Workspace (Browser). This section describes how to set up the sample plug-in, as
well as information about how it operates.
The sample .NET single authentication plug-in defines three pages:
• SingleAuthenticationLoginSample.aspx

172
• customerApplication.htm
• iProcessClient.htm
The SingleAuthenticationLoginSample.aspx page provides the user the
ability to define login particulars. Once the data has been filled in, the user will
select the Login button. This action sends login data to the event method, which
stores it in the session using a C# hash table. The event method then launches
customerApplication.htm.
The customerApplication.htm page provides the user the ability to specify the
URL from which to launch the iProcess Workspace (Browser) application, as well
as the window width and window height. The customerApplication.htm page
also contains an Open new window button, which launches the application
specified in the URL field in a new browser window using the specified width
and height settings.
Since the iProcess Workspace (Browser) application has been configured for
single authentication, it bypasses the client’s login window, and sends a single
authentication request to the Action Processor. The AuthenticateFilter is inserted
into the Action Processor request pipeline, and it examines each request looking
for the single authentication request. When it finds a single authentication
request, it uses the sample object, SampleAuthenticator, which implements the
IAuthenticator interface, calling the Authenticate method and passing the
HttpContext object. The Authenticate method obtains the login data hash table
from the session and queries the hash table to populate it with the login
properties. The AuthenticateFilter then uses the SampleAuthenticator to
construct a login request that is passed to the Action Processor.
This sample assumes that SingleAuthenticationLoginSample.aspx,

customerApplication.htm, iProcessClient.htm, and the TIBCO iProcess
Workspace (Browser) application itself will reside in the Action Processor
installation directory. (The iProcess Workspace (Browser) application must reside
in the Action Processor installation directory for this sample because of .NET
security constraints.)
Setting Up the .NET Single Authentication Sample

The .NET single authentication sample plug-in includes the following .zip file
and assembly:
• SingleAuthenticationSample.zip
• SingleAuthentication.dll
These files are located in the following directory:
InstallationHomeDir\iprocessclientbrowser\samples\SingleAuthentication\
dotNet

|

To set up the .NET single authentication sample, following these steps:
1. Unpack the SingleAuthenticationSample.zip file into a temporary
location.
This zip file contains all of the files needed for the plug-in sample (including
the sample source code), which include:
— AssemblyInfo.cs
— SingleAuthenticationLoginSample.cs
— SampleAuthenticator.cs
— bin\Release\SingleAuthenticationSample.dll
— SingleAuthenticationLoginSample.aspx
— SingleAuthenticationLoginSample.aspx.resx
— Web.config
— customerApplication.htm
— iProcessClient.htm
2. Stop Microsoft IIS.
3. Compare the APInstallDir\Web.config file to the one supplied in the
SingleAuthenticationSample.zip file. They should differ by the
<appSettings> and <httpModules> sections. Assuming these are the only
differences, you can safely replace the APInstallDir\Web.config file with the
one supplied in the SingleAuthenticationSample.zip file.
4. Copy the assemblies bin\Release\SingleAuthenticationSample.dll and
SingleAuthentication.dll into the APInstallDir\bin directory.
5. In the new APInstallDir\Web.config file, modify the

key=AuthenticatorAssemblyPath value in the <appSettings> section to point
to the absolute location where you installed the
SingleAuthenticationSample.dll file (APInstallDir\bin).
6. Copy the files SingleAuthenticationLoginSample.aspx,

SingleAuthenticationLoginSample.aspx.resx,
customerApplication.htm and iProcessClient.htm to the Action

174
7. Install a copy of the TIBCO iProcess Workspace (Browser) in the Action

Processor installation directory. This is required for this sample because of
.NET security constraints.
8. Configure the iProcess Workspace (Browser) to perform a single
authentication. For information about how to do this, see iProcess Workspace
(Browser) Configuration on page 171.
9. Restart Microsoft IIS.
Launching the .NET Single Authentication Sample

To launch the .NET single authentication sample, follow these steps:
1. Execute the following URL in your browser:
http://Host:Port/APDir/SingleAuthenticationLoginSample.aspx
where:
— Host is the name of the machine hosting the Action Processor.
— Port is the port number used by IIS to communicate with web applications.
This defaults to TIBCOActProc.
This presents a dialog on which you can enter login credentials. This
represents the outside source from which login credentials are provided.
2. Enter a user name and password, as well as the information about the iProcess
Objects Server to log into, then click the Submit button.
The customerApplication.htm page is opened. This page contains the
following fields: New window URL, Window width, and Window height.
The New window URL field will be prefilled with “iProcessClient.htm”. You
can specify different width and height values, if desired.
3. Click the Open new window button.
If the login particulars you entered in step 2 are correct, the iProcess
Workspace (Browser) will start without displaying its Login screen.

| 175
Chapter 9 Localization
This chapter describes how to add a language resource file to the iProcess
Workspace (Browser) to display the application in the desired language.
Topics
• Localizing the iProcess Workspace (Browser), page 176

176
| Chapter 9 Localization
Localizing the iProcess Workspace (Browser)
Localizing the TIBCO iProcess Workspace (Browser) involves the following steps:
• Create a new localized language resource file. The resource file contains a
collection of application text strings that have been translated to a specific
language and may be localized for language variations used by individual
countries.
• Configure the new localized language in the iProcess Workspace (Browser).
• Modify an existing, or create a new, General Interface system locale file. These
files contain localized resources utilized by the General Interface framework.
• Translate user access profile descriptions.
• Set the new default language for the iProcess Workspace (Browser).
• Create a new folder to hold localized help files.
These steps are described in detail in the following subsections, using Spanish as
an example of the new language being added to the iProcess Workspace
(Browser).
Note that each localized language is represented by a two-letter code, in the
format:
— ll
where ll is a lowercase, two-letter ISO 639 language code. For a list of
language codes, visit the following web site:
http://www.loc.gov/standards/iso639-2/langhome.html
Each country is represented by a two-letter code, in the format:
— CC
where CC is an uppercase, two-letter ISO 3166 country code. For a list of
country codes, visit the following web site:
http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists
/index.html
A locale key is a string representation of a locale that includes a language and a
country code in the following format:
— ll_CC

Localizing the iProcess Workspace (Browser) 177
|
Create a New Localized Language Resource File

You must create a resource file that contains a collection of application text strings
that have been translated to a specific language and may be localized for language
variations used by individual countries.
Perform the following steps to create a new language resource file:
1. Determine whether the new language file will contain translations that are:
a. Generic for all locales - for instance, Spanish is sufficient without regard to
variations for the specific dialects or alphabets of Spain or Mexico.
b. Language defaults, with variations for specific locales - for instance,
Spanish is the default, however, some words or phrases are defined
specifically for the dialects or alphabets of Mexico and Spain.
c. Locale specific - for instance, if the Spanish of Mexico did not have any
words or phrases in common with the Spanish of Spain, you would create
a separate language resource file for each country.
2. Open a new XML file and insert the following XML elements, using the
proper language code (if of type a or b above), or locale key containing both
language and country codes (if of type c), as the value for the key attribute:
3. Open the default (English) locale file:

ClientInstallDir\JSXAPPS\ipc\locale\locale.xml
4. Copy all record elements that are direct children of the <locale> element in
locale.xml.
Note - Only copy children of the <locale> elements that do not have a key
attribute (e.g., <locale key = en_AU>).
5. Paste all copied record elements into the newly created file as direct children
of the <locale key=”es”> element.

178
6. Translate the value of every jsxtext attribute in the newly created file to
language-specific values.
Note - Any record elements that are deleted from the new language resource
file will cause the iProcess Workspace (Browser) to “fallback” to the record
that is defined in the default (English) locale file.
7. Optionally, localize the new language resource for specific countries. The
purpose of localizing for specific countries is to provide a mechanism for
overriding default language text values (translated in Step 6) with text values
that are specific for a country and that differ from the default (type b above).
For each country-specific locale, create a <locale> element (within the root
<data> element) and specify the locale key as the value of the key attribute.
Insert record elements into each new <locale> element, that are to “override”
default language records, with matching jsxid attribute values.
In the example above, the default Spanish language text of “Abierto” will be
replaced with country-specific values when either the Spanish (Spain) or

|
Spanish (Mexico) locales have been selected by the user as the language for
the iProcess Workspace (Browser).
Any records not explicitly overridden in country-specific locales will
“fallback” to the default language definition (e.g., “Cierre” in the example
above).
8. Save the newly created locale resource file as follows:
ClientInstallDir\JSXAPPS\ipc\locale\locale.ll.xml
or (if of type c in step 1):

ClientInstallDir\JSXAPPS\ipc\locale\locale.ll_CC.xml
where ll in the filename is the language code , and CC is the country code (e.g.,
locale.es.xml - for Spanish; locale.es_MX.xml - for a Mexico-only
translation) and ClientInstallDir is the path to the directory in which the
iProcess Workspace (Browser) is installed.
Configure the New Localized Language in the iProcess Workspace (Browser)

Perform the following steps to configure the new localized language in the
1. Add the new language code to the default language resource file.
a. Open ClientInstallDir\JSXAPPS\ipc\locale\locale.xml and edit
the value of the locales attribute of the root <data> element.
b. Insert the two-letter language code of the new language into the
comma-separated value of the locales attribute, as shown in the following
example:
Adding the language code to locale.xml provides the necessary

configuration to support the “override” and “fallback” relationship between
the new file and the default language resource file.

180
Modify or Create a General Interface System Locale File

Some of the text that is displayed in the iProcess Workspace (Browser) application
originates from the General Interface (GI) system locale files. Although several
formats and text strings are defined in these GI locale files, only a few text items
will ever display in the iProcess Workspace (Browser).
By default, GI is already localized for many languages and countries, however,
some of the text displayed in the iProcess Workspace (Browser) is only defined in
the default GI system locale file (English), and must be inserted and translated
into other locale files as required.
For this version of the iProcess Workspace (Browser), General Interface supports
the following languages and countries:
ISO 639-1 ISO 639-1 Code +

Language Country
Code ISO 3166 Code
Arabic ar N/A
Chinese zh zh_CN China

zh_HK Hong Kong
zh_TW Taiwan
Danish da da_DK Denmark
English en en_AU Australia

en_CA Canada
en_GB Great Britain (UK)
en_NZ New Zealand
en_US United States
French fr fr_CA Canada

fr_FR France
German de de_DE Germany
Greek el el_GR Greece
Italian it it_IT Italy
Japanese ja ja_JP Japan
Korean ko ko_KR Korea

|
Language ISO 639-1 ISO 639-1 Code + Country

Code ISO 3166 Code
Portuguese pt pt_BR Brazil
pt_PT Portugal
Russian ru ru_RU Russian Federation
Spanish es es_ES Spain

es_MX Mexico
es_US United States
Swedish sv sv_SE Sweden
The language resource files for these locales are stored at the following path:
ClientInstallDir\JSX\locale\
where ClientInstallDir is the path to the directory in which the iProcess Workspace
(Browser) is installed. For example:
As with the iProcess Workspace (Browser), the default GI language resource file is
locale.xml (English). If the locale resource files already defined by General
Interface do not support the desired localization being created for the iProcess
Workspace (Browser), a new GI system locale file must be created using the
following steps:

182
1. Create a new localized GI system language file using the same instructions as
in Create a New Localized Language Resource File on page 177 of this
document, substituting ClientInstallDir\JSX\locale\ as the file path.
2. Perform Step 1 of the section, Configure the New Localized Language in the
iProcess Workspace (Browser) on page 179 of this document, substituting
ClientInstallDir\JSX\locale\ as the file path.
If General Interface already provides a locale resource file for the desired
localization, perform the following steps to add text resources, utilized by the
iProcess Workspace, into the locale file:
1. Open the XML file corresponding to the language of the new localization (e.g.,
ClientInstallDir\JSX\locale\locale.es.xml) and open the default GI
system locale file: ClientInstallDir\JSX\locale\locale.xml.
2. Copy the following record elements from locale.xml into the locale file of
the new localization (under the <locale> element whose key attribute value
matches the locale key of the new localization):
3. Translate the value of the jsxtext attributes to the desired language.

4. Save the locale file (e.g., ClientInstallDir\JSX\locale\locale.es.xml).
Translate User Access Profiles Descriptions

User access profiles define the functionality available to various types of iProcess
Workspace (Browser) users. The description of the profile defined for the
logged-in user is displayed in the upper left corner of the application:
In the example above, “Access Level: Admin” is defined as the user access profile
description for Admin-level users.

|
To localize user access profile descriptions, locate the <Profile> elements in the
ClientInstallDir\JSXAPPS\ipc\userAccessProfiles.xml file (where
ClientInstallDir is the path to the directory in which the iProcess Workspace
(Browser) is installed), and change the description attributes to the desired
language.
Set the New Default Language for the iProcess Workspace (Browser)
Set the new default language using one of the following methods:
• Modify the config.xml file to specify the default localeKey, as follows:
• Or, specify the language on the Options dialog in the application. For
information about setting options in the application, see the TIBCO iProcess
Workspace (Browser) User's Guide.
Create a New Folder to Hold Localized Help Files

Perform the following steps to create the folders necessary to hold the localized
help files for the iProcess Workspace (Browser).
1. Create a new folder at the following path:
ClientInstallDir\Help\language\ll
where ClientInstallDir is the path to the directory in which the iProcess

Workspace (Browser) is installed, and ll is the two-letter language code for the
help files.
If the help files are not country-specific and will be applicable for all locales of
this particular language, proceed to Step 2 to store the files in this new
language folder.
If your help files are localized for specific countries, create another folder
beneath this new language folder, using the two-letter country code for the

184
folder name (e.g. ClientInstallDir\Help\language\ll\CC). Proceed to

Step 2 to store the files in this new country folder.
2. Copy the localized help files into the new folder.

| 185
Chapter 10 Customizing iProcess Modeler Forms
This chapter describes how to customize TIBCO iProcess Modeler-generated

forms using additional HTML and scripting code.
Topics

• Embedding HTML, page 188
• File Caching, page 196
• Common Issues for Embedded and File-Cached Customizations, page 211

186
| Chapter 10 Customizing iProcess Modeler Forms
Overview
The TIBCO iProcess Workspace (Browser) renders the standard iProcess Modeler
forms as HTML with scripting. This can be customized with additional HTML
and scripting code to alter the appearance and augment the functionality
provided by the standard form.
Customizations can be done using two methods:
• Embedding - Additional HTML can be embedded directly into the iProcess
Modeler Form definition so that it is included when the browser form is
dynamically generated.
— The customizations are stored in the form definitions. Exporting and
importing the procedure maintains the customizations.
— A smaller, simpler set of scripting functions are used to access work item
data.
— The iProcess Modeler Form definition will not be suitable for display in the
rich client versions of the iProcess Workspace (Browser), where the HTML
tags and scripting code will be visible as part of the form.
— Each type of marking (required marking, optional marking, display field,
and embedded field) has a consistent, standard appearance. You can
customize the appearance of each type of control, but not individual
markings. You can, however, create your HTML controls, then set and get
work item / case values.
— Standard Undo, Keep, and Release buttons always appear at the bottom of
the form.
• File Caching - The HTML that is generated for the iProcess Modeler Form can
be altered and saved to a disk cache where it will be used instead of
dynamically generated HTML.
— The customizations are stored in files on the web server and will not
automatically follow the iProcess Modeler Form definition through export
/ import, so backups will need to be maintained separately.
— Customizations can be saved for use with a specific minor version of the
procedure, a specific major version, or for all versions. So when the
procedure is changed, new cache files may need to be created, copied, or
modified so that the appropriate customizations are available for use with

Overview 187
|
a modified procedure definition, or for work items not migrated to the new
version of the procedure.
— The iProcess Modeler Form definition can be designed to work well in the
other rich client versions of the iProcess Workspace (Browser), while the
customizations are used only for the iProcess Workspace (Browser).
— The appearance and functionality of the individual marking control can be
customized.
— The Undo, Keep, and Release buttons can be modified or moved. They can
also be removed and replaced with other controls that would trigger the
actions through scripting.
If you will only be displaying forms in the iProcess Workspace (Browser), and
your customization needs are not overly complex, you might choose to embed the
HTML into the form definition. If you need to be able to use both the rich client
and browser versions of the iProcess Workspace (Browser), or apply more
extensive customizations, you might choose file-cached customizations.
Also, you do not have to handle all procedures, steps, and versions of steps using
the same method. You can use a mixture of standard dynamically generated
HTML, embedded HTML, and file-cached HTML.
These methods of customization are described in more detail in the following
sections.

188
Embedding HTML
When embedding HTML directly into the iProcess Modeler Form definition, any
valid HTML can be included, with a few limitations and considerations, as
described in the following subsections.
Word Wrap in the Editor

The editor for the iProcess Modeler Form limits the line length for entering text
into the form definition. When typing or pasting HTML code into the form, you
may want to set the line length to the maximum value of 128. If the editor does
wrap code to a new line, you may need to alter it so that line breaks do not
adversely affect the HTML.
Pre-Formatting of the Form

By default, all the text that appears in the form definition is treated as one large
block of text with spacing preserved and carriage returns between the lines.
Where fields appear in the iProcess Modeler Form, one or more HTML elements
will be inserted into that block of text. By default, this block of HTML is enclosed
inside an HTML <pre> tag. This preserves all whitespace in the form, including
multiple spaces and line feeds. It also limits fonts to monospaced fonts.
Disabling Pre-Formatting
Pre-formatting could interfere with the appearance of some types of HTML you
embed. If it does, the pre-formatting can be disabled by including the HTML
comment “” anywhere in the form definition. When that
comment is detected, the HTML <pre> tag will not be placed around the HTML
for the form. If there are some isolated sections of your form that still need to be
pre-formatted, <pre> tags can be added where needed in the form definition.
Including Scripts
Scripting can also be included in the form. As an example, to disable the context
menu for the page, you could include the following block of text anywhere on the
form.
<script language="javascript">
document.oncontextmenu = function (){return false;}
</script>

Embedding HTML 189
|
Nesting of HTML Tags with Conditional Statements

Where the iProcess Modeler Form definition includes IF / ELSE / ENDIF
conditions, the blocks affected by a condition are enclosed in an HTML <span>
tag. Make sure that any opening and closing HTML tags that you add nest
properly with these. For instance, you should not put a <B> tag on the line before
an IF statement and the matching </B> tag on the line right after the IF. You
could, however, put the matching </B> tag after the ENDIF.
Functions Available for Embedded Scripting

Two .js files are imported into the page generated for an iProcess Modeler Form:
• spddate.js - Contains functions for date, time, and numeric data conversions.
• spdform.js - Contains functions for accessing the work item / case data and
performing other interactions with the iProcess Modeler Forms.
Comments inside of spddate.js describe the available functions. The file also
contains many private variables and functions. The names of these private
variables and functions all begin with the text “_private”. You should not call or
access these private items as they are subject to change or removal in future
versions.
Comments inside of spdform.js describe the functions that are available for use
from scripting. The ones that are specifically for use with HTML embedded
directly into the form definition are labeled with the text “Supported in Client
Scripting”. Do not use other functions in the file as they are only for use with
file-cache customizations, or are private functions that are subject to change or
removal in future versions.
These are the functions allowed for use in embedded scripting:
• spdSetFieldValue(fieldName, fvalue, spdFormat, spdPreDecimalDigits)
• spdGetFieldValue(fieldName, spdFormat, getInitialValue)
• spdGetWorkItemTag()
• spdGetProcTag()
• spdIsFieldValid(fieldName)
• spdGetFieldErrorMsg(fieldName)
• spdSetFieldNotificationFunction(fieldName, notificationFunction)
Use the spdSetFieldValue() and spdGetFieldValue() functions to get and set the
values of any work item or case fields whether or not the field is included as a
marking. Any change to the field value through these functions will update the
information displayed in marking controls on the form.

190
Separate functions (spdGetWorkItemTag() and spdGetProcTag()) exist for

retrieving the work item tag and procedure tag, since these are not actually
accessible as case fields.
The spdIsFieldValid() function returns false if invalid data is entered on the form
for a field, for example, a date with a value of “13/13/2006”. When the field data
is not valid, the field error message will contain a text description of the problem.
The spdSetFieldNotificationFunction() function lets you specify a function to be
called when the value of the specified field changes. The function will also be
called during initialization of the form if the form includes a marking for the field
(including hidden or embedded markings).
Altering the Style of Various Controls

The appearance of the various marking controls is set through a cascading style
sheet named spdform.css. You should not directly alter this file, but can include
styles to override the values directly in your form definition or add a reference to
an additional CSS file to override settings.
The following are the class names for the styles used in the dynamically
generated iProcess Modeler Forms:
You’ll see the “SPD” acronym used in places. This is a carryover from the
previously used “Staffware Process Definer” name, which is now called the
“iProcess Modeler”.
• SPD_CONTAINER - Style for an area containing the entire iProcess Modeler

Form. Used to create a border, padding default color and font information.
• SPD_MARKING_REQ - Style applied to input controls (text input or select)
for required markings.
• SPD_MARKING_OPT - Style applied to input controls (text input or select)
for optional markings.
• SPD_MARKING_EMBEDDED - Style applied to embedded marking data.
• SPD_MARKING_READONLY - Style applied to read-only marking data.
• SPD_MEMO_BUTTON_REQ - Style applied to memo buttons for editing
required memo fields.
• SPD_MEMO_BUTTON_OPT - Style applied to memo buttons for editing
optional memo fields.
• SPD_MEMO_BUTTON_READONLY - Style applied to memo buttons for
displaying read-only memo fields.

Embedding HTML 191
|
• SPD_MESSAGE - Style applied to a message area that could appear at the

top of the form (rarely shown).
• SPD_BUTTON - Style applied to the buttons used to trigger the undo, keep,
and release actions.
• SPD_HELP - Style applied to area/link for displaying field help.
• SPD_CALENDAR - Style applied to the area/link for displaying the popup
calendar.
• SPDCAL_CONTAINER - Style for an area containing a popup calendar
(used to set border/padding/ default color/font).
• SPDCAL_PREV - Style for the area/link for going to the previous year and
month.
• SPDCAL_NEXT - Style for the area/link for going to the next year and
month.
• SPDCAL_HEADER - Style for the heading areas displaying the year and
month name.
• SPDCAL_WEEKDAYS - Style for the area displaying the abbreviated day
names.
• SPDCAL_ACTIVEDAY - Style for all selectable days from the displayed
month.
• SPDCAL_INACTIVEDAY - Style for all the non-selectable days before/after
the display month.
• SPDCAL_SELECTEDDAY - Style for the currently selected day (or current
date if none was already selected).
For example, to alter the background color for optional fields (only used if the
field is empty), you could include the following in the iProcess Modeler Form
definition:
<style>

</style>
Embedded Customization Examples

The file IPCBrowserExamples.xpdl contains several example procedures
illustrating embedded HTML. This file is located in the following directory:
InstallationHomeDir\iprocessclientbrowser\samples\IPCBrowserFormExamples

192

systems, but can be specified as a different directory when the iProcess Workspace
The examples provided are described in the following subsections.
CHECKBOX
The CHECKBOX example uses check boxes to modify field data.
• The form includes a hidden marking for each of the fields that will be edited
with a check box.
• An input control of the type “checkbox” is included for each field. The onclick
event of the check box calls the function spdSetFieldValue() with the
appropriate value for the current checked state of the control.
• A notification function is defined and is registered with the spdform.js code
using the function spdSetFieldNotificationFunction().
• Any time the field value is changed by other controls or through scripting
code, the notification function is called, which will set the state of the check
boxes to match the data. This includes a call to the function when the form is
initialized so the check boxes will display the correct information when the
form is first loaded.

Embedding HTML 193
|
RADIOBTN
The RADIOBTN example uses radio buttons to modify field data. The setup of a
set of radio buttons is very similar to the check box example, except that each field
requires multiple input controls, one for each radio button.
SCRIPT
The SCRIPT example lets the user enter a URL on the initial step. The form for the
second step shows the URL as an embedded field. The web page for the URL is
displayed on the form inside an IFRAME. A button will let the user alter the URL,
which will both change the IFRAME to the new page and set the new value for
the URL field.

194
TABFIELD
The TABFIELD example creates a set of tabs using HTML <span> elements.
Clicking on the tabs will change the value of a hidden field, which in turn causes
different conditional sections of the form to be displayed.
TABNOFLD
The TABNOFLD example also creates a set of tabs, but it does not use an actual
field value or rely on conditional sections of the form.

Embedding HTML 195
|
CSSCHGS
The CSSCHGS example shows changing the appearance of the iProcess Modeler
Form through a <style> tag embedded in the form definition.

196
File Caching
The iProcess Modeler Form definition, including any embedded HTML, is

converted into an HTML form for display in the iProcess Workspace (Browser).
The dynamically generated HTML can be further modified and saved to a specific
path and file name on the server to be used for subsequent requests for the form.
When this file- cached version of the form is detected, the iProcess Modeler Form
definition is no longer used as a source for generating the HTML for the page.
To begin customizing a form, use the iProcess Workspace (Browser) to display a
work item for the step you wish to change. Right click on the form and choose the
option to view source. The source can then be modified and saved to the
appropriate path and file name. Appropriate file names are listed in a comment
near the top of the source.
In addition to modifying the section of the page used to display the iProcess
Modeler Form, you may also modify header and footer sections of the page. You
can then save the file to an additional location where it will be used as a source for
the header and footer section for multiple steps or procedures. The comments at
the top of the source indicate the appropriate file names for this purpose.
Setting up a Test Environment

Before saving your modifications to the location that will override the standard
rendering of the form, you may want to save them into a work directory where
you can fully test your changes before deploying. To do this:
1. Create a directory for storing the pages you will be modifying.
2. Copy the files spddate.js, spdform.js, spdform.css, and memopage.html
from the directory where the Action Processor is installed to your work
directory.
3. Open a work item in the iProcess Workspace (Browser) for the step you wish
to customize.
4. Right click on the page for the work item and choose to view the source.
5. Save the source to your work directory. Any file name can be used in the work
directory, but using the name you later plan to use in the file cache will make
it easier to identify multiple files.

File Caching 197
|
You can now load the saved page directly into your browser from the work
directory. Everything should work as if you had just loaded the page from the
iProcess Workspace (Browser), except that the Undo, Keep, and Release buttons
will not actually communicate with the server. You can use any text or HTML
editor to make modifications and test your changes.
Once you are satisfied with your changes, you can deploy by copying the file to
the appropriate file name in the “htmlcache” subdirectory under the Action
Processor installation directory (the htmlcache directory does not exist by
default; you must create it).
Structure of the Complete iProcess Modeler Form Page

If you examine the source for a work item page returned by the iProcess
Workspace (Browser), you will see a very simple skeletal web page with four
areas clearly blocked off by start and end comments. Make sure you do not alter
these start and end comments when you customize the page.
The four main areas are:
• Data XML
• Common Header HTML
• Common Footer HTML
• iProcess Modeler Form HTML
Data XML
This block is XML containing data for the work item / case that is displayed. The
XML itself will not be visible on the page, but is embedded in the page as a source
of information for the standard scripting inside of spdform.js. You should not
write scripting code to directly query this XML because the format is subject to
change in future versions. Only use the spdform.js functions to access the work
item / case data.
After you have made some customizations to a form, you might want to try the
form with data for a different work item. To do this, display a different work item
in the iProcess Workspace (Browser), view the source, copy the Data XML section
from that source, and use it to replace the same section in the copy of the page you
are customizing.

198
Common Header HTML and Common Footer HTML

These are blocks of HTML that can be reused for multiple steps or procedures.
These can be saved for use with a specific step, a specific procedure, or for all
procedures. The information for the header and the footer are always retrieved
from the same disk cache file so you can set up HTML in these sections that act as
a wrapper for everything that lies between the header and footer. For instance, a
table could be started in the header, a cell inside of the table could include what
comes between the header and footer, then the footer would close that cell and
specify the rest of the table.
Scripting code can be used to display data inside the header or footer. Make sure
any fields you choose to display will always be available. For instance, fields like
case description and case reference could be displayed for all procedures, but
other case fields may not exist inside all procedures.
iProcess Modeler Form HTML

This is the block of HTML used for the iProcess Modeler Form. As with the
header and footer sections, you can make modifications to the code and save the
HTML to the cached HTML directory. You can choose to save it for use with a
specific minor version of the procedure, for a specified major version of the
procedure, or for all versions of the procedure. There are a few special
requirements for this block of HTML, which will be described in the following
sections.
Functions Available for File-Cached Scripting

The functions for embedded scripting are also available for file-cached scripting.
For details about those functions, see Functions Available for Embedded
Scripting on page 189.
In addition, the following functions can also be used. Comments in the file
spdform.js describe each function in detail.
Functions related to form initialization:

• spdInitForm()
• spdAppendList(listname, markingControlId)
• spdInitMarking(markingControlId, spdName, spdFormat, spdRequired,
spdEmbedded, spdPreDecimalDigits, spdHelp)
• spdCalculateOptionValue(markingControlId, optionId, expression)
• spdConditionalBlock(blockId, condition)

File Caching 199
|
• spdPostInitForm()
Near the end of the HTML that is dynamically generated for the iProcess Modeler
Form is a block of script code that initializes the form. This should be left at the
end since many of the function calls may reference text boxes, select lists, or other
controls defined earlier in the form. The code begins with the spdInitForm()
function and ends with the spdPostInitForm() function. The code in between
performs actions such as populating selection lists, initializing markings, and
defining a function that updates the information on the form after a field is
changed.
The spdInitForm() function sets up some hidden form elements that will be later
used when submitting the form to undo, keep or release the work item.
When a marking has validation items, it will be rendered as an HTML <select>
element. Individual selection items that are part of the form definition will appear
as <option> elements under that. Items retrieved from lists maintained on the
server, however, must be added through code. The spdAppendList() function
retrieves the list values from the data XML block and adds them as <option>
elements under the <select> element.
All markings are converted into HTML elements. In addition to <select> lists,
these might be text boxes, hidden input areas, spans, or buttons. Calls to the
spdInitMarking() function links up these controls to the appropriate fields and
specifies how the data is formatted and whether it is required. When this function
gets called during form initialization, the initial field value is retrieved from the
data XML and placed into the HTML element that is defined.
Next, the spdFormUpdate() function must be defined. This function will be called
whenever a field value changes. If any of the <option> elements for a <select> list
are iProcess expressions (either a field name or a simple supported expression),
there will be a call to the spdCalculateOptionValue() function to update the
value for that <option> element.
If the form contains any conditional sections, there will be calls to the
spdConditionalBlock() function to display or hide the section on the form.
Finally, the spdPostInitForm() function will be called. This makes an initial call to
the spdFormUpdate() function and then performs an initial validation of the data
in the form.
Functions related to marking data

• spdSetMarkingValue(markingControlId, fvalue)
• spdGetMarkingValue(markingControlId, getInitialValue)
• spdIsMarkingValid(markingControlId)
• spdGetMarkingErrorMsg(markingControlId)

200
These are similar to the functions for accessing field values, but rather than
accessing the fields by name, it accesses them through the markings that have
been set up on the form. When accessed this way, formatting information does
not have to be specified, as that is defined for the marking when it is initialized.
For some dynamically generated controls, the onchange event will contain a call
to the spdSetMarkingValue() function. This will validate the data in the field and
notify any other markings for the same field of the change.
If the marking control is a text box, selection list or button, and it uses one of the
standard class names to indicate it is an optional or required field, the colors of
the text and background indicates the status of the data., as follows:
• Valid data - black on white
• Invalid data - white on bright red
• Required fields that are empty - dark red background
• Optional fields that are empty - dark blue background
If a custom notification is set up for the field, it is called. Also, the
spdFormUpdate() function is called so that calculated validation items and
conditional sections of the form can be properly updated.
Also, the onkeypress event for text boxes calls the spdSetMarkingValue()
function, but will pass the optional parameter indicating that actions should only
be performed if the last key pressed was the Enter key.
Functions related to form validation and submission

• spdFormSubmit(actionName)
• spdSetValidationNotificationFunction(notificationFunction)
In the dynamically generated HTML, the Undo, Keep, and Release buttons are
defined between the area generated for the iProcess Modeler Form and the block
of initialization scripting code. Each of these buttons calls the spdFormSubmit()
function with the appropriate action name: “UndoForm”, “KeepForm”, or
“ReleaseForm”.
You can set up a function that will be called after form validation is performed
(done after any field change). The function should have two parameters. The first
parameter will be true if the “KeepForm” action can be performed, and the
second will be true if “ReleaseForm” can be performed.

File Caching 201
|
During form validation, the Keep and Release buttons will be enabled or
disabled as appropriate, and their appearance will be altered to indicate their
enabled state: the Keep button is disabled if any fields contain invalid data, and
the Release button is disabled if there is invalid data or an empty required field.
To override this default behavior, you can change the id attribute for the buttons
and set up a validation notification function to trigger your own code.
Other Functions
• spdEditMemo(markingControlId, isReadOnly)
• spdShowCalendar(markingControlId, calendarLinkControl)
• spdShowMarkingHelp(markingControlId)
The spdEditMemo() function opens a separate dialog to edit or display a memo
field. The memo will be editable unless you specify true for the optional second
parameter.
The spdShowCalendar() function displays a calendar in the page. The
calendarLinkControl parameter is required, and it should be set to an object that
appears on the form. The calendar selection interface will be displayed next to the
control specified. In the dynamically generated HTML, markings for date fields
are followed by an <a> tag containing a small calendar selection graphic. This <a>
tag is passed in as the calendar line control so the calendar appears to the right of
that.
The spdShowMarkingHelp() function displays the help message defined for the
marking in an alert box. The dynamically generated form only includes a link to
display help if help text exists for that marking.
HTML for Marking Controls

This section describes the types of HTML controls that can be used as marking
controls in a customized form. It describes each of the attributes of the control,
values that can be assigned to those attributes, and the way they are typically set
in the dynamically generated forms that will serve as the starting point for
customizations.
All marking controls must have an id attribute, which uniquely identifies the
marking control. This id is used to reference the control when initializing the
marking, and in calls to other scripting functions. The name assigned in
dynamically generated code is made up of the text “marking_”, plus the field
name. If multiple markings for the same field are defined, a number is appended
to keep the id unique.

202
A name attribute is assigned to each control, but is not actively used. The default
name that is dynamically generated is the text “MARKING$”, plus the field
name.
Text Input Controls

Text input controls are implemented as an HTML <input> element, with the type
of “text”.
The class attribute sets the general appearance. In the dynamically generated
HTML, required markings will have a class of SPD_MARKING_REQ, optional
markings will be SPD_MARKING_OPT, and display markings will be
SPD_MARKING_READONLY.
When these standard class names are used, the text and background color of the
control will change to reflect the status of the data (white on bright red if the data
is invalid, black on white for valid data, a dark red background for blank required
markings, and dark blue background for blank optional markings).
If a different class name is used, the field appearance will not automatically
change based on the status of the data. Custom code could be added, using a field
notification or validation notification function.
The maxlength attribute limits the length of the text that can be entered based on
the field definition, and size will typically be set the same.
The value attribute should be left blank. When the marking is initialized, the
value from the work item will be copied to the control.
The onkeypress and onchange events call the spdSetMarkingValue() function so
that changes made in the text box will be applied to the work item data.
Selection Lists
Selection lists are implemented as an HTML <select> element. These are used for
required and optional markings that have validations items.
The class attribute is typically set to SPD_MARKING_REQ for required fields and
SPD_MARKING_OPT for optional. As with text boxes, the appearance of the
control is automatically changed to indicate the validity of the data if one of these
standard class names is used.
The onchange event will call the spdSetMarkingValue() function so that changes
made to the selection will be applied to the work item data.
Embedded Markings
Embedded markings are implemented as an HTML <span> element.

File Caching 203
|
The class attribute of the <span> tag is typically SPD_MARKING_EMBEDDED.

This can be changed to alter the appearance of the marking without affecting
functionality.
A parameter in the call to initialize the marking indicates whether the field data is
embedded. When it is set to be embedded, the field text is wrapped in an HTML
<pre> tag to preserve all white space. Multiple spaces and line feeds and certain
characters are converted to an equivalent entity character to prevent any field text
from being misinterpreted as HTML or XML.
Memo Markings
Memo markings are displayed as buttons, i.e., HTML <input> elements with a
type attribute of “button”.
The class attribute sets the general appearance. Required memo markings will
typically have a class of SPD_MEMO_BUTTON_REQ, optional memo markings
will be SPD_ MEMO_BUTTON_OPT, and display memo markings will be SPD_
MEMO_BUTTON_READONLY.
The appearance of the buttons will change based on the data for the memo field
when the standard class names are used, similar to text boxes and selection lists.
The value attribute for a button is, of course, used for the button text rather than
data.
The onclick event for the Memo button calls the spdEditMemo() function, which
displays a separate dialog window with the memo text. For read-only Memo
buttons, an extra parameter is passed to this function to disable editing.
Calculated Markings
Calculated markings are rendered identically to display markings. They are
shown as read-only text boxes.
Note that calculations are only performed when the work item is locked at the
server and when the work item is kept or released at the server. If calculations
need to occur in the browser, they will need to be implemented in custom
scripting code.
Hidden Markings
Hidden markings are rendered as an HTML <input> element with the type
“hidden” and simply store a copy of the current data for the marking field.

204
Standard Submit Buttons

The standard buttons for submitting the form use the following values for the id
attribute.
• Undo - “undoButton”
• Keep - “keepButton”
• Release - “releaseButton”
The class for these buttons will typically be “SPD_BUTTON”. This can be
changed without affecting functionality.
The onclick event for the button calls the spdFormSubmit() function with the
appropriate action name.
When form validation is performed, the standard submit buttons are
automatically enabled or disabled, depending on the state of the work item data.
To override this behavior, change the id attribute to another value. Custom
scripting code could then be used to change the state or appearance of the button,
or the buttons could be left enabled at all times and the form validation routines
will prevent submitting the form with invalid data.
Calendar Link
Text boxes for date fields will typically be followed by a link used to display a
calendar for selecting a date.
In the dynamically generated HTML, this will be an HTML <a> tag with an href
attribute set to “#” and an onclick event that calls the spdShowCalendar()
function. Inside the link is a <span> element with a class attribute of
“SPD_CALENDAR” that sets a background image for the span, which is a
calendar selection icon.
This link could be replaced with any HTML for calling the spdShowCalendar()
function.
Help Link
Text boxes that have associated help text will typically be followed by a link for
displaying the help text.
In the dynamically generated HTML, this will be an HTML <a> tag with an href
attribute set to “#” and an onclick event that calls the spdShowMarkingHelp()
function. Inside the link is a <span> element with a class attribute of “SPD_
HELP” that sets a background image for the span, which is a help icon.
This link could be replaced with any HTML for calling the
spdShowMarkingHelp() function.

File Caching 205
|
Field and Form Validation

There are three locations where you might insert custom scripting code to react to
a change in a field value.
• A field notification function, if one has been defined for the changed field.
The field notification is typically set up when something other than a marking
is used to modify the data (e.g., editing data through check box or radio
buttons). Although the function could also be used to trigger actions for one of
the supported marking controls.
• The spdFormUpdate() function, which is required as part of the scripting
code for the form.
The spdFormUpdate() function typically updates the options for selection
lists when those are reference field values or are calculated from a simple
expression. Also, it is used to hide or display conditional sections of the form.
Custom code could also be added to the function.
• A validation notification function, if one has been defined for the form.
The validation notification function is called last, after the default form
validations are performed to determine whether the work item can be kept or
released. Custom code here can override the status determined for keep and
release, or to perform any other actions.
The validation notification function is also called right before the form is
submitted. So even if the function doesn't disable every method of keeping or
releasing the work item, it can still block the actual keep or release. When the
form submit is blocked in this way, an alert box is displayed explaining why.
File-Cached Customization Example

A file-cached customization example is provided in the following directory:
InstallationHomeDir\iprocessorclientbrowser\samples\
IPCBrowserFormExamples


206
This example includes a IPCBrowserExamples.xpdl file, which contains a

sample procedure named SITERATE. It contains three steps.
— INIT - Lets a user enter the basic site information for the site that will be
rated later.
— RATE - Lets a reviewer rate the site and provide comments.
— FINAL - Displays a report on the rating.
The example also includes the following files, which customize the procedure for
display in the iProcess Workspace (Browser). To begin using these customizations,
copy these files into a subdirectory named “htmlcache” under the Action
• common_SITERATE.html
• SITERATE_FINAL.html
• SITERATE_INIT.html
• SITERATE_RATE.html
The following screen shots show the steps of the procedure without the
customizations.
STEP 1: Initial form for data entry

File Caching 207
|
STEP 2: Form for rating the web site
STEP 3: Final report on the web site rating

208
The customized version performs a wide variety of customizations. For example:

• Some of the data entry controls, with sets of radio buttons and check boxes.
• Proportionally spaced fonts are used for all text.
• Custom colors for all elements.
• Tables are used for positioning text and input controls.
• Hyperlinks rather than buttons are used to trigger editing of the memo fields.
• The memo data was added to the page as an embedded marking.
• The web site address is made into a hyperlink that loads the page to be rated
in a separate browser window.
• The submit buttons appear as standard browser buttons.
• The Keep button is omitted on forms where it isn't needed.
• Text for the submit buttons is changed to fit the process rather than using
generic terms.
• A file with header and footer HTML is used to define static content used for
all steps.
Here are the customized forms for these same steps:
STEP 1: Initial form for data entry

File Caching 209
|
STEP 2: Form for rating the web site

210
STEP3: Final report on the web site rating

Common Issues for Embedded and File-Cached Customizations 211
|
Common Issues for Embedded and File-Cached Customizations
You may wish to reference images, JS files, CSS files, or other external files in your
custom HTML code. If you will be using a relative path to access these files, keep
in mind that all paths are relative to the Action Processor installation directory.
Although the file cache for your modified HTML is the subdirectory
“htmlcache”, underneath the Action Processor directory, this is not the base
directory for pages generated using those files as a source for the iProcess
Modeler Form or form header and footer sections for the page.
Therefore, if you store images in the directory “htmlcache\images”, you will
need to use “htmlcache\images” as the relative path to those files in either
embedded or file-cached HTML.
When using a working directory to create and test your file-cached HTML, you
will need to create a copy of any files referenced by relative path to an appropriate
directory under your working directory.

212

| 213
Chapter 11 Displaying Forms Outside of the iProcess

Workspace
This chapter describes an example that is provided in the TIBCO iProcess

Workspace (Browser) that allows you to display iProcess forms outside of the
Topics
• The LinkForm Example, page 214

214
| Chapter 11 Displaying Forms Outside of the iProcess Workspace
The LinkForm Example
An example is provided with the TIBCO iProcess Workspace (Browser) that

allows you to display iProcess forms outside of the TIBCO iProcess Workspace
(Browser).
The LinkForm.html file can be found in the installation home directory:
InstallationHomeDir\iprocessclientbrowser\samples\LinkFormExample
The LinkForm.html file is an example of an intermediary HTML file that can be
used to display an existing work item without running the TIBCO iProcess
Workspace (Browser). Note that this can only be used to display standard iProcess
forms. Those forms can include customizations made by embedding HTML into
the iProcess form definition or made by creating a file-cached copy of the HTML
as described in Customizing iProcess Modeler Forms on page 185. Custom GI
Forms, Form Flow forms, or other external form systems that may be
implemented in the future cannot be displayed in this manner.
Also note that this is a simple HTML example that passes login information
directly through a URL and performs manipulation of the request through
client-side scripting. As such, it does not represent a best practice solution
regarding security. However, the general ideas presented can be used in building
a custom Servlet, JSP, or ASPX page.
The parameters passed in a link to the LinkForm.html file are parsed through
scripting code. The following parameters are supported in the example:
• workitemtag
• nodename
• computername
• ipaddress
• tcpport
• isdirector
• nodealias
• username
• password

The LinkForm Example 215
|
where:
— workitemtag identifies the work item. This is required.
— nodename, computername, ipaddress, tcpport, and isdirector identify the
TIBCO iProcess Objects Server. Either these parameters can be provided to
identify the server, or you can provide the nodealias (see below).
— nodealias identifies the TIBCO iProcess Objects Server. Either this
parameter can be provided to identify the server, or you can provide the
five parameters listed above (nodename, computername, etc.). If a node
alias name is specified, code inside of the LinkForm.html must set the
other five values to identify the iProcess Objects Server.
— username and password provide login credentials. These are optional. If
both are provided, the work item will immediately be displayed. If either
of these is omitted, a login section of the page will be displayed allowing
the user to enter the information. If there is a problem logging in with the
information provided, a message is displayed and it will return to the login
interface. (Note that all parameters are passed to the LinkForm.html file
as part of the URL, so specifying the password in the password parameter
is not advised.)
The URL should be launched using the javascript window.open(...) command, so
the work item will appear in a separate window without browser menus or
toolbars. The following is an example of this command:
window.open('http://myserver/actionprocessor/linkform.html?workite
mtag=myserver|TESTPROC|swadmin|R|4475|19048|myserver|FORM1|0|7@nod
ealias=myserver@username=swadmin', '_blank',
'resizable=1,scrollbars=1');
The following is an example of HTML for a hyperlink displaying the work item:
<a target="_blank" href=""

onclick="window.open('http://myserver/actionprocessor/linkform.htm
l?workitemtag=myserver|TESTPROC|swadmin|R|4475|19048|myserver|FORM
1|0|7@nodealias=myserver@username=swadmin', '_blank',
'resizable=1,scrollbars=1');return false;");">Display work
item</a>

216
| Chapter 11 Displaying Forms Outside of the iProcess Workspace
To use the LinkForm example:

1. Examine the contents of the LinkForm.html file for “TODO” messages and
make the appropriate changes. The “TODO” items are for the following:
— Specifying the appropriate Action Processor name, which will be different
for Java and .NET versions.
— Defining node aliases, which will allow you to pass fewer parameters in the
URL.
2. Save the LinkForm.html file in the Action Processor installation directory.

| 217
Index
A baseUrl attribute 18
Button
Access settings 35
profiles 3
Action Processor
configuration settings 60
URL 18 C
version number 67
Activate Case(s) tool 7 Callout interface 40
Activate, in access profile 7 calloutCaseFilter method 49
Add Entry tool 9 calloutCaseFilterColumns method 50
AddHistoryEntry, in access profile 9 calloutCaseSort method 53
Adding custom menu items / toolbar buttons 36 calloutCaseSortColumns method 53
Admin profile 4 calloutColumns method 54
allowDirectLogin attribute 157 calloutInitialCaseFilter method 49
apAction.xsd 66 calloutInitialCaseSort method 52
apConfig.xml file 60, 130, 131 calloutInitialWorkItemFilter method 46
APLog.logX log file 61 calloutInitialWorkItemSort method 50
APLogXXX.log log file 61 calloutSelectColumns method 56
Application calloutWorkItemFilter method 47
log 12, 21 calloutWorkItemFilterColumns method 47
Monitor 22 calloutWorkItemSort method 51
ApplicationLog, in access profile 12 calloutWorkItemSortColumns method 52
Array fields, requesting values from 114 Caption, customizing 25
ASP Forms 64 captionCases attribute 29
aspx extension 19 captionWorkItems attribute 29
Authenticate/authenticate method 164, 170 Case, in access profile 7
Authentication, single 161 CaseStart, in access profile 6
Authenticator interface 164 ChangePwdExpired, in access profile 12
Auto-Repeat Open Work Item tool 11 ChangePwdOption, in access profile 12
Character encoding 134
CHECKBOX example 192
class attribute 76
B Clearing XML cache data 82
Close
Background colors 35 Case(s) tool 7
Base class 71 Close, in access profile 7
properties 78 closeForm method 82
BaseUrl 156 Color settings 35

218
| Index
Columns, setting defaults 40 doKeep method 100
com.tibco.bpm.ipc.Form 71 doRelease method 101
com.tibco.bpm.ipc.Socket class 100, 101
Compressing XML response 62
ComputerName element 17
config-sample.xml 75 E
confirmUserMessage method 83
Connector element 133, 134 Embedding HTML 188
Controls, marking 190 Encoding 134
Conversions, date 116 ERROR log level 61
createFieldDefsRequest method 84 Examples
createKeepRequest method 88 ASP form 138
createLockRequest method 91 form customizations
createReleaseRequest method 95 embedded 191
CSSCHGS example 195 file-cached 205
Custom form prototypes 69 JSP form 148
Custom menu items, adding 36 single authentication (.NET) 171
customCallout record 45 single authentication (Java) 165
Customer support xi External form URI 64
Customizing ExternalFormURI element 64
caption 25
forms 185
D failureUrl attribute 165, 171

File caching 196
Data tab 10 Filter
DataRead, in access profile 7, 8, 10 dialog default user option 30
DataUpdate, in access profile 7, 8, 10 setting defaults 40
Date conversion methods 116 filter
DEBUG log level 61 element 163
Debugging application 21, 22 filter element 30
Default filters, ,sorts, and columns 40 Filter, in access profile 10, 12
Default profile 4 filterCase attribute 30
description attribute 4 filter-mapping element 163
Direct login 156 filterWorkItems attribute 31
DirectLogin element 158 floatCenter attribute 33
Director element 17 floatFullscreen attribute 33
display element 29 floatHeight attribute 33
Displaying forms outside client 213 floatLeft attribute 33
displayNodeName floatRememberPostion attribute 34
placeholder 26 floatTop attribute 33
doCancel method 98 floatWidth attribute 33
doClose method 99 floatWorkItems attribute 32, 76

Index 219
|
Font settings 35 Host, of Action Processor 18, 167, 168, 174
Form Details button 72 HTML, embedding 188
formCenter option 128 HTTP
FormDateHandler class 116 module 169
FormDetails.xml prototype 72 POST requests 133
formFullscreen option 128 HttpContext object 170
formHeight option 127 HTTPS 60
formLeft option 127
Forms 64
customizing 185
displaying outside client 213 I
element 70
GI 69 IAuthenticator interface 171
FormTemplate.js file 72 Icon settings 35
formTop option 127 IIS
formWidth option 127 session timeout 132
Forward Image settings 35
Work Item(s) tool 11 Implementing, GI Forms interface 73
Forward, in access profile 11 INFO log level 61
ForwardAnyQueue, in access profile 11 init method 102
initialDisplay attribute 29
init-param element 164
Interface, callout 40
G Internet Inter-ORB Protocol (IIOP) 65
IPAddress element 17
General Interface Builder 69 IPCBrowserExamples.xpdl file 191, 206
getAbbrMonthNames method 123 iProcess Modeler 186
getAmPm method 124 IsCompressResponse element 62
getAppPrefValue function 127 IsJRMP element 65
getDirectLoginArgs function 159 isRelease flag 88, 95
GetFieldDefs request 84, 107 IsReturnSSOParams element 63
getFullMonthNames method 125 IsReturnVersion element 67
getNode method 78 IsValidateActionXML element 66
GetXMLResult method 63
GI Forms interface 69
Graphical Case History tool 9
GraphicalHistory, in access profile 9 J
Java
Remote Method Protocol (JRMP) 65
H servlet 19
JNDIEnv element 65
History JSDate conversions 116
tab 9 jsDateToLocal method 120
History, in access profile 9 jsDateToXml method 120

220
| Index
JSP Forms 64 M
jsxid value 77
jsxtext attribute 35 major attribute 76
Jump, in access profile 7 Manager profile 4
Marking controls 190
Maximum POST Size 133
MaxLogFileSize parameter 61
K maxPostSize attribute 133
Memo markings 203
Keep button 100 Menu items, adding custom 36
KeepItems request 88 MENUNAME user attribute 3
minor attribute 76
Modeler, iProcess 186
L
language N
option 127
Language, setting 175 Name element 17, 65
layout element 32 nodeName attribute 76
LinkForm example 214 Nodes, server 15
LoadFactor element 65
LoadingChart, in access profile 6, 10
localeKey attribute 29
localhost 64 O
Localization 175
localToJSDate method 121 onBeforeUnload method 105
localToXml method 121 Open
LockItems request 91, 103 Case(s) tool 9
lockWorkItem method 103 First Available Work Item tool 11
Log settings 61 Next Available Work Item tool 11
LogArchiveCount parameter 61 Selected Work Item(s) tool 11
LogFile parameter 61 Open, in access profile 9, 11
Login Options, user 28, 127
direct 156 outstanding element 34
screen 15, 156, 162 Outstanding tab 9
single authentication 161 Outstanding, in access profile 9
Login record 24, 157
LogLevel parameter 61
Logs, iProcess Client 20
P
Participation
tool 10
Participation, in access profile 10

Index 221
|
Password, changing elements 12 Release, in access profile 11
pattern attribute 26 ReleaseItems request 95
Permissions 3 Remote
plug-in 64 Method Invocation (RMI) 65
Port, used by WAS 19, 167, 168, 174 Request parameters, returning 63
POST size, maximum 133 Requesting values from array fields 114
postLoadInit method 106 Resurrect, in access profile 8
postLoginCaption record 25 Returning request parameters 63
precedence attribute 34
Precedence, sub-procedures 34, 128
Predict
Case tool 9 S
Predict, in access profile 9
previewCase attribute 32 Samples
previewWorkItemsfloating 32 ASP form 138
Procedure form customizations
element 6 embedded 191
Loading Chart tool 6 file-cached 205
Versions tool 6 JSP form 148
Procedure, in access profile 6 single authentication (.NET) 171
Process Jump tool 7 single authentication (Java) 165
procName attribute 76 SCRIPT example 193
ProDef profile 4 Scripts, for custom forms 188
Profile element 4 Secure Sockets Layer 60
Profiles, user access 3 Select Columns tool 7
Properties, in base class 78 SelectColumns, in access profile 7, 8, 9, 10, 11
prototypePath attribute 76 Server
Purge factories 65
Case(s) tool 9 field, on Login dialog 15
Purge, in access profile 9 Info tool 12
nodes 15
server.xml file 133, 134
ServerFactories element 65
R ServerInfo, in access profile 12
serverNodeName 26
RADIOBTN example 193 serverUserAttr attribute 3, 13
readFieldDefs method 107 Servlet, Java 19
Read-only access 7, 8, 10 Session
RecalculateDeadlines, in access profile 8 Activity
recurse attribute 34 Log 20
Redirection tool 10 tool 12
Redirection, in access profile 10 timeout 130
Release SessionActivity, in access profile 12
button 101 sessionState element 132
Work Item(s) tool 11 session-timeout element 130, 131

222
| Index
setAbbrMonthNames method 124 Timeout, session 130
setAmPm method 125 Tomcat
setFullMonthNames method 125 session timeout 130
Show Toolbar buttons, adding custom 36
Case(s) tool 7 transformData method 111
Work Items tool 11 Trigger
ShowErrorDetail, in access profile 12 Events tool 8
showFormDetails function 72 in access profile 8
ShowStackTrace, in access profile 12 type attribute 4
showUserMessage method 109
Single authentication 161
SingleAuthentication record 165, 171
socketRequest method 110 U
Sort, in access profile 10, 12
Sorts, setting default 40 UniqueId element 65
SPD 190 Unlock Work Item(s) tool 11
spddate.js file 189 Unlock, in access profile 11
spdform.js file 189 URI, external form 64
SSL 60 URIEncoding attribute 134
Start New Case tool 6 URL
StartCase request 88, 95 Action Processor 18
stepName attribute 76 direct login 158
Sub-procedure precedence 34, 128 displaying forms from 215
subProcPrecedence option 128 User
Summary tab 9 access profiles 3
Summary, in access profile 9 creating custom 13
Supervisors options 28, 127
in access profile 10 profile 4
tool 10 user.home 61
Support, contacting xi userAccessProfiles.xml file. 3
Suspend useRemember attribute 24
Case(s) tool 8 useRemote attribute 171
in access profile 8 username 26
usernameDesc 26
useSingle attribute 165
UTF-8 134
T
TABFIELD example 194
TABNOFLD example 194 V
TCPPort element 17
Technical support xi Validation, XML 66
this.jsxsuper 100, 101, 102, 106 Version, of Action Processor 67
thresholdCases attribute 30, 31 Versions, in access profile 6
TIBCOActProc directory 19

Index 223
|
W
WARN log level 61
WAS 19, 167, 168
Web Application Server 19, 167, 168
Web.config file 132
web.config file 169
web.xml file 130, 131, 163
WebLogic
session timeout 131
Window layout 127
Work Queue Loading Chart tool 10
WorkItem, in access profile 11
WorkQueue, in access profile 10
X
XML
cache data, clearing 82
date conversions 116
response compression 62
validation 66
xmlToJSDate method 122
xmlToLocal method 122
XSD 66
XSL transform 111

224
| Index

Tib Ip Workspace Browser Config

Uploaded by

Tib Ip Workspace Browser Config

Uploaded by

TIBCO iProcess™ Workspace (Browser)

Configuration and Customization

Chapter 1 Configuring the iProcess Workspace (Browser) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2 Configuring the Action Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

TIBCO iProcess Workspace (Browser) Configuration and Customization

Chapter 3 GI Forms Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

TIBCO iProcess Workspace (Browser) Configuration and Customization

Chapter 4 Application Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Chapter 5 ASP Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Chapter 6 JSP Forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Chapter 7 Direct Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Chapter 8 Single Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Chapter 9 Localization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

TIBCO iProcess Workspace (Browser) Configuration and Customization

Chapter 10 Customizing iProcess Modeler Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Chapter 11 Displaying Forms Outside of the iProcess Workspace. . . . . . . . . . . . . . . . . . . . . 213

TIBCO iProcess Workspace (Browser) Configuration and Customization

• Configurations and Customizations, page vi

TIBCO iProcess Workspace (Browser) Configuration and Customization

Configurations and Customizations

TIBCO iProcess Workspace (Browser) Configuration and Customization

TIBCO iProcess Workspace (Browser) Configuration and Customization

• Localization - This chapter describes how to add a language resource file to

TIBCO iProcess Workspace (Browser) Configuration and Customization

This section lists documentation resources you may find useful.

TIBCO iProcess Workspace (Browser) Documentation

TIBCO iProcess Workspace (Browser) Configuration and Customization

Other TIBCO Documentation

TIBCO iProcess Workspace (Browser) Configuration and Customization

How to Contact TIBCO Support

TIBCO iProcess Workspace (Browser) Configuration and Customization

TIBCO iProcess Workspace (Browser) Configuration and Customization

Chapter 1 Configuring the iProcess Workspace

• User Access Profiles, page 3

TIBCO iProcess Workspace (Browser) Configuration and Customization

where WorkspaceDir is the directory that was designated as your workspace

TIBCO iProcess Workspace (Browser) Configuration and Customization

User Access Profiles

TIBCO iProcess Workspace (Browser) Configuration and Customization

TIBCO iProcess Workspace (Browser) Configuration and Customization

Each <Profile/> element contains subordinate <property/> elements, each of

If access to a function is not allowed, the applicable buttons and/or menu

TIBCO iProcess Workspace (Browser) Configuration and Customization

Using a Single Profile for Multiple User Types

Access Profile ‘name’ Attributes

name Attribute Value Parent Meaning Description

Versions Procedure Procedure Versions Provides access to the Procedure

LoadingChart Procedure Procedure Loading Provides access to the Procedure

CaseStart Procedure Case Start Provides access to the Start New

TIBCO iProcess Workspace (Browser) Configuration and Customization

name Attribute Value Parent Meaning Description

SelectColumns Procedure Procedure Column Provides access to the Select

Activate Procedure Case Activate Provides access to the Activate

Close Procedure Case Close Provides access to the Close

Jump Procedure Process Jump Provides access to the Process

DataRead Procedure Process Jump Data Provides read-only access to

DataUpdate Procedure Process Jump Data Provides update access to Case

TIBCO iProcess Workspace (Browser) Configuration and Customization

name Attribute Value Parent Meaning Description

Suspend Procedure Case Suspend Provides access to the Suspend

Trigger Procedure Trigger Event Provides access to the Trigger

DataRead Procedure Trigger Event Data Provides read-only access to

DataUpdate Procedure Trigger Event Data Provides update access to Case

Resurrect Procedure Case Resurrection Provides access to the Trigger

RecalculateDeadlines Procedure Case Deadlines Provides access to the

TIBCO iProcess Workspace (Browser) Configuration and Customization

name Attribute Value Parent Meaning Description

Open Procedure Case Open Provides access to the Open

Summary Procedure Case Summary Provides access to the case

History Procedure Case History Provides access to the case

Predict Procedure Case Predict Provides access to the Predict

GraphicalHistory Procedure Case Graphical Provides access to the Graphical

Outstanding Procedure Case Outstanding Provides access to the case

SelectColumns Procedure Case Outstanding Provides access to the Select

TIBCO iProcess Workspace (Browser) Configuration and Customization

name Attribute Value Parent Meaning Description