Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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: ToolsSubmitting 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: ToolsSubmitting FormsSubmit Options It is useful to disable the save options: ToolsForm OptionsOpen and SaveUncheck ‘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