CentraSite 10.7 | CentraSite User’s Guide | Runtime Governance | Run-Time Policy Management | Supported Run-Time Actions and Asset Type Combinations
 
Supported Run-Time Actions and Asset Type Combinations
Not all virtual asset types support the full set of actions. Some actions execute only with a certain type of virtual assets. For example, a Require Encryption action executes only on Virtual Service asset type. If you create a run-time policy whose scope applies to Virtual REST Service asset type, that policy action definition does not include the Require Encryption action.
The following table identifies the actions that each virtual asset type supports:
Action
Description
Applicable for...
Web Service
REST Service
OData Service
Specify the JMS protocol for the API to accept and process the requests.
Specify the HTTP and/or HTTPS protocol and the SOAP format (for a SOAP-based API) for the API to accept and process the requests.
Invoke an XSL transformation in the incoming request before it is submitted to the an API.
Invoke a webMethods Integration Server service to pre-process the request before it is submitted to the an API.
Enables REST support for an existing SOAP based API by exposing the API both as a REST based API as well as a SOAP API.
Specifies the content type for a REST request received from a client if the content type header is not specified.
Identify and validate the consumer's authentication credentials contained in the request's Authorization header using HTTP basic authentication mechanism.
Identify and validate the consumer's authentication credentials contained in the request's Authorization header using NTLM authentication mechanism.
Identify and validate the consumer's authentication credentials contained in the request's Authorization header using OAuth 2.0 authentication mechanism.
Specify a JMS queue to which the Mediator is to submit the request, and the destination to which the an API is to return the response.
Specify JMS message properties to authenticate client requests before submitting to the an APIs.
Specify JMS headers to authenticate client requests before submitting to the an APIs.
Log request/response payloads to a destination you specify.
Monitor the run-time performance for a specific consumer, and defines the level of performance that the specified consumer should expect from the API.
Monitor a user-specified set of run-time performance conditions for an API, and sends alerts to a specified destination when these performance conditions are violated.
Route requests directly to a native endpoint that you specify.
Route requests to different endpoints based on specific values that appear in the request message.
Enables Mediator to support dynamic routing of virtual aliases based on policy configuration.
Routes the requests across multiple endpoints.
Route requests to different endpoints based on specific values that appear in the request message.
Specify the HTTP headers to process the requests.
Mandate that requests be sent via SSL client certificates, and can be used by both SOAP and REST APIs.
Mandate that a request's XML element (which is represented by an XPath expression) be signed.
Mandate that a request's XML element (which is represented by an XPath expression) be encrypted.
Mandate that timestamps be included in the request header.
Uses a WSS Security Assertion Markup Language (SAML) assertion token to validate API consumers.
*Identify the consumer against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available users in Mediator).
*Validate the client's authentication credentials contained in the request's Authorization header against the list of users in the Integration Server on which Mediator is running.
*Identify the consumer against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available users in Mediator).
*Validate the client's IP address against the list of users in the Integration Server on which Mediator is running.
*Identify the consumer against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available users in Mediator).
*Validate the client's IP address against the list of users in the Integration Server on which Mediator is running.
*Identify the consumer against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available users in Mediator).
*Validate the client's WSS username token against the list of users in the Integration Server on which Mediator is running.
*Identify the consumer against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available users in Mediator).
*Validate the client's WSS X.509 token against the list of users in the Integration Server on which Mediator is running.
*Identify the consumer against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available users in Mediator).
*Validate the client's XPath expression against the list of users in the Integration Server on which Mediator is running.
*Identify the consumer against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available users in Mediator).
*Validate the client's IP address against the list of users in the Integration Server on which Mediator is running.
*Identify the consumer against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available users in Mediator).
*Validate the client's certificate against the list of users in the Integration Server on which Mediator is running.
*Limit the number of API invocations during a specified time interval, and sends alerts to a specified destination when the performance conditions are violated.
*Avoid overloading the back-end services and their infrastructure, to limit specific consumers in terms of resource usage, and so on.
Enables caching of the results of SOAP and REST API invocations.
Validate all XML request and/or response messages against an XML schema referenced in the WSDL.
Invoke an XSL transformation in the SOAP response payloads from XML format to the format required by the consumer.
Invoke a webMethods Integration Server service to process the response from the an API before it is returned to the consumer.
Specifies the content type for a REST response.
Return a custom error message (and/or the native provider's service fault content) to the consumer when the native provider returns a service fault.