Disabling scheduled tasks and emails in Test Environment


(Calvin Krusen) #1

When we copy the production DB to the test environment, all the scheduled tasks are copied as well. Also, business processes that automatically generate output (an email, save a file to server, etc…) always run.

So there’s a couple of points to address:

  1. Is there a way to detect the environment in a BPM? If so I would just add the condition to the BPM’s that I don’t want to run in the test environment. Instead of having to go in and individually disable each one.

  2. Reoccurring scheduled tasks. If the task appears in the Sys Monitor, does disabling the schedule disable that task? Or would disabling the schedule just stop it from re-scheduling to run again after the next time it runs?
    .
    Or should one just delete the task from inside the Sys Monitor. I assume this would prevent it from running on the “Next Run On” date and time, and prevent it from being rescheduled.

  3. Disabling auto generated emails. Particularly from print styles that use Break/Routing. If the environment can be detected in the BPM, I could put a condition like in #1 above.

FWIW - I currently do the following after copying the Live DB to the Test environment

  1. Change the company name to "!!! TEST COMPANY !!!"
  2. Change the default theme to one with an obvious color scheme like the bright green background in the following:
    image
    Note: Add this them to the Live DB , so all you have to do is select it in the Test DB. Otherwise you have to re-add it every time.
  3. Launch the Sys Monitor and delete the scheduled tasks
  4. Disable Tax Connect (we apparently don’t have a sandbox account, else I’d just change the URL)
  5. Open each Print Style that uses break routing for emails and disable the Break/Routing.
  6. Open each BPM that generates output (email, saved file etc…) and disable them.

What do others do after copying the Prod DB to the Test DB?


(Andris Skulte) #2

Calvin,
I don’t have anything to add to this (yet). We’re working on a similar document to make periodic refreshes of our training and test databases easier… I’m also curious what other folks are doing.


(Jason Hawthorne) #3

We also change the output folders of our EDI Report Styles to point to a different testing folder so we aren’t accidentally trying to sending out 810’s or 856’s.


(Joshua Giese) #4

I do this in BPMs

if (Db.ConnectionString.Contains(“MyProductionDB”))
{
toAddr = {my normal logic driven email address};
}
else
{
toAddr = "my-email@domain.com"; // So I can get the test emails.
}


(Calvin Krusen) #5

Is “MyProductionDB” the name of the DB in the SQL server, or the name of the App in the Epicor Admin Console?


(Prakash6738) #6

May this link will help you…


(Andrew Lintz) #7

After restoring the Live DB to Test DB in SQL, I run this SQL script that changes the company name, deletes scheduled tasks from the SysTask schedule, deletes the field that holds the SMTPServer location so emails can’t get sent out to anyone, and changes the theme.

LiveToTestScript.txt (514 Bytes)


(Joshua Giese) #8

@ckrusen “MyProductionDB” is the name of the actual SQL db not the app pool