CDM with multi level relationship and conditional visibility in CFM

Continuing the discussion from Form Modelling: CDM, several relationships and abstract models:

Problem: A CDM should be composed of DM´s A, B and C with the relationship A → 1:n → B → 1:1 → C. The Data from C should only appear after a specific selection in B and an established link between and C.

1. Create three Document Models.

2. Create two Relationship Models. A to B with a 1:n multiplicity. One A can have many B documents, but each B belongs to exactly one A. The second relationship connects B to C with a 1:1 multiplicity. Documentation Link

3. Create the CDM. Root is DM A with repeatability 1, below the first relationship group (A→B, 1:n. To-many relationship requires a proper limit, e.g. 10. Below sits DM B followed by the second relationship group (B→C, 1:1) below sits DM C. Documentation Link

4. The critical addition is inside the B→C relationship (to-1 binding) group: add a StringType field called t_docRef and a BooleanType field called HasC. Documentation Link

5. Then add a computation rule that sets HasC to true when t_docRef is filled, and false when it is not. The t_docRef field is automatically filled by the system when a C document is linked to B. The HasC boolean will be used in the next step to control visibility in the CFM. Documentation Link

6. Create the CFM which references your CDM. Build one screen where A fields are at the top. Below that build the A→B relationship group (component type Table List). Each row represents one B document. When the user clicks a row, a detail screen opens.Inside the detail screen, there are three parts: First, a Section with the B fields, second the B→C relationship binding. This is where the user selects which C is linked to this B. You configure this as a Drop Down Selection. The dropdown shows available C documents (products) and lets the user pick one. Documentation Link

7. Third, a Section with the C fields.This section is controlled by a dependentGroup configuration that uses the HasC computed field as its masterField. When HasC is null or, the entire section is hidden. As soon as the user selects a C through the dropdown, the t_docRef gets filled, the computation sets HasC to true, and the DM C fields appear automatically.

What This Gives You

The user opens an A document and sees the request data at the top and a list of B documents below. Clicking a B row opens a detail screen showing the B data, a dropdown to select a C, and once a C is selected, the C-specific fields (risk questions) appear dynamically.

What This Does NOT Cover

The automatic creation of B documents based on a selection in A requires Camunda or custom code. The CDM and CFM handle the display and the relationship bindings, but not the automatic document creation.

Thank you for your answers! One question: how does it work if C is my “abstract” DM, but I would actually like to add/display fields of the subtypes based on the user selection?

Hi @maria-wintry-ice
The easiest way would be to add all the Fields that you need to the supertype. You can use includes to ensure consistency between the supertype and the subtype Fields. However, this assumes a to-many Relationship.

That being said, @paul-tall-kernel and I think there’s a logical error in your initial post. If you want to use a 1-to-1 relationship that means that you could only ever link one product. As some of your other screenshots suggest that multiple products may be linked to a tender, this seems to suggest that you need to:

  1. Model Relationship Models (1:1) between the Tender and the Sub-Type Product
  2. Add all of these to the CDM
  3. Add the t_docRef Fields to each of these Groups in the CdM

This way, the Fields of each subtype can be shown when the specific SubType Document is linked.

Hi @malcolm-silver-ice ,

thanks. So, the tender can only be linked to one product, thats correct.
Maybe the confusion comes from the tenderRequest, that has a 1-many relationship with tenders, which means, that it also has a 1-many relationship with the product (via the tender).

So, the idea was, that we only have one relationship between tender and the abstract product_dm, instead of having a relationship between tender and every possible subtype of the product_dm. Because in each instance only one of the relationships than actually is active.
But if I understand it correctly, this doesn’t really work in practise? And I need to model a relationship with every subtype?

Hi @maria-wintry-ice

I’ve asked my question relating to the Model Graph on the original post as the information was more relevant there. Form Modelling: CDM, several relationships and abstract models - #3 by mcaemmerer

Regarding the use of Heterogeneity in CDMs, you can certainly use the link to the SuperType DM in a CDM. TenderRequest (1) - (n) Tender (1) - (1) Products.

If you use Child Activities you can enter the data into the SubType Product using a specific Form Model for each subtype. This will allow you to enter any and all field values that you have. The only restriction would be that you could only work with the Fields on the SuperType for Validation and Computation Rules on the CDM.

If you do not use Child Activities and you want to show the Controls from the to-1 linked Document directly on the Form, then you are restricted to one of the following:

  • Only Referencing Fields from the SuperType Model in the Controls (and therefore adding all SubType Fields to the SuperType in extreme cases)
  • Modeling separate Relationship Models to each of the SubTypes and adding each of these Relationships to the CDM.