Cannot Publish Workflow with Embedded Macro

[Jake_Jake_Jake]

Just getting started with Alteryx and cannot publish a workflow with a macro to the server. I have tried getting rid of all macros and reloading them, ensuring the macros is stored with an UNC path that the server can access, giving myself full server access, and selecting "Manage workflow assets" when saving it to server.

The watered down test workflow is simply this:

This is the error that I get:

 

Anyone run into this issue?

[BenMoss]

This looks like it might be a macro-ception issue, i.e. that macro itself contains another macro; could you check this by doing right click and open macro?

Ben

[kat · Accepted solution]

Hi @Jake_Jake_Jake

The crew wait a second macro contains an embedded macro.

There are two ways of dealing with this, that I normally use.

1. Install the Crew Macros on the server. I think that this is probably the best solution, as you'll often be using crew macros. This way all workflows published to the server that use Crew can rely on them. You then don't need to attach them in a workflow.

2. If you have a macro in a macro and you want to attach this to your workflow, you need to follow a slightly different process. The normal way of embedding assets only allows first level embedding.

• click onto the canvas
• go to events in the config tab
• select add > send email
• go to the assets tab
• attach the CReW_WaitASecond.yxmcbatch file (it will be in the folder in which you installed the crew macros)
• go back to the email tab and click OK
• when you now publish your workflow, you will see the second macro as a file to embed. Make sure it's ticked and it will be saved to the gallery with your workflow.

Also just by the way - sometimes when you publish things to the server it shows an error. This is because the server itself may not have access to the file location. However, when you run it under your user it works, provided you have the access. So sometimes worth trying to run a workflow, even if it had errors.

Hope this helps!

Kat

[BretCarr]

Does anyone know if this workaround still works? This is a giant PitA.

[mkbhagat]

Thank you KAT for the solutions. It works for me. We will also have to provide SMTP host details as we are configuring the Send email feature. 

[BretCarr]

Ok, so it has been 7 months since I posted about this. I finally figured out the sure-fire way to ALWAYS get this macro-in-a-macro-in-a-macro-in..etc. (I'm going to call this the "Stuffed Macro") issue to work.

RELATIVE PATHS for related macros in the dependencies settings.

When you attach the macro stuffed full of macros into your workflow, each layer of the macro is still looking for the other macros exactly where they were when you added it to the workflow. When that macro is uploaded to the server, even when the assets are checked to upload with them and show they've been uploaded, too, the paths to those macros will still work locally because their dependencies are still in the same place...

...on the server, however, those locations likely specific to your machine won't work any longer--the server can't find these locations!

SOLUTION:

1. Save your solution to the server and let it fail but DON'T CLOSE THE WORKFLOW YET.
2. You must now act quickly because certain events will move/clear your staging area
3. While still in the workflow, open up the primary Stuffed Macro.
4. Copy (☠️ don't MOVE them!!! ☠️) your internal macro(s) and save them in the same folder in the temp staging area where the Stuffed Macro is currently saved on your local drive.
5. Navigate to Options > Advanced > Workflow Settings
6. Click the "All Relative" button.
7. OK
8. Repeat as necessary down your rabbit hole of macro layers.
9. Save all assets back to the server.

If you did everything correctly, which may take a few times and some swearing, you should get a green light verification upon save and a nice, fully-working workflow!

Phew! Happy solving!

[Jay-RDC]

Has anyone found an easier way to do this or is this still a pita?

[BretCarr]

Reading my original solution, it still seems correct. Are you running into something else?

[jpaplanus]

Hi @BretCarr. I am attempting to use your solution but running into a snag. My situation is identical to the OP where I am trying to use the CReW Wait a Second macro. It has the embedded macro CRewWaitASecond.yxmcbatch and when I go to save this to the temp staging folder it tells me there is already a file there with the same name (CReWWaitASecond.yxmc) and asks if I want to override that. I have not tried yet because I did not want to cause any separate problems. Have you seen a situation like this and should I go ahead and override?