Communication Business Object Groups

In the previous section we did not focus on the relationship between Member and OutgoingLetter, Member and OutgoingEmail, Member and ContactNote. Should the Member object have a relationship with the OutgoingLetter, OutgoingEmail and ContactNote objects? Yes, it should because a member should know all the communication that took place with her. So in principle, the Member object could have a relationship with each of the above objects independently.

However, if we look carefully at OutgoingLetter, OutgoingEmail and ContactNote objects, we will notice that they all have a lot of things in common. From the Member object’s perspective these are all different types of communication with the Member.

Maybe OutgoingLetter, OutgoingEmail and ContactNote should be represented by a single object (called, for example, Communication) where the type of communication is an attribute (just like it is in the ContactNote object)? This is certainly possible. However, we should notice that even though there are a lot of things that are common to all these objects, there are certain things that are specific to a particular object. For example, an e-mail may have CC and BCC attributes, not relevant to other objects, the state of the received e-mail can be Read and Unread whereas the state of the outgoing letter or e-mail can be Sent and Unsent and so on. In other words all these objects are quite different semantically.

AwareIM solution to this commonality problem is business object groups (see also the “Business Object Groups”). By making business objects members of a business object group we recognize the fact that business objects are sufficiently different (so the existence of them as separate objects is justified), yet there is a lot of commonality between them (this commonality is above all manifested by the existence of attributes of the same name and of the same type).

So we need to introduce a business object group called Communication and make OutgoingLetter, OutgoingEmail and ContactNote objects members of this group.

Once we introduce the Communication group, the Member object can be related to this group only rather than to each individual member of this group independently.

To summarize, we have introduced a number of new business objects with a relationship to the Member object and a new business object group Communication with a relationship between the Member object and the Communication group.

We can now configure the OutgoingLetter, OutgoingEmail and ContactNote objects (see Configuration of Business Objects). Note that at this stage we define only simple attributes of these objects without defining a reference to its Member object. The reason is that the matching attribute on the Member object must refer to a group and we do not have the group yet.

Now it is time to define the “Communication” business object group. We right click on the “Business Object Groups” node in the Elements Tree and select “New” in the pop-up menu – the editor of the business object groups appears in the working area. We specify the name of the new group Communication. Then we select the OutgoingLetter object from the panel containing available objects and click on the right arrow button to move it to a panel containing the group members. Then we do the same thing with the OutgoingEmail and ContactNote objects. Our group is ready now and we click on the “Save” button. The new group appears in the Elements Tree.

The last step is to define a reference to the Member object in all members of the Communication group and define the matching reference to the Communication group in the Member object. We can do this by going to the Member object and adding the Communication attribute. Note that existing business object groups appear in the list of available attribute types just as individual business objects. So we select the Communication group as the attribute type, specify the name of the attribute “Communication”, tick Multiple allowed (member can have multiple communications), specify the relationship type as Owner of (communications cannot exist without the member they belong to) and create the matching attribute with the name “Correspondent”. Note that since the Communication attribute in the Member object refers to a group, the system automatically creates matching attribute in all members of the group! If we open each member of the Communication group now we will see the Correspondent attribute referring to the Member object. The only problem is that the system automatically created the attribute as Multiple allowed so we need to un-tick this flag.