Details :
I would like to adapt my lvl error on log if i’m on REPEAT or NOT.
As long as my repeat occur i only want to log on WARN, until all the repeats fails and i log an error during the exception.
I can do it simply by adding a variable on the pipeline and analyse it later.
But i would like to find a way to identify that sub flow are on a REPEAT to manage these only on the log framework, and not by sharing to the other developer to initialiaze and drop a variable correctly each time they used one.
Here are some things i considered :
Manage this with the $retries create by the REPEAT function - issue this variable isn’t initialize till the second REPEAT
Used pub.flow:getRetryCount but i realize that this function as nothing to do with the REPEAT function
I feel that the the triggers or the systems must know that he is looping through a REPEAT.
Do you have any solutions for me?
Strictly speaking, it’s the first REPEAT – the first time through the steps is not a REPEAT.
Branch on $retries, checking if present or not (can use regex or other technique). If not present, you know you’re in the first iteration. Else, not. Or check if > 0 or whatever value you want to check.
If you’re only interested in doing something different when the steps are REPEATed, then
BRANCH on $retries
…/\S/ : SEQUENCE (in 1st or subsequent REPEAT)
…$default: SEQUENCE (no $retries – executing steps for first time)
@Holger_von_Thomsen, there is no iteration variable during a repeat, tha variable that manage the retry is $retries
@Simon_Hanisch1, i would like to not initiate anything other than puting the RESET function, so i don’t have to share to the developers directives like ‘before each update you initialize this variable and manage the droping afterward’, but with no other solution i will consider that technique.
@reamon, I aggree the first time is not really a REPEAT, but the server should know that he began a flow that will need to be REPEAT if the condition are met.
Saddly with your suggestion i won’t be able to detect that i’m on REPEAT or not, with this condition it will be not present if i’m in a the first repeat or outside.
The steps are in a repeat, right? So then you know. And the developer writing the FLOW with the REPEAT in it knows.
Are you trying to pass this “knowledge” to a child service in some way? What do you have in mind? The presence of $retries? Is it explicitly passed or are you expecting it just to be in the pipeline? If the latter, that’s a no-no.
EDIT: Clarifying the comment – If $retries is explicitly being passed to a child service which is defined on its Input tab, cool. The “that’s a no-no” comment was a child service reference a variable that is not explicitly defined on the Input tab and passed to it.
I think you can access those properties and parse accordingly to see if you are in a repeat or not by using wm.server.services:serviceInfo but you need to use that service with caution.
This service is supposed to be used internally, hence SAG doesn’t provide support for it and they can change it whenever they feel like it. It is in wmRoot package, you need to make it visible from the extended settings to see that service in designer. wm.server.services:serviceInfo returns the properties of a given service, you should be able to easily detect if the service is in a repeat or not from those properties.
It is detectable by reading the service properties I guess, like comparing the current repeat number with max retries. I don’t know any other way to accomplish that.
Shouldn´t there be a FAILURE signal with “max retries exceeded” then in this case?
Wrap the REPEAT in a Try-Catch-Sequence in the Try-part and handle the max retries exceeded in the Catch-part.
I think they are trying to implement an error logging mechanism or something similar, which can be used anywhere in any function. So my guess is they don’t want to touch the repeat or loop at all. They want to add a service below the repeat and that’s it.
We do so by setting the Count property of the REPEAT using a variable that we load from a config file.
Then if we need to do something on the last retry, when $retries = that var we do “last try” things, like send a notification or as indicated here, record an error.
But the OP seems to want a child service, called in any context, to “know” that it is called by something that is in a REPEAT (presumably repeat on fail) and when it is on its last retry.
At this point, I’m wondering if the effort is worth it. Does WARN vs ERROR provide meaningful value in the face of:
Using undocumented-not-for-our-use services
Reverse engineering to find if the caller is in a REPEAT and if this is the last iteration or not.
I’ve done similar to both of these for other purposes. Kinda fun. Could be applied here. The question for the OP is if the resulting sauce will offset the mess in the kitchen. Would it be simpler to trust developers to add what is needed?
For now i am leaning toward the implementation solution, where i will share to the developers the consequences.
But i will make some try with wm.server.services:serviceInfo before.
