Possible to use outside of ECA

Hi @cosmicdreams this is an interesting question. I'm not sure what's the best way to answer this. All the UI you see in this module is a third-party set of libraries, and the purpose of this module is (a) to compile them into a webpack for Drupal and (b) to integrate it into ECA.

As for the first part, you can find all of that on https://bpmn.io and of course you can use the same libraries for a different purpose.

As for the second part, the integration in Drupal and ECA, is about forwarding an existing ECA config entity in the correct format into the webpack and when the user is saving a model, to receive that data and store it as a config entity.

This integration part is fully tailored towards ECA and I currently don't see how that could be re-used for a different purpose. But you could use this module as a blueprint and just modify it to meet your own needs.

Having said that, if there were a way to have the integration just once and really use it for multiple purposes, I'm all up for that and love to hear your ideas.

I agree that your tight integration is unlikely to provide reuse verbatim. That's your application and its focus should remain on solving your specific problems.

What I suppose I am proposing/asking here is whether you see value in converting parts of your use of BPMN in a platform or maybe just a series of examples.

I would love to gain access to the knowledge you've gained in making your integration work, so that I can make a slightly different / maybe similar integration work.

Since I might be the first to request such a knowledge dump. Maybe all that's needed here is for you to point out the key bits of code for me to study.

I've been thinking about building something like this for 3 years, but haven't had the time to teach myself everything I would need to know to get it done. And now it seems as if the waiting might be beneficial. You might have a shorter path to success here.

The knowledge transfer is pretty straight forward:

• In the build directory, there is everything for the NPM environment to build the webpack application which will be stored in the webpack directory of this project when running npm install and npm run all
• The libraries file provides a library which is then included into the Drupal page when needed

The bpmn.io framework has a ton of components, of which we've just integrated some to get to an MVP. We have lots of ideas on how this could and should be improved, e.g. with regard to a11y or to replace the property panel inside the canvas with a Drupal controlled panel using Drupal's form API. You may get an idea when you browse the issue queue.

Having said that, I still wonder if this module drupal/bpmn_io should be improved such that it could be used as a bpmn.io frontend not just for ECA but also for other use cases like e.g. yours. But I'm sure others would probably have more ideas of what could be done with that.

WRT the ECA integration, all of the ECA specific logic for BPMN integration lives in the ECA module and not here. So, similar things could be done for other types of integrations, maybe. If done well, we - as in the Drupal Community - could all benefit from a bpmn.io integration that serves many benefits.

Just thinking loud, I haven't validated the idea yet. Wondering what your thoughts are? But first, you may want to look around how we've done it and how close this is to what you would require.

I agree that trying to play with this module would be a good next step

I think my Next steps are:

1. Compile the library
2. Attempt to render my top level config entities

Just came to my mind, I should have also mentioned that in the ECA context, the config entity is always derived from the BPMN data which is XML. So, the model is built in bpmn_io and when saved, the XML data is being transformed into the Drupal config entity. That config entity should never be modified elsewhere, it will always be re-created from XML.

I call this downstream conversion, i.e. the XML in BPMN contains all the known data which makes up the config entity later on - and in addition to that it also contains the visual representation of the model, i.e. the location of each item on the canvas.

It would be nice to also have some upstream conversion, i.e. from the config entity into the XML model. This would certainly be possible for the data part, but not as much for the visual part of it. And if you don't have that visual component, there is no reason to use bpmn_io in the first place.

RE: Upstream conversion

I imagine that this would solve the user story, "As a manager of my config-entity-driven data, I want to generate a flowchart that represents my existing data.". Like, build up my config entities, then drop in the BPMN module to generate the flowchart the represents my data.

For example, imagine wanting to build a diagram the represents the complicated relationships that node + node references can sometimes derive. You'd want an upstream conversation to do it's best of making sense how the data is related. That way you could generate how, this node right here, relates to other pieces of content. That kind of insight can solve some pretty complicated dependency problems.

For me, I'm looking for a visual means of managing configuration entities that basically comprise a state machine. The process of making decisions begins at the start and as it proceeds the choices the process is confronted (the states) are the ones my configuration entities describe, the lines are also represented by configuration entities.

Each state has data that represents the data you access while on that state, and data the represents the choices a user can possibly make, each of which would direct the flow to a specific next state.

All that said, you've given me a lot to study.

Next Steps

1. Study the conversion of XML to configuration entity you're mentioning above.
2. Consider a configuration to XML conversion.
3. Consider impacts of data binding to administrative configuration pages

TBH, those use cases sound more like you want to visualize existing structure rather than building new structure. A tool like bpmn_io would be a good choice for building new models/structure, but to visualize existing structure I would rather go for an UML based technology.

If you search for modules here on drupal.org with the term diagram, then you may find some rather interesting ones.

The work to make the management of the individual configuration entities, in a user-friendly manner, needs something like BPMN. The visual nature of management of configuration entities is appealing enough for me to invest the time to learn how this is working. Just generating a diagram of our existing structure isn't enough.

Is the value of BPMN strong enough for my team to ditch our existing data (so that we would have to rebuild everything in BPMN)? Yea, I actually think it is. It might be painful at first, but if the configuration entity that is built EXACTLY matches our existing schema for our configuration entities, then there shouldn't be extra work we need to do in order to use this.

Does that value proposition work for others? Probably not.