The previous recipes described two different approaches to manage and control SSIS packages, projects, and executions. If everything works successfully, nothing more needs to be done, but if something goes wrong with data or more information is required, maybe another step should be taken, which could be from simple to very complicated. Imagine the case if some record fails a lookup or even an unexpected error arises. The previous logging information is enough to detect the data quality problem, but may not be enough to troubleshoot and identify the origin of the problem. There are several reasons that custom logging can be applied:
Accessing error records could be needed
Default logging information is too much or too little (independently of the deployment approach followed)
SSIS administrators may be interested to take control of SSIS packages through SSIS frameworks they manually created before
There may be a need to create custom...