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.
Generally speaking, it's a good idea to run a module from the Scheduler database instead of a local path unless that module is going to be updated frequently, and you want the module updates to be reflected when run from the Scheduler. If you do need to Schedule a module from a local path, however, there's several possible reasons why a module run can end up a "corrupted" state, but most likely the module isn't being found correctly by the Scheduler when it's time to execute.
The first suggestion is to verify that that app runs correctly when run from the Scheduler database. Try scheduling the module in this fashion, does it run correctly?
If the module does not run when scheduled in this fashion, then we should examine your Scheduler setup in more detail, as there may be other problems lurking.
If it does run, hooray! And on to the next step...
When running module from a local location, it's critical that the path you choose is available to (and readable by) the Scheduler, otherwise the module will not be located and execution will fail. By default, the Scheduler will execute a module as the System account, but your Scheduler may be configured with a "Run As" user in the System Settings dialog:
Regardless of the user under which your Scheduler is running, the module path must be available to that user. If you schedule a module from your local account referring to a drive alias (for example, G:\my_modules\module.yxmd) or UNC path (for example, \\remote_drive\my_modules\module.yxmd), that same path must be available to the Scheduler.
Can you please confirm that the paths you're using are available to the Scheduler? If not, try scheduling the module from a path that is available... perhaps that fixes it?
If you have further questions or continue to have difficulty, feel free to follow up here. I would also encourage you to reach out to your support contact at Alteryx or to Client Services (firstname.lastname@example.org) so we can resolve this matter quickly.
@ericy330 -- If @SteveA's suggestion did not work for you, you might want to try downloading the newest version of Alteryx (10.1, which was released yesterday). I was having a similar issue as the one you're seeing, and it's been fixed with 10.1.
The log is telling us that the Server does not have permissions to access those shared resources (the UNC paths). You need to ensure that the UNC paths accessed by the scheduled module are readable by the account used by the Server when processing workflows. By default, the Server will run workflows as a Service account, but that can be changed by specifying a "Run-As" user on the Server as described in this thread.
Specify a Run-As user on the Server with correct access permissions to shared resources accessed by modules scheduled on the Server
Leave the Server configuration unchanged but modify the access permissions on the shared resources to allow access to modules scheduled on the Server
Make sure you open the workflow that you want to schedule from the network location before scheduling. So when you open the workflow initially, browse to the network location instead of the absolute location and then schedule. This worked for me.