Includes

🚧

Includes are Limited Availability

This feature is still in Limited Availability. If you're interested and would like to use includes now, contact your Akamai account team.

Some behaviors and products such as Adaptive Media Delivery, IoT Edge Connect, and Progressive Media Download may not be supported with includes yet. Adding them to an include results in an error. To use the unsupported behavior, add it to the parent property's rule tree instead.

Includes are compatible with all security products. However, note that you can't use includes to split up the security configurations maintained outside of Property Manager.

We are continually updating Property Manager behaviors to make them work in includes. See PAPI documentation for a particular behavior to check whether it's currently allowed in includes.

Overview

Includes are small chunks of a property configuration that you can create, version, and activate independently from the rest of the property's rule tree. Includes are similar to regular properties, also referred to as “parent” properties, but don't have hostnames assigned to them. Instead, includes are executed from the include behavior you add to the parent properties. Includes have their own JSON rule files that specify reusable portions of property configurations.

With includes, you can:

  • split your property configurations into small reusable components,
  • delegate the management of different parts of a single domain to responsible teams,
  • implement common settings and auto-populate changes across multiple properties,
  • update parts of the configuration contained in an include without the need to version an entire property.

Though you may have achieved some of these functionalities through complicated, multi-level nesting in a property's rule tree, includes provide better performance and safety by extensive validation checks against parent properties. Includes come with official support and simplified configuration, and prevent double billing.

The use case for includes also differs from PAPI's Bulk Search and Update operations that let you update many properties at once but you still have to activate them all and you risk overwriting someone else’s changes. With the common settings includes, you update a shared piece of a rule tree once and it automatically takes effect everywhere.

When you create an include, you can set includeType to either of these:

  • MICROSERVICE includes that let you split the configuration into smaller chunks, each of which contains settings for a specific microservice.
  • COMMON_SETTINGS includes that serve as a single place to update reusable settings across properties.

Microservice includes

Step by step workflow for using MISCROSERVICE includes >>

With MICROSERVICE includes, you can delegate the management of different parts of a single domain to responsible teams. Includes have a separate activation flow, which allows different teams to work independently of each other. You can control access to an include with groups, so that an application team can only edit the settings within a designated include, having read-only access to the parent property.

Breaking up your configuration into MICROSERVICE includes improves flexibility and makes it easier to incorporate automation. Developers can push changes to staging or production networks on their own schedule. They no longer have to wait for other teams to approve and test their updates.

In the parent property's rule tree, in order to use the MICROSERVICE include, you need to add a mutually exclusive path match to the same rule. If you don't set a path match within the same rule or the match isn't mutually exclusive, you'll get a validation error that prevents activation.

You can have up to 300 MICROSERVICE includes in one parent property. A single MICROSERVICE include can have up to 3,000 activated parent properties. See Rate and resource limiting for more details.


Consider this sample setup:

Site (property hostname)MicroserviceScopeConfiguration
www.example.com/Default settings that apply to all requests.Parent property “www.example.com”
/loginSettings that apply to all requests under the /login path.The “login” include
/login/videosSettings that apply to all requests under the /videos path.The “videos” include
/apiSettings that apply to all requests under the /api path.The “api” include

Common settings includes

Step by step workflow for using COMMON_SETTINGS includes >>

COMMON_SETTINGS includes come in useful in configurations that share a significant number of settings, often managed by a central team. By referencing the same COMMON_SETTINGS include in different parent properties, you ensure there’s a single place to update standardized settings. This helps to improve consistency and avoid duplication of effort. When you update and activate the include, changes take effect immediately across all parent sites.

In the parent property's rule tree, you add the COMMON_SETTINGS includes to the default rule or rules without any matches. You can have up to 3 COMMON_SETTINGS includes in one parent property. A single COMMON_SETTINGS include can have up to 3,000 activated parent properties. See Rate and resource limiting for more details.


Consider this sample setup:

Site (property hostname)ScopeConfiguration
www.example.comSpecific settings for the www.example.com siteParent property “www.example.com”
www.foo.comSpecific settings for the www.foo.com siteParent property “www.foo.com”
Settings that both www.example.com and www.foo.com shareCOMMON_SETTINGS include

Relationship with parent properties

These are the limitations and dependencies that apply to the include-property relationship:

  • You can only add includes to properties that share the same contract, product, and rule format.

❗️

Includes and the parent properties that reference them must use the same ruleFormat. It is best practice to use the most recent frozen rule format. The latest rule format is not supported. See Rule format schemas for more details.

  • A parent property can only reference active includes.
  • If the include is not activated, the parent property returns an error and can't be activated. Also, you cannot deactivate an include if any active parent properties reference it.
  • Activating another version of your include triggers a validation against all its parent properties. Any errors found in the include or parent properties block the activation. You need to resolve all errors to be able to proceed. See Validation errors for specific error types. Warnings note non-blocking, less severe issues that you can ignore.
  • You can only delete deactivated includes that are not pending on either the staging or production networks. If an include gets deleted, all parent properties remove references to this include.
  • Includes inherit the values of the global variables from their parent properties. If you have more than one parent property that uses a specific variable, the include that features this variable gets the value from the parent it's currently referenced in. See Variables within includes for more details on global and local variables.

Check the rate and resource limiting section for other limits that apply to includes.