Kent Bradshaw and I continue to update SSIS Framework Manager, the visual tool for managing SSIS Framework Applications. In our parlance, an SSIS Application consists of one or more SSIS Packages (to which we refer in the framework as application packages) configured to execute in a specific order. To date, enterprises using SSIS Frameworks (well, our SSIS Frameworks, at least) have relied on T-SQL for management functionality. We aim to change that with the next release of our SSIS Framework which will include SSIS Framework Manager.

In addition to Script and Execute operations, our current focus features are:

• Clone applications
• Rename applications
• Delete applications

Delete Applications

Our first version of framework application delete functionality is contingent upon whether the framework application has been executed. Framework logging includes application execution history. We refer each individual execution of a framework application as an application instance. Because configurations metadata may change over time – even between individual application executions – application configuration metadata is stored as part of application execution history (and reported in the SSIS Framework Reports’ Application Instance Report).

Currently, application delete checks for application instances in history, and disables the Delete button if historical application execution instances exist. I write “first version” because this version may not be our final version of application delete functionality. The next version on our minds involves a soft delete, but Kent and I have not yet implemented soft-application-delete functionality, nor have we thought about it enough to have the warm fuzzies (<– technical term…).

Clone Applications

The ability to clone framework applications adds tremendous flexibility to enterprise data integration teams. This feature surfaces framework functionality that has, really, been there all along – but has been cumbersome to practice.

Imagine your team configures an SSIS Framework Application to execute a data load operation made up of several dozen – or several hundred – SSIS packages. Enterprise Data Integration Teams may want to preserve the current framework configuration metadata while configuring the next version of the load application.

Cloning for vNext

In this use case, cloning serves your Enterprise Data Integration Team well. Cloning the existing framework application first preserves the current, working configuration and metadata. Cloning also means data integration teams do not need to start from scratch when building the next version (vNext) of the framework application.

Cloning to Refactor

Similar to cloning for vNext, cloning also means Enterprise Data Integration Teams do not need to start from scratch when refactoring a new application that is a subset of an existing application. All software evolves. When a framework application expands so much that it becomes unwieldy, several clones are a good way to start the process of refactoring the framework application into smaller, more focused chunks of functionality.

Refactoring at the Application Package Scope

We previously implemented application package delete functionality. This, in addition to disable application package functionality that’s been part of our SSIS Frameworks since we began carving them out of wood. You can observe an example of disabled and deleted application packages here:

I can hear some of you thinking, “What’s the difference between disabling and deleting an application package, Andy?”

That’s an excellent question. I am so glad you asked!

One important difference is deleted application packages are not cloned during framework application clone operations; disabled application packages are cloned. This helps when cloning to refactor as one may delete (and undelete as necessary) application packages one does not wish to be part of the cloned framework application.

Cool, right?

Rename Applications

As we worked through requirements for cloning applications, Kent and I realized adding rename application functionality would be very helpful. We expect refactor operations may create a need to re-label a freshly-cloned framework application because the sheer act of refactoring often surfaces the need for even more refactoring. Rather than delete and re-clone misconfigured framework application clones – for which (much) configuration may have been updated, we felt the ability to rename a framework application would be of value.

Valid framework application FromDate and ToDate datetime columns may greatly assist if we decide to implement framework application soft-delete functionality. Kent and I continue to mull this possibility.

Conclusion

I’m digging the updated functionality for two reasons:

1. It’s cool to support customer feedback-driven use cases.
2. It is awesome to be working with Kent again. I missed working with him earlier.

We would love your feedback. Please contact us or leave a comment below.

:{>