Quarkus http Kogito Paths

19 views
Skip to first unread message

tapi...@gmail.com

unread,
Mar 3, 2021, 3:46:09 AMMar 3
to Kogito development mailing list

Hi,

All the default API endpoints are always generated at the root of the project (
quarkus.http.root-path=/) is there a way to make the compiler take the resource path into account as per in the image below?

Screenshot_2021-03-03 OpenAPI UI (Powered by Quarkus 1 11 3 Final).png

The folder structure is something like this
multiple-kogito-resources.PNG

I don't know if I can configure that with the quarkus.http. config? How is Kogito setting the paths under the hood?

Best regards,
Tapio Vepsäläinen

Matteo Mortari

unread,
Mar 3, 2021, 5:54:19 AMMar 3
to Kogito development mailing list
Hi Tapio,
by design of the overall Kogito platform, it is indeed expected that the endpoints for the knowledge assets are always created at the root. So this is unrelated to Quarkus (or Spring Boot) configuration.

This requirement is applied to all knowledge assets, DMN but also DRL, BPMN2, etc.

Also, this is unrelated to the src/main/resources folder structure you presented in the screenshot: for DMN, BPMN2 and DRL, the endpoints relate to the asset "name" (or "id") as per the example templates I linked above.

If you want to customize URLs, imho, you may opt for two solutions:
  • you specify a manual redirect or URL rewrite, depending if this is either Quarkus-based or SB-based, using the underlying platform mechanism
  • you specify your own REST endpoints at the @Path you want, and wire the codegenerated kogito endpoints from there
    (or alternatively, you copy-paste the codegenerated endpoint of Kogito to customize it, but while it may work I don't consider it a clean solution)
Hope this helps!
Let us know,
MM

--
You received this message because you are subscribed to the Google Groups "Kogito development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kogito-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/d20706e6-0c44-448d-946b-6ec2951be7bbn%40googlegroups.com.

tapi...@gmail.com

unread,
Mar 3, 2021, 6:08:18 AMMar 3
to Kogito development mailing list
Hi Matteo,

Thanks for the response. This was what I kind of expected.

Could you suggest me some resources what to study in order to make required changes into a Quarkus application? 

Also, what is the best practice: run multiple models in one container, or run one container per module? assuming the models have very little load.

Best regards,
Tapio Vepsäläinen

Matteo Mortari

unread,
Mar 4, 2021, 4:41:00 AMMar 4
to Kogito development mailing list
Hi Tapio,

On Wed, 3 Mar 2021 at 12:08, tapi...@gmail.com <tapi...@gmail.com> wrote:
(...)Thanks for the response. This was what I kind of expected.
Could you suggest me some resources what to study in order to make required changes into a Quarkus application? 

According to this guide, it seems the Undertow handlers are supported by Quarkus, so you could setup the URL redirect similarly to what shown here.
If I recall correctly, is something analogous to the Apache htttpd's mod_rewrite, and still if I recall correctly I've used these both in the past in a similar situation, but it has been a while for me :)
 
Also, what is the best practice: run multiple models in one container, or run one container per module? assuming the models have very little load.

Difficult to say on a general principle, as architectural consideration may vary depending on the actual use-case at hand.

But here is my personal advice, taking into account also the question above:
I would start by placing all the DMN models in a single "container" Kogito application, without caring too much of the inner folders etc. but making sure the model IDs are consistent and the system behaves as expected.
When eventually the application will start to grow in size (eg, more models) you may opt to split the Kogito application before it becomes a monolith.

And since the deployment scheme may vary "tomorrow", you will notice that handling the redirect within the Quarkus app will become superseded, as you will need to coordinate the deployments in a K8s or similar cloud management / solution ?

Hope these are helpful considerations
MM
 
Reply all
Reply to author
Forward
0 new messages