The Capping API helps you to create, configure and monitor your capping configurations.
Method | Path | Description |
---|---|---|
POST | list/endpointConfigs | Get a list of the endpoint capping configurations |
POST | /endpointConfigs | Create an endpoint capping configuration |
POST | /endpointConfigs/{uid} /deploy |
Deploy an endpoint capping configuration |
POST | /endpointConfigs/{uid} /undeploy |
Undeploy an endpoint capping configuration |
POST | /endpointConfigs/{uid} /canDeploy |
Check if an endpoint capping configuration can be deployed or not |
PUT | /endpointConfigs/{uid} |
Update an endpoint capping configuration |
GET | /endpointConfigs/{uid} |
Retrieve an endpoint capping configuration |
DELETE | /endpointConfigs/{uid} |
Delete an enpoint capping configuration |
When a configuration is created or updated, a check is automatically performed to guarantee the syntax and the integrity of the payload.
If some problems occur, the operation returns warning or errors to help you correct the configuration.
Here is the basic structure of an endpoint configuration:
{
"url": "<endpoint URL>", //wildcards are allowed in the endpoint URL
"methods": [ "<HTTP method such as GET, POST, >, ...],
"services": {
"<service name>": { . //must be "action" or "dataSource"
"maxHttpConnections": <max connections count to the endpoint>
"rating": {
"maxCallsCount": <max calls to be performed in the period defined by period/timeUnit>,
"periodInMs": <integer value greater than 0>
}
},
...
}
}
`{
"url": "https://api.example.org/data/2.5/*",
"methods": [
"GET"
],
"services": {
"dataSource": {
"maxHttpConnections": 30000,
"rating": {
"maxCallsCount": 5000,
"periodInMs": 1000
}
}
},
"orgId": "<IMS Org Id>"
}
When a canDeploy method is called, the process validates the configuration and returns the validation status identified by its Unique ID, either:
"ok" or "error"
The potential errors are:
<!--<given value>-->
: must be ‘dataSource’ or ‘action’The potential warning is:
ERR_ENDPOINTCONFIG_106: capping config: max HTTP connections not defined: no limitation by default
In this section, you will find the five main use-cases that you can perform to manage your capping configuration in Journey Orchestration.
To help you in your testing and configuration, a Postman collection is available here.
This Postman Collection has been set up to share the Postman Variable collection generated via Adobe I/O Console’s Integrations > Try it out > Download for Postman, which generates a Postman Environment file with the selected integrations values.
Once downloaded and uploaded into Postman, you need to add three variables: {JO_HOST}
,{BASE_PATH}
and {SANDBOX_NAME}
.
{JO_HOST}
: Journey Orchestration Gateway URL{BASE_PATH}
: entry point for the API. The value is ‘/authoring’{SANDBOX_NAME}
: the header x-sandbox-name (for example, ‘prod’) corresponding to the sandbox name where the API operations will take place. See the sandboxes overview for more information.In the following section, you will find the Rest API calls ordered list to perform the use-case.
Use-Case n°1: Creation and deployment of a new capping configuration
Use-Case n°2: Update and deploy a capping configuration not deployed yet
Use-Case n°3: Undeploy and delete a deployed capping configuration
Use-Case n°4: Delete a deployed capping configuration.
In only one API call, you can undeploy and delete the configuration with the use of the forceDelete parameter.
Use-Case n°5: Update a capping configuration already deployed