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.
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:
MICROSERVICEincludes that let you split the configuration into smaller chunks, each of which contains settings for a specific microservice.
COMMON_SETTINGSincludes that serve as a single place to update reusable settings across properties.
Step by step workflow for using
MISCROSERVICE includes >>
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, without having 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.
Consider this sample setup:
|Site (property hostname)||Microservice||Scope||Configuration|
|www.example.com||/||Default settings that apply to all requests.||Parent property “www.example.com”|
|/login||Settings that apply to all requests under the ||The “login” include|
|/login/videos||Settings that apply to all requests under the ||The “videos” include|
|/api||Settings that apply to all requests under the ||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 three
COMMON_SETTINGS includes in a parent property.
Consider this sample setup:
|Site (property hostname)||Scope||Configuration|
|www.example.com||Specific settings for the ||Parent property “www.example.com”|
|www.foo.com||Specific settings for the ||Parent property “www.foo.com”|
|Settings that both |
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
latestrule 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.