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
Properties
Kenmerken
Kenmerk
Beschrijving
Ontkoppel categorie
Domein functie (1)
Complexiteit
Laag
| Table of Contents | ||
|---|---|---|
|
Samenvatting
Berekeningen worden vaak gebruikt binnen applicaties en vormen een belangrijk onderdeel van de domein laag. De laag waarin alle business regels zijn gedefinieerd. Berekeningen moeten autonoom kunnen worden uitgevoerd en eenvoudig worden aangepast. De berekeningen in dit voorbeeld hebben een beperkt aantal input parameters waarvan de implementatie op een onderhoudbare manier moet worden gerealiseerd.
Context
Binnen elke applicatie worden berekeningen uitgevoerd. Berekeningen hebben binnen een applicatie een speciale rol omdat ze onderdeel zijn van de domein laag waarin bedrijfsregels worden vastgelegd. Voor bedrijfsregels die ontsloten worden zijn onderstaande kenmerken van belang:
Door gebruik te maken van truth maintenance is het domein model altijd in een state die 'waar' is.
Om aan bovenstaande kenmerken te kunnen voldoen is het belangrijk dat berekeningen op de juiste manier worden geïmplementeerd.
Daarnaast zijn er verschillende typen te onderscheiden van bedrijfsregels binnen de domein laag:
- Eenvoudige bedrijfsregels (zoals berekeningen) met een beperkte aantal (<5) input parameters en een output parameter.
- Een bundeling van bedrijfsregels waarvan de output van de een de input is van de ander. Bedrijfsregels die dus een sterke afhankelijkheid met elkaar hebben.
- Complexe bedrijfsregels waarin een groot aantal input parameters (> 10) voor nodig zijn. Dit komt vaak voor bij de evaluatie van complete klant dossiers.
In dit artikel wordt alleen de eerste behandeld waarbij de oplossing zorgt draagt voor een goed onderhoudbare implementatie binnen Blueriq Studio.
Binnen Blueriq implementeren van berekeningen die eenvoudig ontsloten en aangeroepen kunnen worden. Hierbij mag geen verwevenheid ontstaan tussen de implementatie en de aanroep. Hierbij spelen (1) implementatie, (2) ontsluiting en (3) aanroep een belangrijke rol.
Probleem
Bij de implementatie van de berekening én aanroepende applicatie ontstaat er vaak verwevenheid dat voorkomen moet worden; hetzelfde deel van het domein van de applicatie wordt ook voor de berekening gebruikt. Dit heeft een sterk negatief effect op de onderhoudbaarheid van de applicatie (zie Maintainable applications). Daarnaast zijn er nog andere belangrijke aspecten die spelen bij de ontkoppeling van een berekening binnen Blueriq. Deze zijn beschrijven in tabel hierboven.
Een concreet voorbeeld van een berekening is bijvoorbeeld een LTI (Loan to Income) berekening.
Voorbeeld berekening:
In een concrete situatie kan dit als volgt uitzien:
In dit voorbeeld is het belangrijk dat de parameters ontkoppeld zijn van de daadwerkelijke implementatie van de berekening en de aanroepende applicatie. Het
Om dit probleem goed op te lossen moeten onderstaande vragen worden beantwoord:
- Hoe berekening implementeren?
- Hoe berekening ontsluiten?
- Hoe berekening aanroepen?
Oplossingen
Hint: Focus op patroon ipv implementatie van het patroon. Dit laatste is alleen relevant binnen het patroon.
Voor de oplossing wordt rekening gehouden met de kenmerken die benoemd zijn in de tabel onder "Context".
Er zijn verschillende oplossingen mogelijk waarbij de bovenstaande kenmerken in meer- of mindere mate gerealiseerd kunnen worden. Per geval dient de best passende oplossing te worden gekozen. In de tabel hieronder worden de belangrijkste eigenschappen getoond en hoe elke oplossing daarop scoort.
Webservice
**Mogelijk in Blueriq 10.x
Hieronder worden per oplossing in het kort de verschillen in de implementatie beschreven. Voor de realisatie van de daadwerkelijke oplossing wordt verwezen naar het desbetreffende patroon en wordt een concreet voorbeeld beschreven.
Functie
Door gebruik te maken van een functie kan aan de belangrijkste kenmerken voor de implementatie van bedrijfsregels (zie tabel onder "Context") invulling worden gegeven. Met de functie kunnen onderstaande aspecten worden gerealiseerd:
- Autonome functies implementeren
- Eenvoudig onderhoudbaar
- Herbruikbaar vanuit het Blueriq platform
- Rule Engine kan worden gebruikt t.b.v. de afleiding van regels
- Out of the box mogelijk
De essentie van de functie is:
- Aparte module voor de implementatie van de berekening en aanroepende applicatie. Hierdoor is design-time vermenging niet mogelijk.
- Geen side effecten tussen berekening en applicatie. De applicatie kan run-time nooit ongewenst het gedrag van de berekening beïnvloeden.
- De berekening eenvoudig binnen het BQ platform aanroepen en ontsluiten.
- Functie is eenvoudig te realiseren en te onderhouden
Voorbeeld
Dit patroon wordt beschreven in Decoupling Pattern 8: Function. Het gebruik van een Functie binnen Blueriq wordt beschreven in MyBlueriq.
External Rule
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.
Voorbeeld
Dit patroon wordt volledig uitgewerkt in Decoupling Pattern 6: External rule. Het gebruik van een External Rule binnen Blueriq wordt beschreven in MyBlueriq.
Webservice
Door gebruik te maken van webservices wordt het mogelijk om functies te ontsluiten. Het nadeel van deze oplossing is dat het alle aspecten van Blueriq (Truth maintenance, rule engine, impliciete calls) niet gebruikt worden. Hierdoor is een webservice wel geschikt voor het ontsluiten van bedrijfsregels maar dit gaat altijd gepaard met het verlies van essentiele Blueriq functies.
Blueriq ondersteund het creëren van Webservices OOTB. Hierbij wordt echter geen invulling gegeven aan de autonomie van de functie die ontsloten moet worden. Hierdoor zal er nog steeds verwevenheid ontstaan tussen de implementatie van de berekening en de overige applicaties doordat het domein model nog steeds onderling wordt gedeeld en deze in dezelfde scope worden uitgevoerd.
Voorbeeld
Dit patroon wordt volledig uitgewerkt in Decoupling Pattern 2: Webservice call. Het aanmaken van een Webservice met Blueriq wordt beschreven in MyBlueriq.
Issues en overwegingen
Als rekening wordt gehouden met de belangrijkste kenmerken voor de implementatie van bedrijfsregels voldoen is de Functie de beste methode. De functie heeft de beste implementatie kenmerken en daarnaast maakt het het beste gebruik van Blueriq mogelijkheden. Daarnaast worden de mogelijkheden van de Functie in de toekomst uitgebreid zodat maximaal gebruik wordt gemaakt van de mogelijkheden van Blueriq. Het implementeren en executeren van bedrijfsregels wordt daarmee maximaal ondersteund door het Blueriq platform.
De andere oplossingen, webservice en mapping, zijn het minst geschikt doordat ze weinig gebruik maken van de mogelijkheden die Blueriq biedt.
Gerelateerde patronen
- Dossier validatie; hierbij worden complexe bedrijfsregels geimplementeerd en ontsloten. Het lijkt daarom sterk op dit voorbeeld van berekeningen met het verschil dat het mogelijk wordt om een volledig klant dossier kan wordt gevalideerd.
- Applicatie functie; een applicatie functie biedt functies aan die niet sterk leunen op de rule engine.
- Front-end ontsluiting; Koppeling met ontsluiting kennis naar een front-end.
Property | Description |
|---|---|
Decouple category | Database decoupling (2) |
Complexity | Medium |
| Related patterns/solutions |
|
Overview
Content Tools