Summary
With this pattern, a business function is modelled and distributed in a library, similar to Decoupling Pattern 5: Distributed function library. The difference to Pattern 5 is no module mapping is needed. Hence, the implementation of this decoupling pattern is less cumbersome.
Implementation
In the table below the implementation charateristics by using a Function are shown.
| Type | Score | Descriiption | |
|---|---|---|---|
| Knowledge characteristics | Implicit or Explicit call | Explicit* | This is an implicit call that is triggered by the rule engine each time when an input value changes. |
| User set or System set | User set* | System set. | |
| Parameters or complex model | Parameters | The complete profile can be used as input, but the Action attributes of the External rules are most likely to be the input parameters. The implementation of an external rule has access to the complete profile. It is therefore important to document what values are needed by the external rule. You can set what values should trigger the external rule mechanism. Most likely are those identical to the input values. An external rule can be used as default on an attribute, but in general it could change the value of any attribute. There are no additional attributes required in your domain, keeping it clean. | |
| Maintainability characteristics | Internal or External | Internal | This type of decoupling is mainly for internal and external use. As the function is in a web service, any party could call it. |
| Automated or User Interaction |  | ||
| Implementation complexity |  | This pattern does not clutter your domain with unnecessary attributes, which is an advantage. A disadvantage is that it is not clear to the business engineer what the external rule exactly does. That is all hidden away in the service. For example, you can not use the dependency function in studio to find which external rule might change its value if it is not placed as default value on the attribute. | |
| Part of Application or Separate Deployment | | The decoupled function is partly in the model, and partly in code. You should make sure that the code is deployed together with the project. | |
| Internal invisible |  | ||
| Testable | | ||
| Autonomous/decoupled | | Implementation of an external rule is seperated from the calling application. | |
| Reusable | | ||
| Out of the Box | | A new external rule that calls a specific web service has to be created by a developer. |
*In a future version of Blueriq this will be an implicit call.
Example
Het functie concept wordt gerealiseerd door twee verschillende modules te definiëren, de functie en de applicatie.
De modules staan naast elkaar, en niet op elkaar. Hierdoor is verwevenheid niet mogelijk.
Binnen de applicatie worden onderstaande elementen gedefinieerd:
- Global Service met de naam van de functie ("AQ_FunctionType_Add" en "AQ_FunctionType_Multiply")
- Service type van het type dat hierboven gedefinieerd is.
- Exposed flow waarin de juiste services worden aangeroepen.
Binnen de functie implementatie worden onderstaande elementen gedefinieerd:
- Global Service voor "GetInputParameters" en "SetOutputParameters"
- Exposed flow met naam van de functie; hierin wordt een mapping gemaakt van de input en output parameters naar de attributen binnen het domeinmodel.
- Definitie attribuut met daarin de berekening.
Definities aanroepende applicatie
Definitie Global service type in Blueriq
Definitie van Service type
De applicatie attributen (calculator.A en calculator.B worden gescheiden van de functie interface (zowel input als output).
De services worden aangeroepen vanuit een exposed flow.
Definitie functie
Creëren van exposed voor de functie.
Mappen van input en output parameters.
Aanmaken van attributen waarin de berekening wordt gedefinieerd.
Overview
Content Tools