nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Doing by design

martin_grofcik

I welcome any input, feedback, comment…
https://gromar01.wordpress.com/2016/06/16/design-by-doing-with-activiti6/

Find more posts tagged with

Comments

martin_grofcik

In fact it is Design by doing (opposite direction).

jbarrez

It's an idea that I also wanted to do once I find time 😉
The hard part is finding a good relationship/reference model for the various deploymens that get created along the way that fits within the Activiti architecture/API's.

martin_grofcik

Hi Joram,

The hard part is finding a good relationship/reference model for the various deploymens that get created along the way that fits within the Activiti architecture/API's.

Could you describe it more? (example….)

regards
Martin

jbarrez

Sure: there are a few options here as how to handle the 'previous' process definition (more specifically what the upgradeProcessInstanceDefinitionVersion() method does):

- Overwite the existing process definition and set the process instance to this one. In this case the change must be possible, as in there must exist a matching element in both process definition
- Explicitely map. Do a mapping from activities to the new activities (A->A, B->C, etc)

Which is clear, I think. But there are now two deployments, in both cases, and this needs to be reflected in the audit history too.
So my comment was more referring to that: how would the 'dynamicity' be captured, both in runtime and history.

But both options are born from the fact that deployments and process definitions are static in Activiti (and rightly so, for performance reasons). I wonder if there are different mechanisms possible … where that is not needed, and where the process definition is really fluid … but that would mean a different implementation of some of the core parts … or maybe not.

Stuff to think about!

martin_grofcik

Hi Joram,

But there are now two deployments, in both cases, and this needs to be reflected in the audit history too.

The command to set process definition in the process instance updates history too. (I read something like that in the code - but I did not check it.

Yes, let's think about.

Regards
Martin

jbarrez

Yes, it does I believe. But I'd also like to capture the fact it's being done by a 'dynamic operation', so that one can reconstruct what happened exactly from the history (which is not the case if we simply use what's there now).