Problem
A good example can be found in a DCM application for mortgage applications. Based on the current application the system has to decide whether the Junior Mid-Office employee is allowed to make the approval decision, or if a more senior role is needed. The stakeholders may decide that any property with a value under half a million can be done by junior employees, while anything above has to be done by a senior employee. Furthermore the user should not have performed previous tasks for the application, to adhere to the four-eyes principle.
The problem of this case is not how to create such logic, as that is perfectly doable using Blueriq's rule engine. The problem lies in the maintainability of the application. Logic for user permissions is different to other logic (e.g., calculating a mortgage amount) and mixing them may decrease the maintainability. User permissions concerns the manner in which knowledge workers interact with the system, not with the domain at hand.
Decouple Category
Properties
| Property | Description |
|---|---|
| Decouple category | Application function (5) |
| Complexity | Low |
| Related patterns/Solutions |
|
Solutions
Webservice
It is possible to create an authorization web service. This could be a BAAS, or created in some other manner. This web service would return the users roles based on the user ID, and other important information concerning the current application, such as the property value. This pattern is a suitable fit as user set results are appropriate and the authorization might be needed by other applications as well.
| Type | Score | Description | |
|---|---|---|---|
| Knowledge characteristics | User set or System set | User set | User-set values enter the profile, which are set from the returning message and the subsequent data mapping. |
| Parameters or complex model | Parameters | Only simple input/output parameters could be used with Web services (BaaS). The input and output parameters are neatly defined in the contract of the web service. You are able to steer what values are set in the data mapping. If you want to fill in the parameters differently for different calls from the same module, an additional data mapping and AQ_WebServiceClient service call needs to be created. | |
| Enhanced by Blueriq Functionality |  | Blueriq can use dependencies up to the contract. There are no decision requirement graphs or dependencies possible between the calling application and the BAAS. | |
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality. | Focus on Internal or External Use | External | A web service is intended for external use, and relies on an official contract definition. |
| Low Implementation complexity | | You get two additional modules in your project, and a second project next to it. As you are in control of the information being send, the structure will be similar to what you use in the application module. Therefore the mapping should be easy (1 to 1). You have to create your own contract for the communication, and keep this updated. | |
| Internals invisible (encapsulation) | | Internals are not visible and/or accessible of a web service. | |
| Autonomous | | The business rules are executed in a separate profile, and no side-effects are possible. | |
| Highly Testable | | Webservices are easily testable. | |
| Highly Reusable | | A BaaS implementation is not very reusable because of a lack of parameter support. Hence, for every web service call a mapping must be defined. | |
| Out of the Box | | No custom code required in general. | |
Deployment characteristics | Part of Application or Separate Deployment (=deployment) | Separate Deployment | As soon as a new version is deployed, all consumers directly use the new version. When web services are versioned, the calling party can decide itself when to migrate to a new version. |
Function
A Blueriq function can be created which handles the authorization question. This function is then distributed across Blueriq applications. This pattern is suitable as user-set results are a good fit, as well as likely simple parameters suffice. The high reusability of this pattern allows us to easily check whether a user has permission in different applications or contexts.
| Type | Score | Description | |
|---|---|---|---|
| Knowledge characteristics | User set or System set | User | Any output of a function call in a flow is made user set and the rule engine can not overwrite it. |
| Parameters or complex model | Parameters | The function call support simple in- and output parameters. | |
| Enhanced by Blueriq Functionality | | In- and output parameters are validated and dependencies can be shown. | |
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality. | Focus on Internal or External Use | Internal | Although a function can be exposed as web service, the focus is on internal use. |
| Low Implementation complexity | | Functions are easy and lightweight. The only significant complexity gain is due to an additional module in your project, which does not need to be connected in any manner. | |
| Internals invisible (encapsulation) | | The internals can be viewed if wanted, but when using a function there is no need to do so. You only see the in- and outputs of a function and there is no mental load on the Business Engineer with the internals. | |
| Autonomous | | The business rules are executed in an own separate profile and do not mingle with the profile of the calling application. | |
| Highly Testable | | These functions can be unit tested in studio, as well as automated as regression tests that call it as web service. | |
| Highly Reusable | | You import a function into a project as library, and are ready to use it. | |
| Out of the Box | | No custom code is needed. | |
Deployment characteristics | Part of Application or Separate Deployment (=deployment) | Part of the Application | A function is distributed as library, and that model becomes part of the application. |
External rule
The derivation whether a user has a certain role within the given context can be implemented using an external rule. It would either derive a boolean attribute which indicates that the user is allowed a certain action or not, or derive a set of roles of a multivalues string attribute. The decision what a user is allowed to do, is taken in code. The code has to read the appropriate attribute values from the domain to come to its decision.
| Type | Score | Description | |
|---|---|---|---|
| Knowledge characteristics | User set or System set | System | An external rule is part of the truth maintenance mechanism and any result is system-set. |
| Parameters or complex model | Complex Model | On the external rule parameters can be defined which trigger the truth maintenance. In code you however access to the complete profile, and can use any attribute during the calculation. Although it is best practice only to use the truth maintenance parameters, we classify this as complex model. | |
| Enhanced by Blueriq Functionality |
/
| External rules are part of truth maintenance mechanism. However, there are dependencies for the truth maintenance parameters, but there is no way of knowing what happens in the external rule or what attributes are actually needed. In these cases it is not possible to rely on truth maintenace mechanism. | |
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality. | Focus on Internal or External Use | Internal | External rules are only used by Blueriq. |
| Low Implementation complexity | | There is a simple hook, and the code that needs to be written is simple. The difficulty lies with keeping the code in line with the model, as the external rule reads attribute values in a hard coded manner. | |
| Internals invisible (encapsulation) |
/ | The internal code is not visible from the model. From the code however, you can view the entire model. | |
| Autonomous | | As the complete profile can be input to the external rule, changes in it may lead to side effects during the execution of the external rule. In addition, code and models are highly coupled so it is difficult to test the model autonomously. There is always a strong dependency with code. | |
| Highly Testable | | Unit tests can be written in code. the difficulty lies in the hard link to the defined model. When the model changes, the code might break as it is hard-coded what attributes are needed. | |
| Highly Reusable | | Once you have the external rule defined, then you can distribute the definition in a library and use it simply on any desired attribute.The domain needs however be very similar, as the code reads the values of certain attributes in a hard coded manner. When different attributes are needed for another application, then the code needs to be changed. | |
| Out of the Box | | An external rule requires writing of code. | |
Deployment characteristics | Part of Application or Separate Deployment (=deployment) | Part of Application | The code has its own life-cycle and is deployed separately. It is however strongly coupled with the domain of an application. This leads to the code moslty only be used by one application. Therefore, we regard it as part of the corresponding application. |
Module with Flow
A separate user authorization module can be created which is distributed as library across projects. In it is a domain with authorization rules, and a flow which takes the decision. You might not even need the flow if everything is handled by the rule engine. The calling application has to make sure to fill the appropriate attributes with values when calling the flow, or when the authorization is needed. The support of dependencies and the decision requirements graph make this pattern interesting.
| Type | Score | Description | |
|---|---|---|---|
| Knowledge characteristics | User set or System set | System set | As the underlying module is included, the rule engine can do its work. |
| Parameters or complex model | Complex Model | The entire function can be used as output. There are no clear input parameters defined. | |
| Enhanced by Blueriq Functionality | | This pattern is enhances by Blueriq functionality, as model validations, the Decision Requirements graph, dependencies and specifications keep working. | |
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality. | Focus on Internal or External Use | Internal | This pattern purely covers internal use. The business function is included in a Blueriq library. |
| Low Implementation complexity | | Including a library is done quickly and easily. The complexity can however increase drastically in case that many libraries are used and stacked, or if many projects need updates from the same library. When many specializations are present, then the complexity is high. | |
| Internals invisible (encapsulation) | | All internals are visible and increase the mental load of the business engineer. Mistakes may be made when elements are used which were not supposed to be used. | |
| Autonomous | | The business rules are executed in the context of the main application. When the main application uses internals of the library, then making changes generates side effects. | |
| Highly Testable | | The library can be tested on its own, either by unit tests in studio or with special test applications. When the application gets larger testing larger chunks of model can get difficult. | |
| Highly Reusable | | Including libraries by hand can be time-consuming when the number of projects becomes large. The Blueriq Control Center can help with many projects. | |
| Out of the Box | | This is possible without custom coding. | |
Deployment characteristics | Part of Application or Separate Deployment (=deployment) | Part of Application | The library has to be imported into a project and becomes part of it. |
Issues and considerations
The preferred pattern for this problem is Decoupling Pattern 5: Function. It has the knowledge characteristics required for this problem, namely that values are user set and support for parameters, so that the same authorization function can easily be used in different applications/contexts with a different domain. The high reusability and testability make the implementation of this mechanism simple.
Decoupling Pattern 2: Webservice call is also a suitable pattern but it is more complex to implement due to the data mappings, and the reusability of these data mappings can be a problem in this example. Furthermore, in this example the authorization is likely only used internally, and the focus of a web service lies on external consumers.
The advantages which Decoupling Pattern 6: External Rule and Decoupling Pattern 1: Module with Flow have in terms of integration with the rule engine are not utilized in this example. An authorization is usually only done when loggin in or when opening a case. The inference mechanism is then simply not needed. As these patterns score low on maintainability characterstics, the other patterns are preferable.
Overview
Content Tools