Siebel Business Process Framework: Workflow Guide > About Workflow Process Design Options > About the Workflow Mode Property >

Defining an Interactive Workflow Process

This topic includes the following topics:

• About the Synthetic Event
• About Suspending and Resuming an Interactive Workflow Process

When you define an interactive workflow process, the tasks you perform include:

• Set the Workflow Mode property of the workflow process object definition to Interactive Flow.
• Set the Auto Persist flag for interactive flows that must be persisted.
• Configure business components and applets by adding buttons to applets to make use of the synthetic event that controls user navigation of a workflow process.

About the Synthetic Event

A synthetic event is a specialized run-time event that is dedicated to controlling workflow navigation. To control the way a user navigates through the Siebel application, you can create a button on an applet within a view then associate the synthetic event with the button.

For example, in the Account Note view of the Siebel application you are configuring, there is an Account Entry Applet on which you need to include buttons for Back, Next, and SaveWorkflow synthetic events. These buttons allow the user to move forward or backward from the Account Note view, or to suspend an interactive workflow process then return later to resume the workflow.

After you have created the buttons, you associate methods within the interactive workflow process. For example, with Back and Next synthetic events, you associate methods to outgoing connectors on the User Interact step. You set the synthetic event method name in the MethodInvoked property of the button controls.

About Forward and Backward Navigation Between Views

You can use a synthetic event to define an interactive workflow process so that when the user clicks the Next or Back button, the user is taken to the next or previous view in the sequence without losing the context of the process instance.

NOTE:  Use a synthetic event to allow the user to navigate backward through views. Run-time events allow forward navigation, but not backward navigation.

Requirements that must be met for a workflow process to navigate back and forth include:

• The workflow being resumed must be an interactive workflow process or a 7.0 workflow process.
• The triggering event must be a workflow navigation event, that is, an event with a name such as InvokeMethod, and a sub-event with a name such as FrameEventMethodWFBFxxxx or EventMethodWFBFxxxx, where "xxxx" is the name of the event, such as Next.

Table 25 describes backward and forward navigation availability for workflow modes.

Considerations to weigh when deciding whether to allow backward navigation in your workflow process include:

• The backward navigation feature does not undo the effect of the workflow process. Backward navigation only modifies the current step counter to point to a previous step.
• The workflow configuration must make sure the segment of the workflow that can be repeated by the backward navigation feature is idempotent. That is, acts as if used only once, even if used multiple times.

Description of Synthetic Event Methods

Table 26 describes synthetic event methods.

Procedures for Creating Synthetic Events

This topic describes procedures for creating synthetic events.

To create a synthetic event button for next and back events

1. In Siebel Tools, identify a view to which a User Interact step navigates the user.
2. Configure a Next button or a Back button on an applet where the event is triggered. For more information, see Using Siebel Tools.

   The button must be exposed in the applet that is based on the primary business component associated with the business object defined for the workflow process. For example, if the workflow process is based on the Service Request business object, and if the view displays Service Request Activities records, then the button must be exposed in the applet based on the Service Request business component. In this example, the synthetic event button does not work if the button is exposed in the applet based on the Activities business component.

3. Specify the MethodInvoked property of the button control as the name of the associated event. For example, FrameEventMethodWFBack for backward navigation.
4. In the Process Designer, associate the applet type run-time event.

   For example, assign FrameEventMethodWFBack to the outgoing connectors of the User Interact step in the workflow process that receives the event. Assign the event using values described in the following table:

   Property	Value
   Event Type	Applet
   Event Obj	AppletName
   Event	InvokeMethod
   Sub Event	[Method Name] For example, FrameEventMethodWFBack.

TIP:   You do not have to manually create buttons for each applet. You can copy a button you have created to other applets by using the Applet Comparison capability in Siebel Tools. Also, if you add the applet button controls to the HTML Model Controls applet, when you create new applets with the New Applet Wizard or the conversion process, you can then choose the Workflow related method buttons.

To create a synthetic event button for the saveworkflow event

1. In Siebel Tools, identify a view to which a User Interact step navigates the user.
2. Configure a Save button on an applet where the event is triggered. For more information, see Using Siebel Tools.
3. Specify the MethodInvoked property of the button control as the name of the associated event, SaveWorkflow.
4. Use the script below to invoke the Workflow event handler to handle the button click event. The script also passes to the Workflow event handler the event's contextual information, which is the name of the view where the event occurs.

   Note that it is not necessary for you to define the event in the workflow process definition.

   function WebApplet_InvokeMethod (MethodName)

   {

   return (ContinueOperation);

   }

   function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke)

   {

   // Recognize SaveWorkflow event, which is

   // used to save Interactive flow

   if (MethodName == "SaveWorkflow")

   {

   CanInvoke = "TRUE";

   return (CancelOperation);

   }

   return (ContinueOperation);

   }

   function WebApplet_PreInvokeMethod (MethodName)

   {

   // Handle SaveWorkflow event.

   // Call Workflow Process Manager to save the interactive

   // flow(s) that is waiting in the current view.

   if (MethodName == "SaveWorkflow")

   {

   var Inputs = TheApplication().NewPropertySet();

   var Outputs = TheApplication().NewPropertySet();

   // Event name ("SaveWorkflow"), view name, and the rowId

   // of the active row of the underlying buscomp are

   // three required parameters for handling the event

   Inputs.SetProperty("Event Name", MethodName);

   var viewName = TheApplication().ActiveViewName();

   Inputs.SetProperty("Sub Event", viewName);

   var bc = BusComp ();

   var bcId = bc.GetFieldValue ("Id");

   Inputs.SetProperty("RowId", bcId);

   var workflowSvc = TheApplication().GetService("Workflow Process Manager");

   workflowSvc.InvokeMethod("_HandleSpecialEvent", Inputs, Outputs);

   return (CancelOperation);

   }

   return (ContinueOperation);

   }

