process not proceeding after task expiry.

[Gary@ADL]

hi guys  i have a process which has a task that is set to expire on a user specified date (specified in a previous task). my second task on my process was set to expire 05/03/2021, which is has done, however the process is now just sitting there not moving onto the next node? its my understanding that once a task has been completed OR expired, it moves on to the next node?

thanks 

 

 

[Gary@ADL]

 

[Steve Giller]

Without seeing the exact values it's tricky to say, but "Last Working Day: 2021-03-05" suggests to me that the value passed would be 2021-03-05 00:00:00 which is nearly 8 hours before the task is created - so it will never expire as you have already passed the expiry trigger.

[Gary@ADL]

thanks @Steve Giller ive just tried another one for tomorrow, although having just checked the value for the ticket above (SR00183867), i can see that the date still isnt being stored in H_custom_b field (pic attached)

this value must be getting stored somewhere as we can refer to it (as h_custom_b field) within the same stage when setting the summary and card title value as below which is working;

LVRRQST - &[functions.getTaskAnswers("task-7ec2b8ec").Leaver] leaving: &[functions.getTaskAnswers("task-7ec2b8ec").h_custom_b] notified by: &[functions.getTaskAnswers("task-7ec2b8ec").notified]

 

i have moved my countdown task into the same stage now, and it referring the same value as referenced in the changing card title, and on the day i created it it stayed active, then next day it had moved to expired so its kind of working, 

 

many thanks  

 

 

 

 

[Steve Giller]

@Gary@ADL I think the confusion stems from thinking that h_custom_b = h_custom_b

While on the surface you would expect this to be true, in the database query above you're looking for the Taks's h_custom_b in the Request table, and you won't find it there!

[Gary@ADL]

thanks @Steve Giller - can you please advise how i can progress my process above? ive got a few of these now where the task has expired, but the process is just sitting there, i cant complete the task (as its expired), but my process wont move on now?

 

thanks 

[Hornbill Staff DR]

Hi @Gary@ADL

 From your screen shot above showing the variable being used to set the task expiry, it appears you are feeding the task expiry date from a previous task. I believe this to be the case because the variable begins with "&[functions(getTaskAnswers...").

I can see you've given the field an id of "h_custom_b" (so I can see why you might be expecting the value to exist in h_itsm_requests.h_custom_b) however custom task fields don't support field mapping, which is why the value isn't appearing in h_itsm_requests.h_custom_b. You'll be able to find this in h_sys_tasks.h_answers.

Just like the request table, the task table is going to contain alot of records. To make life easier it'll be better for us to know the task id then we can query that table and inspect the values captured against the task.

Finding the task id is relatively simple. First go into the request and find your task on the right hand side and click on the task title to open the popup. Then, click on the task title which appears in the popup itself. A new tab will open at the main "activities" view (the view where you can see and manage all your tasks). The task id can be seen and copied from the URL. We can then use this in a database query to inspect the data against that task.

The following query can be used to get the task record with the columns of interest: SELECT h_task_id, h_created_on, h_answers FROM h_sys_tasks WHERE h_task_id = "TSKxxxxxxxxx"

Inspecting the task record will allow you to confirm the situation @Steve Giller describes where the expiry date is earlier than the task created date.

If we find that to be true, there's two things that stand out for me:

1) Should the system allow a task to be created where the expiry date is earlier than the date/time on which the task was created?

2) If point 1) above is a legitimate situation which meant the task immediately expired after it was created, why hasn't the bpm progressed?

Are you able to obtain the task ID and show me the result of that query to confirm what we think is happening? 

In the mean time I'll see if there's a way to rescue the stuck BPMs.

Thanks,
Dan

 

[Gary@ADL]

2 hours ago, DanielRi said:

Hi @Gary@ADL

 From your screen shot above showing the variable being used to set the task expiry, it appears you are feeding the task expiry date from a previous task. I believe this to be the case because the variable begins with "&[functions(getTaskAnswers...").

I can see you've given the field an id of "h_custom_b" (so I can see why you might be expecting the value to exist in h_itsm_requests.h_custom_b) however custom task fields don't support field mapping, which is why the value isn't appearing in h_itsm_requests.h_custom_b. You'll be able to find this in h_sys_tasks.h_answers.

Just like the request table, the task table is going to contain alot of records. To make life easier it'll be better for us to know the task id then we can query that table and inspect the values captured against the task.

Finding the task id is relatively simple. First go into the request and find your task on the right hand side and click on the task title to open the popup. Then, click on the task title which appears in the popup itself. A new tab will open at the main "activities" view (the view where you can see and manage all your tasks). The task id can be seen and copied from the URL. We can then use this in a database query to inspect the data against that task.

 

 

