search

camunda / camunda-modeler

An integrated modeling solution for BPMN, DMN and Forms based on bpmn.io.
https://camunda.com/products/modeler
MIT License
1.47k stars 474 forks source link

Discover custom location for cockpit links #4261

Open AlexanderSkrock opened 2 months ago

AlexanderSkrock commented 2 months ago

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

Alternatives considered

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.

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 commented 2 months ago

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: draft-configure-webapp-url

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

nikku commented 2 months ago

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

AlexanderSkrock commented 2 months ago

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 /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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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.

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 commented 1 month ago

@AlexanderSkrock Your checklist sounds about right. No other issue is needed for the Desktop Modeler.

We use well-known URLs at the base URL of a C7 (REST) or C8 (REST, GRPC) connection. A simple file basically states the locations of services.

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 (https://github.com/camunda/camunda-modeler/issues/4261#issuecomment-2100688445):

${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 commented 1 month ago

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 commented 1 month ago

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

AlexanderSkrock commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

Hi @nikku , this approach would simplify the development.

For clarification, the Camunda Desktop Modeler user would configure the REST endpoint as usual: image 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

  1. 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 commented 1 month ago

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.