Configuring flowable-rest - flowable-custom-context.xml

Flowable Engine
1

For Flowable 6.2, configuring most common settings in UI apps is easy now via flowable-ui-app.properties which you easily place somewhere in your classpath - no need to unpack the war packages, easy to deploy
This seems a bit more troublesome with flowable-rest. Everything in the default flowable-custom-context.xml, added to flowable-rest/WEB-INF/classes, is commented out and the default (process) configuration does not seem to pick up the db.properties, only the engine.properties (both in flowable-rest/WEB-INF/classes).
Enabling the first 2 beans, dbProperties and dataSource, does the job, but still can’t place the db.properties somewhere else in the classpath like with flowable-ui-app.properties apparently.

-> classpath:db.properties

But we also need to configure the mailServerHost for flowable-rest and we don’t succeed in that part. Therefor we need to replace the process engine configuration, but we don’t seem to find a valid one. Using the one commented out in flowable-custom-context.xml results in multiple errors and following the direction in How to configure flowable-rest.war using JNDI results in following error:

02:36:04,236 [localhost-startStop-1] WARN  org.springframework.web.context.support.AnnotationConfigWebApplicationContext  - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'formRepositoryService' defined in class path resource [flowable-custom-context.xml]: No matching factory method found: factory bean 'processEngine'; factory method 'getFormEngineRepositoryService()'. Check that a method with the specified name exists and that it is non-static.
15-Nov-2017 14:36:04.245 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file
15-Nov-2017 14:36:04.245 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Context [/flowable-rest] startup failed due to previous errors

This error is related to the last part added according to https://forum.flowable.org/t/how-to-configure-flowable-rest-war-using-jndi/446/4

<!-- start new -->
<bean id="formRepositoryService" factory-bean="processEngine" factory-method="getFormEngineRepositoryService" />
<bean id="formEngineService" factory-bean="processEngine" factory-method="getFormEngineFormService" />
<bean id="dmnRepositoryService" factory-bean="processEngine" factory-method="getDmnRepositoryService" />
<bean id="dmnRuleService" factory-bean="processEngine" factory-method="getDmnRuleService" />
<bean id="contentService" factory-bean="processEngine" factory-method="getContentService" />
<!-- end new -->

The same error would occur for each of those beans, but without them auto wiring errors appear

We did rebuild the war file as indicated, without the @Configuration annotation, but same error occurs with or without the rebuild war

What should be the correct processEngineConfiguration and how can we configure the mailServerHost or other extra properties like passwordEncoder for flowable-rest?

This has been tested in a tomcat 8.5 container with the flowable 6.2 war files. Rebuilding was done from master.

2

The email settings can be configured for the rest app using email.host, email.port, email.username, email.password (see https://github.com/flowable/flowable-engine/blob/8b93c5324157560bea6d7ccaf4fe02be5586b0af/modules/flowable-app-rest/src/main/java/org/flowable/rest/conf/FlowableEngineConfiguration.java#L102)

However, your question is also about how to configure the application(s). The custom context is a fallback mechanism in there for backwards compatibility. If they are often used properties, we try to add them directly (if we miss some, please let us know). The alternative is dependening on the flowable-app-rest dependency, and having a custom FlowableEngineConfiguration class, package that jar and add it to the webapp. However, that should be a last resort, the properties way is much easier.

3

Hmm, I can’t recall that the flowable-ui-app.properties was being picked up by the flowable-rest app, since we already applied the correct (email, datasource, …) configuration for the other apps.
We got the rest app working with the old db.properties configuration file, but never with custom configuration like email in the custom context.

Anyway this is more then 2 months ago and in the meanwhile we have been perfectly served by the flowable-task rest endpoints. So let me test again if we get the flowable-rest to work with the flowable-ui-app.properties. That would be the referred situation since we don’t want to expose the task app and we do want the swagger doc available in flowable-rest