Hi,
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.
Is it possible to do the same with FME Server REST API or do we need to specify, each time, NMDirectives when running the transformation (transact or submit) ?
Thanks for your help,
Thibaut.
Looking at the v2 REST API documentation, it doesn't seem possible.
It is true, that when publishing a workspace from FME Desktop you can define the success/failure topics, but those topics are only valid for the jobsubmitter service.
This means that if you use any other service to execute a translation, e.g. the transformations service in the REST API, then you will have to specify the NMDirectives anyway.
@david_r Thank for the answer. Are you sure that these success/failure topics are only valid for the jobsubmitter service? I just published a workspace from FME Desktop to datadownload service and I specified a success topic. When I execute the workspace using the datadownload service from the FME Server Web Interface, the selected topic is well trigger. Perhaps I miss something.
Is there any plan to have the possibility to define default NMDirectives when registering a service to a workplace using the REST API ( /repositories/< repository >/items/< item >/services) ? Could be useful when, for example, a team is responsible of the development of the workspace and their publication to FME Server 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 development team will not receive notification in case of failure.
@david_r Thank for the answer. Are you sure that these success/failure topics are only valid for the jobsubmitter service? I just published a workspace from FME Desktop to datadownload service and I specified a success topic. When I execute the workspace using the datadownload service from the FME Server Web Interface, the selected topic is well trigger. Perhaps I miss something.
Is there any plan to have the possibility to define default NMDirectives when registering a service to a workplace using the REST API ( /repositories/< repository >/items/< item >/services) ? Could be useful when, for example, a team is responsible of the development of the workspace and their publication to FME Server 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 development team will not receive notification in case of failure.
Regarding what Safe has planned, I have no idea. If none of the Safers chimes in here, you could always contact support and ask. You could also post it as an idea here and try to gather support.
Hi @thibaut_gheysen
As I see it there are success/failure topics for both:
DATADOWNLOAD_ASYNC_JOB_FAILURE
DATADOWNLOAD_ASYNC_JOB_SUCCESS
JOBSUBMITTER_ASYNC_JOB_FAILURE
JOBSUBMITTER_ASYNC_JOB_SUCCESS
However, I don't see a way of setting these to a workspace using the API.
I think the best thing to do now is to contact our support team (safe.com/support) and ask about it. Tell them I think it is related to PR#55214. If you can explain why you need to do this, then the FME Server product manager can take a look and see if that ability is one we can add easily - or if there is another solution on the horizon.
Regards
Mark
Hi @thibaut_gheysen
As I see it there are success/failure topics for both:
DATADOWNLOAD_ASYNC_JOB_FAILURE
DATADOWNLOAD_ASYNC_JOB_SUCCESS
JOBSUBMITTER_ASYNC_JOB_FAILURE
JOBSUBMITTER_ASYNC_JOB_SUCCESS
However, I don't see a way of setting these to a workspace using the API.
I think the best thing to do now is to contact our support team (safe.com/support) and ask about it. Tell them I think it is related to PR#55214. If you can explain why you need to do this, then the FME Server product manager can take a look and see if that ability is one we can add easily - or if there is another solution on the horizon.
Regards
Mark
@Mark2AtSafe Thanks for the answer.
Following a discussion with the support team, I created the corresponding idea :
If you are in a hurry, maybe you can use this solution.
If the original REST API is still available, you can look at a workspace properties using this url sample:
http://fmeserver/fmerest/repositories/<repository>/<workspace>/properties?token=<token>
You will have to previously use the v2 API to register your workspace to the jobsubmitter service:
See: http://fmeserver/fmerest/repositories/< repository >/items/< item >/services
You will then be able to set properties using this v1 REST call (POST):
Note that for the topic to be triggered, you have to launch the workspace using a direct service call instead of a REST one. See this link for details.
If you are in a hurry, maybe you can use this solution.
If the original REST API is still available, you can look at a workspace properties using this url sample:
http://fmeserver/fmerest/repositories/<repository>/<workspace>/properties?token=<token>
You will have to previously use the v2 API to register your workspace to the jobsubmitter service:
See: http://fmeserver/fmerest/repositories/< repository >/items/< item >/services
You will then be able to set properties using this v1 REST call (POST):
Note that for the topic to be triggered, you have to launch the workspace using a direct service call instead of a REST one. See this link for details.