General Information

Metadata contains general information that is descriptive in nature and that is manually modified.

Metadata contains the following general information (descriptive attributes) and the fields always start with lowercase:
  • Type: unique type. OOTB policies start with the prefix o:

  • Name: can be the actual name or a key within the l10n file (l10n string)

  • Version: version of the policy

  • Revision: revision number of the policy

    Note:

    For information on version and revision number, see Change the Version and Revision Number in Metadata
  • schemaVersion: The schema of the JSON for policy configuration can change resulting in multiple versions over a period of time. schemaVersion, helps you know which version of the JSON the policy is configured with.

  • sdkVersion: version of sdk

  • category: category name for the policy. The category can either be an ID to an OOTB category, or an l10n string. To have pointer to the OOTB category IDs, prefix the ID with an @ symbol. To use a category by name, provide the string without prefixing the @ symbol. The following are the IDs and their values:

    • @implementations.policyCategory.endpoints = “EndPoints”

    • @implementations.policyCategory.routing = “Routing”

    • @implementations.policyCategory.trafficMgmt = “Traffic Management”

    • @implementations.policyCategory.interfaceMgmt = “Interface Management”

    • @implementations.policyCategory.other = “Other”

    • "@implementations.policyCategory.security='Security'". Custom policy cannot be added to this category.

  • description: can be the actual description or a key within the l10n file (l10n string)

  • constraints: Policies can be inserted at different points in the execution flow, with some possible restrictions. The metadata also captures constraints for the policy:

    • direction: represents where a policy can be inserted. One of the four possible values for direction are: REQUEST, RESPONSE, REQUEST_OR_RESPONSE, REQUEST_AND_RESPONSE

    • requestZone / responseZone: If the policy direction is "REQUEST", provide requestZone and for "RESPONSE" provide responseZone. Provide both if the direction is either REQUEST_OR_RESPONSE / REQUEST_AND_RESPONSE

    • singleton: represents whether the policy is allowed only once, true by default.

    • required: the policy is required to be present

    • requires: a policy might require other policies to be inserted before or in the other pipeline

    • before: a policy might need to be inserted before other policies. For example, the API Request policy must be before the Service Request policy

    • after: a policy might need to be inserted after other policies. For example, the Service Request policy must be after the API Request policy.

      Note:

      Zone signifies the order of execution during runtime. You cannot place a policy with zone 30 after a policy with zone greater than 30. You can place policies only in specific positions in your API implementations. For more information on where and in what order polices can be placed in the request and response flows for your APIs, see Policy Placement in Using Oracle API Platform Cloud Service guide.
The general information in metadata looks like:
{
    "type" : "o:ApiRequest",
    "name" : "policy.name",
    "version" : "1.0",
    "revision" : "4",
    "schemaVersion" : "1",
    "sdkVersion" : "3.0",
    "category" : "@implementations.policyCategory.endpoints",
    "description" : "policy.description",
    "ocsgActionName" : "ApiRequest",
    "constraints" : {
        "direction" : "REQUEST",
        "requestZone" : "5",
        "singleton" : true,
        "required" : true,
        "requires" : [ "o:ApiResponse/1.0"],
        "before" : [ "o:ServiceRequest/1.0" ]
	}
}

Note:

The attributes policy.name and policy.description refer to a key in the file L10n/header.js