Page History
Problem
The problem which is addressed in this example is that the rate of change of the content of the value list is different than the lifecycle of the application itself. If these are coupled, then a new version of the application has to be created when the master data changes. When the master data changes is outside the span of control of the project. For a larger discussion on Master Data in different forms, see How to handle Master Data.
In our example of the municipalities, these change almost every year in the Netherlands. In 2005 467 municipalities existed and there were 458 municipalities in 2006. The general trend is there are less and less municipalities, and 2017 counted 388 municipalities.
An important aspect of this is that we want to maintain this list outside Blueriq, as it does not affect the behavior of the application (generally) and the data does not belong to the business for which we create the model. When the data changes, no new Blueriq application should have to traverse the DTAP street.
Solutions
Webservice
When there is a web service available which returns all municipalities as instances, then the Container type: AQ_InstanceLinker can simulate a value list. This pattern fulfills the requirement that the list is always up-to-date and that the model does not need changing when the list changes. This pattern is suitable for this amount of instances, but would not be if there would be much more municipalities, as otherwise too many instances would be present in the profile, reducing performance.
| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
External Value List
The external Value lists can be used to load the data, and is a pattern specifically aimed at large or quickly changing value lists. The data is not part of the profile and is updated when the server is restarted. Another advantage is that the model stays clean. Custom code is required to determine the possible values.
AQ_CsvConnectivityService
The Service call type: AQ_CsvConnectivityService can be used to load a CSV file into the profile. It is shown as value list with the Container type: AQ_InstanceLinker, similar as above. The main difference is that the CSV file is maintained by the project, and not by an external party. This can be both an advantage as well as a disadvantage.
Issues and considerations
For the municipality case, we advice to use the external Value list. Although the implementation effort may be somewhat larger because of the custom coding, it awoids a large number of instances in the profile. It also keeps the model clean, as no additional relations or containers are needed as are with solutions which use the Container type: AQ_InstanceLinker.
For a larger discussion on Master data, see How to handle Master Data.
Decouple category
(dynamic)
(static)
(dynamic)
/3
/3121External source check mark property of Value List and configuration. Work for Business Engineer.
2Custom code for reading data from source and the creation of instances. Work for Technical engineer.
3Depends on number of values/instances in the list.
Below differeent solutions will be described. For the realization of a specific solution, a reference is made to the relevant pattern and a concrete example is described.
Value list static
Value list defined within Blueriq Studio once. This value does not change run-time anymore.
Changing the value list requires a model customization and deployment.
With small value lists (<10 values), maintenance is easy. With a large value list (100+ values) maintence is very cumbersome.
Example
Adding values to a value list is descrbied in MyBlueriq.
Value list dynamic
An external rule also allows business rules to be implemented and unlocked. Compared to the Function, an external rule is not possible to ensure autonomy. An external rule uses attributes within the same domain as the application so that unwanted mixing is possible. In addition, the maintenance is low because an external rule is a rule that is implemented in code. Business rules do not want to be implemented in code but in Blueriq because of its maintainability.
Met een external rule kunnen ook bedrijfsregels worden geïmplementeerd en worden ontsloten. In vergelijking met de Functie is het met een external rule niet mogelijk om autonomie te waarborgen. Een external rule maakt gebruikt van attributen binnen hetzelfde domein als de applicatie zodat ongewenste vermenging mogelijk is. Daarnaast is de onderhoudbaar laag doordat een external rule een regel is die in code wordt geïmplementeerd. Bedrijfsregels wil je niet in code implementeren maar in Blueriq vanwege de onderhoudbaarheid.
Example
Adding values to a value list is described in MyBlueriq.
Instance list static
Instances should be created design-time and show instances by using an instance linker. Define a relation attribute to catch the instances.
Example
The implementation of an static instance list will be described in MyBlueriq.
Instance list dynamic
Some custom code is needed to implement dynamic instance list. An external resource must provide the values for the instance list and instances should be created run-time.
Example
No example available. Too bad joh.
Issues and considerations
Value lists that change regularly should be implemented by an external value list. The initial work is way more compared with a static value list, but the maintenance is way less. With an external value list you do not have the option to apply design-time model validation. In an expression, a value can be used which does not exist. This is only observed run-time.
Value lists that are constant (e.g. gender, yes / no / unknown) should be realized by a (static) value list.The values are defined design-time.
Decouple category
Properties
Property | Description |
|---|---|
Decouple category | Database decoupling (2) |
Complexity | Medium |
| Related patterns/solutions |
|
Overview
Content Tools