Managing Your Configuration Through PAPI

July 28, 2017 · by Gareth Hughes ·

Last year, I worked with a customer to support the transformation of their configuration, their application, and their procedures to be more streamlined and DevOps. As part of that, they had an initially vague, but interesting requirement - Improve the Release Process.

What they meant was that the Akamai part of a release had high friction:

  • Changes can only be made by a small number of people in the organization.
  • The application hasn’t been tested with Akamai until it reaches production.
  • Testing the configuration on ESN is difficult/impossible via the corporate network.

This was partially resolved through integrating the Dev, Test, & Pre-prod environments with Akamai, this allowed more people to have access to the configuration, at an earlier stage in development. Additionally, as the changes could be made on the Akamai production network, changes were tested and verified before the application got to production.

The remaining issue was that although they had a semi-automatic release procedure on each environment, a new bottleneck was introduced: changes to the Akamai configuration. This manual process was time intensive, and prone to error by manually copying the changes from Dev to Test to Pre-prod.

map: Akamai configuration flow


Enter PAPI...


We scoped this requirement at an early stage, and so as I worked on the integration of the additional properties (and re-factoring their configuration), I automated the entire process. This made my life easier when pushing a change through the lifecycle, as well as providing a basis for the customer to integrate the Akamai configuration with their release process.

PAPI (or the Property Manager API), makes this easy by allowing us to work with a configuration ruleset as a JSON object. This object can be downloaded, modified and uploaded back to the same, or a different property. Once downloaded the ruleset can be stored in source control alongside the application code.

map: flow with PAPI

The initial script I wrote (in NodeJS) was a bit Heath-Robinson, and required everything to be hard-coded into the main code - however this allowed me to prove the value, and quickly achieve my goal of moving a configuration from one property to another (something not currently possible in Luna).


Making it Reusable

In order for the customer to be able to use the code I had written, it needed to be made more reusable, and the version I passed over to them used a configuration file that held all the information about the source and destination properties and any transformations that needed to be made as part of the process.

{ "config" : { "auth" : { "baseUri" : "...", "clientToken" : "...", "clientSecret" : "...", "accessToken" :"...", "max-body" : 131072 }, "source" : { "contractId" : "ctr_C-123ABC", "groupId" : "grp_12345", "propId" : "prp_312791", "network" : "PRODUCTION" }, "dest" : { "contractId" : "ctr_C-1ED34DY", "groupId" : "grp_67890", "propId" : "prp_312791", "activate" : false, "notifyEmails" : [ "", "" ] } }, "transformations" : [{ "source" : "", "dest" : "" }, { "source" : "PRC_Test", "dest" : "PRC_Prod" }, { "source" : "\"id\" : 98765", "dest" : "\"id\" : 54321" }]




This version also gave some feedback to indicate status, outputting a JSON object which can be interpreted by the customer's CI tools.



This post demonstrates a simple way to manage the Akamai Configuration as part of an application’s code, allowing it to be thoroughly tested and controlled through the DevOps release process. It also relieves the perceived friction of Akamai during the release process - changes are made once, and then “follow” the application through the process.