This has probably been mentioned before, but in case it hasn't....
The dynamic input tool is useful for bringing in multiple files / tabs, but quickly stops being fit for purpose if schemas / fields differ even slightly. The common solution is to then use a dynamic input tool inside a batch macro and set this macro to 'Auto Configure by Name', so that it waits for all files to be run and then can output knowing what it has received.
It's a pain to create these batch macros for relatively straightforward and regular processes - would it be possible to have this 'Auto Configure by Name' as an option directly in the dynamic input tool, relieving the need for a batch macro?
The current version of the Publish to Tableau macro retrieves an API key at the start of the workflow run. Often times the workflow may take several hours to run before it's ready to write to Tableau by which time the API may have expired. (I think the default tableau server setting times out in 2 hrs) It's one of those soul crushing "I should've forked the output!"
Sample Log Error -
The idea would be to change when the macro obtains the API from when the workflow is initiated to just before the workflow is ready to write to the Tableau avoiding these timeouts.
(If you're having this issue in the meantime you can have your Tableau server admin up the timeout)
I rarely use the Group By tab on batch macros, but it's unfortunately always the first tab that pops up. When I have a questions tab on a batch macro, it would be great if it appeared first (ie I should see the questions tab when I click on my batch macro.) Thanks!
I've recently been delving into using the interface tools and there are a couple of glaring issues for me as a developer/designer, all having to do with the UI, ironically (yes, I used that correctly!) with the interface tools. The irony here is that the interface tools utilise a poor user interface.
Firstly, I finished this video to ensure I was indeed doing things correctly, and I was.
The UI for designer's interface tools is incredibly sluggish. In order to rearrange tools, each time you create a new one, you have to push the up arrow for each tool and you have to traverse the groupings.
Instead of this, I suggest two changes to the interface designer.
I know not everyone is building macros/apps and dealing with this, so I have little faith that this will jump to the top of your queue. But this is a painful part of the UI. I don't know if your UX designers could easily fix this or if it is more pain on your end than the pain you're giving me, but I just want to say: This hurts. 35 clicks every time I add a new element with no option to 'move to top' like you (wonderfully) do in the select tool is a big drag on my time (hint: maybe add that sort of functionality too; the select tool manages this stuff so well!). Which is supposedly valuable. In theory. But it certainly doesn't feel that way when I've spent 10 minutes clicking an up arrow (and yes, my UI is slow. And I may be exaggerating, but not by much!).
Thank you for your continued improvement!
A common problem with the R tool is that it outputs "False Errors" like the following: "The R.exe exit code (4294967295) indicted an error"
I call this a false error because data passes out of the R script the same as if there were no error. As such, this error can generally be ignored. In my use case, however, my R tool is embedded within an iterative macro, and the error causes the iterator to stop running.
I was able to create a workaround by moving the R tool to a separate workflow and calling it from the CReW runner macro within my iterator, effectively suppressing the error message, but this solution is a bit clumsy, requires unnecessary read/writes, and uses nonstandard macros.
I propose the solution suggested by @mbarone (https://community.alteryx.com/t5/Alteryx-Designer-Discussions/Boosted-Model-Error/td-p/5509) to only generate an error when the R return code is 1, indicating a true error, and to either ignore these false errors or pass them as warnings. This will allow R scripts and R-based tools to be embedded within iterative macros without breaking.
My idea comes when I've built an application, where user select filter from drop-down list. However it contains thousands of records, so it takes lot's of time to find desired record.
In Excel and MS Access when you use filter you can put many letter and filter shows rows that match the input. In Alteryx user can only put first letter, which is huge drawback to my users.
This is how it works in Excel:
Hope you like it!
We all love seeing this. And, it's fairly easy to fix, just go find the macro and insert a new copy. But, then you have to remember the configuration and hope that it was simple.
With the tool that's there, the XML still contains the configuration, all that's missing is the tool path. It would be great to be able to right click and repair the path from the context of the missing macro.
In the newer versions of Alteryx - if you open up a canvas that was created in a newer version, alteryx offers to auto-fix this by opening the canvas anyway.
However if that canvas includes custom macros - these macros are not imported if they are a newer version.
Please could you extend the Newer Version process to include macros used on a canvas, and attempt to import these too?
Idea: Prompt the user to find a missing macro instead of the current UX of a question mark icon.
Issue: When a macro referenced in a workflow is missing, then there is no way to a) know what the name of the macro was (assuming you were lazy like me and didn't document with a comment) and b) find the macro so you can get back to business.
When this happens to me know, I have to go to the XML view and search for macros and then cycle through them until I find the one that's missing. Then I have to either copy the macro back into that location or manually edit the workflow XML. Not cool man.
Solution: When a macro is missing, the image below at the right should be shown. In the properties window, a file browse tool should allow the user to find the macro.
In GIS, spatial data is regularly stored/transmitted as text. With this comes metadata, including the projection used.
Example Issue: When extracting data from ESRI's ArcGIS REST Directories, the projection can be extracted from the information, but must be manually defined in the Make Points Tool. If you are trying to compile data from several different sources, all using different projections, you cannot automate the process.
Suggested Solution: Add WKT to macro interface configuration options so that an Action Interface Tool can update the Create Points Tool.
JSON extract.png - This is a screenshot of the spatial reference metadata in a JSON formatted query from an ArcGIS REST Directory.
action tool.png - Current configuration options for Create Points Tool in the Action Interface Tool.
It would be helpful to be able to embed a macro within my workflows so in the end I have one single file.
Similar to how Excel becomes a macro enabled file, it would be great if the actual macro could be contained in the workflow. As it stands now, the macro that I insert into a workflow is similar to a linked cell in MS Excel that points to another file. If the macro is moved the workflow becomes broken. I often work on a larger workflow that I save locally while developing. Once it's complete, I then save the workflow to a network drive and have to delete the macros and reinsert these. It also makes it challenging if I were to send a workflow to someone else... I will have to give them instructions on which macros to insert and where. Similar to a container, they could be minimized so to speak to their normal icon, and then expanded/opened if any edits were needed....then collapsed when done.
Thanks for the consideration.
The join tool currently does not allow case-insensitive joins, but the find/replace tool does. Additionally- even if both sides are identical, the join tool will not join "Sean's house" to "Sean's house" because of the non-letter character in the middle. Finally - if one side is a string(2), and the other is a vString(200) - even if you have a single identical character on both sides you get uncertain outcomes unless you force the type
Please could you consider amending the join tool to include 3 new options or capabilities:
- Case insensitive join
- Allow full Unicode character set in join
- Full match across text types (irrespective of string size) - this would allow a string(2) value to match to a string(100) value as long as the string(100) value only has the same 2 characters in it as the string(2) value
That would remove a load of work from every text-join that's being done on every canvas we do.
Figuring out who is using custom macros and/or governing the macroverse is not an easy task currently.
I have started shipping Alteryx logs to Splunk to see what could be learned. One thing that I would love to be able to do is understand which workflows are using a particular macro, or any custom macros for that matter. As it stands right now, I do not believe there is a simple way to do this by parsing the log entries. If, instead of just saying 'Tool Id 420', it said 'Tool Id 420 [Macro Name]' that would be very helpful. And it would be even *better* if the logging could flag out of the box macros vs custom macros. You could have a system level setting to include/exclude macro names.
Thanks for listening.
I would like to see In-DB batch macros, currently we are joining tables with 30 million+ records and we are having to run it through standards tools because we are unable to process via In-DB, which has a 20% improvement in processing speed based on the peformance profiling.
Can we get the input tool to automatically convert long filenames to the 8.3 convention inside of a macro?
I've written a batch macro that individually opens files in order to trap files that fail to open. However, when I pass in really long file names it bombs because beyond some length the Input tool converts the path to 8.3 but that logic doesn't fire inside of my macro.
Example of filename:
\\ccogisgc1sat\d$\Dropbox (Clear Channel Outdoor)\Mapping\BWI MapInfo\Workspaces\Local\AEs\Archives\Cara\Sunrise Senior Living\Washington+DC_Adults+55++With+HHI+Of+$75,000++Who+Are+Caregiver+Of+Aging+Parent_Relative+Or+Planning+To+Shop+For+Nursing+Care_Assisted+Living_Retirem.TAB
Despite being an Alteryx user for 2 and a 1/2 years this is something I have only recently came across but it does not appear that you are able to use debug mode appropriately with macros.
What I mean is, I have a macro input which drives a series of drop down boxes. In debug mode my drop down boxes will not populate. Now I understand why, Alteryx doesn't know what the input is so it doesn't generate the meta data for the debug mode drop downs.
What I suggest Alteryx do is automatically convert your macro inputs for file browses for the purpose of debug mode (I had to do this myself manually and it was a tedious task, not only to set up but then maintain two separate versions, one essentially an application and one a macro).
Or, by default debug mode uses the macro input data to run through debug mode as.
When building and debugging batch macros - it is important to be able to add test values and use these for debugging. However, the input values in the interface tools section do not allow input, and the ability to save or load test values also does not work.
While there is a workaround - setting the values in the workflow variables - this does not work fully (it doesn't reflect in the interface view; and is incorrect in the debug report) and is inconsistent with all other macro types.
Please could you make this consistent with other ways of testing & debugging macros?
All screenshots and examples attached
Screenshot 1: not possible to capture test values
Screenshot 2: saving and loading test values does not work
Screenshot 3: Workaround by using workflow variables
Screenshot 4: Values entered do not reflect properly
Screenshot 5: Debug works partially
When building an Alteryx Macro - one of the tough parts is that the input data you put into the Macro Input is used for testing, but you cannot set the type.
So for example - I want to test with the value 1, and Alteryx automatically assumes this is a Byte.
However 1 is just a useful test value, but I need this to be an int 64.
Can we provide the option to strongly type the macro inputs - this way, we can give advanced users the ability to control the type on Macro Inputs, and not run into this sort of issue with test data implicitly defining the type?
Note: this is similar to the idea here:
I decided to get real fancy when building a standard macro the other day. I checked the box on my macro input that made the connection optional:
It worked really well. My macro then became more complex, so I changed it to a batch macro. To my great surpise/astonishment/shock, the optional incoming connection is no longer optional:
The standard macro is working as expected on the left, but the batch macro is producing an error because my optional connection is requiring that something be connected to it.
I've been told that the code to make it optional is not there for batch macros and that this would be a product feature/improvement.
when writing an iterative macro - it is a little bit difficult to debug because when you run this in designer mode, it only does one iteration and stops.
Could we add the capability to the designer itself to be able to run the second and third iteration using the test data built into the macro input tool? Even something as simple as an option to run X iterations; or when it's run the first iteration allow me to look at what happened and trigger iteration 2 (or to trigger a run-through to completion) would be immensely helpful.
While you can do this with a test-flow wrapped around a macro, macro development is a bit of a black box because Alteryx doesn't natively have the ability to step into a macro during run-time and pause it to see what's happening on iteration 1 or 2 or n and why it's not terminating etc. So putting the ability to run in a debug mode would be HUGELY helpful.