I’m excited to announce Building Custom Tasks for SQL Server Integration Services: The Power of .NET for ETL for SQL Server 2019 and Beyond 2nd Edition is available for pre-order at Amazon!
I spent more time on this book and the demo task – the Execute Catalog Package Task – than any other book I’ve authored or co-authored. It is humbling and an honor to be published and I do not take publication for granted. I thank Apress, Jonathan Gennick, and Jill Balzano for all their hard work. I’ve worked with several editors; Jonathan and Jill are (and remain) the easiest to work with.
As I’ve stated on this blog and elsewhere, I write because I like to write. I hope others gain something from my writing, and I am thrilled when others learn – especially from my mistakes! In the foreword to this book, Kirk Haselden is astute about my passion for data integration in general and, specifically, SSIS.
I am most honored and humbled by this foreword written by my friend, Kirk Haselden:
Reading this book in preparation to write this foreword was a blast from the past for me. Some of the function names for custom tasks, the code, the GAC, the various steps to getting the custom task into the designer. All that brings back a rich memory of what it was like when we first built Integration Services. The year 2020 marks the 20 year anniversary of when we started coding SSIS.
SSIS started as a small team with the purpose of replacing Data Transformation Services (DTS) with something more. What exactly, it was not clear. But we all knew that the new product needed a more robust data processing engine, better control flow, a richer design and runtime experience and notably, we needed to address some of the design flaws with DTS. Without reminiscing too much here, it is fair to say that we set out to create a lasting, flexible, extensible, feature rich product that would sufficiently address enterprise data processing needs.
We ended up scrapping DTS completely until we realized that DTS actually did some pretty cool stuff that we did not support and that because we had made some design decisions to address the DTS shortcomings, we had severely limited the ability for our DTS customers to upgrade their existing packages. The answer? Embed DTS into SSIS. This was the first time, of many, that the intentional and deliberate extensibility design in SSIS to support creating custom tasks was not only important, but essential. We were able to programmatically embed the entire DTS product in a custom task within a few days in what became known as the Execute DTS Package Task!
Andy makes mention here of my contribution to the annals of SSIS documentation. I wanted to share a few things about that before moving on to highly recommending Andy’s book.
First, my contributions to the SSIS project have often been overstated. I have noticed that because my name is associated with that book, I am sometimes primarily associated with the product’s successes. There were many on the team that did amazing things. Ashvini Sharma, Matt David (Technical Editor for my books), Mike Blaszczak, Kamal Hathi, Donald Farmer, Slobodan Bojanic (code reviewer for my books), James Howey, Michael Entin, Runying Mao, Silviu Guea, Nick Berezansky, Sergei Ivanov, Mark Durley, Euan Garden, Anjan Das, Bill Baker, Jeff Bernhardt, Bryan Hartman, Craig Guyer, Ranjeeta Nanda, Ovidiu Burlacu and a few others that I’m sure I’ve missed! SSIS was truly a team effort that resulted in a product that continues to evolve, improve, far outgrow, and out-perform our initial vision. It was an honor to be a part of that team.
When I started writing that book, I had severe misgivings; the kind of self-doubt that I’ve since learned is quite common among authors. From the very beginning I asked myself these kinds of questions. “Is this worth the time?” “Will anybody even buy the book?” “Is there any value in me doing this thing?” “Will people just see the errors and faults, or will they appreciate the effort and passion that I’m pouring into this?”
Early in the process, a group of people that wanted to also write an SSIS book reached out to me and asked if they could have my table of contents for my book as a starting point for their book. I said, of course. My reasoning was that the more people writing about SSIS, the better adoption it would have.
As I was preparing to publish, the SSIS user education team approached me. For various reasons, they were behind in documenting SSIS and needed a jumpstart. They asked if they could have my manuscript as a starting point for the SSIS books online documentation. I said yes, of course. I was honored. Much of what I had written became Books Online content before I even published my book.
Why do people write technical books? There are many reasons. Some more valid than others. It is certainly NOT to make a lot of money. For me personally, I had a passion for SSIS and I wanted the community to have as much help absorbing the product as possible. And so, it was ironic to receive comments about my book on Amazon such as “You can get everything in this book from books online” and “This is not a tutorial.”
So, what’s your point Kirk? Of the technical authors I know and with whom I have had the pleasure of associating, they are genuinely passionate about the products they document. It was not fame, notoriety, career advancement or money that truly drove them, or me, to write. It was love of the product and the desire to help people adopt and be successful with it.
Andy is no different. There is nobody who knows, uses, teaches, understands SSIS better than Andy Leonard. And I know that he personally writes these books out of the passion he has around helping people be successful at what they do using SSIS.
So, as you read, use, learn from this book, keep all this in mind. If you find what you believe is a fault or a shortcoming here, remember, this is a labor of love. It is a product of passion combined with kindness with the intent of helping you be successful. Writing a technical reference is just plain hard work! It is not just words, it is code, it has to pass not just the critical eye of you the reader, but the tyranny of the demo code compiler as well.
And, when you find that this book has been essential in your SSIS pursuits, remember to reach out to thank Andy for all the hard work. That is the best reward a technical author can experience.
I cannot remember the first time I met Andy. I am fairly sure we have never met in person. However, over the years, we have conversed through various channels and come to know each other virtually. I have watched Andy’s training, read some of his books and watched as he has firmly established himself as one of the most knowledgeable experts on enterprise data and analytics generally and SSIS specifically.
This book is a deep dive into a subject that requires such a treatment.
In several places in this book, Andy makes the disclaimer that he is no C# programmer. Do not let him fool you and do not let that dissuade you from using this reference. The guidance given here is both functional and unique. Building a custom component to plug into any complex system is hard. Building an SSIS custom task can be confusing and it is not uncommon to hit roadblocks that have no immediately obvious solution. I know. Even though I was part of the team that designed custom task architecture, I still ran into problems implementing them. Andy walks you through each step in meticulous detail while calling out the gotchas that are easy to overlook.
Andy is an SSIS expert. If you want to extend SSIS to do something that it currently does not support, building a custom task is one powerful and highly flexible way to do that. This book does not just capture the books online details. It documents the things that you cannot learn there or anywhere else for that matter about how to build an SSIS custom task.
Best of luck in your Custom Task adventures,
Thank you, Kirk!