Skip to main content
  • EN

When publishing a workspace from FME Desktop to FME Server, we can specify the success/failure topics to raise at the end of the execution. Unfortunately, it's not possible to do the same by using the REST API (https://knowledge.safe.com/questions/33872/define-sucessfailure-topics-when-publishing-worksp.html#answer-34135). Meaning that we have to explicitly specify the NMDirectives when running the transformation (transact or submit).

Could be useful when, for example, a team is responsible of the development of the workspace and their publication to FME Server (done inside a continuous integration/deployment environment relying on FME REST API) while a lot of different clients can consume those services and some of them will perhaps forgot to specify the NMDirectives (even if specified in the documentation). In such situation, the FME development team will not receive notification in case of failure.

With FME Server 2017, there is a new feature called Projects that allows you to move FME Server workflows/solutions/automations from one FME Server to another. You define a project to contain any number of components (e.g. workspaces, subscribers, resource files, schedules) and then export it - then you can import it on another FME Server. The idea is to support the deployment of solutions through the dev/test/staging/prod cycle and continuous integration/deployment. The definition of projects, their export and import can all be done through the REST API.

I wonder if the Projects feature can be used as an alternative to the idea here? This means you initially publish workspaces to FME Server using FME Workbench, however, the subsequent deployment of those workspaces from one stage/environment to the next is scripted/automated.

Give it a try and let use know what you think.

https://knowledge.safe.com/articles/44299/tutorial-automation-planning-and-deployment-with-f.html

I'd also suggest sharing the details of your multistage (dev/test/prod) or continuous integration/deployment solution over here in this Q&A:

https://knowledge.safe.com/questions/35716/how-can-i-move-a-solution-from-my-development-envi.html

Here as well (more from the community - related to configuration files for different environments):

https://knowledge.safe.com/questions/34975/moving-workspaces-between-fme-installs-tips-and-tr.html

I'm sure the rest of the community would really value learning how you do it.

I could not recapitulate this better. Thanks for putting this up!

 

 

The whole projects-idea is definately a step into the right direction. In my work I mostly have no access to all stages of the continuous integration cycle, and have to hand over some install-package to the maintainers upwards.

 

 

Have not yet explored the boundaries of this new projects feature as my current client is still on 2016 and only wants to upgrade every 2 years. I'll have to experiment in non-billable hours. Hopefully by communicating to Safe on our experiences during real world use, we can together make this thing work.

 

For us the use case is internal, just streamlining the process of setting up a new customer. Most can be done with the REST API, however, this step still has to be manual :(

Open→Archived

Community Stats

31,842
Posts
120,950
Replies
39,474
Members

Latest FME

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.