Changes Introduced with the Rules Engine Upgrade

Applies To:

HTTP LargeThis platform has been optimized to cache and deliver static content (e.g., HTML, CSS, JavaScript, ISO, multimedia, and software downloads, etc.) over HTTP or HTTPS.

HTTP SmallLegacy. If you are currently serving traffic over this platform, then you may continue to do so. However, we recommend that you serve your traffic over our more robust HTTP Large platform.

ADNThe Application Delivery Network platform has been optimized to deliver dynamic content (e.g., login credentials, account information, etc.) over HTTP or HTTPS. Typically, user-specific and database-driven content are served over this platform.

Rules EngineAllows the customization of how requests are handled by our CDN service. It may be used to override the default response provided by an origin server, CDN settings, and the default edge server behavior.

This article provides an overview on the changes introduced by Rules Engine version 4.

Rules Engine v3 is undergoing end-of-life and will be discontinued on June 26, 2020. Your account will be scheduled for automatic migration starting from 4/6/2020. Please contact your account manager or our Technical Customer Support to schedule an earlier migration.
Learn more.

Summary of Changes

This upgrade to Rules Engine introduces the following concepts:

Staging Environment
Drafts
Policies
Deploy Requests
Independent Conditional Expressions
MCC Update

Staging Environment

This environment provides a safe workspace for testing the compatibility of a new Rules Engine configuration with mock site traffic.

Key facts:

It mimics your production CDN environment on a much smaller scale.
Changes to your configuration in this environment do not affect live site traffic.
This environment should not be used to perform scale, volume, or throughput testing.

Please keep traffic below the following levels:
- 50 Mbps
- 500 requests per second

Draft

A draft of a policy consists of one or more rules meant to identify requests and the set of actions that will be applied to them. A draft is a work in progress that allows frequent configuration updates without impacting site traffic. Once a draft is ready to be finalized, it should be converted into a read-only policy.

Rule

A rule identifies one or more types of requests and the set of actions that will be applied to them.

It consists of:

A set of conditional expressionRules Engine: Refers to the logic (i.e., IF and ELSE IF) through which one or more match conditions identify a type of request.s that define the logic through which requests are identified.
A set of matchRules Engine: Defines a prerequisite that must be met before one or more actions (i.e., features) may be applied to a request. conditions that define the criteria used to identify requests.
A set of featureRules Engine: Defines the type of action that will take place when a set of match conditions have been met.s that define how the CDN will handle the above requests.

These elements are identified in the following illustration.

Policy

A policy, which consists of a set of read-only rules, provides the means to:

Create, store, and manage multiple variants of your rules.
Roll back to a previously deployed version.
Prepare event-specific rules in advance (e.g., a rule that redirects traffic as a result of a customer origin maintenance.)

Although only a single policy per environment is allowed, policies may be deployed as needed.

Deploy Request

A deploy request provides a simple and streamlined procedure through which a policy may be quickly applied to the Staging or Production environment. A history of deploy requests is provided to facilitate the tracking of changes applied to those environments.

Only requests that do not pass our automated validation and error detection system will require manual review and approval.

Independent Conditional Expressions

A rule's matchRules Engine: Defines a prerequisite that must be met before one or more actions (i.e., features) may be applied to a request. conditions may now be configured to be mutually exclusive (i.e., select first match) or independent (i.e., match). Each of these options are briefly described below.

Match Type	Description
select first match	Highlights: Emulates the logic used in the previous version of Rules Engine. This logic will be applied to all matches and features that fall within the section identified by a blue line. Once a match is found, the features associated with that match condition will be applied to the request. No additional processing within the current "select first match" section will be performed on the request. A successful match will prevent further processing within the current "select first match" section. However, this will not prevent the request from being processed by match conditions defined outside of this section.
match	Highlights: Selecting "match" outside of a "select first match" section defines the criteria that a request must meet before a set of features may be applied to it. A request may satisfy multiple sibling match conditions within a rule. View Example A request may satisfy all three of the following match conditions: The parent of nested match condition must be satisfied before the features associated with it will be applied to a request. If there is a conflict when applying a feature to a request, then the last successful match determines which feature will be applied to it.

