How long is 50 hours?

[Guest Paul Alexander]

If I put '50' in the hours box of and expire period option in a BPM node, how long does this expiry time last?

Our working hours are 10 hours a day, 5 days a week (as used in our working calendar). So 50 hours is 5 X 10, which is 5 working days. But if I add 50 to the hours section, these requests never seem to move on......I'm now assuming that there is a limit to what I should put in here?

[HHH]

it was suggested some time ago to put a 0 (zero) in the other fields.

[Guest Paul Alexander]

Thanks @HHH

I'll give it a go.....bit of a pain mind you as I have lots of BPM's where I've added this! 

Thanks again

[Victor]

FAQs... FAQs... FAQs....
 

 

[Guest Paul Alexander]

@Victor

Yup...I have seen that before BUT....it does say: 

"We advise to always configure hours (rather than days) as it is easier to figure out the values required to be configured for SLA targets or expiry times on business process nodes. However, in certain areas (e.g. SLA timers), depending on the target, it might not be always possible to use hours exclusively. "

 

I can't see anywhere on there that mentions needing to put zeros in if a field is blank though? If HHH is correct, that is why my 'expiry' isn't working? 

[Victor]

2 minutes ago, Paul Alexander said:

I can't see anywhere on there that mentions needing to put zeros in if a field is blank though?

You don't need to put zeros....

What node is that?

[Guest Paul Alexander]

It's the 'suspend  - wait for status change' node:

[Victor]

It should work... what if you put 1 hour there for testing purposes?

[Guest Paul Alexander]

Hello

Yes, 1 hour works.....however I have instances of BPM's which have been stuck at this point since 29 Jan this year...

 

[Victor]

Aaaaaa..... 29th of Jan!! .... in Hornbill time this is like Jurassic !!!  

In this case I don't think there is an issue with the expiry configuration, more like a number of defects regarding how "suspend" nodes handle the expiry outcomes, meaning there were scenarios when the expiry was not set correctly which means that particular section is now in a continuous loop. Each loop lasts 50 hours. I do see how one might think it has not expired but I am quite certain it did, but it just looped back to wait for another 50 hours because of broken expiry and so on... The defects I mentioned were fixed in subsequent SM updates, I don't expect to have this scenario on any recent requests...