Hi René,

You could consider using a Layout procedure on the task that will alert the user and disable the Execute button (@confirm_button_type = 1) if the task parameters do not meet the requirements. Could that be what you are looking for?

Kind regards,
Mark Jongeling

Hi Mark,

It could, but the user still has to click the task away, not understanding why the execute button is disabled, when they just had an ‘error message’ which states the task cannot be executed anyway. Lets say our users often complain about the amount of (unnecessary) clicks they have to perform, which is really an issue and I can't disagree on that...

Is there a particular reason to hide the reason why the task cannot be executed? 

To answer: 'I want to inform the user as early as possible that the task cannot be executed, and cancel the task. What is the easiest way to achieve this?’

1. The earliest is by using a default/layout procedure but you are not able to close the task panel. 
2. The earliest after 1. is when the user executes the task, check if the values matches the requirements and if not tell the user about it. You can use the tsf_send_message with abort = 0. That way the task will continue it's way. In the SQL code, you can then make sure the task if not changing anything after the error. Sort of if wrong] then hnothing] else ldo stuff]
3. In case you use a process flow anyway because of actions needed to be taken after executing the task, you can draw a red arrow to Stop from the Execute (table) task and a green arrow to the next process action if successful.

Hope this helps you out!

Hi Mark,

I don't want to hide the reason why the task cannot be executed, the user must see that. To make clear, this is what should happen:

• User clicks on the task button, it can go two routes:
  • Route 1: The task cannot be executed
    • A error message is shown and after pressing “OK” it returns to the subject.
  • Route 2: The task can be executed:
    • The user sees the task dialog with some input parameters which he can edit.
    • The user presses “Execute” to execute the task.

*The real reason is that we encounter issues on large sets of data which eventually causing timeouts in the Web GUI. We currently have to set a hard limit on some tasks unfortunately. In the meantime we're investigating a stable and clear ‘async’ model for certain tasks. We have a task which is not always long running, in the majority of the time the result should be there in just a few seconds. But depending on the user input it could be running longer than a minute or so, so it eventually crashes in the current setup. It is very difficult for a user to determine if the task is going to be long running or not, so we have to make the decision. We do can decide if the task is potentially going to be long running (async) or not (sync).

Using async tasks doesn't work either as the long running task is a process flow / http call / sql saving task. I've tried some, but it doesn't work and it's very unclear for an user. 

I have not worked it out yet, but I was thinking of using a system flow each minute ‘picking up’ the potentially long running tasks. A bit like creating / copying a database via the Azure Rest API: It can return a HTTP 200 immediately, or it could be HTTP 202 accepted. When the user starts the potentially long running task, with some SQL code we can decide if it can be 200 (sync) or 202 (async). This could be done in a process flow sending the user to the proper sync/async flow. But I'll have to figure that out later.

I'm going a bit off-topic by this, but this is the real cause of asking this question . As far I can think up now, is only a process flow the way to go for the early message.

Br, René