-
Notifications
You must be signed in to change notification settings - Fork 471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configuration parameter for base url regarding cockpit links #4261
Comments
Hi together, I tried to quickly code a minimal example how I could imagine the requested functionality. If there's positive feedback from a maintainer, I would love to finish my pull request, which I started here at my fork. If this request would be accepted, I'd see the following tasks:
|
@AlexanderSkrock For the user I think it would be much better to offer some sort of auto-discovery. I'd need to check what we have in place. What I'd be interested is to understand the following:
|
Hi @nikku , thank you for the quick response. Regarding auto-discovery an option I could think of
This would basically be the same as already implemented except for the dynamic base path we extract from the REST endpoint url written here: https://github.com/AlexanderSkrock/camunda-modeler/blob/develop/client/src/plugins/camunda-plugin/deployment-tool/DeploymentTool.js#L701 This sort of auto discovery would work in the default case as well as in our case where we use the same base path Kind regards |
Getting back to this issue: What I could imagine is to aid auto-discovery through a magic Reached out to the automation platform team to understand if auto-discovery of cockpit is something we already support. |
After discussion with the automation platform team we support the following solution proposal: Desktop Modeler queries We'll not be able to support any other solution, as it will degrade the experience for standard setups, and won't offer good utility (auto-discovery), too. |
Hi @nikku , thank you for discussing this idea with the automation platform team! This sounds like a solid idea. For me this means, I will close my current pull request.
Which steps are already resolved? Do we need separate issues? And one more thing, do we need additional changes for the web modeler. I appreciate your thoughts and would happily try to assist on the conceptual work/ implementation. Kind regards |
@AlexanderSkrock Your checklist sounds about right. No other issue is needed for the Desktop Modeler. For Camunda 8, let's agree on the following well-known URL:
For Camunda 7, let's agree on the following well-known URL (#4261 (comment)):
In all cases the result is parsed as JSON and extracts the respective base URLs for the services that we link to. |
For web modeler (self-managed) we'll consider if such an addition makes sense. One alternative route there is to offer alternative means of discovery. |
I propose that you focus your efforts on improving your C7 use-case for the time being. |
Hi @nikku , I am not sure when I will have spare time to have a look into the C7 platform part. I am quite confident around engine code but not that much about the provided REST endpoints. Anyways, I look forward to implement this, just do not expect a pull request too quickly. :D Kind regards |
@AlexanderSkrock I believe an engine contribution is not necessary. Consider your setup, where you have full control over all endpoints; this is where you want to simply provide the wellknown URIs to point to custom REST-Endpoint URLs. For the moment I'd not expect you to update C7 bundle to provide these URLs; we're fine to assume a default where we don't find a (user create) wellknown URI (as defined). |
Hi @nikku , For clarification, the Camunda Desktop Modeler user would configure the REST endpoint as usual:
or rather
If it is related to the hostname of the REST endpoint (option 1), then I'd create a Then, if available the endpoint delivers a similar json:
|
It would query relative to the HOST, not to the path:
Hope this clarifies things.
Sounds good. |
Problem you would like to solve
Hi there,
at our company we host the Camunda REST api and web apps at a different paths, e. g. /camunda/rest or /camunda/app/cockpit/. This works fine and integrates very fluently with the Camunda Desktop Modeler by specifying the url pointing to the api. Sadly, when starting a process, a message pops up with a link to my started process, but it points to the default path which can not be resolved in our environment.
Kind regards
Alexander Skrock
Proposed solution
It would be great if we could have another field below the one for the process engine for the web apps or alternatively a parameter for the flags file so we can pre package our custom urls.
Personally, I would prefer the first option and I think it would be a better fit as it can defined in the same scope as the rest api url.
Alternatives considered
Sadly, I was not able to find any configuration parameters for this.
Additional context
Camunda Desktop Modeler
Camunda 7 (less interesting for 8 I think, because of the different architecture)
The text was updated successfully, but these errors were encountered: