Retroactive blocking of individual jobs

[Carsten Schmitz]

Hi.

One of our users created a job plan. I don't know why, but he elected to put dependencies on the "end" object as shown below: Unless objects 3 and 4 run ENDED_NOT_OK and 5 runs ANY_OK, do "block".

All objects ran ENDED_OK.

This is what apparently happened due to these dependencies:

1. the job plan is blocked. Okay, I can understand this, this makes sense.
2. Objects 3 and 4, but not object 5 are blocked. This makes no sense to me.

Why are objects blocked after they have already ended ENDED_OK? Why do the end object's dependencies cause only 3 and 4 to be blocked, but not 5?

This makes no sense to me. Is this just a consequence of somewhat unexpected input into a crufted and not very well defined state machine, or is there any logic to this that I (or we, actually, I shared this mystery with some colleagues) can not see?

Thanks.

[Carsten Schmitz]

Oooh here's wacky theory.

In the german version, it does NOT say "This Task" for the else condition, and instead of "Block", the radio button says "Aufgabe blockieren" ("Block task").

Is it possible that even though the list of Dependencies is (should be at least) a list of AND dependencies, the logic is that it blocks only those tasks that did not satisfy their individual constraint?

So because 3 and 4 didn't match their constraint (did not run ENDED_NOT_OK), those get blocked, but 5 doesn't get blocked because it did satisfy it's constraint (did run ANY_OK)?

And is it possible that beyond this, the English version has a really really really bad label? That where it says "This task" it actually means "THAT particular task"? And then the blocked workflow is probably just a given that follows from any of it's children being blocked.

This is the only explaination I can find. If this is true, then I have two questions:

• Why, why would you make an AND "if" clause and then an "else" clause that acts not on the JOBP as a whole, but on individual elements of your "if" clause?
• Why would that be labeled "This task"?
  
  "This", in the English language, means "this very object", so it could mean the END object that the clause it attached to, or with some goodwill it's parent container. But "this" could never mean SOME OTHER object on the same organisational level that the clause is not directly attached to, like 3 or 4. And in Programming, "this" is also a well-known idiom that's equivalent to "self". "This" or "self" can never apply to a totally different object.

I must either be missing something, or I am correct. And if the later ... wow!

[Tatjana Radic]

Hello Carsten,

The tasks have not actually been blocked retroactively. If you open executions of the particular tasks, you will see that they actually have status 'ENDED_OK', as they should. The tasks are only displayed as blocked in workflow monitor, so you can easily distinguish which tasks contributed to this workflow being blocked. (think about having workflow with thousands of tasks, for example).

On your other question about - This task. This is actually -this very object- which is the object you have selected - ie. End node.

Lg
Tatjana

------------------------------
Product Manager - Automation
CA Technologies, A Broadcom Company
------------------------------

[Carsten Schmitz]

​Hi Tatjana.

But it's not the end node being blocked, but some different object. Thus, I can not follow the logic behind this still.

Lg,
Carsten

[Carsten Schmitz]

​Oh, and also, I do maintain it's blocked retroactively.

"3" and "4" run. Both go into ENDED_OK.
"6" (6 being the END node) needs to run AFTER it.

Only when "6" has run, a programmatic decision can be made to block "3" and "4" because those conditions are attached to "6". So only when "6" has been processed can "3" and "4" be set to "BLOCKED". And processing naturally happens serially here.

To me, that's retroactive.

[Tatjana Radic]

Hi Carsten

The tasks only appear as blocked in the process monitoring. Their original status has not been changed. Check the executions of the tasks.

------------------------------
Product Manager - Automation
CA Technologies, A Broadcom Company
------------------------------

[Scott Hughes]

ENDED_OK is the job state

BLOCKED is the task state in relation to the workflow

--

Scott Hughes

IT Network Services

O 949 286 7668
M 505 373 7872
7000 Central Blvd SW
Albuqurque
Albuqurque, New Mexico 87121

[Franz Zalubil]

Hi Carsten,

please change on "END" to ANY_OK or ENDED_OK for 3 and 4. Here the status ENDED_NOT_OK what meas the status where "END" should continue and "ELSE" goes to block 3 and 4.

Maybe the idea is to abend the workflow then the decision on END should be ENDED_OK else ABEND, what is setting the workflow to not OK. 

Best, Franz

------------------------------
Managing Consultant Enterprise Studio
HCL Technologies Austria GmbH
------------------------------

[Carsten Schmitz]

Hi Franz,

Thanks for your response. I have already advised that user how to "fix" his job.

But the intention of this report is not to correct the problem inside the particular job. How we'd have to go about this is rather clear (in part also thanks to your own advice), but I am not even allowed to modify this job. It was built by someone over whom I have no authority. I have no clue why he built the job that way in the first place, and I would not have built it that way myself, but he can do whatever he wants. That's how the company wants it to be, and that's in part because Automic has sold AE as a point-and-click solution that people with little training can use.

As administrators for Automic in the company, we are, however, also the first line support for the user base. In that capacity, we try to make it heard at Broadcom when the users struggle because the product isn't intuitive, and especially when we investigate this and share that sentiment (which in this case, we do).

I merely wish to tell Broadcom that their product confuses people, their state machine appears inconsistent to me and they should, in my mind, improve the user experience.

Best,
Carsten

[Carsten Schmitz]

Hi Tatjana.

I appreciate your responses, but it's not my intention to argue beyond reasonable doubt why Broadcom should improve the user experience in that point.

I think I have sufficiently made the point that this aspect of the product is not intuitive and that it has, in practical use, confused part of our user base and some admins also. I have had other discussions as a result of this thread, offline and online, wherein other Automic users were also speculating why the product does or does not behaves in certain ways in this aspect. If a feature in a GUI sparks such discussion and speculation as to how it works or why it works the way it does among the intended user base, that's already a UX fail to me and thus, an opportunity for doing something better.

Just one more thing of note though. The user has now cancelled the parent job plan. The jobs (which were always showing as ENDED_OK in the executions, that much has always been undisputed) and which were showing as BLOCKED in the monitor are now showing as ENDED_OK in the monitor also, they are now yellow and have a BLOCKED symbol:

Whereas when I create a job plan that doesn't have it's block condition on the END object, and block a job (Haltepunkt / Breakpoint) and then unblock it, that is blocking the CURRENT object and not a previous one, those are eventually ENDED_OK and do not have a blocked symbol anymore and are plain grey.

Imho, that discrepancy, and the whole ambiguity exists only because the product allows to block something (once again: retroactively) that has already run. This does not produce issues when you have a straight path through the job plan, but when you block something that has already run way after that fact, e.g. by doing this from the END object (or anywhere further down the job chain really), going backwards over other jobs in between that have already run, that logic breaks down.

I can not make this eny more clear. This is an inherit design flaw in the product, but clarifying the labels in the Properties -> Dependencies tab of the workflows (most especially for the english version) would be a start.

Best,
Carsten

[Carsten Schmitz]

Actually, let me try it this way.

When I go to the pub to forget all of this, I pass certain houses. This is my route:

1. I go past house one, it's full of pirates
2. I go past house two, it's a supermarket
3. I finally reach the pub

As I reach the pub, the bartender tells me that nobody can possibly ever get past the pirates, as I must get blocked there. But I am already at the pub, and I have successfully made a purchase at the supermarket.

See why this doesn't work?