04-03-2020 07:24 AM
Gentle hubber,
this is my workflow schema
It is a simple workflow that runs on any JunOS device in our netwkork environment once a day. It launches “show chassis alarms” to look for some particular malfunctions that are not sysloggable by the device. If there are alarms they are written in a log file on the server and and email is prepaired for every device containing its own alarms.
There are five workflow’s scope variables to handle this passage of informations:
Two things are not working after more that 300 attempts. Here it is the first: the central inclusive parallel don’t trigger the right path even though i can see that the variables are correctly valorized and the check is made looking if the variable GLB_found is “Equals to” “nothing”/”alarms”/”errors”.
The second one is: when (randomly) the inclusive trigger the alarms path, only one email is sent for one device evev if there are multiple devices choosen by me that should be there.
If you want i can past the code of each box here.
Thank you for the support
Solved! Go to Solution.
04-08-2020 10:38 PM
The 8.4.3 will address the bug with conditions. 8.4.3 is expected mid April (very soon).
There is a fix available for 8.4.2. Ask GTAC.
regarding the email, one of options you have:
As inspiration you can use ERS inventory workflow.
Good luck and stay safe!
04-06-2020 07:51 AM
Yes i am using this forum as last chance before opening a GTAC case.
In your workflow you can only get one email per worflow execution.
You could create a loop to go through all the devices but this is not supported by the support, you could create infinite loops.
It is better to create one mail for all devices with the email object or to handle the mail generation directly with python code and not the email object.
I thought that every device that enters the workflow could trigger the email box activity as it does for every other activity box of the workflow. I don’t get the meaning of havig a mail box activity that can be triggered only once per workflow.
All great ideas, thank you so much for the sharing however I feel much comfortable with creating only one summary email using a temporary list or file support rather than creating unsupported loops or handling the emails with Python.
If we do all with Python we can call it a script instead of a workflow , i hope for a future where we can rely on the stability and functionality of the workflow activity boxes.
Best regards
04-06-2020 07:19 AM
Alessandro,
In my case only the gateway was not functioning but I don’t use the email object as such.
I suggest to open a case at GTAC to address this.
In your workflow you can only get one email per worflow execution.
You could create a loop to go through all the devices but this is not supported by the support, you could create infinite loops.
It is better to create one mail for all devices with the email object or to handle the mail generation directly with python code and not the email object.
Mig
04-06-2020 07:06 AM
Hi Miguel,
thank you for sharing. Yes i am using XMC 8.4.2.38.
Wow, it could mean that there is a bug on this new version. Help me understand the behaviour you’ve got. You mean that only the gateway object is not working for you either. is it?
And what about the email activity box? Before the XMC upgrade even if the inclusive parallel was working better i had only 1 email per workflow instead of 1 per device. But this could be another issue.
However rewriting the workflow to avoid using the gateway could be a workaround and at the same time i could focus on the emal activity box issue.
Thank you
04-04-2020 06:57 PM
Alessandro,
Are you running XMC version 8.4.2.38?
I’ve been hitted by such behavior after upgrade to 8.4.2.38 and rewrote the workflow to not use the gateway object (paraallel with O inside).
Mig