This blog post will go over how you can migrate from advanced metadata to custom behaviors so you can directly manage and edit your configurations without going through Akamai professional services.

Akamai Edge servers are smart reverse proxies located at the edge of the Internet that you can leverage to deliver fast and high-quality content to your end-users. Two of the key benefits of using edge servers are:

• Higher quality content thanks to various network optimizations like SureRoute, or advanced protocol optimizations

• Faster content delivery thanks to low network latency and server-side content caching

Running edge computing functions closer to end-users can considerably improve the performance of your applications and reduce the load (and associated costs) of your origin infrastructure.

You can configure edge computing functions via three different technologies:

1. EdgeWorkers: pre-packaged JavaScript functions that are executed on Edge Servers

2. Edge Side Includes (ESI): a markup language similar to Apache Server Side Includes which allows you to assemble dynamic content at the Edge

3. Edge Metadata: a proprietary XML language that allows running pre-defined logic at the Edge. Note that you can also create Edge Metadata logic using JSON via the Akamai Property Manager API

You can enable most of these edge computing functions using Property Manager Behaviors (either via Control Center or via the Property Manager API). 

The Property Manager API (and the Property Manager CLI package) allows you to manage Akamai properties as code using JSON instead of XML. 

However “advanced metadata” can only be edited by Akamai professional services, therefore it is recommended to migrate “advanced metadata” code to JSON or custom behaviors in order to regain full control of the configuration.

Why migrate advanced metadata to custom behaviors?

While Advanced metadata is sometimes required to unlock advanced functionality, it can pose a management challenge because advanced metadata can only be added or edited by Akamai employees. For example, if you need to apply that samed advanced functionality to another property, then you would need to contact Akamai professional services to do that for you. The recommended solution is to migrate the “advanced” code to “custom” code, a one-time process that will help you regain control of your configurations that have “advanced” logic.

Advanced metadata can appear in a configuration in two different flavors:

• Advanced Behaviors: snippets of advanced metadata XML code that are inserted within the rules of the configuration (see picture 1)

• Advanced Override: a block of advanced metadata XML that is located at the very end of the configuration (see picture 2)

Advanced behaviors can be migrated to custom behaviors while advanced override would migrate to a custom override:

The migration from “advanced” to “custom” is a one-time process described below that needs to be done by an Akamai specialist within professional services and consists of “converting” the XML code into a format that is available to Akamai users.

How to migrate to custom behaviors and custom overrides

The following steps describe the prerequisites for migrating from Advanced metadata to custom metadata and how to contact an Akamai representative to complete the migration.

1. Convert advanced behaviors to custom behaviors.
   Open the property that contains the advanced metadata in Property Manager, and scroll down until you locate the “Advanced” behavior containing the code you want to migrate, and click the icon with a “+” to create a custom behavior. 
2. Convert Advanced override to custom override
   Navigate to the “Advanced Override” behavior which is on the left side of the screen. If it is present, it will always be the last rule. Click the wheel icon in order to create a custom override behavior.
3. Referencing custom behaviors and overrides
   Once these behaviors have been created, they can be referenced. You can find all of your custom behaviors via the “Manage custom behaviors and overrides” button.The custom behavior id (highlighted below in green) can be used as reference in configurations through code.

    

Use APIs to migrate to custom behaviors and custom overrides

The UI is not the only method of doing this. We can also retrieve the behavior using APIs. Here is an example of a call made using HTTPie.

root@akamaidev:/$ http --print b --auth-type edgegrid --auth papi-ps: GET :/papi/v1/custom-behaviors
{
    "accountId": "act_1-6JHGX",
    "customBehaviors": {
        "items": [
            {
                "approvedByUser": "jsikkela",
                "behaviorId": "cbe_73905306",
                "description": "AWS authentication v4",
                "name": "AWS_Auth_v4",
                "sharingLevel": "ACCOUNT",
                "status": "ACTIVE",
                "updatedByUser": "jsikkela",
                "updatedDate": "2017-11-08T17:33:58Z",
….
 
            {
                "approvedByUser": "pmedrano@akamai.com",
                "behaviorId": "cbe_194816106",
                "description": "DNS freshness settings",
                "name": "DNS freshness settings",
                "sharingLevel": "ACCOUNT",
                "status": "ACTIVE",
                "updatedByUser": "rramnath",
                "updatedDate": "2020-07-16T22:22:24Z",
                "xml": "<network:dns.positive-min-ttl>2s</network:dns.positive-min-ttl>"
            },
...

To get more details about the behavior, you can enter the following:

root@akamaidev:/$ http --print b --auth-type edgegrid --auth papi-ps: GET :/papi/v1/custom-behaviors/cbe_194816106
{
    "accountId": "act_1-6JHGX",
    "customBehaviors": {
        "items": [
            {
                "approvedByUser": "pmedrano@akamai.com",
                "behaviorId": "cbe_194816106",
             "name": "DNS freshness settings",
                "sharingLevel": "ACCOUNT",
                "status": "ACTIVE",
                "updatedByUser": "rramnath",
                "updatedDate": "2020-07-16T22:22:24Z",
                "xml": "<network:dns.positive-min-ttl>2s</network:dns.positive-min-ttl>"
            }
        ]
    }
}

The Property Manager configuration will look like this:

If you were to examine the JSON, you’d notice that it now references this behavior id instead of the XML.

This JSON fragment can be the starting point to update configs as necessary. The workflow would be to delete the advanced behaviors and then replace them with a custom behavior.

Updating custom behavior

Let's say that 6 months down the road, there are some changes required and we end up creating an updated behavior. We can manage this by code by replacing the custom behavior id (cbe_xxxx) in the JSON and pushing the changes live.

You might also like

Here are great resources you can read to learn more:

• API Docs: Property Manager APIs

• API Docs: Custom behaviors and overrides

• Blog Post: 20 Years of Edge Computing

About the authors