Relationships in xCP – Part 2

This is the second in a three part series on how to make your relationships wonderful and full-filling using xCP2. Click here for part one.

One Tool To Model Them All

I have already mentioned that with xCPDesigner we have a consolidated tool to create xCP applications. Part of this shift is the move to model driven design, which is a lot like pig latin only instead of putting “a” after every word you use the word “model.”

Everything is a model

Everything is a model – and not the America’s top model sort. xCPDesigner follows the nomenclature of Rich Client Platform(RCP) tools so any discussion of an xCP application design from now on makes me long for a synonym for the word “model”. Just be glad marketing didn’t put an “x” in front of that too.

In this post I want to focus on how creating a model changes your approach to a design. Since we have covered history now let’s set the current context. There are five “kinds” of data models that serve as the foundation of your design in xCP2.

• Content Models – this will be the most familiar as it is really just good ole’ dm_document inherited custom object types to manage stuff that has content. I resist using the term “unstructured” data here but that is really what we are talking about. These are files + metadata.
• Folder Models – as the name implies custom types inherited from dm_folder.  Containers that you extend with custom properties and logically different UI’s but that is another topic.
• Business Objects – I dislike this name though I undertand why they chose it. These are structured data entities (contentLESS object).
• Picklists – these are …. Well they are picklists. Ordered name value pairs used throughout the application as “datatypes” in the other kinds of models or in UI’s.

And Lastly –

• Relationships – Relationships and picklists are similar in that both can be added as a “property” of one of the other kinds of models.(Content, Folder, BO)

These property models (my term for referring to picklists and relationships) can be given unique property names to qualify them in the context of a defined metadata model.

What does that mean?

Think of a customer and a purchase order. In the past we would put likely use a customer ID on the PO to create the binding to the customer object. Not bad but you are forever creating the need for hand crafted DQL in the UI to represent the tie and likely custom java to access, format and map to the correct UI element.

To access details like default shipping and billing addresses in xCP1 we might have had to create dql activities to look up those values and store them in process variables. To prevent repetitive fetches we might have also expanded the model of the PO to hold this data but that introduces another set of issues.

Here is the change. With xCP2 you can simply create a many to one relationship from the PO to the customer type in the designer and give it some logical name like “customer.” Everywhere within the designer (processes, UI’s,etc)  that you need to refer to a property on the “other side” of the relationship it is as simple as “po.customer.shipping_address.”

Let me stress something. EVERYWHERE in the designer. This is critical. The new designer has standardized on a single script editing view and syntax so that inserting a test for a value like this is the same whether you are in a UI validation or an activity template condition. This editor exposes a laundry list of functions (standard string manipulation, type conversions, etc.) What is REALLY cool here is that you can write your own in javascript or java (depending on the context) and add it to the designer! – but I digress.

When defining a relationship you can add properties to the relationship itself. Take marriage for example. Two instances of people objects are tied together with a relationship. For the sake of sanity let’s assume it is a one to one relationship for now. The relationship itself has a start date,end date,location, etc. In order to capture this data previously these attributes would have been replicated to each of the participant objects or a third contentless object.

I might have to write something like this “select location from marriage_object where r_object_id in (select current_marriage_id from person_object where name=’Perry, Tyler’) ” Because the “current_marriage” relationship property of the person object is in the model we no longer have to create complex DQL joins to access it, just refer to it as “husband.current_marriage.start_date.”

As a testament to the underlying power of the repository, this capability is implemented as inherited relationship types. We have theoretically always been able to do this but the tooling has in many ways caught up with the potential of the concept. I also point this out as I believe that as we get more experience with the platform some of our practices around tuning and sizing of these parts for the underlying architecture will need to evolve.

That I can now model relationships in the designer with point and click is amazing and if this is all they had done it would have been great. The story does not stop here though. In the next post we will examine the visualization of relationships in the xCP UI and data services.