Object states and the need for occurrence-level attributes

Hi Ivo,

In my previous company we had the same problem, not with BPMN but in working with data object states in eEPCs. We solved it by maintaining multiple state attributes for each object definition. In our case 10-15 text attributes have been sufficient. In the occurence the appropriate attribute was displayed. This was not very convenient for the modeller and difficult for analysis - but at least it worked somehow. Could be something you want to consider as well?

Best regards, Martin

Hi Ivo and Martin,

I have the same issue and I am stumped on this one as I have no idea how to associate different states to the same object.

Try this...

1. Create your first data object Policy and give it a state eg New
2. Create your second data object Policy and give it a state eg Reviewed
3. Create your third data object Policy and give it a state eg Approved

Now select the properties of your first data object, select Variants, select New, select Use existing objects, select Next, select Add, navigate to the location where you have created your data object Policy and select all the data objects of that name.

You have now created a Master object (the first data object) and the other are all Variants of this object.

I'm not sure if this will give us the results we want but have a go and let me know what you think.

Damian

@Martin,

Good idea, it's just that I'd prefer to have an easy way to allocate different states (for example using standard group-level Find). Alternatively there would be e need for a special report and a bit of risk for the quality of data. That latter is also associated with having the attribute as text. I'd prefer user-defined values but I understand that it's at the expense of flexibility.

A sort of a mixed approach would be to use a State attribute within annotation in cases where annotation is used to indicate state. Then getting the states is a query away.

@ Damian,

Using variants is nice but at the expense of having variant attributes diverge and not getting the right results in Output object information and other definition-level reports. (I forgot to mention that the Data Object is used in non-BPMN models as well. In any case.) Do you have any idea how to meet this requirement as well?

Regards,

Ivo

Ivo,

I fully agree. Searching for models with a specific object state would not work following our approach. In a report it is possible but more work as you need to check the attribute placement of each object occurence.

But I am not sure if the standard group-level Find method would work if different symbols are used as you have described. As far as I know the search result is only reflecting the default symbol. E.g. in case an object is used 5 times with the "New" state symbol and 2 times with "Released" the default symbol would be either "New" or the "Released". And I guess the default symbol needs to be defined manually or is based on the symbol which has been used first for the object.

The annotation could indeed work better here. We have evaluated the option as well to use a different "state" object connected to data objects but in our case it was prefered to work with one object type only. Another option would be using different connection types (similar effort as different symbols) or writing the state in an attribute of the connection. But this would both not fulil your requirement for being searchable.  

In a nutshell: yes, we need occurence level attributes!

Martin

Hello Ivo,

almost 10 years later I have found your post and have to say, yes we (still) need it!

Regards,

Radek.