Landmark - Refreshing Application Data With A Federated System

unknown

Finally getting around to doing a data refresh from prod to test of our Landmark applications and I have some questions.
1. When we use daexport/daimport to copy the data can I assume that it will also copy
the flows for each data area that we copy and will they run based on the schedule
that is set up in prod?

2. If the answer to question one is yes then if I use cdexport on the destination system
prior to refreshing the data and then use cdimport to re-import the configurations back
in will that copy our test flows back in and replace the ones from the production
system? Will this also take care of the schedule for flows?

3. Can I run daexport on the prod system while users have access? I would be doing
this late at night so there would be very few.

4. Does anybody know of a way to update all of the users email addresses to a
generic one so that when we are testing they don't receive it? I was thinking of a
flow, but not sure what business class to use.

5. Anything else I should consider?

Thank you.

unknown

Hi JimY,



This will be a long response. However, I'm only going to give you general answers to your questions. I don't really have many details because Infor Managed Services performs these steps for us when we need a data refresh. In any case, here you go.



1) Using daexport/daimport will copy everything from source to destination - app data, flows, workunits, actions, effective-dated entries, configurations, flow triggers, scheduled flows, etc. This caused us problems initially because our flows would continue to send emails to "live" email addresses from dev either because workunits were pending/processing when copied or because approval nodes timed out or were triggered by future-dated entries.



In order to (mostly) resolve this, we worked with Infor to create a multi-step process to be used during a data refresh:

- Export PROD data

- Export specific DEV (or destination) business classes for later use

- Truncate a list of tables that we DON'T want populated in DEV (WorkUnits and related tables, ActionRequests, Effective Dated Records, Email Queue, etc)

- Truncate and then load from DEV export a list of tables that we want to retrain their pre-Refresh data (Flows, Triggers, Scheduled Jobs, Configuration Settings, Cross Reference, Services, Email Templates, Configuration Parameters etc)

- SQL update all email addresses (EmployeeContact and Actor) to a generic email address (see below)

- Run Landmark Commands to update auditlog email addresses (see below)

- Update DB2 permissions for DB2 SQL access



2) I'm guessing that this would not resolve the issue, but our process (above) eliminates the need. Note that our ConfigConsole mods are copied from PROD and we don't restore them from DEV, so we are very careful to ensure that our ConfigConsole changes are either promoted or not needed prior to a data refresh.



3) I strongly suggest that you don't do this while users have access. I know AMS does this during our downtime, and our systems will be down for hours - PROD during the export and DEV (even longer) during the load.



4) See my notes under 1). I would NOT do this as a flow, because it needs to be completed while the system is shut down. You have to do more than just the email addresses in the tables. You also have to hit the auditlog, otherwise you will still have the potential to send live emails from DEV. Here are the commands that IMS uses for us:



- SQL: update lmhcm.EmployeeContact set CDEMAILADDRESS = 'genericemail@whatever.com' where CONTACTMETHOD = "6" and CDEMAILADDRESS like '%@%';

- LRMK Cmd: datamaint --auditsnapshot -Uc prodhcm EmployeeContact'



- SQL: update lmgen.Actor set CIEMAILADDRESS = 'genericemail@whatever.com' where CIEMAILADDRESS like '%@%';

- LMRK Cmd: datamaint --auditsnapshot -Uc gen Actor



I hope this is helpful!



Kelly