out of interest: there is a java implementation for the external task worker that hides the details of the REST API.
My question is: Why isn’t there a java implementation for the whole REST API? Why was the external task part treated in a special way?
If one wants to work with a remote engine, one needs not only the external task API, but also all the other methods too, e.g. to start a process or to send a message to the process.
Open question is: which features of an embedded engine are important for a developer to be available in this client? For example: Automatic deployment of contained process diagrams, decision tables and forms?
Which additional features would be nice to have in this client?
thank you for the quick response and the information. Good to know that I’m not the first who has this question!
IMO the client should be just client. All the other features you mentioned (automatic deployment of contained process diagrams etc.) are good and needed but they should be part of another library IMO, e.g. a spring boot starter. This another library would use the client, configure and expose it. The client would have an API for configuring it but would not prescribe a certain form of configuration and such. Thus, the client could be used in any environment.
Just some thougths off the top of my head.
Do you happen to know whether there are plans to integrate this community lib into the main product (as it was done with the external task client)?