[SOLVED] Business Object Groups Referencing

PointsWell

I think I may be pushing things too far here.

I have an unwieldy fugly BO called Contact. There are multiple types of Contact that I have been managing by multiple ps_RoleType attributes, however this has left me with an unwieldy Contact BO that requires a lot of conditions on forms, queries etc.

I have instead decided to start using BO Groups. So I now have 6 Contact BOs:

Contact_1000

Contact_1001

Contact_2000

Contact_2001

Contact_3000 and

Contact_3001

I've then used multiple BO Groups such as:

Contacts_Companies which are all Contacts ending in 0

Contacts_People which are all Contacts ending in 1

Contacts_Buyers which are all Contacts in the 2000 range

... and then

Contacts_All which are all the Contacts

Previously I have used BO Groups as a means of tying together Contact Methods BOs such as email, telephone, websites.

My question (finally): am I being overly ambitious trying to connect one BO Group to another BO Group

ie Contacts_All.om_ContactsMethods and ContactsMethods.ob_ContactsAll?

I seem to keep generating integrity errors, though I am possibly getting tired and cross eyed at the moment.

ACDC

I don't understand why you went for a contact group, surely a single Contact object with a role attribute and related object rules could have worked.

Could you expand on why you went this way, I think using an object group just complicated things.

PointsWell

I can see why you might think that but a single contact BO had too many redundant fields.

Although it seems like a Contact would just be a simple object it actually owns and peers to multiple different other objects depending on the role.

Contacts sellers, contact company buyers and contact agent company have tax records.
Contact employee don’t. There’s a ton of other different other relationships. The original monster contact record only had about 30% of the fields used by any single role. This created an overhead in queries and displaying forms. Every time a Contact was selected in the contacts home screen it required a process to determine company or person and then every refresh showing and hiding buttons based on the role attributes. It seems like it should be simpler as just a Contact but it’s the keystone BO that has grown to be a painful monster that has to tamed.

ACDC

That makes sense, dividing them into individual objects and then grouping them into a grouped object is the answer. I have a similar setup and referencing the Grouped Object in all rules and processes makes it work like a dream.

My question (finally): am I being overly ambitious trying to connect one BO Group to another BO Group

I don't think so, in my setup I have very complex grouped objects

johntalbott

Out of curiosity ... what's preventing you from creating individual BOs for Employees, Sellers, Buyers, etc?

PointsWell

johntalbott wrote
Out of curiosity ... what's preventing you from creating individual BOs for Employees, Sellers, Buyers, etc?

I have through the numbered BOs those ending in 0 are companies and 1 are people. The leading digit in those BO names then determines the they are Buyers Sellers etc. The model is quite complex and how they interact at various points differs and you need to be able to group Contacts together at different times as they all interact differently with the other BO families that exist in my model. Only 4 of the 6 Contact BOs can be contracting entities for example and those Contracting entities then have relationships later when doing contract calculation and commissions. By having Contracting entities I am able to have much less and more reusable processes later on.

Rennur

My experience with groups is, if it is not configured properly (when used as references) can cause problems with processes in context not being killed of, resulting in EXECUTION_CONTEXT table filling up which may cause memory issues.

It is a very useful feature in large apps.

PointsWell

Rennur wrote
My experience with groups is, if it is not configured properly ...

Yeah I think that is my problem, I am trying to migrate from one large BO to multiple groups and the journey is proving to be a bit lumpy - have gotten down from 1000+ integrity issues to 32 so far (in a day - which is a massive testament to AIM). That obviously doesn't include the further unit and end to end testing that I am still going to have to do.

It just really is not happy with the Contacts Groups owning Contact_Methods groups at the moment.

PointsWell

Have figured out (at least part of) the issue.

At some point when deleting my fugly Contact record AIM did not fully delete all references to it. As a consequence some of my forms had a lingering ob_Contact.

Every time I added back my ob_Contact pointing to the new Contacts_All group it would come back and complain about the lingering ob_Contact.

Interestingly the ob_Contact was directly duplicated i.e. it did not have 1 appended.