Browse Prior Art Database

Optimized steps for flows controlling dialogues Disclosure Number: IPCOM000010835D
Original Publication Date: 2003-Jan-24
Included in the Prior Art Database: 2003-Jan-24
Document File: 3 page(s) / 519K

Publishing Venue



In this article, we show how the efficiency of dialog handling through a workflow engine can be significantly improved through the introduction of a special activity type dealing with dialog steps. The introduction of this activity allows to reduce the number of transactions and possibly needed poll cycles.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 3

Optimized steps for flows controlling dialogues

The problem: Inefficiencies implementing dialogue flows using a state-of-the-art flow engine It is state of the art that flow engines support different types of activities, e.g., automatic activities invoking back-end functions, people-based activities involving people into a flow via work-items generated to a work-list, and others.

    Using those constructs, it is possible, but cumbersome, to create a dialogue flow. Figure 1 shows how a dialogue flow might look like.

  p not p

Figure 1: Dialogue flow

    This figure shows a flow consisting of activities implemented by automatic backend functions (shown in green), and of activities facing people (shown in yellow). People-facing activities refer to the necessary GUI rendering information, like descriptions of the panels, forms and other artifacts to be displayed on the screen, which can be created separately. For usage in a dialogue, the modeler must adhere to the convention that all people-facing activities are performed by the very person that initiated the flow.

    It is desirable to use flows to describe dialogues, as this provides greater flexibility in their design. Also, as state-of-the-art flow engines provide for recoverable execution of flows, which survive system crashes, this implementation provides for recoverable dialogues, where the dialogue can continue exactly where it was left, even after a system crash.

The usage of this flow for controlling a dialogue is shown in figure 2.


not p

Flow engine

Spawn flow Query work-item Claim activity

Query work-item


Complete act. Query work-item Claim activity

Query work-item

screenGet first screen Response Get next Response Get next screen Response Get next screen Response



Complete act. Query work-item Claim activity

Query work-item

...Complete act. Query work-item Query work-item

GUI controller

Figure 2: Dialogue flow using state-of-the-art flow engine. In this scenario, condition p evaluates to true, so the lower left path of the flow is skipped.

[This page contains 2 pictures or other non-text objects]

Page 2 of 3

    As can be seen, the GUI controller component (realized, e.g., by a servlet) not only has to rely on the modeling conventions, but has to create a poll loop, querying for new work-items while the flow engine continues execution of the flow, until a work item for the same flow is received and the associated data can be displayed as the next dialogue panel. That poll loop gets even worse at the end of the flow, because the end of the flow has to be detected either by intermixing flow instance queries, or by providing a time-out. Thus, using a state-of-the-art flow engine to drive dialogues this way is possible, but cumbersome, error-prone and inefficient.

The solution: Provision of dialog st...