I have several doc models linked with relationships, and a CDM reflecting the structure. I would like to copy some values from a repeatable group into another one, with a similar index field.
As the new computation cannot be in any single model (it would not see the other path in the other small model), it has to be defined in the CDM itself. But then, the rule cannot be in either the source or the target repeatable groups, so that the rule cannot express “do that for every row in the repeatable group”.
From my knowledge, it is thus impossible to model.
Is there another way?
Other options I consider are:
letting the backend do the copy programmatically
changing the whole structure to one single big doc model…
Hi @marieestelle-firm-summit,
are the corresponding index values always present or do you want to copy them over as well? If so, is there always a constant number of entries?
I will need to check that with the client, but most probably all 16 Bundesländer will be present on both sides.
The next question is whether a human has to create all 16 target repetitions manually, or if it should be done by BE… I guess it’s not possible with modelling?
If you don’t need this copying behavior when the user is working with the actual form, then I would suggest to copy the necessary information programmatically instead of a modelling approach.
Hi @marieestelle-firm-summit,
just to clarify: the only issue we currently have, is that we can not initialize a document with a given set of repetitions and in your case a document with a given set of links to a set of (to be created?) child documents. You would have to do this in the back end with custom code.
Everything else is indeed modelable with a CDM.
In the meantime I had a look into your models and the CDM currently contains some errors:
the annotations are missing/incorrect (the cdm.queryRoot annotation is wrong and the annotations on the “relationship representing groups” (=Relationship Element) are missing.)
the repeatability is set incorrectly. In the model given, the includes are set to be repeatable, while this should be set on the Relationship Element.
If the latter point is corrected, this:
is not an issue. So it is in fact easily modelable to “copy”/transform data from one repeat row to another.
As said above, the current limitation we have, is that we can not initialize a document with a set of repeat entries. But you would face the same issue, if you would try your other option
I will try to take this topic to Kernel, but this will only solve “regular repeats”, not CDM Relationship Elements.
@felix-blazing-river Thanks for your advice. I corrected the structure of the CDM. Could you please check my new models? Hereby I had to rename all relations, roles and rootgroups, because it seems there is some implicit naming conventions: with “random” names, the annotations were not created automatically and I got an error “role not found” (or similar).
There is still no “official” tutorial about CDMs, I guess it’s under progress, but if there are naming conventions, I hope they will be stated explicitely!
Now my CDM has all annotations, but I still get the same error on my computation, because I can put the rule in the target “relation” group, but the value I want to copy is still inside a repetition that is inside the include.
@erik-radiant-gorge Yes, I think I will advise the client to choose a programmatic approach to both initialize the 16 Laender and fill the values.
regarding the naming conventions/creation of a CDM
yes, unfortunately the addition of the annotations were quite error prone. Therefore, a new editor for CDMs was added to the SME with the 2023.06-ext3 release. (see its demo here: GetA12 under Modeling Presentation Video)
If you are working with a previous version of A12, you need to adhere to the following steps, in order to use the SME’s feature that adds the CDM annotations automatically:
add the cdm.queryRoot annotation in the model settings
include the root Document Model. The name of the include must be equal to the included-DM’s root group name.
add a new group as a sibling to the include. Its name must be equal to the Relationship Model’s name, it should represent. Its repeatability must match the Target Role’s multiplicity.
include the child Document Model. The name of the include must be equal to the included-DM’s root group name.
(repeat steps 3 and 4 to traverse more relationships)
save the CDM. Do not save in between. The SME will only go thru branches of the model tree that do not have annotations yet. (So if you saved at step 3, any new groups in step 5 will not get annotations.)
check the annotations created.
As CDMs are still an experimental feature, there is no tutorial yet. But we updated the documentation and added a new use case and more screenshots to follow along. See here: A12 Docu CDM Creation. There is also a Monthly Modeling Highlight Recording - CDM.
regarding the computation rule
It is currently not allowed for rules (Validation and Computation), targeting fields in a repeatable group, to lie in a different branch of the model tree than the target field (in regular DMs as well as in CDMs). But there is a ticket to change that (see A12-15148).
Your target field is /MainDocumentYear*/YearTargetRepartition*/TargetRepartitionRoot/Laender*/[SomeTargetValue]
so you are allowed to place your rule here /MainDocumentYear*/YearTargetRepartition*/Rule
but not here /MainDocumentYear*/YearTargetRepartition*/AnySubGroup/Rule
(as this is a different branch, branching off from /MainDocumentYear*/YearTargetRepartition*/)
If you move the rule to the parent group, it should work fine. (At least the error message in the SME is gone.)
Hi,
thanks for your answer, and I’m sorry that I didn’t reply sooner.
The client has chosen another way of modelling the main document model, and the feature I was trying to model will be eventually programmed in Backend. But I’ll keep your explanations for later
