Solved

Cancel a task before showing up

  • 29 October 2020
  • 4 replies
  • 127 views
R
Rank
Userlevel 5
Badge +15

I have a task on a subject which cannot always be executing, depending on the input parameters. 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?

The only thing I can imagine is having two tasks defined and connected via a process flow. In the process code for the first (dummy) task the cancel-check is done without showing the task dialog (all parameters hidden). If the task cannot be executed, the user will see a tsf_send_message and the proces flow ends. If the task can be executed, it can continue to the next task in the process flow which shows the task with input parameters. The users then confirms with "Execute".

But is there an easier way without using process flows? I was thinking of the default concept, but I don't know how to cancel the task (close the task window, or not even show it).

icon

Best answer by René W 29 October 2020, 10:07

View original
This topic has been closed for comments

4 replies

Mark Jongeling
Rank
Userlevel 7
Badge +23

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

"Wake me up before you low-code"
R
Rank
Userlevel 5
Badge +15

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...

Mark Jongeling
Rank
Userlevel 7
Badge +23

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 [nothing] else [do 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!

 

"Wake me up before you low-code"
R
Rank
Userlevel 5
Badge +15

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 [nothing] else [do 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é

Terms & ConditionsCookie settings