ServiceDataParser for Version: 2024.2.1.14

[FkeetGuy]

Running elevated.

I've recently upgraded to Version: 2024.2.1.14 and my ServiceDataParser has broken with the following error 

Plugins cannot be loaded from a DLL path with upward references: 'EngineDll="..\AlteryxService_Client.dll"'

I've trying tried editing the xml for the workflow and the configuration for the tool to use C:\Program Files\Alteryx\bin but no luck. Also tried turning off AMP.

Would appreciate some help with a workaround, thanks

[melissa_m]

I am on the same boat.  Anyone able to figure this out?

[FkeetGuy]

I had to roll back to a previous version. 

[patrick_digan · Accepted solution]

@FkeetGuy @melissa_m I can replicate the issue. After some digging around, here is the most straight forward workaround I could come up with. I don't know if there would be any unintended consequences of copying the file to a second folder. I did verify that I could use the macro as expected once I made the 2 changes below.

1) Copy the AlteryxService_Client.dll from the bin folder to the bin\Plugins folder. For non-admin installs, that would be from %LOCALAPPDATA%\Alteryx\bin\ to %LOCALAPPDATA%\Alteryx\bin\Plugins\ . For admin installs, that would be from %PROGRAMFILES%\Alteryx\bin\ to %PROGRAMFILES%\Alteryx\bin\Plugins\ .

2) Update the xml of the macro to remove the ..\ at the beginning of the engineDLL that points to ..\AlteryxService_Client. I used notepad/notepad++ to change the ServiceDataParser.yxmc file. Here is the line:

I removed the ..\ and then saved the yxmc file:

I can then open the macro in designer and see that it updated the engine dll:

Essentially, it looks like the default EngineDll folder is Alteryx\bin\Plugins. The serviceDataParser used ..\ to move up a folder to the bin folder where the AlteryxService_Client.dll lives. That worked until 24.2 now has an error about not allowing relative references to parent folders. It also appears that any attempt to change the location in the macro using alteryx designer isn't actually updating anything. You can type in whatever you want in the EngineDLL box and it doesn't actually use that; instead, it uses whatever engine Dll info is stored in the .yxmc itself. The box is just read only, but the user can type in the box even though it won't change anything. I was also surprised that writing the full path in the .yxmc and pointing to the file in the bin folder didn't work either. The only way I could get it to work was moving the file to the plugins folder and just referencing the name.

In case it helps, here is the yxmc with that one change. Note that you would still need to do step 1 and copy the dll to the plugins folder for this version of the macro to work.

To the extent that you copy the dll to the plugins folder, this macro should work with any version of alteryx.   

[melissa_m]

Thank you so much @patrick_digan .  It worked!!!!

[FkeetGuy]

Thanks very much, that got me working as well,

appreciate the help

[CailinS]

@patrick_digan thanks for the detailed solution / workaround! @FkeetGuy if you haven't already, it would be great if you could report this behavior through Mission Control -> Case Creation (my.alteryx.com and sign in with your licensed email address). This will allow the Customer Support team to track this issue and the instances of it impacting users like you as well @melissa_m . I'm not personally sure if this is expected or not, but I'm also passing along in case they are working on a Knowledge Article related to this experience.

[melissa_m]

Hi @CailinS , 

Thanks.  I do have an open ticket with Support on this.  I was being told that I dont need the parser as the fields have been made available.  We are using SQLite (not mongoDB) and noted with support that I was able to make it work on our end thanks to the solution provided by @patrick_digan .

[CailinS]

Ok I see, thank you for following up with the context. I will also keep following up internally on the potential creation of a Knowledge article created by Support for folks who encounter this!

[EdP]

Opened as case 00735812