Pageflow Process Modeling
A pageflow process is a short-lived process designed to present user interface pages to the user in sequence. They are always executed by one person (the person that initiates the process instance).
All tasks that are available in a business process are available within a pageflow process with the exception of a business process user task. Pageflow processes have a special variant of a business process user task that does not have participants, and does not generate work items. These are referred to as pageflow user tasks.
A pageflow process is stored under the Processes branch of the Project Explorer alongside business processes.
For example:
In this example, the user is presented with the user interface page (in this case a form created using TIBCO Business Studio Forms) associated with pageflow user task one. When the form is submitted, the service task runs. When the service task is completed, and the user interface page associated with user task 2 is displayed. The user is not aware of the service task, and sees one form followed directly by the next one.
A user task in a pageflow process differs from a user task in a business process in several key respects:
- Pageflow user tasks do not have participants assigned to them (this is because the user who initiates the process instance completes all the tasks in the pageflow process).
- Pageflow processes cannot contain lanes or pools.
- Pageflow user tasks do not create work items. The user interface pages are presented to the user without them needing to access their work queue.
- Pageflow user tasks do not restrict the type of technology used to create the user interface page that is displayed. For example, you could use TIBCO Business Studio Forms or a different technology. This allows the same process to be deployed to several runtime environments that utilize different user interface display technologies.
There are also special considerations to observe when using pageflows, specifically:
- Pageflow processes are not persistent (if the user cancels out of a pageflow process, data entered to that point is lost).
- Pageflow processes are not audited.
- Pageflow processes are not transactional (for example, there is no provision to roll back changes if a service task fails). If transactional control is required, chaining might be a better choice than a pageflow process (see "Creating a New Embedded Sub-Process" in the TIBCO Business Studio Modeling Guide).
- Deployed pageflows are held in memory, and in some cases, having pageflows in different XPDL package files or in different Applications can result in errors. This is because one pageflow is available sooner than another dependent pageflow which may not have loaded yet.