This is something that should have been specified during the installation of the remote engine. Here's where you should enter the UNC path to the main server share:
You will also have to make sure that the distributed engine service is executed as a domain user with network access and the necessary rights to the folder pointed to in the UNC path. This domain user is specified in the preceding step of the distributed engine installation.
This is something that should have been specified during the installation of the remote engine. Here's where you should enter the UNC path to the main server share:
You will also have to make sure that the distributed engine service is executed as a domain user with network access and the necessary rights to the folder pointed to in the UNC path. This domain user is specified in the preceding step of the distributed engine installation.
Yes, this was all configured correctly during the remote engine installation. There are no issues communicating between the two servers. The issue seems to be that the directory watch is being run on fme server and when the directory watch is not actually passing the $FME_SHAREDRESOURCE_DATA to the fme workbench, but rather it converts the location of the file to a string of the fme server's machine local location and is not the UNC path. If the workbench actually received the variable as $FME_SHAREDRESOURCE_DATA this should not be an issue I don't think.
Yes, this was all configured correctly during the remote engine installation. There are no issues communicating between the two servers. The issue seems to be that the directory watch is being run on fme server and when the directory watch is not actually passing the $FME_SHAREDRESOURCE_DATA to the fme workbench, but rather it converts the location of the file to a string of the fme server's machine local location and is not the UNC path. If the workbench actually received the variable as $FME_SHAREDRESOURCE_DATA this should not be an issue I don't think.
Aha, that's an interesting twist. Sounds like you should flag this to Safe support, either directly or through your FME reseller. It could be a bug / missing functionality.
I just wanted to add a quick note to this post to say that Safe were able to work with @adriano_n90 to resolve this issue.
The problem was occurring because the FME Server Automation Triggers are run by Core processes, since Adriano started with an Express install the File System referenced the default C drive location as opposed to a UNC path. These definitions are loaded into the database for core processes to use when FME Server is first installed.
In Automations the output keys from each event store the fully qualified file path as opposed to referencing the FME Server macros, meaning that the distributed engines were looking for the file in the wrong location (their local C drive) and therefore the jobs were failing as the file does not exist here.
Therefore at this time to resolve this issue we need to go into the backend database to update the shared resource file paths to point to the UNC path to the file share. If you encounter this issue please contact Safe Software Support and we can walk through this process with you. FMESERVER-14874 is being used to explore how we can improve this user experience.
I just wanted to add a quick note to this post to say that Safe were able to work with @adriano_n90 to resolve this issue.
The problem was occurring because the FME Server Automation Triggers are run by Core processes, since Adriano started with an Express install the File System referenced the default C drive location as opposed to a UNC path. These definitions are loaded into the database for core processes to use when FME Server is first installed.
In Automations the output keys from each event store the fully qualified file path as opposed to referencing the FME Server macros, meaning that the distributed engines were looking for the file in the wrong location (their local C drive) and therefore the jobs were failing as the file does not exist here.
Therefore at this time to resolve this issue we need to go into the backend database to update the shared resource file paths to point to the UNC path to the file share. If you encounter this issue please contact Safe Software Support and we can walk through this process with you. FMESERVER-14874 is being used to explore how we can improve this user experience.
Hi @hollyatsafe, thanks a lot for this information, much appreciated!
I just wanted to add a quick note to this post to say that Safe were able to work with @adriano_n90 to resolve this issue.
The problem was occurring because the FME Server Automation Triggers are run by Core processes, since Adriano started with an Express install the File System referenced the default C drive location as opposed to a UNC path. These definitions are loaded into the database for core processes to use when FME Server is first installed.
In Automations the output keys from each event store the fully qualified file path as opposed to referencing the FME Server macros, meaning that the distributed engines were looking for the file in the wrong location (their local C drive) and therefore the jobs were failing as the file does not exist here.
Therefore at this time to resolve this issue we need to go into the backend database to update the shared resource file paths to point to the UNC path to the file share. If you encounter this issue please contact Safe Software Support and we can walk through this process with you. FMESERVER-14874 is being used to explore how we can improve this user experience.
Thanks for your support for helping me resolve this issue and your great explanation of the solution holly.
