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.
Do you use Alteryx in a language other than English? If so, we want to hear from you! Please help us improve the international experience of our products by participating in this 5 minute survey.
We are updating the requirements for Community registration. As of 7/21/21 all users will be required to register a phone number with their My Alteryx accounts. If you have already registered, you will be prompted on your next login to add your phone number.
I'm attempting to automatically deploy Alteryx solutions to Alteryx Server via Azure DevOps CICD. In order to do that in the way I need it, I have to figure out how to take a folder full of yxmc and yxmd files and programmatically turn that into a yxzp.
We know that yxzp files are a compressed binary format. If you change the extension from yxzp to zip and unpack, you'll find the constituent workflows. The challenge that I'm hoping the community can assist me with is finding a means of doing the opposite.
Unfortunately it doesn't seem as simple as compressing a file or collection of files and changing the extension to zip.
Quick nomenclature abbreviations that I'll be using…
p-yxzp: properly created yxzp using the export option in Alteryx
c-yxzp: custom yxzp created by manually compressing one or more workflows/macros then changing the extension to yxzp
Here are my observations:
Practical loading - loading a yxzp into Alteryx
p-yxzp: after unpacking Alteryx knows to open the primary workflow of that yxzp
c-yxzp: Alteryx unpacks the file but does not open any of the constituent workflows
Xml file differences
The primary workflow of the yxzp has additional code added to it (in red) describing encoding and MetaInfo of the outputs of any connectors in the workflow: (See the attached images)
When tested with a parent workflow that calls a child workflow, I found that the child workflows and macros are unchanged
I tried copying the xml from the resulting primary workflow of the unpacked p-yxzp and using that code in a workflow where I then manually zipped it up and changed the extension but I didn't get the desired result upon opening in Alteryx.
Packaging a yxzp using Alteryx must be doing something to indicate what the primary/parent workflow is but I can't tell what the indicator is. I feel like figuring this part out would crack the problem.
@PWD5032 I just saw your post (a few months late I know). I'm not sure exactly how @tlarsen7572 solved it, but in this post I pointed out that the p-yxzp has a comment field in the properties that contains the name of the workflow that should open up.
Thank you for teaching me Python. Seriously. I've been dissecting the code for a project of mine and I learned a lot. However, I do have some issues with the code.
Two things: 1. The yxzp files weren't actually getting compressed. Opening them in Notepad++ revealed all the XML, prefaced and suffixed with binary code. Adding zipfile.ZIP_DEFLATED inside create_package(*args) fixed that.
with zipfile.ZipFile(yxzp_full_path, 'w', zipfile.ZIP_DEFLATED) as current_package:
2. OK, here's the showstopper. The comment added to the compressed yxzp file works great, in that Alteryx Designer knows which file to open after importation. It works with yxzp files of one workflow or workflows with supporting macros.
But when attempting to publish the newly minted yxzp to Alteryx Server, only compressed files with no internal directory structure will succeed. (Using Postman to POST to the /api/admin/v1/workflows/ endpoint.)
First, there's this in the logs:
There was an unknown error executing the application. The engine reported status Error
Then if a run is attempted, this:
Problem Loading App
Could not create Directory "C:\ProgramData\Alteryx\Service\Staging\XProcessCache\F82B7A2A82F54356\_externals/1/"
If I take the same workflow and export it from Designer, the file is the same size but there are no issues with either publishing via Postman or running the app in Gallery.
I'm at a loss on what is missing from or wrong with the output of the Python code.
Hello @DavidM ! Yes, I have been through both sets of code and used both the Python tool in Designer and PyCharm. I used the latter to step through the code. But the problem is not the creation of the yxzp but the error when publishing via a POST to the /api/admin/v1/workflows/ endpoint. It goes in and I get the unique ID back but the logs show a failure after that.
I did some further playing and discovered that the server is OK with one layer of subdirectories but it barks at any subdirectories nested within the first layer. My solution will be to create some code to copy the nested directories to the root then delete the _externals folder. This does necessitate a pass through the affected workflows, apps, and macros to correct the paths to the content in the subdirectories. But I'm already doing something like this to swap out old data sources for shiny new Gallery Data Connections in the destination server.
(Off topic, I had written my "replace old data sources with new" in R, using readLines() and gsub(). Worked great in R Studio; the R tool chokes on files longer than a thousand or so. I might try it in Python.)