Continuing the discussion from Computation of a field only one time / if it has NULL value:
Is this correct?
Let me start the discussion by saying that as a modeler, creating models that use external data is always more complex.
When all data comes from an end-user inputting data into a form based on a Form Model, then I have full control to task this and ensure that everything works as expected. The default behavior that computations are updated on every value change makes sense and therefore the Kernel Language returns the results we expect.
When receiving data from an external source, lots of extra questions come up.
- Is the data valid?
- How is the document being updated?
- Is the document being validated at the same time?
- Will this data be used in Computation Rules?
- …
These are things that need to be discussed with the development team. Sometimes, the Kernel Language can be used to validate or process the data that is coming in. In other cases, this might not be appropriate.
So much about incoming data, but what about letting computed values determine the outcome of external processes? For example evaluating permission / user access rights from computed fields or instructing a backend process to create new derived documents based on the truthyness of computed fields?
Thanks for the extra ideas. I’ve asked some of my more technical colleagues to take a look at your ideas relating to UAA and backend processes.
From a modeling perspective, the truthiness of computed fields can be evaluated in Workflows. The computed Field value can be made available to the BPMN process and evaluated using expressions or a DMN Table. We have a specific delegate for creating new documents so this could be used once the value evaluates to true.
Thanks for inquiring. Unfortunately we do not use workflows. But I have another related question: Since our backend relies on computed fields, we wondered in which way computations could be tested. In line with the model driven approach these computations are developed by a team of domain experts and there are no unit-test-like automated tests of the possible outcomes of these computations. Is there a recommendation here?
There are!
Ad Hoc Testing when Modeling
Ad Hoc Testing allows modelers to:
- Test individual Computation or Validation Rules.
- Multi-Select Computation or Validation Rules and test them together.
This means that manual tests can quickly be completed in the Simple Model Editor as you model.
Once you have selected the Rules for your Ad Hoc Test, a new window will open with an automatically generated UI that contains the relevant Fields based on your selection. For example, when testing the Computation Rule “TotalPriceWithDiscountComp” from Order_DM in the “basic” workspace you see the 5 Fields and 1 Repeatable Group referenced in the Rule.
This allows you to test through the different combinations that you modeled and ensure the correct results are shown.
To support these tests, the Ad Hoc Testing allows you to import and export sample data so that you can create test data that should always lead to a certain result. Just use the options under “Data” on the left-hand side of the Ad Hoc Testing window.
mgm Q12-TDS - Test Data Suite
The Test Data Suite is specifically designed for testing the business logic modeled in the Document Model. This is a separate product (part of the Q12 Quality Landscape) which allows you to define and automate tests for your Document Models.
Sabine and Ferdinand (contacts at the bottom of the linked Test Data Suite page) will be able to give you more information on this product.