From time to time, I (Andy) will be adding updates about product development. I would also love to hear your suggestions and feedback on the utilities we maintain here at DILM Suite. Please share in the comments.
You can learn more about why I built the Data Integration Lifecycle Management Suite and how to use it by reading my book titled Data Integration Lifecycle Management with SSIS.
You can find free excerpts from the book on my blog, AndyLeonard.blog. For example, chapter 6 is published in this post: Why I Built DILM Suite, by Andy Leonard.
This post is long enough to serve as a welcome and introduction. I look forward to sharing more soon!
:{>
Hi Andy. Thanks for your little, usefull SSIS Framework. I like the idea of metadata based management for SSIS Workflows. There’s one thing with the SSIS Framework Community Edition that i am concerned with (only a little bit :). All the custom code/tables are directly added to the SSISDB.
Usually i consider the SSISDB as an “system object/database” and i’m a fan of “don’t mess around/modify system objects in SQL Server”. Nobody know’s what happens with the custom code when a official service pack or patch modifies/updates/recreates the SSISDB. Don’t you think it would be more future proof to put all your custom code/tables in an new DB for your Framework and from there access all needed data/code in the unmodified SSISDB?
Hi Markus, Thank you for using our framework and for your kind words! You are not th first person to ask this question, and it’s a good question. Dropping an additional schema (pronounced “schemer” in Farmville) into a Microsoft database was not my first choice. We made this design decision for two reasons, and neither appear in the Community Edition:
1. We enforce referential integrity in the other versions; and
2. We leverage encryption configured by Microsoft for encrypting sensitive values that *we* store in our schemer.
Hope this helps,
Andy