HI,
Are you using smartbox, to store the data. If so, could you not just script the produciton K2 database (data only) for those smartbox tables that store the data and run that script to populate those smartbox data in dev and test.
Yes, we do use smartbox for data, and yes, we already copy them over via script, but what we really need is for all in process and completed workflows and history to be copied from production to test / dev.
I.e. every in process workflow should come over exactly as it is, and all of the log data for them should come over as well - we run a lot of queries / reports on the logs, and we want everyone's task lists to look the same. As it is now, test and dev are a half-baked imitation of production, and while that's fine for us tech folkks, the end users who are testing get confused and annoyed by it and end up reporting bugs that are not really bugs.
E.g.
If a CRM contract - copied into test from a production re-deploy - says "approval in process", then someone should have it as a task in their tasklist (in test and prod). Similarly, if a contract record from CRM says "Approved", then someone should be able to go to the process instance reports for that approval workflow and see all of the workflow steps for that contract and see who approved it and when.
Note that it just occurred to me that one of the things I'll need to figure out if I copy the data down from production is how to update all of the client event URLs for running workflows to point to the correct environment!
Thanks,
C
p.s. To be honest, I'm surprised this isn't a more common requirement. I couldn't find any other discussions on it, but I would think most medium to large sized organizations would want to have their test envronment mimic production. Perhaps when you fget big enough you have a complete test network that is an exact mirron of prod - right down to the server names and URLs...
We initiate new transaction in our test K2 environment to test front-end apps/workflow process.
Test refresh other backend data, but not K2 workflow data.
If there are in-progress K2 QA requests that don't match refreshed backend data, they are "orphaned" and need to be deleted.
Yes, that's what we've been doing up until now, and that's what we're trying to get away from.... we really want a test environment that's consistent with production for ALL systems.
Anyway, with the consolidated database structure, it shouldn't be too hard to play around with it for an hour or two with some database renames and backups and restores. I've already compiled a list of the tables that seem to contain the sort of server / environment configuration information we'd want to merge into the production data once we restore the db from production in dev. Thankfully our databases are not too big and we only have one db server and one app server in each env.
...I know what I'll be doing at 11PM tonight :)
Still not sure how I'm going to deal with the client event URLs as I fear those are compiled into the workflows...
Thanks,
Chris
Sounds like a big job. I have also wanted to know how to change the usrl of a already assigned task. Please let us know if you manage to achieve it.
Im still not quite sure why you would want workflow data to be synced with production tbh. I can understand you want non workflow related data such as lookups and etc the same as production but would it not get really confusing. Surely, as long as you have all the lookup tables and etc the same as produciton , users can test with new requests in the test environment.
Anyway, Good Luck.
