Start in: \\<UNC path where the batch file is stored>
Any ideas would be greatly appreciated!
Best answer by ninixink
Thanks, everyone for your answers. I have got it to work in the end and only have time to come back and share my solution/experience and hope someone else might benefit from that.
I have changed my code to 1 line only (if you copy straight from FME it will break into several lines), and you only want one line of code in your batch file. And like @hkingsbury mentioned above, no caret needed (^). So something like this:
In the Task Scheduler, Actions were set as follow:
Start a program
Program/Script: \\<UNC path where the batch file is stored>\UpdateData.bat
Start in: \\<UNC path where the batch file is stored>
And as @rahulsharma mentioned above, the users have to have full access to the UNC path and other paths that are mentioned/used in the bat file and within the FME workspace.
As @nielsgerrits mentioned, WorkspaceRunner is the transformer to use here.
I do note you have a caret (^) in your system call - you shouldn't need that
I'm also assuming you don't have FME Server? There's some really good scheduling tools in that
Thanks @hkingsbury , we do have FMEServer but we have been having issues with it and couldn't figure out how to make it work for more than a month already so I just sort of giving up on using the schedule function in FME Server.
Our problem is we are using arcpy (Esri arcpy 3.6) in the PythonCaller in our workspace to call and delete and append features in our geodatabases.
The workspace works fine in FME Desktop both in my local machine and server machine but failed with FME Server even though in the log files it pointed to the correct python library, it still complained it couldn't find that tool we are using (arcpy.deletefeature_management for example).
It also creates an issue where it burns out our FME Server memory, dumped all Java memory crash logs files in the FME temp folder, and in the end quickly crashes the whole server.
Thanks @nielsgerrits , I have used WorkspaceRunner, it says the workspace run successfully but I don't think the main workspace actually runs since I didn't receive any email sent to my inbox (I've set Emailer in the main workspace to notify when the workspace finishes) and there was no data update.
Thanks @hkingsbury , we do have FMEServer but we have been having issues with it and couldn't figure out how to make it work for more than a month already so I just sort of giving up on using the schedule function in FME Server.
Our problem is we are using arcpy (Esri arcpy 3.6) in the PythonCaller in our workspace to call and delete and append features in our geodatabases.
The workspace works fine in FME Desktop both in my local machine and server machine but failed with FME Server even though in the log files it pointed to the correct python library, it still complained it couldn't find that tool we are using (arcpy.deletefeature_management for example).
It also creates an issue where it burns out our FME Server memory, dumped all Java memory crash logs files in the FME temp folder, and in the end quickly crashes the whole server.
Have you been in touch with support re your FME server? They'll be able to help you diagnose the problem
Thanks, everyone for your answers. I have got it to work in the end and only have time to come back and share my solution/experience and hope someone else might benefit from that.
I have changed my code to 1 line only (if you copy straight from FME it will break into several lines), and you only want one line of code in your batch file. And like @hkingsbury mentioned above, no caret needed (^). So something like this:
In the Task Scheduler, Actions were set as follow:
Start a program
Program/Script: \\<UNC path where the batch file is stored>\UpdateData.bat
Start in: \\<UNC path where the batch file is stored>
And as @rahulsharma mentioned above, the users have to have full access to the UNC path and other paths that are mentioned/used in the bat file and within the FME workspace.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
