Association Traversal Issue

I've got 2 entities in my Domain Model, Party and InfoSystem, which are logically M:M.  I am resolving the M:M via an information entity, PartyRole, with two 1:M associations to the above entities, both of which are owned by PartyRole.  I'm using PartyRole as I want to store additional attributes, e.g. RoleType, in this intermediate entity. Otherwise, I could have used a M:M between Party and InfoSystem. When I make a page to create a new InfoSystem, part of the form requires linking to a User-selected Party. I've managed (via Microflows) to create a temporary InfoSystem, PartyRole and Party, each of which are linked together. The associated Party is then swapped for the User-selected Party upon selection, using a microflow under the Selection button.   However, if the user tries to select another party (by re-opening the selection pop-up), I am left with multiple temporary objects. Ideally, I would retrieve the existing (temporary) PartyRole by association with the InfoSystem, remove it, and then link the new  one. However, I cannot do this, as the PartyRole is not accessible from the InfoSystem which I have access to.   I feel like I am missing something fundamental here, any advice would be appreciated.  For some reason, I couldn't select Version 7.21.0, but that is what I am using.   Many thanks,  Joe
3 answers

Is it because it's a 1:* association and you can only access a List? If so, you could retrieve your temporary list (by association) and filter out what's not needed (maybe you can just grab the head of the list). If it is empty, create a new one, if not, use the existing one.

Or do I miss something?


Hi Joe,

I think I understand your issue and I have had the same frustration. These are two possible solutions for this:

  • Add a 'create PartyRole' for the InfoSystem, which creates a party role object, connects that to the InfoSystem and shows a reference selector to select a party;
  • Add a 'selection' association between Party and InfoSystem, which - On Change - automatically creates the role and sets the right associations. You don't want to commit that selection in the 'help-association' though, so you would need to empty it again before committing.


My preference would be the first option, since that's most representative for what you're conceptually doing (i.e. creating a new party role). In the event of changing the party, you just edit the party role and select the new party via the reference selector.


Hi Andreas, 


First of all, thanks for your quick reply. The problem is that since we only have access to the Info System at that point, we are at the wrong end of the association (i.e., the side without ownership), and so we cannot access the PartyRole(s) at the other end.

It's similar to the sample app "AdvancedCourseStarterPackage", which has OrderLines owning the association OrderLine_Order. Presumably, you can't access the OrderLines FROM the Order, by association? 


Thanks again,