Solved

same parameter name, different meaning for desktop and server

  • 10 October 2018
  • 5 replies
  • 3 views
tnarladni
Rank
Badge +9

So I've asked this question of the FME server team, but I'm hoping someone has a work-around I can try. I want to specify, I don't want to use a table with locations, I don't want to use python to map to the right location either. Maybe there isn't a way to do what I want.

So I have some workspaces that run nightly. I want to test them on desktop as well as our development fme server. There's a production fme server as well.

For .sde connections: I created a folder (sdeConnections) on the E drive of each of the server environment and the connection files go in there. on desktop, I am mapping E:\\ to a network shared location. The E drive on desktop and the dev server both have connections to development databases. fme workspace authors will use these connections to test their workspaces. They can publish them to any of the environment and data will be read from the right database and will write to the right database. Only issue is that whenever you publish them, fme server wants to upload the connection files and you always have to uncheck.

I also create ffs file in one of the jobs and on dev or desktop, should go to 1 location and another on prod. I created a network resource called ffsLocation pointing to a network share. In my workspace, I also create a published parameter called ffsLocation pointing to a network share. Now, when I publish the workspace to FME server (either dev or production, I want it to read the resource and not the parameter. But it's not and the only way for it to do so, is for me to specify $(ffsLocation) in the published parameter box when I run the workspace. The reverse is that if I don't create a parameter, I can't use the resource in desktop.

Now, to read the ffs file (which I do need to do in some workspaces), I can specify that as a reader source, but I can't use it to write to it. Weird right?

What is even more confusing is that I can create a database and web connection on FME server, and create the same ones on desktop and I can use it regardless of which environment I publish the workspace to. FME server tells me that connection already exists. I would love to be able to use resource/parameter the same way.

The end goal is to have one workspace (already version controlled in bitbucket) and be able to make it work seamlessly regardless of dev or prod, desktop or server.

Would love your thoughts on this.

icon

Best answer by mark2atsafe 10 October 2018, 22:42

View original

5 replies

nielsgerrits
Rank
Userlevel 6
Badge +32

Do I understand correctly you want to run a workspace with dev / test / prod parameters?

My solution for this is to check the fme server engine parameter ($(FME_ENGINE)) to determine if it is running in dev, test or prod and assign parameters accordingly.

tnarladni
Rank
Badge +9

Do I understand correctly you want to run a workspace with dev / test / prod parameters?

My solution for this is to check the fme server engine parameter ($(FME_ENGINE)) to determine if it is running in dev, test or prod and assign parameters accordingly.

What do you mean assign parameters? Do you have a sample workspace so I can understand better?

 

 

mark2atsafe
Rank
Userlevel 4
Badge +25

If I'm reading this right, in terms of published parameter, I think what you might need is a parameter of type Choice with Alias. You have a parameter where you can choose from Dev, Test, or Production; but the value returned is the path to the FFS file. You can link that parameter to the FFS reader/writer parameter, and it should work just fine. You just pick the parameter value when you run the workspace.

However - as I think @nielsgerrits was saying - you could also set the parameter depending on the value of the $FME_ENGINE parameter. I know you said no Python, but this should be fairly simple. Create a parameter of type Scripted (Python). In there set it up to be If $(FME_ENGINE) = Test then FFSPath= xyz, else If $(FME_ENGINE) = Prod then FFSPath = abc, else... etc - then just link that parameter to the FFS reader/writer. Then you don't have to pick anything at run time; it just works.

But to take a step back a bit... is this the best way to do things? Well I think the scripted parameter is designed for this sort of scenario. It just means you have to maintain it within FME. If you don't want to set things up that way *within* FME, then what you could do instead is use an environment variable.

For example, set up your FFS writer to write to %SystemDrive%\\FMEOutput\\FFS (or whatever) using either a preset environment variable or creating one of your own. Then you can push that workspace to FME Server and it will use whatever the variable is set to on that machine.

That makes sense to me. I mean, you're talking about different environments, and for that there are environment variables. FME can use one of those in its parameters for reader or writer.

tnarladni
Rank
Badge +9

If I'm reading this right, in terms of published parameter, I think what you might need is a parameter of type Choice with Alias. You have a parameter where you can choose from Dev, Test, or Production; but the value returned is the path to the FFS file. You can link that parameter to the FFS reader/writer parameter, and it should work just fine. You just pick the parameter value when you run the workspace.

However - as I think @nielsgerrits was saying - you could also set the parameter depending on the value of the $FME_ENGINE parameter. I know you said no Python, but this should be fairly simple. Create a parameter of type Scripted (Python). In there set it up to be If $(FME_ENGINE) = Test then FFSPath= xyz, else If $(FME_ENGINE) = Prod then FFSPath = abc, else... etc - then just link that parameter to the FFS reader/writer. Then you don't have to pick anything at run time; it just works.

But to take a step back a bit... is this the best way to do things? Well I think the scripted parameter is designed for this sort of scenario. It just means you have to maintain it within FME. If you don't want to set things up that way *within* FME, then what you could do instead is use an environment variable.

For example, set up your FFS writer to write to %SystemDrive%\\FMEOutput\\FFS (or whatever) using either a preset environment variable or creating one of your own. Then you can push that workspace to FME Server and it will use whatever the variable is set to on that machine.

That makes sense to me. I mean, you're talking about different environments, and for that there are environment variables. FME can use one of those in its parameters for reader or writer.

Thanks for the suggestions @Mark2AtSafe. I didn't think about using environment variable and I really like that idea! Except it doesn't work. Or maybe I'm doing it wrong?

 

I created a variable, tested that it navigate to the right location. I used it in the writer:

 

%PODS_HIE%\\hierarchy.ffs

 

All it did was create a folder in the current location of the workspace with the name %PODS_HIE%. lol. Obviously I'm not doing something right.
mark2atsafe
Rank
Userlevel 4
Badge +25
Thanks for the suggestions @Mark2AtSafe. I didn't think about using environment variable and I really like that idea! Except it doesn't work. Or maybe I'm doing it wrong?

 

I created a variable, tested that it navigate to the right location. I used it in the writer:

 

%PODS_HIE%\\hierarchy.ffs

 

All it did was create a folder in the current location of the workspace with the name %PODS_HIE%. lol. Obviously I'm not doing something right.
Try using ${PODS_HIE} - making sure to use the curly braces, not round or square. That should read an environment variable for you. One of those oddities of FME that I just remembered about. Sorry I didn't remember that earlier.

 

Like this this question: https://knowledge.safe.com/questions/24619/how-to-use-environment-variables-in-user-parameter.html

 

Reply


Community Stats

28,670
Posts
109,366
Replies
36,531
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.