How to use a string table value in a destination rule for deployment across environments
KB000163
PRODUCTK2.net 2003
TAGSDeployment
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.
In order to avoid getting an error that reads "The number of installed licenses for K2.net 2003 has been exceeded"; you will need to allow for the limitations of the 10 user development license. K2.net developers can do this by creating mock groups in their development environments that are designed to only ever have 10 test users in them.
| Introduction The K2.net 2003 Development license limits the number of destination users for any process to 10 destination users. While processes are under development the following error may be generated, especially for development environments that are exact replicas of the production environment. "The number of installed licenses for K2.net 2003 has been exceeded." To avoid getting this error the developer will need to allow for the limitations of the development license. This can be accomplished by creating mock user groups in the development environment that hold no more users than the license allows. If you are unclear on how the number of users is calculated please refer to the following K2.net Knowledge Base Article article KB000165 - How K2.net evaluates Name User Licenses (NULs). This article describes a technique that uses a combination of string table values and destination rule logic to identify which environment the process is running in and based on that environment, which groups to use. |
| Assumptions
| |
| | |
 | |
| Step 1 Create a string table variable that will be used to determine which environment is in use. For example if you wish to deploy to both the development and production environments then you will have a variable named "whichEnvironment" it will either be set to dev or prod depending on which server it is on. You can create the string table variable in K2.net Studio (it looks like this): | |
| | |
| Then after you deploy, you will need to go into K2.net Service manager and change the value of the variable according to which server the string table is on. That interface looks like this: | |
| | |
| Step 2 Create destination queues for each group that you will need in your process. In the example provided in this article note that an Active Directory group called HR and a corresponding development version of that group HRdev has been created. Create the corresponding destination queues DevQ and ProdQ which will map to these Active Directory groups as well. | |
 | |
| Step 3 Create a set of 2 destinations in the destination rule for each activity in your process. | |
| |
| | |
| Step 4 Assign the DevQ as the destination user for the desDev destination, and assign the prodQ as the destination user for the destProd destination. | |
| |
 | |
| Step 5 Configure the rules for the destinations. Use the ellipses for the first variable to look up the string table key for your environment and the second variable should be set to the appropriate Environment Name. Example, if you have deployed to dev you will have set the string table variable to dev on that server, and if you have deployed to production you will set the string table variable to Prod on that server. This rule is checking the string table to determine which environment you are in. | |
| |
| Settings for the development destination rule | |
 | |
 | |
| | |
| Settings for the production environment destination rule | |
| | |
 | |
 | |
| Now your code will handle the switching between environments based on the value of the StringTable variable whichEnvironment and you won't have to do it manually every time you export. |
