Jump to content

What's changed with the GetTimeStamp node that it's now not configured correctly?


Recommended Posts

I have this configuration which has always worked but now I have a red flag in the process that it's not correct. What's changed and what do I need to do to correct it please?

image.thumb.png.c4c13df6964fd0f3835ee4195d439d4f.png

Link to comment
Share on other sites

OK I think I have worked it out. The node defaults with the "Set" options showing dor Days/House/Minutes/Seconds and this has previously validated OK.

But now it's necessary to put those as "Ignore" (they still appear by default as "Set").

So it looks like HB have increased the validation here.

Link to comment
Share on other sites

I was NOT getting errors in existing running workflows but as soon as I opened a BPM to be edited I saw the error and could not publish a new version until I rectified it. I have not tried creating a new BPM with this node yet.

Link to comment
Share on other sites

@Berto2002 I went into a BPM with one of these nodes and when the error appeared I backed out of it as fast as possible as we have a lot of automated processes that use these nodes and can't afford for them to break as it would severely impact our customer experience.

Hopefully this gets picked up by Hornbill and fixed asap.

Link to comment
Share on other sites

@Jeremy the issue was mine. I had failed to set the Starting Timestamp to Ignore in one node. So it is POSSIBLE to leave the Starting Timestamp as "Set" and with no value and save and validate and publish (I had assumed wrongly that when they tightened the validation, they would ensure all the fields that needed a value would flag as red if they were wrong); but that does not give you the outcome you want. I have assurance if you set all the fields to Ignore (except the Operator) then it will give the outcome of what they say is NOW(). This from Support is correct.

image.thumb.png.4266e9721202dc1dd92f4e0a70198697.png

But yes, ANY BPM you now open that is not like the above for get current timestamp will need editing before you can re-save. Maybe you were already in best practice and have this correct! Well done if so!

Link to comment
Share on other sites

3 minutes ago, Berto2002 said:

I had assumed wrongly that when they tightened the validation, they would ensure all the fields that needed a value would flag as red if they were wrong

Only the Operator needs a value here - if the field were mandatory it would be marked in red, but it would also not be possible to set it to Ignore.

I suspect that the issue is that Set was used and the field presented "nothing" (an empty string) as a value - this is passed to a Timestamp which requires a number, and is correctly parsed as undefined.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...