Configuration parameter for base url regarding cockpit links

[AlexanderSkrock]

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)

[AlexanderSkrock]

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.

The UI could look as follows:

If this request would be accepted, I'd see the following tasks:

• Handling default cockpit url considering default "Tomcat or not" logicc
• Implement the same behaviour for the start-instance-tool
• Refactor code to reflect changes to the start-instance-tool with minimal effort
• In general a quick review of my code, the current state was done in quick & dirty fashion to have a quick draft
• Testcases
• Documentation

[nikku]

@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:

• Why did you choose to use a different endpoints / apps layout?

[AlexanderSkrock]

Hi @nikku ,

thank you for the quick response. Regarding auto-discovery an option I could think of

• Check whether the REST endpoint url ist Tomcat-like
• Remove last segment of the REST endpoint url
• Depending on the first check, we could add /camunda/app or /app

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 /camunda for both the REST engine which is available at /camunda/rest and the webapps are located at /camunda/app. We choose to do so, because our Spring Boot Application Server runs our own frontend and backend as well as an embedded process engine. So we had to separate them to avoid conflicts and setup Spring Web rules properly for those paths.

Kind regards
Alexander Skrock

[nikku]

Getting back to this issue: What I could imagine is to aid auto-discovery through a magic .well-known URI, i.e. we discover cockpit by trying to query ${BASE_URL}/.well-known/cockpit-url, where BASE_URL is deduced from the REST API URL you provide.

Reached out to the automation platform team to understand if auto-discovery of cockpit is something we already support.

[nikku]

After discussion with the automation platform team we support the following solution proposal:

Desktop Modeler queries ${BASE_URL}/.well-known/camunda-automation-platform/webapps. If the file exists, then it will be parsed as JSON with { "url": "https://some-base-url" } with url interpreted as the base URL of the C7 webapps. The solution will work equally well for Camunda 8 (self-managed, non-standard setups).

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.

[AlexanderSkrock]

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.
Tho, to be able to further contribute on this enhancement, we would need to summarize necessary tasks.

• Well known endpoint for Zeebee
• Well known endpoint for Camunda Platform
• adjustments to the Camunda Modeler plugin for zeebee
• adjustments to the Camunda Modeler plugin for Camunda Platform

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
Alexander Skrock

[nikku]

@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:

${BASE_URL}/.well-known/camunda/webapps = { 
  "operateUrl": "https://some-operate-base-url",
  "tasklistUrl": "https://some-tasklist-base-url"
}

For Camunda 7, let's agree on the following well-known URL (#4261 (comment)):

${BASE_URL}/.well-known/camunda-automation-platform/webapps = { 
  "cockpitUrl": "https://some-cockpit-base-url"
}

In all cases the result is parsed as JSON and extracts the respective base URLs for the services that we link to.

[nikku]

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.

[nikku]

I propose that you focus your efforts on improving your C7 use-case for the time being.

[AlexanderSkrock]

Hi @nikku ,
sounds good to me!

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
Alexander Skrock

[nikku]

@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).

[AlexanderSkrock]

Hi @nikku ,
this approach would simplify the development.

For clarification, the Camunda Desktop Modeler user would configure the REST endpoint as usual:

Then, with the example in the above image in mind, the modeler would try to query:

1. http://localhost:18081/.well-known/camunda-automation-platform/webapps

or rather

2. http://localhost:18081/camunda/rest/.well-known/camunda-automation-platform/webapps

If it is related to the hostname of the REST endpoint (option 1), then I'd create a WellKnownAPI next to CamundaAPI, it is related to the REST endpoint url (option 2), then I'd rather extend the CamundaAPI. As a side note, it is probably slightly more difficult to add a resource below the Camunda REST segment.

Then, if available the endpoint delivers a similar json:

{
    "adminUrl": "http://xxxx:18080/camunda/apps/admin/",
    "tasklistUrl": "http://xxx:18080/camunda/apps/tasklist/",
    "cockpitUrl": "http://xxx18080/camunda/apps/cockpit/"
}

[nikku]

It would query relative to the HOST, not to the path:

http://localhost:18081/.well-known/camunda-automation-platform/webapps

Hope this clarifies things.

If it is related to the hostname of the REST endpoint (option 1), then I'd create a WellKnownAPI next to CamundaAPI

Sounds good.