Today, the behaviour of batch macro can be strange.
If I refer to https://community.alteryx.com/t5/Alteryx-Designer-Discussions/Batch-Macro-not-looping-after-running-the-workflow-as-an/m-p/84495#M29584
we can have big behaviour differences between :
-wf and app
-designer and schedulerExample here with a batch macro running for all lines in designer and only for line in scheduler
Designer works fineScheduler only runs the first line!!
I know the turnaroud (just use a message box) but it's not natural and I think
-at least the same behaviour is needed in any use case-if you want to do some optimization, ok, but make it an option!!
The explanation provided in the Link you referenced is good but left out some nuance.
So given this additional nuance maybe you could explain more fully the value of what you are asking for? Why would it be valuable to a developer or an end user running the app to have a job run and leave nothing to look at?
When run as an App the only evidence it even ran the iterations is if you can access the output log which end users would likely not be able to do.
Hello @fharper .Here my batch macro is used to drop a table through SQL code.What is after a drop? Well, nothing. Or sometimes some logging (and that's why there is an exit) but sometimes I use it, sometimes not, depends of the workflow.But the main reason I want this functionnality, it's that it's pretty dangerous, I mean, really dangerous and counterintuitive to have a different behaviour between running in desktop and scheduler.
I disagree on your characterization of the current behavior as very dangerous in this case. But that is just my opinion.
That said you may have an argument on modifying the optimization based on executing a tool that uses sql.
I would like to see the actual macro to see what u r are doing. What tool are you using to execute sql to perform a drop table?
Everything I suggest will sound like a work around rather than a solution but you can
1. Make your sql dynamic and put the tool executing the sql in the main flow vs macro.
2. add an output tool or pass out a record confirming the tables dropped which is more natural and good practice than using the message box as you mentioned.
3. Another option is to write a dynamic script to drop the tables in the macro and execute the batch from a run tool.
I suspect the optimization logic is complex and far reaching on how Alteryx runs and to tweak it is likely a more costly and complex problem than one thinks. So finding the best alternative for your need is probably the best you can do for now. But I’m not Alteryx so this is again just opinion.
I ran into this with Python and Command cases, where the meat of what's occurring happens outside of Alteryx's jurisdiction, and it thinks it's done before it really is.
Adding a browse as some threads suggested only outsmarts the Designer, but when in Gallery (which implicitly disables browses), once again it would end the iterations early. It really, really needs the output stream to be used.
Based on what I could find, the options were:
a) Generate dummy output to satisfy it (invites trampling or race condition)
b) Modify all contributing macros (several in overall process) to not have an output stream (rather not make two versions of each macro)
...neither desirable.
But I found a way to trick it. I created a simple standard macro with an input stream (template = single column "Any Field"), a count records, and browse.
Placed on the output streams where I didn't want to do anything with the output, this was enough to trick it into still going.
Guts of the macro:
Guts of macro
Calling the macro:
Attaching to output stream I don't care about
Someone more versed than me can tell me a more stripped down version of what I did that would still work (I ran out of fuse a long time ago and stopped at "working").
This is maddening that a batch macro would run differently via the Scheduler and when run manually.
I have a file output tool inside my batch macro. When run manually, it runs as expected (a file is output for each date in my batch).
However, when run via the Scheduler, it only runs once.
I had to add ANOTHER (garbage) file output tool AFTER the macro to get the macro to run more than one iteration via the Scheduler. And I only knew to do that after significant time searching the community and finding this thread.
I agree that this is VERY DANGEROUS (and just plain awful "functionality").