The bundle includes ASE check request and check response encapsulated assertions. 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 and ASE Check Response. ASE Check Request is applied before routing the request to the backend. Whereas ASE Check Response is used after a call to the downstream endpoint (which is on line 25 in the screenshot below):

The ASE Check Request assertion is configured with the following:

ASE check request

ASE Check Request:

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 other if you are customizing to accommodate special use cases.
  • CorrelationID: Optional – used if you want to override the 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 which 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:
  • 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.

API discovery

PingIntelligence API discovery is a process to discover, and report APIs from your API environment. The discovered APIs are reported in 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 Dashboard before adding them to ASE. For more information on editing and configuring API discovery, see Discovered APIs.