TS
Hello,
I need to delete around 700 objects, which have empty value for 'Occurrences' attribute. I hoped that I can use the 'Find' funcionaliy to find all objects with empty 'Occurrence' attribute and then simply delete them from the Result window. I tried to create a rule in 'Find' like 'Occurrences equals to zero', but the 'Occurrences' is not present between the attributes of the rule.
Can somebody help me please?
Thank you in advance,
Tibor.
Well I would suggest the DB Reorganize feature of Aris. I just did this yesterday on our DB. This will Delete Objects and Connections with NO OCCURRENCES. You should do a DB Backup prior to running the reorganize and there is a Standard Report of Objects with No Occurrences (not connections unfortunately) that can be run before and after the reorganize to see which objects were removed. One thing I didn't like about the reorganize (out of the box) is that the display of what it did CANNOT be copied and pasted into say Excel and there is no log or report output (that I can find) just a display. I you don't know how to get at these Aris features/functions just respond and I can provide print screens.
Hi Michael,
thank you for your prompt answer. What you suggest sounds to me like a admis option. I have some admin rights, but I am just a user. It would even help me, if I can somehow put more object IDs in to the Find. We are external users working for EC and we must do this cleaning by ourself before the delivery.
I am not sure I can do the DB reorganise feature.
Thanks, Tibor
Tue, 09/28/2021 - 17:38
Wed, 09/29/2021 - 10:35
Hi Tibor,
So, let's try to find out whether you have the reoganize permissions :)
1. Log in to the applicable database
2. right-click on the database
3. check for "reorganize"- can you see that option?
4. if you do: make sure to backup your database before reorganizing it :)
.png)
Best,
Veronika
Dear Veronika, thank for your prompt answer. I have the "reorganise" option, but can I somehow select which part of the database will be reorganised? Because there are hundreds of different models in the database from different organisations and I cannot interfere with their models...
Hi Tibor,
the point is: Only objects and connections without ANY occurrences will be purged with a reorganization. So unless you have reason to believe there is valuable information in the database, which does not have occurrences in models, it should be safe to use reorganisation. If you have the slightest doubt: That's why Veronika recommends to do the backup first.
BTW: If they did not want you to use reorganisation, they wouldn't have given you the privilege to use it.
In reply to Hi Tibor, by M. Zschuckelt
Somehting I just found out about the DB Reorganization. If you run it via Administration/Databases in Aris 10 Connect you actually get some more Detailed Options (see scrren shot) that previously were ONLY available via the command line running of the DB Reorg.
I was particularly interested in the "Delete connection definitions that are used in Matrix Models Only" option as we had hundreds if not thousands of these connections (I called them no occurrence connections) as they exist in the DB cluttering up our Repository even if the connection was not displayed on the Matrix. If they are displayed on a Matrix they will not be deleted with this option. The default DB Reorg would NOT delete these "cluttering" occurrences.
In reply to Somehting I just found out by mikhubb
I have to go back on my words.
The DB Reorg option described by me previously does NOT delete "no occurrence connections/relationships". It will DELETE real connections/relationships that were CREATED and only EXIST on a Matrix Model. These are NOT the "No Occurrecne" connections/relationships that I am looking for and are also described in another post Relationship/Connection and DB Reorg that I submitted to the Aris Community.
Hello Michael,
as far as I understand the matrix model is a report on connection definitions. Connections shown in a matrix model do not represent connection occurrences. When you create a connection by setting a check mark in a matrix model you only create a connection definition.
The option you discussed toggles if you want to protect the connection definitions of all objects occurring on any axis of a matrix model from getting deleted if they have no "real" occurrences. That's why the reorganization does not distinguish between your "clutter" connections and those that actually show in a matrix model. In both cases there are no occurrences.
Wed, 09/29/2021 - 14:41
Hi Tibor,
I fully agree with M. Zschuckelt.
However, while I was thinking about your problem, another potential solution came to my mind- if you created a dedicated folder for your processes, you could proceed as follows:
1. Create a new folder for your "final" processes
2. Cut a process
3. Right-click on that new folder
4. Select paste as --> model with objects
5. Select the refresh button in the upper menu
--> repeat until every process has been cut and pasted as model with objects.
This should only paste the objects into the folder that have an occurence; you can then delete the remaining objects from the old folder structure.
So much to the theoretical part- however, in practice, I have made the experience that sometimes the "paste as model with objects" function does not work properly. So, make sure to check the relevant folders (also a refesh might help). :)
Hope that any of the two suggestions help.
Best,
Veronika
Thanks for the kudos, Veronika. I have not had any issues with "paste as model with objects". The point to observe is, that as soon as you have an entire folder structure where you want to use your idea this may happen:
- you have folder A and B with models a and b with object definitions X residing in A and Y residing in B.
- X has got an occurrence in b and Y has got an occurrence in a.
- Using paste model with objects neither X nor Y will be moved to the new groups, because the function only takes objects with it, that reside in the same group as the model you are moving out.
- So following Veronika's strategy you would still have to verify for all objects remaining in the groups, that they do not have any occurrences before deleting them. There might also be someone else you do not know of, who reused any of the objects, because he wanted to invent an object of the same name.
The logic of this feature is, that usually objects are created in their "home" model, while other objects are reused from elsewhere. So if you are moving homes you only take the inhabitants with you but you do not accomodate guests in your new home.
Wed, 09/29/2021 - 16:37
Thank you guys both for your ideas. Honestly I would rather go in direction of moving models (variant B from Veronika), but there is a problem. Following our internal rules, all the objects must be in internal library, I have a separated folder (other than the folder where the objects are used) where all the objects reside. So for example I have a folder 'BPMNs' containing all the models, and then I have a folder 'Library' where I already moved all the objects from all other folders. How can I proceed in this case?
Thanks a lot for your appreciated help :)
Tibor
Fri, 10/01/2021 - 09:08
Hi Tibor,
Unfortunately, I don't know :(
If I were you, I would check a person in charge whether there is anything that prevents you from reorganizing the database.
You can store the backup on your local machine (or somewhere else) and easily restore the backup, if needed.
What this reorganization function does is:
it checks every folder and every model for objects and if
1. object in folder and in model = nothing happens
2. object in folder but in NO model = deleted
Best,
Veronika
Actually, it looks like the variant B will work. I moved some models into newly created folder, and only those used objects were copied. And they were automatically moved into a new folder created by the ARIS. The name is the same as was in the former model: 'Library' :)
The only problem is that the links to ARIS UML modeller are gone, but I will recreate them. The links within the Architect are OK.
Hi,
if you wanted to "pick" the object definitions with occurrences in your model and have them with your model again, you could move the model to the group, where the objects are and then move it back "with objects", thus you virtually go "collecting" your objects.
From an administrative point of view I am not quite sure, what the point is having the objects in a separate group from the model. For object types like roles, organizational units, applications etc. you normally want to govern those object types centrally (e.g. in a "library") and probably you also have different owners for those. They should be locked away in separate groups, where the owners have appropriate access. For the flow objects, events and Lanes in your BPMN processes you normally do NOT want to reuse them anywhere. If you did, you would run the risk that anyone reusing them inadvertently changes them and hence impacts your process. If you leave those objects where they were created in the group of your process, anyone who might be tempted to reuse them would get the information where they belong and can refrain from doing so. If you put everything in a big bucket, governance becomes a nightmare.
Yiou are completely right, and exactly for this reason we have two libraries:
- one within our modeling group, reused only by us;
- another one at the level of all the organisation (including EC) - we use this moslty for reusing some very general objects.
In my comments I was speaking about the first one, of course
Here is my recommendation on "reused only by us". If you are talking about activities, tasks, subprocesses, gateways, events - do not even reuse them among multiple processes under your control. At the definition level you create chaos, if a task occurs in two processes. BPMN does not have a concept of definition and occurrence. There are only the diagrams and their XML representation. But in ARIS you are likely to have the need to create reports based on your modelling artefacts. And then it becomes difficult, if a task has got two different predecessors and successors in two different process models.
EDIT:
Summary: A similar activity in a different process (even with identical description) is a different activity, because it serves a different purpose (goal of the other process). Activities are unique, because they define, what the process does and that includes their context of predecessors and successors.
