Apply these assertions to each API that you want to monitor using PingIntelligence. You can include these assertions in global policies if you want each incoming API call to automatically be checked by PingIntelligence, or you can attach those assertions in service-level policies.

For service-level policies, each API will add two assertions:

  • ASE Check Request: Applied before routing the request to the backend
  • ASE Check Response: Used after a call to the downstream endpoint (which is on line 25 in the image below)
A screen capture of the ASE Check Request and ASE Check Response.

ASE Check Request

The ASE Check Request assertion is configured with the following properties:

A screen capture of the ASE Check Request Properties menu.

If you do not configure the properties, the assertion extracts all required details by itself. This includes:

  • Retrieving all the request headers
  • Generating a correlationId (used as X-CorrelationID)
  • Retrieving the ASE token
  • Retrieving the ASE HTTPS host
  • Retrieving the ASE request path
  • Sending a message to ASE

PingIntelligence recommends adding username to capture the user name when it is available. Examples of username variables include:

  • ${request.http.parameter.username}: The username variable included in the incoming request HTTP header
  • ${session.subscriber_id}: The username variable when authenticating users with the OAuth Toolkit (OTK)
  • ${request.username}: The username variable 
in the case of HTTP basic authentication

The variable name to use in this case will often be very implementation-specific. Use what you already defined as part of your CA API Gateway implementation.

You should change others if you are customizing to accommodate special use cases.

  • CorrelationID: Optional, used if you want to override correlationId, which will otherwise automatically be assigned
  • Custom data: Optional, used to modify the internal of that assertion
  • true: Useful for users developing an API for debugging or auditing purposes

The assertion has an output that is the generated correlationId:ase.correlationId that is utilized by the ASE check response assertion.

ASE Check Response

This ASE Check Response assertion must be configured for each API with the following variables:

Variable Description

Correlation-ID

The ASE request and response correlation IDs, if specified, must match. Otherwise, keep ase.correlationId.

All service response headers

The default value is ${response.http.allheadervalues}. This variable is created by the routing assertion that executed the backend call. If it is customized, for example, myresponse, then the updated variable should be used.

Response code

The HTTP response status of the backend call.

Response status

This value is ignored and hard coded to OK.

Username (optional)

This should match the username variable setting in the ASE Check Request assertion. The screenshot shows an example where the username is being extracted from the incoming HTTP request.

Custom data (optional)

Used by customers who would like to modify the internals of an assertion.

true

Useful for users developing an API for debugging or auditing purposes.
A screenshot of the ASE Check Response Properties menu with the values entered in the fields.

API discovery

PingIntelligence API discovery is a process to discover, and report APIs from your API environment. The discovered APIs are reported in the PingIntelligence Dashboard. APIs are discovered when a global API JSON is defined in the ASE.

For more information, see API discovery and configuration. You can edit the discovered API's JSON definition in the Dashboard before adding them to ASE. For more information on editing and configuring API discovery, see Discovered APIs.