Currently I am evaluating flowable integrated with spring boot as BPMN engine to automate UI ( web portal) for certain task as well as to automate test cases along with web drivers.
So far in my learning process, I have not found any hurdle to achieve expected use cases except one technical challenge regarding accessing web driver instance across service tasks in BPMN process. As I understand from documentation, all sharable objects should be serializable before set as variable. Since vendor specific web drivers are non serializable and resource critical ( each remote web driver create one session in server grid and has limitation of number of instances) so can’t create new instance in each service task.
Is there any way (or document reference) to make web driver instance thread safe shareable across process instance?
If you want to cache certain things you’ll need to write some custom Java code. Flowable does not have a way of doing such a thing cross multiple nodes and it does not provide a local cache that you can use in such a manner between your processes.
Another suggestion might be to expose the web driver instance as a Spring bean. This could be injected into a Spring aware Java service task and the life cycle would be tied to the Spring application rather than a process instance.
Thanks a lot for suggestion. Here I want to keep web driver lifecycle bind with process instance ie. once process is completed then web driver session should also be killed since each process instance is intended to complete UI automation. For example, automation process required web site version check, authentication, product selection, shopping basket creation, payment and order creation. I want to keep each activity in separate service task and keep session ( via web driver) alive till process get completed.
Thanks Filip, One more point about deployment in case go with ehcache as in memory JVM solution, then does flowable support multi instance ( active -active ) deployment model OR is it traditional BPM active- passive deployment model ?
Moving the management of the web driver into Spring sidesteps the workflow variable/serialization limitation. The bean could be a factory to create a instance per workflow and then you would have to manage the clean up when the workflow ends, perhaps through a special service task or maybe via a FlowableEventListener.
Flowable is entirely stateless, which means that you can scale it as much as you need.
Another potential, and interesting, solution would be to use a custom VariableType. You could create your own VariableType, that will persist the configuration for creating an instance for a WebDriver, then you can initialize the WebDriver and get a hold of it when you need it in any Flowable instance. This would allow you working with this on multiple nodes.
The only thing here is the closing of the WebDriver, you’ll need to work with the Flowable Session mechanism in order to close the WebDriver once the interaction in the transaction is done.