To homepage To homepage
Solved

Difference in post execution step behavior for execution packages with a usage condition

  • 18 July 2023
  • 6 replies
  • 101 views
L
Rank
Badge

Hi TimeXtender,

 

We’re seeing the following scenario:

 

We have a execution package ‘A’ that is set up with an usage condition and a next package ‘B’ in the post execution steps.

Now, when we manually execute package ‘A’ through the user interface and the usage condition resolves false, the display message appears with this information, package 'A’ won't start as expected and, importantly, the next package 'B’, from the 'Run Package’ setting, won't start as well.

However, when the same execution package 'A’ is triggered through the scheduler, we see that even though package 'A’ won't start, because the usage condition returns false, the next package 'B’ in this case does start executing.

 

Is this something you are familiar with or are able to reproduce? Extra information is that package 'B’ doesn't have an usage condition applied and we're running TX 20.10.43.64.

 

Best regards,

Luuk Bouman

icon

Best answer by rogier.helmus 18 July 2023, 16:46

View original

6 replies

bas.hopstaken
Rank
Userlevel 3
Badge +4

Hi @luuk.bouman ,

If you run TimeXtender as the schedule service user and start the packages manually, is it working as expected?

Not sure wat the condition looks like, maybe it is not possible to run/check the condition using the service account user.

Bas Hopstaken (2Foqus)
L
Rank
Badge

Hi Bas,

 

The service account is able to resolve the condition. It's a simple “which environment are we on?” condition. We also do see in the execution logs that package 'A’ is started according to schedule and takes 0 seconds to execute. Which is in line with starting the package, resolving the variable, this returns false, so the content of the package itself is not executed.

rogier.helmus
Rank
Badge +1

@luuk.bouman My guess is that TX considers the starting and ending of package A as successful since there are no failures inside the package. This in turn causes package B to be started. Perhaps as a solution/workaround you could create a package C which is a copy of package B. You then put the same condition on package C as on A and set C to start after completion of A. 

L
Rank
Badge

Hi Rogier,

 

Thanks for your answer. We've implemented the workaround you suggest and it's working properly like that. We are curious though as to why, for the same package set up, the behaviour is different when you run it either manual or scheduled.

Thomas Lind
Rank
Userlevel 6
Badge +5

Hi @luuk.bouman and @rogier.helmus 

Rogier is correct about what happens. When using the usage condition it is seen as successfully executed. Even when it is for blocking the execution on one package, it will still continue with the next as it is seen as a success.

The solution is to use a overarching package that has the sub packages in it. Then it will block all the others from starting.

You can still use the execute on success option if you only add the first package in the overarching package.

L
Rank
Badge

Hi Thomas,

Thanks for your reply. We consciously steered away from using sub packages because this did not give the desired result as well. I will have to check tomorrow what exactly caused us to not use this option.

I want to put emphasis again on why I created this topic: the observed difference in handling of execution packages with a usage condition and an execute on success option when started manually versus scheduled.

  • Manually executing a package with a negative evaluation of the usage condition does not start the ‘execute on success’ package.
  • Scheduled executing a package with a negative evaluation of the usage condition does start the ‘execute on success’ package.

Can you provide insight on this difference from your side?

Best regards,

Luuk

Reply


Terms and ConditionsCookie settings