Activiti Cycle explained
On the left you see a first screenshot of the Activiti Cycle web application. There you have a tree view of repositories. The basic idea is, that you can access different types of repositories here in one unified tree. For the first release we concentrated on file system, Activiti Modeler and Signavio Modeler Repository. But actually our main goal was to create a good API for repositories, so that we can add other repositories later on easily, e.g. SVN. And you could even do that on your own for whatever you need. In the screenshot you can see that I included multiple SaaS-Signavio-Accounts, possible as well 🙂 For the next iteration we plan some thinking on tags and virtual folders, to structure that tree more easily even if the amount of repositories and folders is growing.
When clicking on one item – we call it artifact – you can see details on the right. These details differ depending on the type of artifact. A BPMN model maybe wants to show the diagram, for Powerpoint slides you may want to see a preview, XML code may need some highlighting and so on. We call these kind of detail views content representation, and an artifact can have multiple ones, in the example to the left you can see, that a BPMN model currently has 4 representations: The image, the Signavio JSON sourcecode, the BPMN 2.0 XML and some BPM 2.0 XML made more readable for the developer.For every artifact you have some actions you can execute, some links you may use or some downloads. Again, these things can be easily extended or added, our first goal was to provide a good infrastructure to get that working. The example I added as screenshot on the left is to copy the developer friendly BPMN XML from the Modeler repository to the file system. In the background, a link between the two models is created and saved (okay, actually persisting that link is not yet finished due to some bigger refactoring of persistence in Activiti, but it is scheduled for the next released). This supports a development approach, where business process model and technical process model could be kept in sync (something we already stressed a couple of times in this blog). When creating the technical model, we can influence the mapping easily. The optimal case would be, that the BPMN 2.0 XML from Signavio is executed as is. I actually don’t really believe this is a good idea and blogged about why a couple of months ago. In the current beta1 of Activiti Cycle I have a very easy example. Even if this could have been solved by Signavio directly as well, it is a nice showcase, what you can easily hook in in cycle. Signavio is a tool for business process modeling, so the primary focus is not XML source code. That’s why they don’t have to care that element id’s are random unique ids (like “4DD85C61-62D1-401D-88B9-2B9D8BC93D83”). But for the developer now really working with the XML source file it is a hazzle to have these id’s instead of human readable names. Well, no problem for a quick transformation in cycle 🙂 On the left you see the both versions compared. Not that cycle currently replaces all names nicely, but it shows that this can be easily hooked in. And you could do that yourself by writing a simple class and use the Plug-in mechanism! Speaking of which, the Plug-in mechanism is something I really like very much. Even if that was the first try and needs some refactoring, it allows you to drop a jar in your classpath and Cycle can add whole repository types, artifact types, actions or content representations. Everything is controlled by simple annotations. The example I want to stress is our camunda fox jBPM 3 mapping we use at different customers. This can create a jBPM 3 process model out of BPMN models. The customers even add own patterns in this transformations (like “in our application User Task means calling EJB XY to create a case for the help desk”). And this can be dropped into Cycle and appears magically at the right places. I love it 🙂 And last but not least we added an action to validate the BPMN 2.0 XML with the Activiti Engine, exactly like it is done during deployment. It took me just 5 minutes to write! So you always can check directly within the GUI if the current model is deployable.
Okay, overall the current features may not seem overwhelming, but as I already mentioned now we have a good, extensible foundation. Even if we scheduled some bigger refactorings for the next iteration, I think we are on the right track. And once we have this basis stable, we can do the really fancy and cool stuff. And we will 🙂 The release of Activiti 5.0.beta1 is on Wednesday September 1st, so I can just recommend to download it and try it out yourself! And don’t forget to give us feedback… But maybe don’t dig too deep into the code yet, as some stuff is still subject to change.