Ayman/Netvariant Moqui Workflow Automation

Hi.

I remember seeing this post a few years back :
https://groups.google.com/g/moqui/c/cXYw9SsUGq0/m/-Dk5TyzlAAAJ

I got particularly interested in the Workflow Automation features (note that the UI look and feel enhancements were looking equally impressive).

I went on doing my own integration with a BPMN engine (Flowable) thinking it’d better to have a ‘real’ bpmn engine in the background.
I now realise that seamless integration matters a lot more.

Using my Flowable integration, albeit working, I see that:

  • The same 10% of the bpmn2.0 feature set are used 90% of the time.
  • Sending http requests all over (between Flowable and Moqui Services and back) is not optimal.
  • Having to go elsewhere to edit and redeploy a workflow is really painful.

So my question to Netvariant is … how did the tool progress? Do you have some performance/scalabilty numbers to share?

Thanks

1 Like

moqui-workflow is an excellent component, not sure why it is no longer upgraded. I think this component should merge into moqui as default workflow component.

The biggest problem is the workflow-designer, due to the version of nodejs and the version of the dependency libraries, it’s now hard to pass the compilation.

2 Likes

hi,domiko:

I have learned about the integration solution between Flowable and Moqui during this period. There are two options, Option A, which involves packaging Flowable as Moqui’s Tools and integrating them into the overall Moqiu system. Option B, the same approach as you currently do, deploying Flowable and Moqui independently and connecting them in some way.

Option A, according to my test, There are no problems with engine startup, process deployment, task query, etc. The more troublesome thing is how to call Moqui’s service in the process node. I call it through MQ, that is, Flowable sends the service name to be called to MQ through a message, and MQ pushes Moqui to execute the corresponding service, and sends the result back to Flowable through MQ.

But I think Option B may be a better solution, and there are also many benefits to having an independent engine, such as upgrading separately and not affecting the performance of Moqui. I am not sure how your current solution solves the problem of form definition and how to handle forms in the process and in Moqui. If both forms and process definitions are completed in Moqui, would it be easier to use?

Hi,
I integrated moqui with camunda and evertything work fine.
Use moqui tool factory for integrate with flowable.

Can you introduce your specific solution for integrating Camunda? For example, how to call the Moqui Service from the camunda engine

In My solution for example you can use Service in script task in camunda modeler or you can use service vi rest api in moqui and call ws in service task.
Note: you can use both service task and script task in modeler.

If you integrate flowable with moqui tool factory you can use both service and webservice in flowable and vice versa.
if you need more help let me know.!

Thanks a lot!
Could you please provide some sample code? about how the Flowable engine call Moqui Service.

First of all you must integrate flowable with moqui?
did you do that???

Is camunda a better choice?

Actually Camunda have some plugin you can integrate with
like identity plugins cockpit plugin and etc
I think you have better options with camunda but its on to you.
I can help you with camunda if you need!.

The workflow engine hasn’t been updated in a while. I’m planning on releasing a new version in the near future that is better architected and is more closely integrated with OOTB Moqui entities.

2 Likes

That’s great!
Is it convenient to share the design ideas in advance?