Skip to main content

Change detection and validation

Change detection and validation

Hii Retail has advanced change detection and validation capabilities. The services provided within this area consists of:

  • Change Detection
  • Validation Engine
  • Approval
  • Print Scheduling
  • Distribution

Together they provide the following capabilities:

  • Identify what has changed on an entity and output these changes, including previous values
  • Validate the change against customer specific rules
  • Hold back a change that violates any of these rules
  • Set aside changes that requires manual intervention before it can be distributed
    • Printing of paper labels or posters
    • Manual approval of the change in a UI
  • Trigger custom actions and warnings
  • Distribute to downstream services when all is ok

Change Detection Service​

The Change Detection service will keep track of the current state of any entity (Item, Price Specification, Item Identifier, etc.). When an update on the same id is received it will identify what has changed and produce change events. These events are stored and can be the source for a UI to display all changes happening for individual stores. These event are also the source for the Validation Engine.

The change event will contain a list of changes holding every property that has changed since the entity was last updated.

The Changes Query API contains further details.

Validation Engine​

The Validation Engine will listen for all change events and identify if any of contained field changes must be validated. If a change event must be validated it will execute all the rules that apply to the changed properties and produce a Validation Result.

The Validation Result is then used by the Distribution service to determine if the content is ready for down-stream consumption.

How the validation works​

The Validation Engine requires defined rules to operate. If no rules exist for any of the changes in the change event or none of them is violated, the Validation Result will be valid and it will instruct the Distribution service to allow the change. Produced Validation Result will contain execution results for all the violated validation rules.

Validation Rule can be of several types and can apply different kinds of checks to the changed data. See more about Validation Rules in the API.

The most important properties to consider on the Validation Rule, besides the obvious ones (name, entityType, fieldName), are the ruleType, ruleValue and severity.

Rule Type​

The rule type defines the functional area the rule is meant for. There are 4 possible values here:

  • LABEL_RELEVANCE - which is used to determine if the change should trigger label printing. This is of course only relevant if the store has paper labels or posters.
  • VALIDATION - should be used for validation of the content according to your own custom preferences. This types could be coupled with an action that triggers an alert in your own system or in Hii Retail if one is defined.
  • MANUAL_APPROVAL - will stop the change from being distributed no matter what severity is set on the rule. It is used to put changes on-hold until a manual approval command has been triggered to release the changes. See further details in the Approval section.
  • ACTION - allows actions to be triggered without applying any other restrictions on the changes. It is recommended to set severity to ACTION as well in this case.

Rule value​

The Rule Value defines the rule logic to apply to the change. The following Rule Values exists:

  • MUST_BE_DIFFERENT - a basic inequality check to verify that the data is not the same as before. If a property with this rule has NOT changed, the rule will be violated and defined actions will apply.
  • MUST_HAVE_VALUE - The property MUST have a value. If it is empty or null, the rule will be violated and defined actions will apply.
  • MUST_BE_INT - The property MUST be an integer value. Does not accept decimals or strings. If the rule is violated defined actions will apply.
  • MUST_BE_BOOLEAN - The property must be a boolean value. true, false are accepted values. If the rule is violated defined actions will apply.
  • MUST_BE_NUMERIC - The property must be a valid number and can include decimals. If the rule is violated defined actions will apply.
  • MUST_BE_FLOAT - The property must be a valid float number and can include decimals. If the rule is violated defined actions will apply.
  • MUST_BE_ONE_OF - The property must be one of the defined values in the arguments list. This requires a list of defined values as an argument to the rule. If the rule is violated defined actions will apply.
"arguments": [
    {
      "key": "pnp.validator.isOneOf",
      "value": ["1", "2", "3", "10", "55"]
    }
]
  • MUST_BE_GREATER_THAN_PREVIOUS - The property must be numeric and it must be greater than the previous value. If the rule is violated defined actions will apply.
  • MUST_BE_SMALLER_THAN_PREVIOUS - The property must be numeric and it must be smaller than the previous value. If the rule is violated defined actions will apply.
  • MUST_BE_GREATER_THAN_THRESHOLD - The property must be numeric and it must be greater than the threshold defined as an argument to the rule. If the rule is violated defined actions will apply.
"arguments": [
    {
      "key": "pnp.validator.isGreaterThanThreshold.threshold",
      "value": "40.5"
    }
  ]
  • MUST_BE_SMALLER_THAN_THRESHOLD - The property must be numeric and it must be smaller than the threshold defined as an argument to the rule. If the rule is violated defined actions will apply.
"arguments": [
    {
      "key": "pnp.validator.isSmallerThanThreshold.threshold",
      "value": "1200"
    }
  ]
  • MUST_MATCH_REGEX - The new value of the property must match the regular expression 100%. If the rule is violated defined actions will apply.
"arguments": [
    {
      "key": "pnp.validator.regEx.expression",
      "value": "/[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?"
    }
  ]

Approval​

The Rule Type of MANUAL_APPROVAL is specifically for holding back changes that the customer determines to need manual approval before it can be distributed to downstream services.

A typical example is price changes for franchise stores. These stores typically operate more independently than self-owned stores and might have stronger opinions on how they want to price their goods. This can be solved with a manual approval process for stores of this type.

A large retailer with 4 brands under their umbrella controls the prices on a brand level. Prices for each brand are determined centrally and assigned to a Business Unit Group for the entire brand.

One of these brands consist of many franchise stores where the central pricing often deviates from their required margins on the items, so they want to control the pricing locally in the store.

The manual approval process will stop all price changes for these stores and the store manager has a daily routine to open a Manual Approval UI where all the price changes for the day are listed. She can then check each of them and select the prices she approves and deny the prices she does not agree with. The store will then keep their own prices and not update according to central assignments

The Rule Type LABEL_RELEVANCE is made specifically for the process of manual label printing. The changes caught by this Rule Type will mark the entity for printing. The print process is not managed by Hii Retail and an integration must be in place. Hii Retail will only identify the changes, schedule what needs to be printed and hold back the entity from being distributed to downstream services.

When the printing has been performed in the integrated system, Hii Retail expects a confirmation through the input API and it will then mark the print schedules as completed. The changes will then be ready for distribution, unless a Manual Approval is also needed.

Distribution​

The Distribution service will keep all the changes ready for further processing until a Validation Result has been received from the Validation Engine. If the Validation Result is positive the data will be distributed. If the Validation Result is negative, the service will perform the actions defined on the Validation Result according to the severity.

Note! The actions may not be native to Hii Retail or the Distribution service, and other services might be responsible for performing actions.