Business Rules

This is the layer where your business logic will be applied to the data. It is a second layer on top of the business object, which can then be fed to the accesslayer. The business logic will be applied in the form of a database view. This enables you to make use of any functionality of the underlying database.

Definition

A business ruleset is a view on top of a business object. It allows the application of custom business logic.

Note

Even though the definition of the business ruleset is a view, mainly for performance reasons, it can be beneficial to persist the data again. For this process, Datavault Builder provides two approaches you may use depending on the use case:

Approach	Full Historization/Auditability	Supported Loading Strategy	Job Integration	Maintenace Effort
Business Vault	Yes	Full or delta	Need to be part of seperate load job.	May require adjustments for underlying Raw Vault model changes.
Materializing a Business Ruleset	No	Full	Can be part of same job as source loads.	Simple.

1. Search Bar

   Filters the business ruleset list.

2. Business Ruleset List

   Lists the existing business rulesets. Grouped by Business Object > System. Select a business ruleset from the list to see and edit its code with the editor.

3. Business Ruleset Editor

   The editor displays the SQL-Code of the view and allows implementation of new business logic.

   By using the -icon in the top right corner, a horizontal split-view can be activated.

   The next to it (de-)activates the data preview of the result at the bottom.

   Often used Keyboard-Shortcuts:

   Action	Windows/Linux	Mac
   Find	Ctrl-F	Cmd-F
   Replace	Ctrl-H	Cmd-Option-F
   Fold	Alt-L	Cmd-Option-L
   Go to Line	Ctrl-L	Cmd-L
   Remove line	Ctrl-D	Cmd-D
   Move line up, down	Alt-Up, Alt-Down	Option-Up, Option-Down

4. Add Business Ruleset

   Opens up the creation dialogue for adding a business ruleset.

5. Business Ruleset Properties

   Clicking onto the opens up the slider from the left, containing the business ruleset properties.

1. Quick Inserts

   Quick inserts can be used to search for tables/views on the database you would like to join to.

   This panel is made up of a search box at the top and a list of tables/views.

   • You can add more entries to the list using the search field.

   • Expand the name of the available list entries to see the fields available within the object.

   • Use the plus-icon or double-click to add the element to the view.

Adding Business Rules

To be able to add a business ruleset, an underlying business object needs to be created first.

Steps

1. Navigate to the Business Rules module and click onto “Add Business Ruleset”. Alternatively, you can click onto in the business ruleset list. This will automatically complete the first two fields of the creation dialogue.

2. Complete the creation dialogue.

3. Modify the view code in the editor to implement business logic.

---

1. Business Object

   Selection of the underlying business object to build the business ruleset on top of.

2. System

   Declaration of the source system, to define, for which related business object the rule should be created.

3. Business Ruleset Name

   Displayed name of the newly created business ruleset.

4. Business Ruleset ID

   Technical suffix ID for the business ruleset, which will be added to the view-name on the database.

5. Add Business Ruleset

   Button to complete the business ruleset creation.

Business Ruleset Properties

1. Include in Accesslayer

   The button toggles, whether the specific business ruleset is fed into the accesslayer. If enabled, a priorization can be given. The priorization is used, when combining different business rulesets in the accesslayer:

   • When a positive number is defined for the priorization for two or more business rulesets and if these rulesets have a different result for a field, then the value of the priorized business ruleset or the first non-null value is taken (golden record selection).

   • When a priorization of -1 is specified, then no golden record selection is performed for this business ruleset (e.g. the business ruleset is combined using a UNION ALL in the corresponding accesslayer).

   Hint

   This means, if there are three business rulesets, the first two having a positive priorization and the last has a priorization of -1, then for the first two the golden record selection is applied and the result is combined (using a UNION ALL) with the last business ruleset.

2. Is Error-Ruleset

   Defines the ruleset to be an error-view. The error-view will be mirrored into the errormart, as well as combined into an accesslayer-like errormart-view.

3. Alias View

   Create an alias view (schema_name.view_name) on the database to mirror this business ruleset. When choosing a custom schema, make sure that the schema exists and dvb_user/dvb_admin have the grants to manage views in it. May not be one of staging, datavault_staging, datavault, business_rules, business_rules_staging, business_rules_materialization, businessobjects. If alias_schema_id is accesslayer, best practice is to use same view_nq_id as business rule (this way stays unique).

4. Comment

   Custom notes about the business ruleset

5. Is Materialized

   Marks a business ruleset to be materialized.

Deleting a Business Ruleset

Steps

1. Click onto the located next to a business ruleset in the business ruleset list.

2. Confirm the deletion.

The deletion of a business ruleset will:

• Delete the business ruleset view

• Remove the business ruleset from the accesslayer (if fed into the accesslayer)

• Remove the error-mart view (if declared as error-ruleset)

• Remove the alias view (if declared having an alias view)

Materializing a Business Ruleset

Steps

1. Open up an existing business ruleset.

2. In the properties, activate the toggle “Is materialized”.

Explanation

When turning it on, it will:

• Create a table in the schema business_rules_materialization

• Create a business rules staging view in schema business_rules_staging, containing the view code of the business rule.

• Replace the current business rule view with a proxy view - which is either selecting from the business rules staging view - or from the materialized table. The proxy view will switch depending on the load state:

  • When the materialization is not yet done or ongoing, it will point to the business rules staging view.

  • Once the materialization is done, it will point to the materialized table.

Hint

The business rule will automatically be added to the jobs corresponding with the system of the granularity of the underlying business object for the business ruleset. For business objects with system “dvb_hub” it will be added to all jobs of a system having a load defined into the start hub of the business object.

When turning it of, it will:

Revert the above mentioned changes.

Loading

The materialization can either

• be triggered directly from the business rules module.

• Or it can be initiated over operations / a job.

Hint

• The materialization is always executed as full load.

• Materialized business rules added to a job will respect dependencies. E.g. if there exist multiple business rules within a job of the same system which are dependent on one another, they will be loaded one after the other.

• The load of the materialized business rule will also wait for any underlying loads within the job it depends on to finish prior to start loading.

Warning

Do never use either the tables in business_rules_materialization or the view in business_rules_staging anywhere else directly! Always use the proxy (e.g. regular business_rules.) view, also in other business rulesets.

Business Rules Limitations

• On Exasol, a business rule may not contain a “;” besides the one ending the view code (others will be removed automatically on save by the database).

• Changing the materialization of a business rule may result in an altered code for the business rule (i.e. CREATE vs. CREATE OR REPLACE).

• When having multiple materialized business rules stacked (built on top of one another) and altering an underlying rule, the dependent views may be manually reloaded to represent the changes.

• When switching from materialized to non materialized again to materialized, the state shows previous load state.