CentraSite Documentation : Runtime Governance with CentraSite : Virtualized APIs in CentraSite Business UI : Creating a Virtual API : Assigning Actions to a Virtual API : Policy Actions and Message Flow Stages
Policy Actions and Message Flow Stages
Summary of the Policy Accordions
The policy actions are classified into one of the following accordions:
Accordion
Use to...
Request Handling
Request handler allows receiving and transforming the incoming message from a client into a custom format as expected by the native API. For example, a Require HTTP / HTTPS action mandates that the incoming requests for an API are received over the HTTP and/or HTTPS protocol.
Policy Enforcement
Enforces the adherence to real-time policy compliance identifying/authenticating, monitoring, auditing, and measuring and collecting result statistics for an API.
Response Processing
Response handler allows processing of the response message coming from the native API into a custom format as expected by the client.
Error Handling
Error handlers are used to format and return error messages. Errors can occur at run-time for various reasons. For example, security errors occur if a username is not correctly validated or authorized; transformation errors occur if transformation action is unable to successfully transform a message; a routing error is raised if a routing endpoint is unavailable, and so on.
Summary of the Run-Time Actions
Actions are the core elements of stages in a message flow that define the handling of messages as they flow through a virtual API. The following table lists the actions you can configure for the virtual API's message flow, and links you to topics that describe the actions, including how to configure them.
This action...
Use to...
Available in Message Flow Stage...
Applicable for...
Request Handling > Protocol
Specify the JMS protocol for the API to accept and process the requests.
Receive
*SOAP APIs.
Specify the HTTP and/or HTTPS protocol, SOAP format (for a SOAP-based API), and the HTTP methods (for a REST-based API) for the API to accept and process the requests.
Receive
*SOAP APIs.
*REST APIs.
Invoke an XSL transformation in the incoming request before it is submitted to the an API.
Receive
*SOAP APIs.
*REST APIs.
Invoke a webMethods Integration Server service to pre-process the request before it is submitted to the an API.
Receive
*SOAP APIs.
*REST APIs.
Policy Enforcement > Authentication
Identify and validate the consumer's authentication credentials contained in the request's Authorization header using HTTP basic authentication mechanism.
Routing
*SOAP APIs.
*REST APIs.
Identify and validate the consumer's authentication credentials contained in the request's Authorization header using NTLM authentication mechanism.
Routing
*SOAP APIs.
*REST APIs.
Identify and validate the consumer's authentication credentials contained in the request's Authorization header using OAuth 2.0 authentication mechanism.
Routing
*SOAP APIs.
*REST APIs.
Policy Enforcement > JMS Routing
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.
Routing
*SOAP APIs.
Specify JMS message properties to authenticate client requests before submitting to the an APIs.
Routing
*SOAP APIs.
Specify JMS headers to authenticate client requests before submitting to the an APIs.
Routing
*SOAP APIs.
Policy Enforcement > Logging and Monitoring
Log request/response payloads to a destination you specify.
Enforce
*SOAP APIs.
*REST APIs.
Monitor the run-time performance for a specific consumer, and defines the level of performance that the specified consumer should expect from the API.
Enforce
*SOAP APIs.
*REST APIs.
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.
Enforce
*SOAP APIs.
*REST APIs.
Policy Enforcement > Routing
Route requests directly to a native endpoint that you specify.
Routing
*SOAP APIs.
*REST APIs.
Route requests to different endpoints based on specific values that appear in the request message.
Routing
*SOAP APIs.
*REST APIs.
Routes the requests across multiple endpoints.
Routing
*SOAP APIs.
*REST APIs.
Route requests to different endpoints based on specific values that appear in the request message.
Routing
*SOAP APIs.
*REST APIs.
Specify the HTTP headers to process the requests.
Routing
*SOAP APIs.
*REST APIs.
Policy Enforcement > Security
Mandate that requests be sent via SSL client certificates, and can be used by both SOAP and REST APIs.
Enforce
*SOAP APIs.
Mandate that a request's XML element (which is represented by an XPath expression) be signed.
Enforce
*SOAP APIs.
Mandate that a request's XML element (which is represented by an XPath expression) be encrypted.
Enforce
*SOAP APIs.
Mandate that timestamps be included in the request header.
Enforce
*SOAP APIs.
Uses a WSS Security Assertion Markup Language (SAML) assertion token to validate API consumers.
Enforce
*SOAP APIs.
*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.
Enforce
*SOAP APIs.
*REST APIs.
*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.
Enforce
*SOAP APIs.
*REST APIs.
*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.
Enforce
*SOAP APIs.
*REST APIs.
*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.
Enforce
*SOAP APIs.
*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.
Enforce
*SOAP APIs.
*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.
Enforce
*SOAP APIs.
*REST APIs.
*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.
Enforce
*SOAP APIs.
*REST APIs.
*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.
Enforce
*SOAP APIs.
*REST APIs.
Policy Enforcement > Traffic Management
*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, etc.
Enforce
*SOAP APIs.
*REST APIs.
Policy Enforcement > Validation
Validate all XML request and/or response messages against an XML schema referenced in the WSDL.
Enforce
*SOAP APIs.
Response Processing
Invoke an XSL transformation in the SOAP response payloads from XML format to the format required by the consumer.
Response
*SOAP APIs.
*REST APIs.
Invoke a webMethods Integration Server service to process the response from the an API before it is returned to the consumer.
Response
*SOAP APIs.
*REST APIs.
Error Handling
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.
Response
*SOAP APIs.
For detailed descriptions about the individual run-time actions that CentraSite out-of-the-box, see Built-In Run-Time Actions Reference for Virtual Services.
Summary of the Message Flow Stages
Message Flow defines the implementation of a virtual API.
A message flow is a sequence of stages representing a non-branching one-way processing path. Message flow is used for request, enforce, routing and response paths as well as for error handlers.
A message flow tree is constructed by chaining together actions of these top-level stages:
Stage
Description
Receive
Request stage is used for processing the request path of the Message Flow.
Enforce
Enforce stage is used for processing the enforcement path of the Message Flow. The enforce stage is used to identify and validate specific consumers invoking APIs, throttle traffic, log request/response payloads, and monitor run-time performance conditions.
Routing
Routing stage is used for processing the routing path of the Message Flow. The routing stage is used to perform request-response communication. It represents the boundary between request and response processing for the API. When the routing stage dispatches a request message, request processing is considered finished. When the routing stage receives a response message, response processing begins.
Response
Response stage is used for processing the response path of the Message Flow. In addition, response stage is used as error handler.
Copyright © Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback