Create single Activity Instance for Queue

2 years ago
24 February 2022
0 replies
9 views

Userlevel 3

CodiKaji
Nintex Employee
12 replies

Create single Activity Instance for Queue

KB000155

PRODUCT

K2.net 2003

TAGS

Active Directory

Deployment

Microsoft InfoPath

LEGACY/ARCHIVED CONTENT

This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.

K2.net 2003 with SP3 introduces an enhancement around Destination Queue user management at runtime. Currently in K2.net we have scenarios where Destination Queues resolve to large number of users creating a huge overhead on K2.net Server having to manage the activity instances representing the worklist items.

Introduction

K2.net 2003 with SP3 introduces an enhancement for Destination Queue user management at runtime. Currently in K2.net scenarios exist where Destination Queues resolve to multiple user groups which may be large depending on the number of users. This increases the operational overhead on K2.net Server because the activity instances representing the worklist items need to be managed. Currently K2.net Server creates an activity instance for each user belonging to the destination queue. The new feature, which is enabled at design time, has been added to the Destination Rules to force K2.net Server to create a single instance of the Activity shared by the user part of the destination queue. The new functionality is especially applicable for implementations where destination queues consist of many users and only one user is required to complete the task; which is commonly seen in Call centre environments.

A number of design considerations are required to implement this function properly as well as understanding the impact this might have on your current design.

Using the "Create single Activity Instance for Queue" option affects the following:

Activity Slots
Succeeding Rules
Line Rules
Email notifications (Client Events and Server Mail Events)

Enabling the "Create single Activity Instance for Queue" option:

The "Create single Activity Instance for Queue" option will only be available when the configured Destination Rule contains a Destination Queue

Create single Activity Instance for Queue - Disabled

Create single Activity Instance for Queue - Enabled

Runtime behavior

To fully understand the concept of "Create single Activity Instance for Queue" lets consider the runtime behavior of the K2.net Server when the option is enabled versus being disabled. The following section looks at various scenarios to illustrate how the feature works.

The affect that "Create single Activity Instance for Queue" has on Activity Instances (Slots)

The table below lists a number of scenarios including the outcome for the configuration. The scenarios are based on common example implementations and should be considered during the configuration of Destination Rules, Succeeding Rules, Line Rules and Activity Slots.

Assumptions:

Call Center Queue - This Destination Queue resolves to 10 unique users
Sales Queue - This Destination Queue resolves to 10 unique users

Maximum number of Activity Instance (Slots) available during runtime: 10

Maximum number of Activity Instance (Slots) available during runtime: 1

Maximum number of Activity Instance (Slots) available during runtime: 13

Maximum number of Activity Instance (Slots) available during runtime: 4

Maximum number of Activity Instance (Slots) available during runtime: 20

Maximum number of Activity Instance (Slots) available during runtime: 2

The effect that "Create single Activity Instance for Queue" has on the behavior of Worklist item interaction

The management of the "Status" of a Worklist item is also affected by the use of this function, the following examples illustrates the expected behavior.

Scenario 1:

Assumptions:

Call Center Queue - This Destination Queue resolves to 3 unique users (Bob, John and Mandy)
Create single Activity Instance for Queue - Enabled
Activity Slots - 3

1. Initial Status of Items		2. Emile opened his Item
Christo Emile Jaco Bob John Mandy	Available Available Available Available Available Available	Christo Emile Jaco Bob John Mandy	Available Open Available Available Available Available
3. Christo opened his item		4. Jaco opened his item
Christo Emile Jaco Bob John Mandy	Open Open Available Available Available Available	Christo Emile Jaco Bob John Mandy	Open Open Open Allocated Allocated Allocated

Scenario 2:
Assumptions:
Call Center Queue - This Destination Queue resolves to 3 unique users (Bob, John and Mandy) Create single Activity Instance for Queue - Enabled Activity Slots - 3

1. Initial Status of Items		2. John opened his Item
Christo Emile Jaco Bob John Mandy	Available Available Available Available Available Available	Christo Emile Jaco Bob John Mandy	Available Available Available Allocated Open Allocated
3. Emile opened his item		4. Jaco opened his item
Christo Emile Jaco Bob John Mandy	Available Open Available Allocated Open Allocated	Christo Emile Jaco Bob John Mandy	Allocated Open Open Allocated Open Allocated

