I have a package that is going to have roughly 20 sequence containers in it. Each of these containers is going to have the same start task and the same end task. The data flow task(s) in each sequence container will differ. So I was thinking I would create a custom sequence container that would implement the common steps I need in each of my containers. I started to create a task that would inherit from Sequence, but I found that it is sealed. Bummer.
What is involved in creating a sequence task by inheriting from Task? I see that Sequence implements IDtsSequence. But looking at this interface, it seems like I would have to build the logic to execute the workflow contained in my sequence.
Any pointers?
-Darrell
Darrell,
What you're talking about here is task reuse right? So implementing a new type of container won't help you and you cannot do it anyway as far as I am aware.
The only unit of reuse in SSIS currently is a package so you will need to hive off that repeatable functionality into another package and call it using the Execute Package Task.
There are huge improvements to be made in the area of reusability and reuse of tasks rather packages is my numero uno for vNext. Read more here: http://blogs.conchango.com/jamiethomson/archive/2005/02/05/929.aspx
-Jamie
|||
I don't think I explained my issue well enough if you think that a new type of container won't help. I want to create a container that when it "starts" will update a status in a table and when it "ends" it will update the status again. I planned to use a custom property in my custom container object so that each instance of my container can differentiate itself in the status table. What my container "contains" would vary with each instance in the package. Hence, the control needs to be a container.
Bummer I can't make my own.
-Darrell
|||Darrell Davis wrote:
I don't think I explained my issue well enough if you think that a new type of container won't help. I want to create a container that when it "starts" will update a status in a table and when it "ends" it will update the status again. I planned to use a custom property in my custom container object so that each instance of my container can differentiate itself in the status table. What my container "contains" would vary with each instance in the package. Hence, the control needs to be a container.
Bummer I can't make my own.
-Darrell
Containers in the context that we are talking about them do not and should not affect external data. That is not what they are for. They are to affect control-flow, nothing else.
Updating tables can be done very easily using the Execute SQL Task. Use the right tool for the job is I guess what I'm saying here.
If you want to achieve the thing that you are looking to achieve with what you refer to as a custom property, all you need to do is scope a variable to the Sequence container that holds that container's "ID". Each of your 20 sequence containers has an identically named variable scoped to it with a different value.
Hope that helps.
-Jamie
|||To be clear, sequence containers are not extensible, you cannot write your own. You could perhaps write the the start and end processes as task, that require minimal setup. This would make for faster development, and also encapsulat ethe logic in a reusable unit and also make them easy to maintain, that is just change the task code and redeploy, not maintain n packages or n instances of the task in a package.|||
Thanks, that's what I ended up doing. I created a new Task which has my start code and my end code. It has a property which indicates which MainPipe to execute in what would be the body of the sequence. It loads the TaskHost that contains the MainPipe at runtime and passes in the variables that are neccessary. It is not as elegant as it would be if I could subclass Sequence, but it seems to work pretty well for what I need. It reduces the number of tasks in my package from around 180 to 30. Also, as you poitned out, it allows me to modify my start and end code one place in my custom task and then just redeploy.
Thanks,
-Darrell
No comments:
Post a Comment