Created a Test copy of Production and now would like to refresh that data, how?

[Stephen_Dinh1]

We need to refresh our Test environment with Production data (DB and Files). How do we go about updating the data without going through the whole process again?

[Chris_Boultingh]

Hi Adam,

I must say, I'm really disappointed to hear that document types and keyword types do not come over with the new utility! That is, after all, our biggest pain point and issue when setting up new life cycles or Unity scripts in test, then transferring to live. If the keywords are different, we have to manually make the changes once imported and that really negates the testing done because changes were made! 

Are there any plans to at least release SQL scripts or stored procedures that customers can use to change all the pointers after doing a manual test system creation?

Having matching document and keyword  types is a primary priority in our test environment.

Chris

[AdamShaneHyland]

Hi Chris.

For clarification ALL (or at almost all) configurations are migrated (there is a list in the documentation of the items which are not migrate).  When I referred to the Document Types and Keyword Types, I was referring to the unique identifiers (e.g. Document Types 123 in PROD might not be Document Types 123 in TEST, it might be 115).  I don't believe that these are going to match between the two.  This is part of the reason that I would defer to not using a unique identifier in a script if possible and instead use the name of the configuration because they can change from one system to another when using Change Manage (Import/Export).

I'm not aware of the request to maintain the unique identifiers from one system to another.  If so, this would be done in the software and not via SQL.

Best wishes.

[Chris_Boultingh]

Thanks Adam!

I've been using the unique identifier in scripts because names can change!  Seems like using the name would be setting oneself up for failure later. 🙂 Also, as far as I know, one must use the identifier / number when setting keyword values in Workflow "expression" actions (eg: %K00100).

I guess we have some thinking to do. Thanks for the info, and sorry to hijack the thread.

Chris

[Roger_Linhart]

@Chris Boultinghouse the identifier number is almost guaranteed to be different from one instance to another but the names typically won't. Yes, it is possible for someone to rename a Keyword or Document type but in those case your practice should be to modify the item name in every instance.

Regarding your Workflow expression example. The import/export tools are able to adjust the identifier numbers.

[Chris_Boultingh]

It has not been our experience that the import/export does the right thing all the time. In fact, our last experience with a life cycle rollout was a monstrous pain in the you know what. NONE of the notification mappings worked right, and we had to manually fix all of them.

There's also the issue of vendor connections using the API. Fiserv / DNA, for example, requires the use of keyword identifiers instead of names. Having the mismatch between test and prod is an issue.

As a developer, I find it odd that we are instructed to use a value in external scripts that could change at the source. That's just bad practice, and having to go modify all of the instances that use the keyword(s) should it change is asking for something to break.

At any rate, I'm apparently in the minority here. Nobody else seems to see the issue. <shrug>

Chris