Hello All,
i was just reading some topics on assigning tasks to Active Directory groups trough Queues. One post noticed that Queues are not the most ideal solution for working between Development and Production enviroments.
Thinking about this i came up with 2 possible solutions:
1) Altering the Queue in the database
This is pretty easy since the queue is defined in XML contained in a NText field. You could even write a quick tool to edit the Queues in the database, I think it's strange that this isn't a feature of the Service Manager (or am i missing something??)
2) Altering the Queue in code
If you could define/alter a Queue in your code you can use StringTable entries to hold specific groups or users for development and production enviroments.
What do you think, or are there any existing solutions??
thanks in regard!
Page 1 / 1
Hi,
Point 1 - it is not a recommended practice to update or change any values directly in the Data Base. The only way to update or change a queue is by using K2.net 2003 Studio, the same counts for Destination rules. This is the only two areas in your process that will be affected between different environments (Dev vs. Production), therefore should one try to replicate AD in the development environment as close as possible (Yes this is in an ideal world and not always possible). Using Groups instead of users makes this task easier for developers. Destination Queues is with out a doubt the best solution working between Development and production environments. It is easier to update a Destination Queue than updating a multiple Destination Rules.
Point 2 - The Destination Queue do not have a code interface in development, for that reason can one not replace groups/users with String Table entries. As you mentions in the previous point the Destination Queue gets exported as a XML Document that is resolved by the K2.net Server during runtime. However one can make use of String Table Entries in the Destination rule, the code is exposed and this will be a valid option for switching between various environments.
Regards,
R
Point 1 - it is not a recommended practice to update or change any values directly in the Data Base. The only way to update or change a queue is by using K2.net 2003 Studio, the same counts for Destination rules. This is the only two areas in your process that will be affected between different environments (Dev vs. Production), therefore should one try to replicate AD in the development environment as close as possible (Yes this is in an ideal world and not always possible). Using Groups instead of users makes this task easier for developers. Destination Queues is with out a doubt the best solution working between Development and production environments. It is easier to update a Destination Queue than updating a multiple Destination Rules.
Point 2 - The Destination Queue do not have a code interface in development, for that reason can one not replace groups/users with String Table entries. As you mentions in the previous point the Destination Queue gets exported as a XML Document that is resolved by the K2.net Server during runtime. However one can make use of String Table Entries in the Destination rule, the code is exposed and this will be a valid option for switching between various environments.
Regards,
R
Thx! I tend to go for the last option, creating Destination Queues for both development and production enviroments and referencing them through String Table entires.
Thank you very much for the reply, if anyone has a different solution I would be glad to hear from you!
Thank you very much for the reply, if anyone has a different solution I would be glad to hear from you!
Hello,
We have the same problem.
We have destination queues to which we assign AD groups.
Initially we assign test AD groups to the queues, as the real groups include management users.
If we want to go live, we need to change the test groups to real groups. This is OK for the first release, but from then on the queues can not be changed as they are used in the production environment.
The information about the groups assigned to queues is stored in table _DestQueue. Is there a way to maintain different data across releases on that table for TEST and PRODUCTION environments? Is it really a problem to modify that table directly through SQL?
I'd be happy to hear about different approaches to this problem.
Thank you,
David
We have the same problem.
We have destination queues to which we assign AD groups.
Initially we assign test AD groups to the queues, as the real groups include management users.
If we want to go live, we need to change the test groups to real groups. This is OK for the first release, but from then on the queues can not be changed as they are used in the production environment.
The information about the groups assigned to queues is stored in table _DestQueue. Is there a way to maintain different data across releases on that table for TEST and PRODUCTION environments? Is it really a problem to modify that table directly through SQL?
I'd be happy to hear about different approaches to this problem.
Thank you,
David
Reply
View our Community Site Map
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.