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.
03-24-2020 02:09 AM - edited 12-12-2022 08:27 AM
The following error is seen when you try to execute a workflow or app on the Gallery, or scheduling a workflow on the Gallery.
"Error: Unable to resolve plugin Python 'XXXXX\main.py' (Tool Id: X)"
Generally, this same workflow works fine when you run it locally in Designer.
When a user installs a .yxi tool, the tool is added to the tool palette in Alteryx Designer, and the .yxi file and supporting macros are installed in the User's directory. For server executions, this does not work and your Administrator will need to install a .yxi tool for all Server users in order for scheduled jobs and Gallery executions to work.
Install the .yxi for all Server users by following this Help article . For multi-node Servers, this will need to be done on all Worker nodes.
Hi. I was able to follow your directions and load the SharePoint add-in to the server version of designer.
I no longer get the Unable to resolve Plug-in error, but when I try to run on the server I now get a "Failed to authenticate" error.
Any guidance on this?
Thanks.
Adding the following the list of applicable tools:
Outlook 365 Input Tool
https://help.alteryx.com/20221/designer/outlook-365-input-tool
Unable to resolve plugin Python 'Outlook365Inputv1.0.0\main.py'
Hi,
I am still getting this error.
Unable to resolve plugin Python 'Outlook365Inputv1.0.0\main.py'
I have installed the Outlook tool on the server in Designer using the service account which is a member of the local administrators group for the server.
I have installed the Outlook tool on the server running Designer as admin and selecting "Install for all" via my personal domain account which is a member of the local administrators group for the server.
I have restarted the alteryx service
I have restarted the server (Windows o/s restart)
Any ideas gratefully accepted.
Thanks
Paul
My investigation done at my work determined that we have 3 authentication protocols running, and they were preventing Alteryx from doing its job. We have OKTA, then an Azure AD then another Microsoft protocols.
All three were not playing fairly with Alteryx.
I solved this by getting my IT to setup a Virtual Machine that bypassed the OKTA protocols. I got IT to load up Alteryx on that, and since then (knock-on-wood) I have not had any issues.
Honestly....having an IT team that knows what they're doing regarding the IT ecosystem and security is a curse and a blessing.
Go create a virtual machine and test it out.
-prpatel.
@prpatel thanks, I'm pretty sure there are no authentication issues with the Alteryx server but I'll consider your comments.
To me this seems to be either authorisation or path issues preventing the workflow from accessing/finding the python module?
Right now I'm focusing on the install location. Our server setting for Global workspace is D:\AlteryxProgramData
But the tool has been installed to C:\ProgramData\Alteryx\Tools
I'm looking for more information as to where the workers look for tool code.
So the installer is working as designed...
https://help.alteryx.com/developer-help/package-tool
When installed, Designer extracts the YXI contents to one of two paths, based on the selection by the user:
For my server %ALLUSERSPROFILE% is C:\ProgramData
So the question is will the worker look for the code in C:\ProgramData\Alteryx\Tools if I have the Global workspace set to D:\AlteryxProgramData, or rather, how do I make that happen since it appears that it is not the case by default?
I finally figured this out as I was able to add the tool in Designer on the server to a workflow where the existing tools were not showing/working correctly.
I checked the XML and only then noticed that my users have
Outlook365Input_v1.0.0
Whereas on the server I have installed
Outlook365Input_v1.1.0
I'm slightly annoyed that the plugin methodology for this means that we have to replace all of the tools in the already created workflows to get this working but it is what it is. Also that Designer doesn't make it more clear where the issue lies i.e. the tool name is "human friendly" and hasn't changed but the actual plugin name has changed and that is the primary key on which this whole thing is based.
thanks! I had installed on server - but not for all users. That did the trick!