Our Senior Technical Consultant, Chris Hanson, will be taking us through this week’s Technical Tuesday:
Today we are going to look at the email task that you can attach to any SmartConnect map that you have setup. The most common use of this that I see is to use it on the Map Failure section to alert a user that something has gone wrong with the map if it is an automated (scheduled or real-time) map.
The amount of data that you can pass back and customize within the email task is fairly extensive. One option that we have, using system global variables to pass data back through the body of the email, has been around for a while. In the screenshot below I have placed different global variables in the task so that it will report the map id, run number, run date, and a list of all the errors encountered on the map run.
You can do this with any global variable, whether it is a user variable or a system one, but the system variables will be populated by SmartConnect – so you don’t have to put data in them in the first place to use them in a task.
The other options that are new to the latest builds of SmartConnect are the 2 checkboxes highlighted in the image. These will tell SmartConnect whether or not to attach additional files to the email when it is sent. The first check box, the validation errors, will attach a file that lists all the rows of data that fail any SQL validation tasks that were setup on the map. SQL validation tasks can be added at the Before Map section and check any data in the source against a SQL table/view and prevent any data to be processed on that map run if it fails. With this option marked on the email the user will see the failed rows in that file, rather than having to come back to the map to figure out what went wrong.The second check box, the process errors, will attach a file with data that failed if you are not running any SQL validation and instead the record fails when trying to be submitted. This is different in the sense that the map is running through every record at this point and each record is either submitted or failed. Those failed records are then recorded and dumped into the file that the user can use as the new source for the next map run, so only failed records are attempted to be re-uploaded.