The following query can be used to get the task record with the columns of interest: SELECT h_task_id, h_created_on, h_answers FROM h_sys_tasks WHERE h_task_id = "TSKxxxxxxxxx"

Inspecting the task record will allow you to confirm the situation @Steve Giller describes where the expiry date is earlier than the task created date.

If we find that to be true, there's two things that stand out for me:

1) Should the system allow a task to be created where the expiry date is earlier than the date/time on which the task was created?

2) If point 1) above is a legitimate situation which meant the task immediately expired after it was created, why hasn't the bpm progressed?

Are you able to obtain the task ID and show me the result of that query to confirm what we think is happening? 

In the mean time I'll see if there's a way to rescue the stuck BPMs.

Thanks,
Dan

 

Hi @DanielRi 

Hi Daniel – thanks for your reply, yes you are correct I am feeding the expiry date of the task from a previous task, which ive tried to save the value into H_custom_b so I could reference the value in another stage. However I haven’t managed to get this to work, so I have changed the process and made it so both the tasks now sit in the same stage.

 

Thanks for advising on the field mapping, I wasn’t told this in a previous post when I was asking – I was just told I was using the wrong field and it didn’t support the data type I was trying to use, not that the field would be in a different table entirely.

 

so the task ID is: TSK20210305000001 , Created on is: 2021-03-05 07:49:07. I cant find just a column called “answers”, however theirs one called “outcome answers” which is empty, and one called “ task answers”, which has the following in it (apologies I cant select it so just took a snip)

I cant actually search this for the “task answers” field though directly it doesn’t like it – see below, searching for all columns is ok,

Searching for the first 3 columns you said works ok,

It will not not search though when h_task_answers column is added, im pretty sure the SQL is correct.

As you can see from the first screenshot. The date being committed has no time on it. Just the date, which is as expected as we only use the date control field to select the value.

If it turns out to be referencing the start of the day rather than the end that’s fine we can accommodate that.

To clarify, this process already works for us (when setting the date to be the same as todays date, or a date that has been passed already),  provided we complete the 2 tasks within the same day it seems. (this is the first time we have let the task expire and noticed its not doing what its supposed to, nor can we progress it), we haven’t yet had any processes expire which reference a future date yet (although we have one due tomorrow, for which I created the task for today), but we still need this to work for past dates, or at least be able to move the process on when the task expires.

 

Many thanks

Gary

 

 

[Steve Giller]

4 hours ago, Gary@ADL said:

I cant find just a column called “answers”, however theirs one called “outcome answers” which is empty, and one called “ task answers”,

These are the Display (or "Friendly") names, if you change the dropdown from "Use Column Display Names" to "Use Column Database Names" you'll see names that the SQL requires.
The "Task Answers" column is called h_answers, if you replace h_task_answers with that your SQL will work.

[Gary@ADL]

thanks @Steve Giller that got it,

the full table doesnt paste very nice, but this is the task answers field (task id and created on in above post)

 

Quote

<taskAnswers><taskAnswers><key>Leaver</key><value>test leaver</value><displayValue>test leaver</displayValue></taskAnswers><taskAnswers><key>h_custom_b</key><value>2021-03-05</value><displayValue>2021-03-05</displayValue></taskAnswers><taskAnswers><key>notified</key>.........</taskAnswers></taskAnswers>

 

the ticket that i created yesterday, with an expiry date for today has worked. the task expired at 00:00:00 on the day set as you expected, and has moved on to the next node.

so im just having a problem with them when the task date is made due on the same day as they are created, or in the past and it is allowed to expire, although id ideally like to keep this as we regularly get notifed of leavers in the past.

 

thanks

[Hornbill Staff DR]

@Gary@ADL thanks for confirming the situation with the expiry date. I'll leave it up to support and the Product team to determine whether the task should allow an expiry date in the past or identify why the bpm doesn't just progress in this situation. Something doesn't seem quite right to me there.

In terms of what you can do in the mean-time to make the process more robust, I'd perhaps add some logic immediately before your task to check whether the leave date is before "now" ("now" effectively being the date at which the task is created).

I've mocked up an example that will hopefully illustrate how this can be done:

 

The above configuration should allow you to avoid the stuck task where the leave date is in the past.

I hope that helps,

Dan

[Gary@ADL]

@DanielRi this has worked i think, certainly working for dates set in the past, i'l keep an eye for dates going forward but i dont think it'l be a problem,

 

many thanks for your help,