Rewrite Rename technical IDs plugin from scratch for Modeler 5

Good morning,

I use the Rename technical IDs plugin (Github: Rename Technical IDs) professionally quite a lot. Therefore I dared to try to adapt the plugin in the sense of the Modeler 5.x.

As a template I used the Auto Save Plugin (github pinussilvestrus/camunda-modeler-autosave-plugin), so the GUI is ready. As far as I just come. So this is built on the basis of React, there is a popup instead of drawing directly on the canvas. So it fits better with the (new) operating concept.

My result is here (Github: Xembalo/Rename Technical IDs), incl. screenshot.

But now the real problem: I could not yet find an approach via try and error nor via reverse engineering of other plugins nor via various blogpots, how I can unite on the one hand a BPMN plugin (registerBpmnJSPlugin) (apparently necessary for the approach of the previous Rename technical IDs) and on the other hand a client extension (registerClientExtension) (apparently necessary for the integration into the footer and the popup).

Would anyone have an entry point or code snippet for me on how to proceed there?

Thanks,
Xembalo

PS: As a new user I can only share 2 links, that’s why the link to the autosave plugin is broken

Any better location/site to asking for help?

Hi @Xembalo, I would start you off with Plugins | Camunda Platform 8, this is our plugin documentation and it should point you to different examples depending on the type of plugin you want to write, if you need any extra information, do ask :slight_smile:

Specifically in the case of uniting several plugins together, we usually make use of the event bus to send messages between multiple plugins. So you would need to register both plugins and then use the eventbus to send signals between the two.

While the eventbus isn’t directly supplied to you in ‘client’ plugins, you can work with it via triggerAction and subscribe, which are supplied to your plugin directly here.

TriggerAction is a bit broader than just the eventbus, look for this.triggerAction('emit-event' use cases in the modeler.

In bpmn-js plugins, the eventbus is accessible directly via dependency injection, example here.

Hey Skaiir,

your link was my starting point, but unfortunately does not help me for my specific question.

All plugins I could find that read or modify the bpmn have so far either no GUI or no settings, or draw something more or less inconsistently directly into the modeler window. So also the original Rename plugin.

Conversely, no plugin with an overlay that I could find accesses the BPMN, but calls actions on the application layer. (Auto-Save plugin triggers only “Save” every 5 minutes).

But the recommendation for Modeler 5 is to use consistent popups How to Migrate Your Camunda Modeler Plugins to Work with Camunda Modeler 5.0 - Camunda. So I wanted to do that now for this Rename plugin, replace the self “cobbled together” overlay with a Modeler-style popup. But now I can’t get to the BPMN. At least I don’t know how.

And now making 2 completely separate plugins out of it might work, but pretty much misses the point.
Maybe it’s also a feature request to the Modeler team that you can use custom React.js components in a BPMN diagram, but at least I just can’t find a starting point right now.

Thanks

Ah I get you. Well unfortunately, you don’t have much of a choice here, besides integrating into two places. To extend the bpmn editor functionality, you have to supply a bpmn-js extension module. And to extend the camunda-modeler UI, the React extension.

The expected implementation pattern here would be to have them both and that the communication between the two would be handled as I’ve described in my second message. Registering multiple modules is a pretty common pattern which can be found in quite a few places.

This is also a pattern that is omnipresent when using electron menu entry extensions, though done slightly differently (subscription code).

So you can keep everything into one repo, one plugin. But you’ll need multiple modules for the different parts of the application that you want to extend.

If this does feel like a limitation to you, and it might well be, do raise it as an issue in the appropriate repo on GitHub, this will involve more people into the discussion. But personally I think you can achieve what you want with my proposal without any sacrifices.