January 16, 2019 at 9:32 pm
Hi All,
I am working on documentation prep and I want to know what is the best way to do it. We have an existing environment with couple of existing SSIS packages. I have to make documentation for that which explains how the package works and control flow. Is there any free tool or template? Also please share any best practices. My plan is to open SSDT and study the packages and take a screen shot and write brief summary about the package as to how it works and what it does? Also if it fails who is notified? Is that enough or need to add more critical details? please advise.
Thank you!
January 18, 2019 at 1:55 pm
No one here knows what level of detail is required in your organization.
My first thought would be to add annotation text into the package. That documentation would live and stay in the package. Print those as PDF files or use the Snipping Tool to grab screen shots for a word processing document.
Mention any settings that are not the default such as MaximumErrorCount, ForceExecutionResult, etc.
Any Event Handlers that are outside the norm for your organization should be mentioned and documented.
January 21, 2019 at 10:51 am
sizal0234 - Wednesday, January 16, 2019 9:32 PMHi All,
I am working on documentation prep and I want to know what is the best way to do it. We have an existing environment with couple of existing SSIS packages. I have to make documentation for that which explains how the package works and control flow. Is there any free tool or template? Also please share any best practices. My plan is to open SSDT and study the packages and take a screen shot and write brief summary about the package as to how it works and what it does? Also if it fails who is notified? Is that enough or need to add more critical details? please advise.
Thank you!
So we have a pile of documentation with screen shots of packages that nobody uses and they are no longer valid because changes have been done.
They way i see these documents being used are for onboarding a new employee or for troubleshooting. Trust me nobody's going to read this just for fun.
For onboarding it can be helpful to give that person an idea of what they are getting into.
But the real reason to do this is so others not familiar with it, can fix it, nobody cares about documentation unless something needs to be fixed and its usually an emergency.
That said the document should start with a section heading of "Important Notes"
The key things to include are
Can this be re-run?
If not, what needs to be done to re-run it.
What caveats are there that only the developer knows?
What department needs to be notified
etc...
Then get into the overview of what it does and why.
Then list the sources and destinations so you know what it impacts and what its impacted by.
Also in regards to source/destination when those will be changing (due to a server upgrade or software upgrade) its hard to query Word documents to find all the SSIS packages that will be impacted.
I recommend a couple SQL tables to store this info so you can later query what SSIS packages will be impacted by this upcoming server upgrade.
Edit: Also if you're clever you can use things like powershell or C# or TSQL to extract the connection manager info from packages or config tables to see what the source/destinations are and update your documentation dynamically.
Also SSIS is self documenting as long as you use proper naming conventions, descriptive names, and annotations. (i know this is not relevant just wanted to mention it)
Anyone who needs to change an SSIS job or troubleshoot or analyze whatever will most likely open the package.
January 23, 2019 at 8:30 am
January 23, 2019 at 8:44 am
jmilter 57172 - Wednesday, January 23, 2019 8:30 AM
Not sure where you got $39 from... what i see for standard single user is $395 + annual maintenance.
January 23, 2019 at 9:09 am
Yep... You are right... In any case this is a great tool that I use...
Sorry for the confusion...
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply