I have a SSIS package with lots of containers and logic. I am running an additional task (which I want to run independently) let's say it acts as an Event Listener. When this separate task is errored, I want to error out the entire package. I thought, it should work by default but to my surprise, it's not:-
I have tried setting both FailPackageOnFailure & FailParentOnFailure properties on both the parent container & the child container but it's not working.
I was about to ask exactly the content of your last comment.
Failure of one piece of a package won't make another, unconnected piece stop executing. Once the executing piece is done, the package will fail, but Sequence Container 3 has no way to know what's happening in Sequence Container 2.
Which, honestly, is what we want. If Sequence Container 3 is doing DML, you could leave your data in an unfortunate state if an unrelated failure elsewhere in the package suddenly made everything come to a screeching halt.
If you don't want Sequence Container 3 to run if Sequence Container 2 fails, then just run a precedence constraint from Sequence Container 2 to Sequence Container 3, #3 won't execute until #2 succeeds and the Execute SQL Task succeeds.
I completely agree with Eric's answer. Let me explain to you why raising a flag on error won't work.
I redesign the package so it includes the flag check.
Let's say we have a success flag as user variable which is by default False.
Now we set this variable as True at the end of sequence 2 execution marking the success of all the other tasks in that sequence.
The second part is put into a for loop which runs only once(if at all). It checks if the success variable is true and only then run the inner tasks. It looks like below:
The problem is, the success variable check at the start of the for loop will always have the inital value which is false(because it runs in parallel with seq 2 and doesn't wait till seq 2 ends). Hence the second part is never executed. Now change the initial value of success variable to true and run the package again. Play by disabling the error prone tasks and run the package. You will understand how it works.
Related
Given the For Loop retry scheme below (working), how can I make the package return success versus failure? I've seen some tantalizing clues such as a task or package's ForceExecutionResult = Success but not sure how I can incorporate that into my process (I have many just like the below). If indeed setting ForceExecutionResult is an answer, do I set this using a ScriptTask or Expression? Is that property available in an obvious way, other than from the properties page? Thank you.
Additional note/explanation: I need to conditionally return success or failure based on the number of retries. A failure, retry, and success is success. In my For Loop, three retries is a failure. I can't arbitrarily set ForceExecutionResults = Success.
The resolution or at least one approach was to assign the On Error Handler's variable Propagate to True or False, using the User variables I was already using for the For Loop try scheme.
#[System::Propagate] = #[User::CountryIncrement] == #[User::RetryCount] - 1
You put that (above) in an Expression Task in the Task's On Error event handler. That way when the error retry count has been reached, the error will propagate up to the parent and correctly report failure. If it retried once, say, and subsequently succeeded, Propagate will be False and not bubble up. The Tasks Job Step will report success.
In the screenshot below you can see that actions are running even though the preceding condition failed. How (should) I stop this happening? Improving the screenshot in this version of the question.
According to my test, this error message in "condition" doesn't mean the condition fail. It seems your condition passed successfully. There is an action under the "if ture" which failed, so the "condition" will show this message. So I think you should check the actions under the "if true" and improve it but not the "condition".
It is really a false-positive statement as it has actually run correctly. There are several reasons why the orchestration still runs despite the failure.
Try to play around with the "Configure run after" option. You can find this by clicking the three dots on the respective action.
I have to execute "Start" and "Finish" Commands in the Sequential Order in my program and synchronize everything at the end. So I'm inserting the Offline commands in the order first and assuming they will execute in the same order. I'm using "List" with "Iterator" for this.
Problem here is: Finish Command will be missed execution in some strange scenarios in the middle and "start" commands will execute next to each other and sending all wrong data and mapped it in a wrong way.
As action will get ID when command executes at the server, I'm keeping tempory id's to map the offline commands in storage(localID). Instaead of List if I use anyother collection will this gets any better? It is hard to reproducing this on simulator. Please review both scenarios and advise where can this approaches go wrong. Thanks
I will add the OfflineCommands into the List and save in the Storage. After that user can perform delete delete operation in the App so that I will retrieve the list and remove the commands which got deleted from storage so now I have filtered list.
Don't synchronize.
That's nearly always a mistake in Codename One. Your code deals with the UI so it should be on the EDT and Display.getInstance().isEDT() should be true.
My guess is that one of the commands in the middle uses one of the following invokeAndBlock() derivatives:
addToQueueAndWait
Modal dialogs
Which triggers a second round of synchronization to run.
You can trace that by reproducing the issue and checking which command in the list is specifically there at each time. Then fix that command so it doesn't block in this way.
Another approach to fixing it is to remove the list immediately when you start processing which will prevent a duplicate execution of commands.
I have a package with 1 container.Does the ssis pacakge fail,If that container fail!?
The property
FAIL PACKAGE ON FAILURE
is false for the container.
Does that mean the package fail only if this property set to TRUE,other wise only the container status is failed ,and the package status is not !?
Yes. If the Sequence Container fails, the overall package will fail. Raise the MaximiumAllowedErrors property of the Sequence Container to get the behavior you want.
Example
Below we have an example package. The Sequence Container has a task that will never succeed.
Above, the Sequence Container has failed and the Package has failed. Below are the properties of the container above. These are the default values for a new container.
Now lets stop and study. If we compare the package behavior against the property settings, this looks wrong. Here we have set FailPackageOnFailure=False, yet a Sequence Container failure is causing a Package failure. Why is this? Unintuitive attribute names. See this Microsoft Connect issue. You are not alone in your confusion. The official explanation from Microsoft is this.
Despite some pretty circular previous messages, we believe that the
feature is behaving as designed. When you set FailParentOnFailure to
false, the parent will not fail until the number of failures in the
child exceeds the MaximumAllowedErrors threshold. When you set
FailparentOnFailure to true, the parent will fail on the first
occurence of an error regardless of the MaximiumAllowedErrors
threshold.
The important piece of information to take away from that quote is that the FailPackageOnFailure and MaximiumAllowedErrors work as a pair!!!
So - knowing this - we can achieve the expected behavior by raising the MaximiumAllowedErrors count from 1 to 2.
This will allow you to have a sequence container which fails, but does NOT fail the overall package.
Hope this helps!
It all depends on how the package and containers is set up. You have to open/import it (in SQL Server Business Intelligence Development Studio) and run on preferable test data to see which one fails. Do the two containers have inter-dependencies on each other?
I have a package that has a loop in it, that loops through a few connections. Each iteration through the loop is a new connection. The problem is though that sometimes these connections are down at package run time. So I've added an on error, send us an email notification, and then continue with the loop.
This works fine, using the Event Handlers and changing the Propagate value to False. But the issue is, if a connection fails, it will finish the loop, but report the entire package fails. This is an issue because inside a job in SSMS, it will stop the job after that package is complete, and report it failed, when it really did not.
Is there a way to have the package report success even if this loop kicks out the failed e-mail? I don't want it "Continue to next step on fail" because there are other parts to that package that could legit fail, and need to be notified on.
EDIT:
Here are screen shots of what I'm doing. Inside the loop there is a dataflow task, the first dataflow has the connection that sometimes fails. When it does, it triggers the email task to notify us, then will continue with the loop.
Unfortunately the FailPackageOnFailure is already set to false.
On the task that fails (or its parent container if applicable), change the value of FailPackageOnFailure to false.
If you are doing this to a task in a loop, you may want to consider whether you also need to set FailParentOnFailure to false as well.
EDIT: If none of your tasks or containers are causing the package to fail with FailPackageOnFailure=true, then probably you are setting the package to fail in a script. Maybe in your event handlers you are keeping a count of errors, and then at the end of the package you are setting the package state to failure if the error count <> 0.
Examine all the points at which you could be setting the package to fail, either through a script or through the FailPackageOnFailure property.
You can fake the execution result to success by setting the property ForceExecutionResult to Success (Default value of this property is None) for the Foreach Loop Container.