"mikkel@vivento.no" wrote:
Hi,

we have a staging environment with dev, test and prod servers. We would like to export our processes to these servers with the destination queues having different contents. I.e. we would like to have different users/groups to have tasks assigned to them for the three environments.

Is there a nice way to handle this.

We have thought of a solution where we have destination queues for each environment like testApprovers, devApprovers etc and we have a string table variable giving the environment test, dev etc and then we have multiple destination rules for each activity based on the string table variable. However it is a tidious and repetitive task to add 3 destination rules every time we add a new activity, so an alternative would be appreciated. We are dealing with this exact problem right now as well. KB163 describes the solution you mentioned above. We were dumb when we started toying with K2 and didn't know about that article so here is how we went about multiple enviroments. Not a lot greater and has some drawbacks, but has worked.

We have a development, test/stage, and production environment we just put in place. The project has over 40 different destination queues. What we did for the first stage of development was create the individual queues, but put the same development domain AD group in each queue. This verified that at least the basic structure of everything worked.

The first problem came up when we went to go to user testing in the test/staging environment. We created AD groups in the production domain and put the developers as well as select business users in the production AD groups. The AD groups were a 1:1 match up of the destination queues as our AD structure was a mess and it was the quickest way to at least start using K2. Because K2 doesn't manage destination queues like it does string tables where you can have different settings based on the deployed to server, what we did was create a 2nd K2 solution that was identical to the development solution, but had different destination queue memberships.

We did essentially the same thing with a production solution.

When we make changes, we make them to the development solution. After things are good, we copy the .kpr file from one solution to the next. If you make changes to destination queues, the string table, or other non-process related settings, you'll have to manually make those changes to each solution. It can be tedious, but it's worked OK so far. The biggest issue has been making sure the destination queues are identical. We had a few typos initially and they always keep coming back as someone as an old copy of the queues and keeps saving it back into Source Safe.

Ideally what I want to do is develop a dynamic way where destination queue membership is determined based off of a string entry and K2 looks up the membership based on environment. That sounds pretty much what you want to do too. Supposedly Black Pearl addresses some of this problem but I haven't heard any details exactly.

Also, how do you delete destination queues from the server? After deleting them in the studio and exporting, they don't seem to disappear...You don't. Once it's out there it's out there. They are stored in a SQL table and theoretically could be removed manually but that is not officially supported. There is also a wipe script that wipes the entire database back to a just-installed state but that is also not officially supported, especially in a production environment. This is another pet peeve I have with K2...the post-export maintenance of processes and destination queues I think is not complete with out delete functions.