Looks like it's a set of calls you have to make... Did you look at network tools when you create one? I would start there.
Looks like it's a set of calls you have to make... Did you look at network tools when you create one? I would start there.
Good tip @runneals, I will have a look at that, but was hoping somebody from Safe would chime in and provide some more information on the issue.
It looks like all you really need to do is recursively loop through all your repositories and get all the workspaces inside of them (see the example I have here). Then it looks like you can either A) Create a token for each of the workspaces (using the token API) with the permissions of Run Workspace = Access and setting the name/description based on each workspace or create a single token to use. Once you have the token, use the url string of https://fme.gov/fmeserver/?run=[token]#/workspaces/demo/[repository]/[WORKSPACE.fmw]/fmejobsubmitter.
Either way, it appears that if you know the repository and the workspace name and have a token with the run workspace permission, it looks like you can run any workspace that the token user has access to. @rylanatsafe might be nice to implement more granular security so you can set permissions by repository or even by workspace.
It looks like all you really need to do is recursively loop through all your repositories and get all the workspaces inside of them (see the example I have here). Then it looks like you can either A) Create a token for each of the workspaces (using the token API) with the permissions of Run Workspace = Access and setting the name/description based on each workspace or create a single token to use. Once you have the token, use the url string of https://fme.gov/fmeserver/?run=[token]#/workspaces/demo/[repository]/[WORKSPACE.fmw]/fmejobsubmitter.
Either way, it appears that if you know the repository and the workspace name and have a token with the run workspace permission, it looks like you can run any workspace that the token user has access to. @rylanatsafe might be nice to implement more granular security so you can set permissions by repository or even by workspace.
Hi @runneals, yes I have come to the same conclusion, thanks for looking it up.
Will give it a spin and see how it goes.
Cheers,
Itay
It looks like all you really need to do is recursively loop through all your repositories and get all the workspaces inside of them (see the example I have here). Then it looks like you can either A) Create a token for each of the workspaces (using the token API) with the permissions of Run Workspace = Access and setting the name/description based on each workspace or create a single token to use. Once you have the token, use the url string of https://fme.gov/fmeserver/?run=[token]#/workspaces/demo/[repository]/[WORKSPACE.fmw]/fmejobsubmitter.
Either way, it appears that if you know the repository and the workspace name and have a token with the run workspace permission, it looks like you can run any workspace that the token user has access to. @rylanatsafe might be nice to implement more granular security so you can set permissions by repository or even by workspace.
We are definitely aware of the growing number of requests for workspace-level permissions, and I'll invite anyone interested to show their support by voting for this idea on the FME Community pages.
Currently, it's not something we are looking to address in the short term (count = months).
>...] it looks like you can run any workspace that the token user has access to.
The tokens that you create for FME Server Apps will have permissions to run any workspaces for that entire Repository it is contained within on FME Server. Definitely something to keep in mind should you start to make public Server Apps. The token should be restricted to only that Repository (Read, Run) and none other.
Looks like it's a set of calls you have to make... Did you look at network tools when you create one? I would start there.
@runneals @itay The FME Server Apps workflow does run on a number of REST API calls, that, as you know, are not currently documented.
You certainly could use Web Dev Tools to investigate the pattern – it's not particularly something we are trying to keep secret; we have simply opted to not expose any API endpoints due to the ongoing development. For example, the experience between 2019.0.x and 2019.1 has changed (significantly, by some opinion).
It would be helpful to continue to hear the use cases that you would be interested in, and definitely include why it would benefit your workflows. Until now, we have not heard any demand for users to have the ability to programatically create FME Server Apps with a series of calls to the REST API.
If there are operations in particular that would be more important than others, that would be great to note – for example, I imagine Enable / Disable is more important than Create, but that's only my guess. We need to hear it from those on the ground, so to speak!
It looks like all you really need to do is recursively loop through all your repositories and get all the workspaces inside of them (see the example I have here). Then it looks like you can either A) Create a token for each of the workspaces (using the token API) with the permissions of Run Workspace = Access and setting the name/description based on each workspace or create a single token to use. Once you have the token, use the url string of https://fme.gov/fmeserver/?run=[token]#/workspaces/demo/[repository]/[WORKSPACE.fmw]/fmejobsubmitter.
Either way, it appears that if you know the repository and the workspace name and have a token with the run workspace permission, it looks like you can run any workspace that the token user has access to. @rylanatsafe might be nice to implement more granular security so you can set permissions by repository or even by workspace.
@runneals After some trials I can now create shareable urls via the REST API. Next to creating the token and adding the permissions to run the workspace an extra call is needed to set the resource permissions for the token.
@rylanatsafe I have added my vote to the idea and will keep in mind the fact that all workspaces in the repository are available via the token and the token should be restricted.
Looks like it's a set of calls you have to make... Did you look at network tools when you create one? I would start there.
@rylanatsafe I can imagine that since the FME Server Apps are quite new, that no demand has been heard (yet).
In my case I am thinking about setting up a public translation service and the reason why I would benefit from it is simple...instead of having to login and manually create the url I rather have an workspace doing it for me and some other things too (such as mailing it to the customer and updating the administration records)
I imagine (and hope) that once the FME Server Apps reach a certain maturity and stability, documentation (or maybe a special REST endpoint) would be made available.
Looking forward to the new developments in 2019.1 for now I have it solved and can continue with automating my project.