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.
Related
I'm currently using cypress to test that a 'pill' element is added on the frontend when the data gets to a particular state.
I identify the row being targeted using cy.contains()
I then chain it with parents('tr').contains('<string>') to identify that the pill I want is being added
The only problem is because the cleanup logic that happens prior to the test triggers a third party webhook that my app responds to, sometimes the row I'm targeting gets removed (after its been found using the first cy.contains() command) and then re-added to the DOM before it reaches its final state.
I believe this is then what causes the second part to fail - cypress appears not to have realised its been detached from the DOM and times out expecting to find my <string> on the detached node.
The full chain looks something like this
cy.get('table')
.find('tr') // Get all the rows
.contains('stringToIdentifyMyTableRow') // Get the text in the specific row I care about
.parents('tr') // broaden scope to whole row
.contains('pillString') // Find text I'm looking for
It seems like its found everything after the .parents('tr') command so its not bothering to retry, even when they are actually detached from the DOM - rather its continuing to look for the pillString in the detached node. What I'd like it to happen is for cypress to continually retry the whole chain until the application reaches its intended state.
Try updating to the latest version 12. It has a new feature that retries when elements are detached from the DOM docs.cypress.io/guides/references/changelog#12-0-0
Maybe try eliminating the .parents('tr') step
cy.get('table')
.contains('tr', 'stringToIdentifyMyTableRow')
.contains('pillString') // should be pill cell
It's easy to get detached errors with React because of the frequent re-render of components.
Your test has no action to cause a re-render, if the webhook is doing it then you need a way to start the test after the webhook has run.
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 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.
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?