Download Yasper/Infopath user manual

Yasper/InfoPath
User Manual
covers YasperWE version 1.1 (January, 2006)
about
Author
Version
Subject
Title
Last update
Last update by
this document
Reinier Post
1.1
YasperWE server installation
Deployment Manual
Feb 21, 2006
Reinier Post
OVERVIEW ......................................................................................................................................................2
DESIGNING A SYSTEM ......................................................................................................................................2
ADMINISTERING A SYSTEM ..............................................................................................................................3
EXECUTING A SYSTEM .....................................................................................................................................3
DESIGN REQUIREMENTS FOR A YASPER/INFOPATH WORKFLOW DEFINITION.....................5
SPECIAL REQUIREMENTS ON THE YASPER MODEL ...........................................................................................5
SPECIAL REQUIREMENTS ON THE INFOPATH SOLUTION ...................................................................................8
REGISTERING AND STARTING A PROJECT WITH THE ADMIN PROJECT CONTROL ...........13
SELECTING AND EXECUTING TASKS WITH THE CLIENT TASK CONTROL ............................15
MONITORING AND DEBUGGING A RUNNING PROCESS .................................................................16
Page 1 of 16
Overview
Designing a system
In this document, we focus on the operational details of how to use the YasperWE software.
For an explanation of how to actually design a working YasperWE application, with
examples, see the accompanying document Handleiding YasperWE en Infopath (in Dutch).
A complete YasperWE application consists of three files:
Yasper is used to specify the process flow of the workflow
system.
If a global database is used, SQL queries are also specified
within Yasper’s transitions. These queries are used to mix
global data with the case-specific data defined in InfoPath.
InfoPath is used in design mode to specify forms handling.
Every task that requires user interaction gets an associated
form in the InfoPath solution. All the data displayed and
edited by the forms is also defined here.
A MySQL database creation script must be supplied to
specify the structure and (optionally) initial contents of a
global database, used by all cases in the workflow. If no
global database is used, use an empty file.
Yasper
.pnml
InfoPath
.xsn
e.g. Visio
2000
Enterprise
.sql
In order to be able to write queries in the Yasper transitions, it is necessary to know how
the InfoPath data map to a MySQL database structure. An auxiliary tool is distributed with
the Yasper clients that raeads an InfoPath solution file and displays this structure in the
form of a MySQL create script:
Page 2 of 16
Administering a system
A finished workflow design must be uploaded into the workflow execution engine,
YasperWE, before it can be deployed. An uploaded design is called a project.
This can, of course, only succeed if a YasperWE server is installed and available on a
server somewhere.
The software to administer processes is called the Admin Project Control. It is not only
used to upload project definitions to the YasperWE server, but also to start and stop
running workflow processes for the projects available.
For a description of working with the Admin Project Control, see page 13.
Executing a system
When a workflow process instance is started, its Yasper model will start executing within
the server, determining at all times which tasks are available for which users, while its
InfoPath solution will be used to communicate with workflow clients (users who can
execute tasks in the workflow).
Workflow clients run a tool called the Client Task Control, which communicates with a
running workflow process on the YasperWE server. It can list the tasks available for the
user and allows the user to pick one of them. Once a task is picked, the user is presented
with an InfoPath form, defined in the InfoPath solution that is part of the project definition.
For a description of working with the Client Task Control, see page 15.
Page 3 of 16
This figure shows the main components and the way these components
are related to each other.
Page 4 of 16
Design requirements for a Yasper/InfoPath workflow
definition
Special requirements on the Yasper model
Roles are used within Yasper to indicate user interaction. Every role name used in the
Yasper model can be used to log in to its project instance with the Client Task Control.
When a role is assigned to a transition, the corresponding user can pick and execute tasks
for that transition in the Client Task Control.
This figure illustrates how the
Client Task Control’s login is
linked to Yasper’s roles.
This figure illustrates how the
roles are linked with
transitions in Yasper.
The InfoPath solution contains a set of forms (a form is called a “view” in InfoPath). For
every transition to which one or more roles are assigned, a corresponding view must be
defined in the InfoPath solution.
While the roles indicate which users can perform which tasks, they do not indicate which
view must be presented for which transition. The correspondence must be defined in
Yasper by entering the view name as the description of the transition.
Page 5 of 16
This figure illustrates how the name and description of the transitions that are defined in
Yasper relate to the Client Task Control’s task list and the InfoPath Solution’s rules for
opening Forms.
Not every possible Yasper process can be used as a workflow: there are some constraints:

(as remarked:) Every transition with one or more roles must carry the name of an
InfoPath view in its description.

Every emitor must be associated with one or more roles (and, therefore, also with a
view).

Transitions without roles are allowed; they will execute automatically without user
interaction. These transitions must NOT have a view assigned to them in their
descriptions.

Every interactive transition (i.e. with one or more roles) must be case sensitive, that
is, with a case sensitive input and/or output place.

