This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
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.
We are working on building out training content in a story mode and would like to have short snippets playing in a loop for people to see embedded in the workflow. Currently you can add a .gif to a comment background and it will provide a still image on the worklfow itself but functions as a gif in the configuration display. The interesting part is when you are running the workflow the .gif works and then it pauses it when the workflow has completed!
Example GifGif upload in comment and playing in the configuration windowGif in workflow when uploadedGif after workflow run
To get simple information from a workflow, such as the name, run start date/time and run end date/time is far more complex than it should be. Ideally the log, in separate line items distinctly labelled, would have the workflow path & name, the start date/time, and end date/time and potentially the run time to save having to do a calculation. Also having an overall module status would be of use, i.e. if there was an Error in the run the overall status is Error, if there was a warning the overall status is Warning otherwise Success.
Parsing out the workflow name and start date/time is challenge enough, but then trying to parse out the run time, convert that to a time and add it to the start date/time to get the end date/time makes retrieving basic monitoring information far more complex than it should be.
Is there a possibility of changing the behavior of Event or the email tool itself to not use anonymous relays?
Our Security team does not want to white list desktops, and a lot of our customers don't use server. Our server IPs have been whitelisted and a couple of desktops, but that's it. So looking to see if an enhancement can be considered for the Email tool and the Event set up.
Here is what we received from Alteryx Support:
Alteryx sends anonymous email, and there is no way to tie (or spoof) a separate IP address to the email to let the server know where it's coming from, or to make it "non-anonymous." The email tool is a very basic SMTP client that currently does not support SSL or authentication. As such if the SMTP server you are connecting to requires SSL or authentication to relay messages the tool will fail to send the intended message(s). If the server IP hasn't been blocked to send anonymous email, you can test in Designer on the server to see if you receive the same error. If it works on the server, you should be able to send emails from workflow scheduled on gallery. Since the IP of the machine itself is blocked from sending anonymous email, there is nothing we can do on our end to resolve the issue for each individual Alteryx user. IT will have to white-list any IP that wishes to send anonymous email.
It would be nice if you could see messages generated by SQL server in through the Alteryx tools that are communicating with the server.
2 examples to illustrate: I was reading in a table, Alteryx gave me no errors, just a message that a certain number of records was read in (about 5M). Since I don't know the exact number of records in the table, just that there are approximately 5M, I thought everything was ok until somebody else pointed out that revenue past a certain date was missing. Turns out that reading in the data was interrupted by an error sql was throwing on a calculated field. Fixed the calculated field and was able to read in all records. It would have been nice if Alteryx had mentioned the error instead of reading in a partial table....
The other example was an output tool that was giving me this error: "An unknown error occured in II_PushRecord". This was caused by a fatal truncation error in SQL. The problem was solved by putting a select tool ahead of my output tool and forcing the field to match. I could have solved that a lot faster if Alteryx had giving me the error from SQL instead of the cryptic PushRecord one.
I understand that this might be challenging, not sure how the SQL drivers behave in regards to reporting error messages. One workaround for the first error would be to count all rows in a table before reading it in, then reading it in and giving a message similar to the one you get from a Calgary tool (5,968 records out of 4,684,784 where read in). Maybe as an option because it might slow things down a bit?
In a short workflow, this might not be necessary as the information related to each tool is spelled out in the progress windows. However, in a complicated and lengthy workflow, tracing such msg can be a tedious task. In addition, using a tool with multiple outputs and only one output is selected while the residual outputs may be used to validate the result in the selected output; for example, joint tool where left or right output should be zero, a visual queue could be a quick way to alert operator on any potential problem. Certainly, a browse tool can be added but in a big workflow, couple with a large data set, it might be a drain to the system resource. What if there is a tool that would activate a visual alert, like a light bulb, based on a preset condition to tell user that something is wrong and perhaps additional work needs to be done to either remedy or to account for the residual data. As in the case of a joint where 100% match is desired, any unmatched row would require an update to the reference list which maybe an additional adhoc process outside the current process. Certainly, an additional steps can be added to first explore the possibility of unmatched data and to update the reference list accordingly. The workflow would in hold until 100% match is achieve. This would require additional system resource in order to hold; especially with large set of data and lengthy workflow. If the unmatched situation rarely occurs, just a lightweight visual queue that 'pop' while allow the process either to break or to go through might be a sensible solution. Just a thought.
When outputting to files in avro format, it would be nice to have Alteryx either throw an error/warning or automatically add a prefix when field names do not conform to the Apache Avro specifications. For example, if I were to try to output an .avro file with a field named "2018 actions", Alteryx could throw a warning/error to remind me to rename the field, or Alteryx could change the field name for me to something like "X2018_Actions".