To create a synthetic event button for the resumelastintflow event

1. In Siebel Tools, identify a view to which a User Interact step navigates the user.
2. Configure a Resume button on an applet where the event is triggered. For more information, see Using Siebel Tools.
3. Specify the MethodInvoked property of the button control as the name of the associated event, ResumeLastIntFlow.
4. Use the script below to invoke the Workflow event handler to handle the button click event. The script also passes to the Workflow event handler the event's contextual information, which is the name of the view where the event occurs.

   Note that it is not necessary for you to define the event in the workflow process definition.

   function WebApplet_InvokeMethod (MethodName)

   {

   return (ContinueOperation);

   }

   function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke)

   {

   if (MethodName == "ResumeLastIntFlow")

   {

   CanInvoke = "TRUE";

   return (CancelOperation);

   }

   return (ContinueOperation);

   }

   function WebApplet_PreInvokeMethod (MethodName)

   {

   // Call Workflow Process Manager to resume the last-executed interactive flow

   if (MethodName == "ResumeLastIntFlow")

   {

   var Inputs = TheApplication().NewPropertySet();

   var Outputs = TheApplication().NewPropertySet();

   var workflowSvc = TheApplication().GetService("Workflow Process Manager");

   workflowSvc.InvokeMethod("_ResumeLastInteractFlow", Inputs, Outputs);

   return (CancelOperation);

   }

   return (ContinueOperation);

About Suspending and Resuming an Interactive Workflow Process

An interactive workflow process that is suspended can be resumed from within the user's Inbox. The user can navigate out of an interactive process, then navigate back into the workflow process and continue where the user suspended the workflow.

For example, assume a transaction involving the user, an insurance agent, cannot be finished because some information is missing, such as a spouse's social security number which is required for an insurance policy quote to be considered finished. In this example, when the insurance agent eventually obtains the social security number after suspending the interactive workflow process, the insurance agent can resume the process from within the Inbox, then enter the social security number to finish the entry of the quote. Once the process is finished, the Workflow engine removes the interactive workflow process from the Inbox.

A suspended interactive workflow is placed in the workflow owner's Inbox for tracking and explicit resumption.

Table 27 describes actions taken when a workflow is suspended.

Considerations to weigh include:

• To realize the behavior described in Table 27, the suspended workflow must have its Auto Persist flag checked.
• A suspended interactive workflow in the Inbox is removed from the Inbox when the workflow has run to its end and terminates.

Suspending a Workflow Compared to Persisting a Workflow

There is a difference between suspending a workflow and persisting a workflow. When a workflow is suspended, it can be persisted, but only when the workflow's Auto Persist flag is set to TRUE.

For example, with implicit suspension, if a user leaves a view the workflow took the user to, the workflow instance is saved in the in-memory cache. In this case, no Inbox item is generated. When the user logs out, Inbox items are generated for workflows in the cache that have the Auto Persist flag set to TRUE. So the Inbox items are visible only when the user logs out then logs back in.

In-Memory Cache of a Suspended Interactive Workflow

A user often navigates out of a structured interactive workflow because the workflow is set up to address your specific business needs. When this happens, the interactive workflow remains in memory so it can be resumed later in the same user session. As it is uncommon for a user to have a large number of unfinished tasks at hand, there can be a maximum of eight suspended interactive workflow instances in the memory cache.

This eight instance limit applies to an individual user session. The limit is eight instances total for interactive workflows initiated from within the user session, not eight instances for each interactive workflow. This eight instance limit is not configurable.

The user session is one connection on the Application Object Manager component, regardless of whether this thread is logged as a single user. When the eight instance limit is reached, new interactive workflows are not prevented from running. Instead, if the user initiates another interactive workflow after eight instances are already cached in memory, and this ninth instance must be saved to the cache, then the oldest instance is pushed into the database if the workflow's AutoPersist flag is set, or dropped as the memory cache has reached the cache's limit.

Event Handling With a Suspended Interactive Workflow

Workflow handles events in the following sequence:

1. Checks the in-memory cache to see if there are workflow instances in the cache that can receive an event, using the matching criteria specified by the event.
2. Checks the database to see if there are persisted workflow instances that can receive an event.
3. Resumes instances found in Step 1 and Step 2.

Detection and Handling of the User Logout Event for a Suspended Interactive Workflow Process

Upon receiving the user logout event, the Workflow engine goes through suspended interactive workflows in the in-memory cache. Workflows with the Auto Persist flag checked are saved as Inbox items. Other workflows are deleted.