Make Task UI a REST client rather than server?

Would it be possible to implement the Task UI entirely as a REST client? That would make it much more flexible and useful, and it would eliminate a lot of confusion (at least for me). I’ll try and explain. (Sorry, it’s lengthy.)

I spent several days wrapping my head around just how the UI apps are interdependent, and how they interact with the REST war. I know Activiti/Flowable well enough to understand its mechanism (I remember being awestruck by Tom Baeyens’s presentation of his Process Virtual Machine over 10 years ago :blush:). The database defines everything, so connect two applications to one database and they share one engine. In a container (where one normally doesn’t flip datasources), this implies that a WAR is connected to a single engine from its moment of deployment – which has always been a bit of a hassle with the Explorer and REST apps.

However, in a very neat departure from v5, this doesn’t (seem to) apply any more to the Admin UI and Modeler UI. They don’t sit on the database of the single engine they control, but instead are stand-alone apps that use REST instead of JDBC to interact with outside engines. (One sore point: the Modeler’s deployment endpoint is hard-set server side; it would be neat if it were choosable, just as in the Admin UI.) So, the Admin UI and Modeler UI now use their own (externally irrelevant) databases, and have replaced JDBC by REST as their interoperation protocol with engines.

Sideline: Or have they? If I would connect Modeler to e.g. the REST war’s database, is then any modeled process immediately available in the REST app, i.e. without deploying it there over REST? I hope not; that would confuse the daylights out of me. But then why does the user guide recommend putting a shared flowable-ui-app.properties in Tomcat’s instance lib directory? Do Admin, Modeler, Task and IDM require access to a shared database after all? :confused:

At least I was comforted to find that the Admin UI and Modeler UIs do not expose a ‘process-api’ REST interface that would enable deploying processes ‘on themselves’ – they probably could, if they include the flowable-engine.jar, but that would muddle things needlessly.

But then, why does the Task UI application provide a REST interface? Unaware of this, I had walked through the “Getting Started with REST” (Ch. 2 User Guide), then opened the Task UI expecting to see the deployed processes and tasks. Nothing? :frowning: Oh wait, the REST tutorial operates against the REST war, and I haven’t pointed the Task UI war’s database.url to it yet. Will do later. But surely now I must see them in the Admin UI. Nothing?! :disappointed:. What’s broken?

It took me a while to figure out that the REST endpoints in the Admin UI are set to point to the Task UI. Huh, why would they? And why would the Task app have a REST interface at all? Like the Modeler and Admin apps, the Task app feels like a client. Functionally it is a client. You expect it to connect to a process engine (such as the REST app), not to be a process engine.

I know that technically there is no issue with having the Task UI war offer a REST interface and expose itself as both a client and an engine. Functionally however, I think the current out-of-box setup will confuse people – it certainly had me pull my hair out :smirk:.

The perfect solution of course would be if Task UI were migrated from using JDBC to using the REST. I don’t know if the exposed REST interfaces are already sufficient for this, but that would truly be the be-all-end-all. The Task app would, just like Admin and Modeler, become a stand-alone client to use with any engine!

Thanks for listening (so long :wink:)

BTW: when I changed the REST URLs in Admin UI to point to flowable-rest/service (and changed the credentials to kermit:kermit), sure enough there were my processes! :relaxed:

Hi,

Wow that’s a long post :wink:
I understand there’s a bit of confusion. Let me explain the reasoning. We wanted to have a separate Modeler, Admin and Task app instead of having one big app like the Explorer that contains all functionality. The Modeler app has a different database schema, just like the Admin application. But it’s still very easy to run everything on the same database as well.

The REST application is a bit of a different app from the rest (yepz). The Task app also contains all the REST services, so if you are using the Task app, you don’t need to run the REST app as well. It would be possible of course to use the REST app for the Engine, and the Task app as a REST client without the Engine. But the Task app contains all the Engines (BPMN, DMN, Form and Content) by default.

Also note that the Task app is an example app to work with the Flowable Engine. The REST application should be used if you want to expose a REST API for the Flowable Engine.

I hope this answers some questions you have and provides some explanation why it’s implemented like this. We are always open for suggestions to change the default setup of course.

Best regards,

Tijs

Hi Tijs,

Thanks for taking the time to read and respond. Good to see that my deductions were close to the mark. Some documentation would’ve been helpful though :slight_smile:.

I think the tl;dr; of my point is: you took the Admin and Modeler out of the Explorer. But why didn’t you take out the Task app too? The first two have become flexible stand-alone clients that can dynamically connect to any (REST-exposed) engine[1], whereas the latter can’t. it’d be really useful (for demo and testing, and for simple setups) to have a Task app that operates the same way as its sister apps: as a stand-alone client that can connect to any (REST-exposed) engine. It’d also reduce confusion by adding uniformity.

Moreover, once the Flowable form engine gets more prominence, I could imagine a generic Task app being sufficient for many (esp. mobile) applications. We work a lot with OpenDataKit (ODK) for data collection in the field. Users go to its online form builder to produce some pretty complex form logic (multi-page, skip patterns, repeat groups, etc.). A generic Android client (ODK Collect) pulls the forms off our server and pushes data back up. I think^Wdream of Task UI as a sort of ODK Collect :wink:

Cheers
Zwets

[1] Modulo the current statically defined deployment.api.url of the modeler, but that’s a trivial change.

Hi Zwets,

The Task app could indeed be using a REST client to the Flowable REST app for the Engine calls. This needs a bit of restructuring and a different positioning of the Flowable REST app, but I agree that it would be a good direction to work on.

Best regards,

Tijs

Tijs,

Is my understanding correct between Flowable Task App and Flowable REST App.

Flowable Task App is combination of Task UI + Flowable Engine + BPMN Engine + DMN Engine + Form Engine + Content Engine.

Where as Flowable REST App is Flowable Engine + REST API

Thanks
Ravi

Hi Ravi,

Almost correct :wink:
The Flowable REST app also includes the DMN, Form and Content Engine and the REST APIs for these engines.

Best regards,

Tijs

1 Like

Hi Tijs,

We have the same needs: Task app using REST calls for engine calls. If we implement it, would you accept such a contribution ?

Regards,
Christophe

Hi Christophe,

Yes, doing REST calls to the engine would be a good approach for the task app.
Let us know if we can do anything to help.

Best regards,

Tijs

1 Like

Hi Tijs,

IMO, Task UI app should use the same REST client stack than Admin UI app. A low level Rest client stack exists in Admin UI app (FlowableClientService). High level Rest clients implementing engine API, IDM engine API, … should be better. It will be easier to create Flowable client apps with them. I have not found such high level Rest clients.

So, is there such projects ? If not, I think It could be interesting to create them.
Want do you think about that ?

Regards,
Christophe

Hi all,

We’ve been facing some problems because of this very issue. Do anybody have any update on this? Is Flowable actively working on making the task UI behave strictly like a dumb client?

Thanks,
Yamil

What kind of problems?

No, that is not the purpose of Flowable Task. It’s purpose is demonstrating basic usage and capabilities of Flowable.