Hi evan.yates. Thanks for your reply - always keen to hear responses that are not directly what's asked for 👍 Yup, I'm also a keen user of variables, and have thought of this trick and do use it occasionally. But I draw the line at creating/updating variables solely for the purposes of working around a system limitation (as it would be in these cases). I'm not keen on paying for extra tasks to fund a workaround 🤣 Hence the enhancement suggestion. But appreciate the response and it might be food for thought for others.
Job Report - Ability to Include "Result Schema" from a Recipe Function When creating Recipe Functions I often find myself exiting the Function and returning one or more values to the calling Recipe (see first screengrab). This is very handy but it does create an issue when customising the Job Report for the Function. That's because when customising the Job Report you're expected to choose the output from a discrete step in the Recipe to show in the output (see second screengrab). But the precise step at which the Recipe Function will exit depends on the exact logic followed for that particular Job, Referencing the first screengrab, one job might exit via Step 6 but another via Step 7. Since my code often has multiple Return points it gets very messy trying to include all of them (and it's a bit incoherent) so I don't bother. And therefore I hardly every use the facility to customise the Job Report - and that's almost criminal! So my suggestion is that, when working with a Recipe that happens to be a Recipe Function, there would be an ability to select from the "Result Schema" defined for that Recipe when customising the Job Report (see third screengrab). That way, regardless of which logic path any particular job took, it would be possible to see the returned values (in this case "Result" and "Notes") from the Recipe Function. In fact, it seemed so obvious to me that this is how it should work that I struggled at first to understand what was going on and why the Job Report only had values populated for Result and Notes some of the time. I can't believe I'm the only one who would find this useful. (Or perhaps I'm missing/misunderstanding something...?).
Hi Swagata R. I suspect the answer to your question is another question... "When is a csv file NOT a csv file?" The answer to which is... "When it's not been created by Workato!" I wonder if you've made the same assumption I did, that uploading a valid csv file to FileStorage should just trigger the Recipe and process the file (and why wouldn't you?). Except that if Workato did not create the csv, it won't be able to read it. I guess it needs to have pre-parsed the file to know the column structure? What I did in my Recipe was to invoke the "Create File" action first, passing in the contents from the file that triggered the Recipe, and then ensuring you choose Yes for the "Create CSV" file option. Once you've done that you can use the output from that Step in the Recipe (rather than using the Trigger data). See screengrab for a sample. I hope I'm wrong and this is unnecessary and I'm missing something. But this worked for me. (Waits for gary to come along, point, laugh, and school us in the Way of Worakto...). Cheers Russell
richy.mulcahy I take it all back. TELL ME ABOUT ALL OF YOUR TECHNICAL GOODNESS!! 😆
Hi John A. I get where you're coming from in seeking to understand the technical possibilities and what others have done. But rather than answer your (great question) I wanted to go off on what I see as an important tangent picking up on the saying... "For a man with a hammer everything is a nail". Or rather, to an engineer with Workato everything is an integration challenge 😀 Putting it another way... just because something COULD be done, doesn't mean it SHOULD be done. Everything is possible, but usually resources are limited and prioritisation is key and in this business requirements are key. So I'd suggest sitting down with your finance team (especially the button pressers that actually do the tasks each day) and asking them what takes them the most time, is most boring and repetitive and that they think someone should "magic away". Users may or may not have an understanding of the art of the technically possible, but they can certainly tell you what takes time and feel like little value add. These are (at least some of) the requirements of the Business. You can then quantify each scenario they flag (by asking how many people do this task x how often x how much time does it take on each occurence). That gives you the impact and how long it will take for "payback" (i.e. how many days/weeks/months of your solution being in place before the cost of your dev time is recouped). Prioritisation is not necessarily purely done on payback, but it certainly helps. And speaking to those in Finance management may also surface other higher level process inefficiencies and possibly other frustrations (perhaps more to do with data they can't see). Apologies if you know all that already, and for not answering your question directly. I'm sure someone else will be along shortly with a more direct response, but after many years as a Business Analyst and Product Owner (as well as developer) I can't let the opportunity pass to bang the "requirements not technology first" message 😆
Yes 😀 Over to you to try it out in your Dev environment...
(The rather odd looking second clause "not equal to true is true" is because I want to include both false and null values, and the drop down list of conditions doesn't allow me to check for that combination)
Hey vivek that's great to hear! Appreciated seeing the detail of your tests & findings. Hopefully it works in your Production solution - let us know. As per an earlier reply, if it were me I'd also want a variable to track the number of times I'd been round the loop and also be able to exit if that exceeded a certain number, just to make sure we're not stuck forever. As soon as you've come out of the WHILE loop I'd then check the value of the variable and maybe flag an error/send a mail/something if we exceeded the number. LinkedIn invitation sent!
