I am trying to understand the positioning of the UI web applications, and in particular the Task UI, to know if we could perhaps reuse it for basic needs:
However, I didn’t find a lot of documentation concerning the “App” concept in modeler/task, except from the 6.3.1 release notes where it’s described as now “first class citizen” engine: is it now comparable to other Flowable engines?
Basically, I have a Java application that embeds Flowable engines (it is a classical Spring application, with auto deployment of a process, some decision rules, and ideally some forms), and I would like to add an UI for the deployed processes and forms.
Is there a way to use the “AppEngine” programmatically like the other flowable engines, in order to deploy automatically an app with the processes and forms auto-deployed in the other engines from the same Java application?
Or otherwise, would there be an easy way to use the ui task module without the “app” concept, showing only what is deployed from the same DB?
(our goal is not to be able to use a front to change the process, we don’t mind repackaging our code when we have changes)
I understand that the UI apps are made for demonstration purposes and that we will probably need to write our own front, but I would like to understand to which extent we could reuse some parts of task app for internal needs.
Also, I would like to keep an “embedded” approach: ideally one Java application (of course dividing the front and backend is not a real issue), we have an agile/feature teams approach and we do not want to have one front used for multiple teams that would create dependencies and complications like with more centralized BPM engines.
flowable-task components are on maven repository, so i guess there must be a way to add them as dependency and then having some glue code that deploys it. Could not find out how to do this in a spring boot setup.
I think there are two things mixed here. One is the concept of an “App definition”. This artifact is generated from the modeler ui, and is a .zip or a .bar file that contains processes, cases, forms, etc, and is deployable using the AppEngine (app-api), or if you are using a spring boot project, I think they can be auto-deployed if placed under the /apps folder in resources.
The other part about the UI applications (modeler, task, etc) is a different topic. As you said, they are there for demonstration purposes. You can fork/reuse whatever you want from them, of course, but maybe writing your own frontend and using the public REST api is the way to go.
Indeed I mixed the two, because I’m not sure I really understand what this concept of app can be used for outside of the UI applications. But I don’t really intend to use it, so it’s not an issue.
I managed to start the admin UI pointing to REST services in my main app, so for the admin UI I think we will reuse it, it’s sufficient for a start.
For information, in case it’s useful for someone, I have 3 components:
My main JVM containing the engines, the REST services, the autodeployed processes/…
And the admin + idm wars, unchanged, but with the externalized java property SPRING_APPLICATION_JSON so that they point to the right REST services (+ in addition to the DB config).
Concerning the Task UI, my opinion is that it could indeed be helpful if it could use other external REST services from the main app, instead of embedding everything, because for internal use only it could also have been sufficient for a first version (but there was already a thread about this… see https://forum.flowable.org/t/make-task-ui-a-rest-client-rather-than-server/457/7 ). But we will redevelop I guess.
Hello Sophie, thanks for your post. I’m also considering implementing the war directly info my flowable spring boot test application to play and with the concepts and challenge them a little bit.
How did you embbed the war ?
Hello Michel,
Well, we don’t embed the war: for the moment we have decided to stay on the separate war approach: on the one side our application (exposing REST services + potentially it will contain a custom UI), and on the other side the admin UI. So we don’t reuse the Task UI.
Best regards,