Expand my Community achievements bar.

Join us for Adobe Campaign Community Q&A Coffee Break on Thursday, March 7th at 8am PT with Eric Perrin, Gael Mouello, Chakravarthy Kalva, Bruce Swann and Sandra Hausmann.
SOLVED

Limiting records for test runs

Avatar

Level 3

Hiya,

 

We're hosted on ACC v7 build 8894 with Postgres as our DB.  Since we don't have a pre-prod region, our end users build campaign workflows directly on Prod and play/test with it.  The testing on Prod results in large data sets being sent from one activity to the other, multiple running until they get the desired target list, saving interim run results .  Instead, we were thinking if they can limit these test runs on a subset of the larger data, it would result in faster workflow execution whilst still be able to give the end users enough confidence with the target list generated. 

 

D'ya guys happen to have any thoughts around this or any easier way to achieve this?

 

-wALF

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hello wALF,

 

Have to agree entirely with Wodnicki here as testing directly in production is against recommended best practices.  Additionally using the Keep Interim Results is also not recommended as it retains temp data within the database and can cause performance issues.  That setting should only be used on a limited basis to troubleshoot a workflow, then turned off.

 

Regards,

Craig

View solution in original post

3 Replies

Avatar

Community Advisor

Hi,

 

You really want to spin up at least one non-prod env.

If queries are running slowly, first place to check is indexes: join, filter, sort columns. Beyond that, check the hardware sizing of the db, if vm bump its cpu/memory allocation as appropriate.

Failing all that, use nms:seedMember to host test records, with the caveat this will require significant manual effort or some light scripting/Excel to generate.

 

Thanks,

-Jon

Avatar

Correct answer by
Employee Advisor

Hello wALF,

 

Have to agree entirely with Wodnicki here as testing directly in production is against recommended best practices.  Additionally using the Keep Interim Results is also not recommended as it retains temp data within the database and can cause performance issues.  That setting should only be used on a limited basis to troubleshoot a workflow, then turned off.

 

Regards,

Craig

Avatar

Level 3

Hi Jon & Craig,

 

Totally agree that we need a pre-prod region and that no testing/build activity should be performed on Prod.  But that's how we are, without a pre-prod region.  Given the situation we're in (and in general, for all other customers too), don't you think having the ability to limit records flowing from 1 box to the other, be helpful?

 

As for saving the interim results, trust me, we have always encouraged users to not make use of this but end users are end users  

 

-wALF