The workflow defined must be sound, since the YasperWE server has no provisions
for recognizing processes that execute indefinitely.
A choice (XOR, diamond) can be used to model choice by the user, as follows.
The view assigned to the choice transition must have a control element with the names of
the output places of the choice as its possible values. The YasperWE engine will read the
result and use it to continue in the selected output place:
Page 6 of 16
This figure illustrates how the choice is passed form an InfoPath Form, as defined in the
InfoPath Solution to YasperWE that has to process the form according to the defined net.
Page 7 of 16
Special requirements on the InfoPath solution
Data source
When defining the data source in InfoPath Design Mode, attributes
cannot be used.
Furthermore, the following fields must be defined:




viewname
(used by InfoPath to determine the view being used)
taskid
(used by YasperWE to identify the task being executed)
runinstanceid
(used by YasperWE to identify the workflow process being
executed)
choice
(used by YasperWE to retrieve a choice for XOR elements)
Views dealing with choice transitions must write the name of an output
place to choose into the choice field. The other three fields mentioned
above must never be altered by the InfoPath views; they are used by the
YasperWE server to identify the task that the form belongs to.
Displaying them is allowed.
Page 8 of 16
Opening the right form
Usually, the InfoPath solution contains multiple views (forms); InfoPath must be told to
start up the right view for the right transition.
This is done by specifying rules, one per view. Open Tools  Form Options  Open
and Save  Rules … and click Add …,
then set the rule’s condition to match the viewname:
and as the rules’ action, specify to switch to the view in question:
Page 9 of 16
Page 10 of 16
Submitting to YasperWE
When a form is completed, it is submitted to a
YasperWE web service. This is configured
within the InfoPath Solution as follows:
ToolsSubmitting Forms
Submit to: Web service
Add…
Step 1
Step 2
Page 11 of 16
Step 3
In order to improve the usability of the YasperWE project, the submit options are best
configured as follows:
ToolsSubmitting FormsSubmit Options
It is useful to disable the save options:
ToolsForm OptionsOpen and SaveUncheck ‘Save and Save As’.
Page 12 of 16
Registering and starting a project with the Admin Project
Control
To upload a new project design into the server, start the Admin Project Control, and click
Create a new Project Type. Specify the InfoPath solution, the Petri net, and the global
database creation script. Give the project type a name and click on Create Project Type.
Uploading a designed project
To see whether the operation succeeded, wait a few seconds (it may take a while), then
click on Get the list of Project Types and see if the new project type name is listed.
To start a Project Type, click on Get the list of Project Types. Wait until the project types
appear. Select the desired project type. Enter a name (just above the Start a new Project
Instance button) and click on that button. Use the Download Project Type Definitions
button to download the files that make up the project type.
Starting an instance of a project
Click the Get the List of the currently running Project Instances button to get the list of
project instances that have been started and are still running. In order to stop a project
Page 13 of 16
instance, the project instance to be stopped can be selected followed by a click on the “Stop
Project Instance” button. Via the “Download Project Instance Data” button, all data
belonging to the project instance are downloaded. These are all XML files, referring to the
project type’s InfoPath Solution.
Error handling is not a strong point in the present version: you will not see any explicit
error messages when anything goes wrong. For example, if after uploading a project type
or starting a project instance, waiting about 10 seconds, and refreshing the list, the new
project type of instance does not appear in the list, you have to assume there was some kind
of problem that caused its creation to fail.
A note on configuration: the Admin Project Control connects to the YasperWE server
specified in its configuration file; by default,
C:\Program Files\ASPT\YasperWEClients\AdminProjectControl.exe.config
If the YasperWE server is not installed in the default location, or runs on a different
computer, adjust its location in this file before starting it.
Page 14 of 16
Selecting and executing tasks with the Client Task
Control
End users can start the Client Task Control and log in as a role to the desired project
(instance). Currently a password is not required. Enter the role name in the Role field. The
dropdown from the Project field contains all running project instances from the YasperWE
instance (Typically, all project instances running on the server). Select the desired project
and click on Sign In.
Logging in to a project instance via the Client Task Control
Note that the server doesn’t check whether the username specified actually exists. For
example, if the project defines a role All and you sign in as all, the signin will be successful,
but you will never see any tasks listed, not even the ones for All, because role names are
case sensitive.
After signing in, a click on Get Task List will display all tasks presently available for the
user (role). Select a task and click Pick Task to start execution of that task. This may fail
(do nothing), in case some other user has already picked it. If it is successful, the Client
Task Control will prepare the data to use in InfoPath (an XML file) and invoke InfoPath on
it.
In InfoPath, the user can complete the form and click on the Submit button. This will send
the data back to the YasperWE server for processing. After both picking a task and
completing a form, the task list will change. Click on Get Task List for the new task list.
Clicking Automatic Task List button will keep the task list up to date automatically – but be
cautious with this feature: in models where very many tasks can be active at the same time,
this might cause the Client Task Control to hang or to overload the YasperWE server.
A note on configuration: the Client Task Control connects to the YasperWE server
specified in its configuration file; by default,
C:\Program Files\ASPT\YasperWEClients\ClientTaskControl.exe.config
If the YasperWE server is not installed in the default location, or runs on a different
computer, adjust its location in this file before starting it.
Page 15 of 16
Monitoring and debugging a running process
Special monitoring and debugging software is not part of YasperWE yet. Logging
information gets written to the log table in YasperWE’s working database.
Techniques for debugging are described in the more extensive YasperWE manual:
YasperWE en Infopath (in Dutch).
Page 16 of 16