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.
Users experience extended delays when attempting to access their worklists. The effect of this for organizations may be more severe when AD (Active Directory) structures are complex, and for those organizations which include multi domain environments.
|Note: The error scenario and steps in this article describes one scenario under which this issue may occur. They are simplified and not all steps are shown or described.|
Users in multi domain environments that have complex or nested user groups within the AD structure may experience delays in accessing their task list. The delay is not necessarily related to the number of active process instances or users actively logged in. The resolution of users is performed using a recursive search of the AD structure. If the AD structure contains nested groups and the user has multiple user group memberships, this causes a delay in results being returned. This is compounded as the search has no limit imposed, which results in an ongoing search, or extended delays in returning user groups.
The system does not report a specific error message; however users may experience the following symptoms, which would then require the hotfix:
- A long delay is experienced by the user when they attempt to access their worklist
- The error message: ‘Service Unavailable’, may accompany the delay in accessing the worklist
The patch provides new functionality, which when activated, can change the behavior when resolving a user’s group memberships. A new flag is provided and when enabled, leverages the flat property which returns all security groups memberships; however the property does not return distribution group memberships. This flat property provides enhanced performance in resolving Security Groups.
When the new flag “OnlyUseSecurityGroups” is enabled, there may be an impact on existing process instances, if Distribution Groups were used to assign worklist items. If a user’s work was assigned at design time using a Distribution Group and not a Security Group, they will not receive their worklist items. If there are deployed processes with active process instances, the destination group must be changed to a Security Group and redeployed to the K2 Server.
When the Hotfix is applied, it does not impact the design time and even if the “OnlyUseSecurityGroups” is set to TRUE, the K2 Designers will still return all group types within the K2 Object Browser. This is because a Distribution Group still has value in a process where a distribution item, not requiring authentication is required. It is up to the individual building the process to ensure that Security Groups are used to assign worklist items.
The summary below provides a description of the flags available and how to utilize them:
||TRUE / FALSE
||When set to TRUE: All UserGroups will be ignored. No Groups for a user will be returned. When set to FALSE: Only top-level groups will be returned. I.e. Groups a user belongs to explicitly.
||TRUE / FALSE
||When set to FALSE: Only top-level groups will be returned. I.e. Groups a user belongs to explicitly. When set to TRUE: Groups will be iterated indefinitely until ALL unique nested groups has been resolved. MUST be used in conjunction with IgnoreUserGroups = False.
||TRUE / FALSE
||When set to TRUE: ResolveNestedGroups will be ignored. ALL Security Groups a user belongs to will be returned. No matter how many nested levels deep. When set to FALSE: Previous 2 switches behaviour will be analysed. MUST be used in conjunction with IgnoreUserGroups = False
To set any of these flags follow the steps below.The OnlyUseSecurityGroups setting will be used as the example:
- Browse to SQL Management Studio -> Databases -> K2HostServer -> Tables -> SecurityLabels.
- Right-click and select Script Table as > SELECT To > New Query Editor window.
- Run the Query.
- For the K2 label, click on the “hyperlinked” XML for the RoleInit column.
- Modify the XML to OnlyUseSecurityGroups=True.
- Create an update script as shown below:
RoleInit = ‘[paste modified roleinit xml here]’
SecurityLabelName = ‘K2’
- Execute script against K2HostServer database.
This Hotfix is contained within the latest K2 blackpearl 0807 Update. Install the update package to resolve the error.
The latest K2 blackpearl 0807 Update is available as an independent installation package which can be found here: https://portal.k2.com/downloads/bp/default.aspx