Match Type

Description

select first match

Highlights:

Emulates the logic used in the previous version of Rules Engine.
This logic will be applied to all matches and features that fall within the section identified by a blue line.
Once a match is found, the features associated with that match condition will be applied to the request. No additional processing within the current "select first match" section will be performed on the request.

A successful match will prevent further processing within the current "select first match" section. However, this will not prevent the request from being processed by match conditions defined outside of this section.

match

Highlights:

Selecting "match" outside of a "select first match" section defines the criteria that a request must meet before a set of features may be applied to it.
A request may satisfy multiple sibling match conditions within a rule.

View Example

A request may satisfy all three of the following match conditions:
The parent of nested match condition must be satisfied before the features associated with it will be applied to a request.
If there is a conflict when applying a feature to a request, then the last successful match determines which feature will be applied to it.

MCC Update

The following upgrades were applied to the MCC to support these enhancements and new capabilities:

A state-of-the-art user interface that makes it easier to set up rules.
The ability to draft changes to a set of rules in a policy before deployment.
The option to either push a set of rules to the Staging environment for testing or directly to the Production environment.
The ability to roll back to an earlier version of your rules.
Categorized matches and features that make it easier to find them.
New matches and features including geolocation match conditions.

Additionally, the following limitations have been repealed:

Limits on the total number of allowed rules have been removed. A policy may now contain as many rules as needed.
Limits on the total number of matches and features within a rule have been removed. A rule may now contain as many matches and features as needed.

Terminology

The following terms describe the new functionality introduced by this update:

Term	Old Term	Description
Draft	New Term	A draft provides a workspace for crafting a set of rules for handling your traffic. A draft may be saved in an incomplete state and will not affect live site traffic. This allows rules to be created over time or in preparation of a future need.
Policy	New Term	Once a draft is finalized it is locked and then becomes a read-only policy. Only policies may be applied to live site traffic via a deploy request.
Deploy Request	New Term	Use a deploy request to apply a policy to either the: Staging environment for testing. Production environment where it will be applied to live site traffic.
Staging	New Term	The Staging environment provides a sandbox through which a policy may be tested on mock site traffic before it is applied to live site traffic. This environment should not be used to perform scale, volume, or throughput testing.
Production	[Production]	The Production environment refers to live site traffic. Submit a deploy request to the Production environment when a policy is ready to be applied to live site traffic.

Workflow

The submission and deployment process for new rules has changed.

Old Workflow

All changes are instantly submitted for manual review. Once approved, they are applied to the Production environment.

New Workflow

Rules Engine now provides the following new functionality:

The ability to work on a set of rules over a given time period without impacting live site traffic.
The ability to have one or more sets of rules (i.e., policies) in stand-by mode. This allows them to be applied to live site traffic as needed.
The ability to test out a new set of rules (i.e., policy) in a staging environment.

This new workflow is depicted below.

The above workflow is described below.

Step	Description
Create Draft	A draft consists of a set of rules that define how requests for your content should be handled by the CDN.
Lock Draft	Once a draft has been finalized, it should be locked and converted into a read-only policy.
Submit Deploy Request	A deploy request allows a policy to be applied to either test or production traffic. Submit a deploy request to either the Staging or Production environment.
Deploy Request Review	A deploy request undergoes automated validation and error detection. Although the majority of deploy requests are automatically approved, manual review is required for more complex policies.
Policy Deployment (Staging)	Upon approval of a deploy request to the Staging environment, a policy will be applied to the Staging environment. This environment allows a policy to be tested against mock site traffic. Once the policy is ready to be applied to live site traffic, a new deploy request for the Production environment should be submitted.
Policy Deployment (Production)	Upon approval of a deploy request to the Production environment, a policy will be applied to the Production environment. This environment allows a policy to act as the final authority for determining how the CDN should handle live traffic.