Rebuilding Automated Imports and email alerts with a SQL script or specs

Ernest Noa

Hello,

I regularly need to build automated imports, with 'commit multiple batches', followed by a trio of custom email alerts letting batch operators know if an automated import \\ commit did not finish, no records were processed or if records were rejected. This all works fine.

Setting this up is a manual operation and we have four environments we regularly support for development, testing, and production. Setting up the above objects is not awful, but takes an around 45 - 60 minutes of manual configuration per environment and is subject to user error as its all manual.

It doesn't look like there are specs for these object, I had hoped to automate or standardize set up of these processes. I have identified 10 tables that are used to store all of the objects I need. I've been toying with the idea of setting up these objects in one environment then writing a SQL script to deploy them in all other environments. This would cut down on the possibility of human error during configuration and it would be very fast. I am worried I'd be missing some crucial bit in some side table. Going around the ‘standard’ way of doing things feels flimsy to me.

Has anyone attempted this? Did it work ok? The tables I'd need to insert rows into are:

batchtemplate
batchtypecatalog
IMPORTFILETEMPLATE
IMPORTPROCESS
BATCHESCOMMITPROCESS
ADHOCQUERY
DATALISTCATALOG
ALERTTYPE
FEEDALERTINSTANCE
QUEUEPROCESS

Thoughts? Bad idea?

Thanks,

Ernie

Steven Finnell

Hey @Ernest Noa,

Because your data is spread across multiple different tables it definitely makes syncing multiple environments much more difficult. Off the top of my head I immediately think of two options.

Build a dedicated business process with a parameter set table where you manage the different different pieces (i.e. batch templates to use) and then sync that singular parameter set table across your environments.

Build out a custom Configuration Data spec that hits all of the different tables you need it to for the given instance of your process.

The second one would potentially be the trickier more robust version as I'm not sure Blackbaud has any documentation out there on how to set up a configuration data spec but you could reverse engineer some of the default ones included in CRM.

Hope this helps