Scenario 3:
Assumptions:
Call Center Queue - This Destination Queue resolves to 3 unique users (Bob, John and Mandy) Sales Queue - This Destination Queue resolves to 3 unique users (Sheri, Brian and Joe) Create single Activity Instance for Queue - Enabled Activity Slots - 3

1. Initial Status of Items		2. Sheri opened her item
Christo Emile Jaco Bob John Mandy Brian Joe Sheri	Available Available Available Available Available Available Available Available Available	Christo Emile Jaco Bob John Mandy Brian Joe Sheri	Available Available Available Available Available Available Allocated Allocated Open
3. Bob opened his item		4. Jaco opened his item
Christo Emile Jaco Bob John Mandy Brian Joe Sheri	Available Available Available Open Allocated Allocated Allocated Allocated Open	Christo Emile Jaco Bob John Mandy Brian Joe Sheri	Allocated Allocated Open Open Allocated Allocated Allocated Allocated Open

Scenario 4:
Assumptions:
Call Center Queue - This Destination Queue resolves to 3 unique users (Bob, John and Mandy) Sales Queue - This Destination Queue resolves to 3 unique users (Sheri, Brian and Joe) Create single Activity Instance for Queue - Enabled Activity Slots - 3

1. Initial Status of Items		2. Christo opened his Item
Christo Emile Jaco Bob John Mandy Brian Joe Sheri	Available Available Available Available Available Available Available Available Available	Christo Emile Jaco Bob John Mandy Brian Joe Sheri	Open Available Available Available Available Available Available Available Available
3. Emile opened his item		4. Jaco opened his item
Christo Emile Jaco Bob John Mandy Brian Joe Sheri	Open Open Available Available Available Available Available Available Available	Christo Emile Jaco Bob John Mandy Brian Joe Sheri	Open Open Open Allocated Allocated Allocated Allocated Allocated Allocated

Scenario 5:
Assumptions:
Call Center Queue - This Destination Queue resolves to 6 unique users (Bob, John, Mandy, Brian, Joe and Sheri) Create single Activity Instance for Queue - Enabled Activity Slots - 3

	1. Initial Status of Items		2. Joe opened his Item
	Bob John Mandy Brian Joe Sheri	Available Available Available Available Available Available	Bob John Mandy Brian Joe Sheri	Allocated Allocated Allocated Open Allocated Allocated

Important: Although the number of available Activity slots has been set to 3, K2.net Server overrides this setting and will only allow 1 slot for the destination queue. This behavior must be taken into consideration during configuration of the Succeeding Rules and Line Rules.


General Design Considerations
This new functionality can cause unexpected behavior during the execution of a process instance. Each point mentioned below requires a specific user context to complete the associated step. The implementation of "Create single Activity Instance for Queue" does not expose the user context until the participant takes ownership of the task

Mail Events (including Client SMTP Notification Message and Mail Escalation)
The runtime implementation of this forces K2.net Server to create a single Activity Instance and assign that instance to the Destination queue rather that the actual users. The only time that the item is associated with a specific user is when the user opens the item using the K2.net Worklist or custom implementation of the K2.net Worklist. The result of this can cause mail events using the "Send to Destination User" to fail. This can cause a runtime exception that will be logged in the K2.net Error Profile.


Redirect Escalation
The Redirect Escalation Wizard allows Worklist Items to be redirected to the current user's manager once a specified time has elapsed. Items NOT allocated to a specific user will not be redirected. This can cause a runtime exception that will be logged in the K2.net Error Profile.


K2.net InfoPath Processes
The "Create single Activity Instance for Queue" functionality is NOT COMPATIBLE with a K2.net InfoPath process. An InfoPath enabled process creates a document for each participant associated with the client activity. Since the task is associated with a destination queue and not a user, the creation of the document requires the associated user context which will not available.

0 replies

Be the first to reply!

Create single Activity Instance for Queue

Create single Activity Instance for Queue

0 replies

Reply

View our Community Site Map

Create single Activity Instance for Queue

Reply

View our Community Site Map

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded