I’d like to raise a question regarding process modeling in Operaton. As I can see, the current approach relies on creating a process in Camunda Modeler and editing the XML file manually. While this might serve as a workaround and could be out of scope for Operaton 1.0 I believe modeling could play rather an important role. It could affect user experience and thus product adoption.
We’re working on making OpenBPM Studio compatible with the Operaton engine so that process modeling will be seamlessly supported directly within IntelliJ IDEA. We’d like to explore the possibility of OpenBPM Studio becoming an official modeling component in the Operaton ecosystem. If there are any requirements or criteria you need us to meet, we’d be happy to discuss them.
Just to highlight this again — we will support Operaton in OpenBPM Studio anyway. But if you’re interested in adopting Studio into your ecosystem, it would be great to talk about it sooner rather than later.
This is not correct. As Operaton is backwards compatible, there is no need to edit the XML manually, the modeler can be used as is. Where did you get this impression, is there anything in the documentation or in the forum you saw?
The modeler situation might become a problem in the future. We discussed forking it, too, but currently our focus is the engine itself, we should not risk. spreading ourselves too thin. At some point we need to have our own solution. For example, DMN 1.6 is coming up, and we are not sure if the modeler for C7 will support it. If we wanted to implement this feature, we need a different solution.
I’d be happy to talk about synergy, here. My personal point of view is that I’d be hesitant to make OpenBPM Studio the primary and recommended modelling component, as the decision which parts of BPMN to support and which extensions to write would always need to be aligned between two projects, which raises some concerns about ownership to me, but that’s just me, not the whole projects opinion.
We’ve integrated bpmn.io into our product and are open to exploring a community-driven fork if the need arises. Alternatively, creating a completely new open-source modeler - ideally under a truly open license - could be a path forward. One that doesn’t require branding elements like the bpmn.io logo would be especially welcome.
Parts of the puzzle are already available. For instance, the rendering layer is nicely handled in this project:
Looking ahead, it seems likely that Camunda will eventually sunset the C7 part of the Desktop Modeler, and the ecosystem will need robust, open alternatives to fill that gap. We’re definitely interested in collaborating on such an initiative.
Indeed, we experimented with Camunda processes, and they work well with the old namespaces. However, in the original Operaton files, there are test processes that already use the Operaton namespace. We tried modifying these diagrams using Camunda Modeler and noticed some inconsistency: in some places the camunda namespace is used, and in others — operaton. It is expected, as Camunda Modeler doesn’t know about the Operaton namespace.
Since the new namespace is already present, it makes sense to use it when creating new processes. But there are currently no tools that support creating processes in the new format. In this case, replacements have to be made manually. For now, we can continue using Camunda Modeler and create diagrams in the old format, but sooner or later we will have to return to this issue.
