When are transient fields computed in Overview and Tree Engines

Modeling
, , ,
1

Hi,
In the Form Engine, one can use “Preprocessing Settings” to control whether computations are executed when a document is opened. But how does this work in the Overview and Tree Engines?
My experience so far is that transient fields are only computed if there is a non-transient field that depends on them. Is this correct, and why is that the case?

Below is an example where I would like the two fields in the green box to be transient (they are actually not) — they are only meant to provide a better overview. When I mark them as transient they are not computed. When I mark them as non-transient they are computed, even if they are not filled in the document.

Location and User/Employee have m-n relationship with StartDate and EndDate als Link-Fields.

Location_TM
Location_TM1377×550 32.1 KB

Regards,
Foued

P.S. Please ignore the End Date output error.

2

Hi @foued-soft-queue

My understanding is

  • Data in transient fields is not sent to the server, see here
  • The Overview or the Tree engine will send a query to Data Services to load the data from the server when you open the Overview or Tree
  • The transient fields will appear as empty in the list view

This matches my test in the Preview App
Data entry
firefox_r05YE5fnwj
After sending the data to the server
firefox_QPD3BDrnVm
Reloading the same data
firefox_XCVuZgdDdY

You can test this yourself with these 2025.06 models
Transient_DM.json (6.5 KB)
Transient_FM.json (4.7 KB)
Transient_OM.json (2.3 KB)

The only exception that I know of is computed fields in a CDM which can be recomputed in post-processing if you set Data Services up correctly, see here. This would include the computed transient fields.

In addition you can use preprocessing in the Form Model to re-computed your document on loading. This would mean that the computed transient fields would be filled when the form is (re-)opened.

3

And it looks like this

firefox_ihmrBiCsE6
firefox_ihmrBiCsE61920×1160 62.9 KB

Computed transient fields that were empty in the Overview are then filled due to preprocessing in the Form.

Simple_Model_Editor_FnhwnpQBRC
Simple_Model_Editor_FnhwnpQBRC1920×1160 118 KB

4

Hi @malcolm-silver-ice,

Thanks to your suggestion, I manually modified the LinkFields documents each time and started the Preview app, then checked the database. I noticed that the documents in the DB are saved with the computed non-transient fields, even if I left these fields empty or set them incorrectly. This means the client (Overview and Tree Engines) actually has nothing to do with the computations — instead, the data services perform the computations before the documents are saved in the database.

This behavior occurs because, in the application-pu_server.properties file inside previewapp-server-202506.0.0.jar, the computation-enabling configuration is set to *:

mgmtp.a12.dataservices.documents.computation.enabled-for-models=*

To verify that this configuration is responsible, I set it to an empty value, and as expected, no computations were performed on non-transient fields during document import when initializing the preview app by Data-Services. Furthermore, when viewing the documents in the Overview and Tree engines, the non-transient fields appear exactly as defined in the documents — meaning the client does not perform any computations on its own. :fire:

I provided feedback for the GetA12 Docs so that this information can be added to the Preview App documentation, since this behavior is not immediately obvious and differs from the default configuration of Data Services.

Behavior with Transient Fields

Nonetheless, the client’s behavior regarding transient fields is somewhat unusual, as I also understood it from your two posts. I am attaching the following (SelectedItems) overview screenshot example: I have just edited the first entry, meaning I modified the form of LinkedFields, and as a result, the computed value of the transient field is displayed in the Overview. For the other two relations/entries that I did not edit, this is not the case.

I find this confusing and think it is not implemented correctly. Either transient fields should always be computed and displayed in Overview and Tree, or they should remain completely empty or developers should decide that by config. In any case, when dealing with such edge cases, it is essential to fully understand how this behavior works.

Selected-Items-after-editing-one-items

Foued

5

There is another question I haven’t addressed yet:

How can one persist a calculation that depends on Today , such as TotalDuration when EndDate is not set? When loading the Tree or Overview, these values are already outdated after just one day. In my opinion, having to solve this programmatically – whether on the server or on the client – is a very unusual approach.

At this point, my current conclusion is that both fields should be marked as transient , and that the calculations should be performed (for example, via a special annotation) whenever the Overview or Tree is loaded.

6

Hi @foued-soft-queue
Thanks for sending the feedback regarding the documentation.

Relating to your point

The screenshots that I posted related to Overviews and Trees used to display document(s). Things like loading all the People in your database and showing them in a list view or showing a tree of Countries, Cities and People.
Your example comes from a different context.

  1. You’re showing a SelectedItems Overview. This means that you have loaded a specific Document (in a Form) and are visualizing the documents linked to the document that you loaded. As you are in a Form you can trigger computations and validations and your form can be “dirty” as the state has changed since you loaded it.
  2. You have computations based on Link Fields. This means that you have loaded a composed document which is a very specific context in A12.
  3. You edited your data. This means you triggered a computation. The default behavior in A12 is that any value change triggers all the computations in the Document or Composed Document. You need to check the preconditions of your computation rule to see why the computations for the other locations were not triggered.
7

Regarding Computations with Today

There is an open ticket, A12-11467, which is trying to clarify how we can model and re-calculate such Computation Rules. As always, please feel free to contact your Project Support or comment this ticket directly to add your project’s feedback.

If you have more questions to triggering computation in the Overview or Tree Engine, I suggest opening a new (linked) topic in the respective category.

8

Absolutely agree with you. However, regarding the third point: in the SelectedItems Overview, we’re actually dealing with three distinct documents. That’s why, technically, it makes sense that only one was updated. I fully understand this from a technical perspective.
Still, from a user experience point of view, this behavior is not acceptable, since end users won’t be able to understand why only one record shows the calculated data while the other two do not.
So, technically understandable – but from a UX perspective, it’s problematic.

Conclusion:
From a developer’s or modeler’s perspective, this kind of situation should absolutely be avoided.

9

Thanks for sharing your workspace with me privately.

I now understand your question a lot better.

This Selected Items Overview is in a “normal” binding on a normal form. When the fields are edited on the Link Document, the Kernel only triggers the computation for that document as it only sees that one document.

One possible solution would be to remodel this Form using a CDM so all the Location documents are loaded in the front end. This should mean that all the computations are triggers for all 3 rows as all 3 documents are in scope.

That being said, this is all a workaround for the actual problem you have, keeping the Total Duration up-to date. Given that you express this Total Duration as a string, I doubt that you want to search for it or filter for it. As a result I think that some form of custom implementation to calculate and display this string is probably more appropriate than using that Kernel Language to calculate it given the current limitations that we have discussed.

10

Hello @foued-soft-queue I am a member of the Discourse team. I can see that there was a new response to your question. Do you find it helpful or should the question remain open?

Thanks ahead for your feedback and have a nice rest of the day!

11

Hello @svenja-still-dawn,

Yes, the exchange of ideas and the suggested solutions are definitely helpful. This way, I and others can choose the most suitable approach for our needs. There isn’t one perfect solution, but rather several possible ways. The thread can be marked as “solved”.

Have a nice day, too!