
	Version 9.5 SP1	SEARCH CONTENTS \| PDF BOOKS \| HOME UP PREV NEXT

— Run-Time Governance Reference —

Built-In Run-Time Actions Reference for Virtual APIs

This section describes the built-in run-time actions that you can include in run-time governance rules for virtualized APIs. You use these actions only when you are using the CentraSite Business UI to create run-time policies for virtualized APIs. The content is organized under the following sections:

Summary of the Run-Time Actions for Virtual APIs
Action Evaluation Order and Dependencies for Virtual APIs
Run-Time Actions Reference for Virtual APIs

Summary of the Run-Time Actions for Virtual APIs

You can include the following kinds of built-in run-time actions in the run-time governance rules for virtualized APIs:

Request Handling Actions
Policy Enforcement Actions
Response Handling Actions
Error Handling Action

Request Handling Actions

Mediator provides the following actions for handling requests:

Request HTTP Protocol

Specifies the protocol (HTTP or HTTPS) for the virtualized API to accept requests.

In addition,

For SOAP APIs. Specify the SOAP version.

For REST APIs. Specify the HTTP method.

Request Transformation

Invokes an XSLT transformation in the SOAP request before it is submitted to the native API.

Invoke webMethods IS Service

Invokes a webMethods IS service to preprocess the request before it is submitted to the native API.

Policy Enforcement Actions

Mediator provides the following categories of policy enforcement actions:

Logging and Monitoring Actions
Routing Actions
Security Actions
Validation Action

Logging and Monitoring Actions

Log Invocations	Logs request/response payloads to a destination you specify.
Monitor Service Level Agreement	Monitors the run-time performance of a virtual alias, especially for particular consumer(s). You can configure this action to define a Service Level Agreement (SLA), which is set of conditions that define the level of performance that a specified consumer should expect from the alias.

Routing Actions

Endpoint Properties	Defines a set of properties for an endpoint to which you route requests. You can specify a SOAP optimization method, timeouts for HTTP connections and socket reads, the SSL client authentication aliases for the endpoint (Client Certificate Alias, Keystore Alias, Truststore Alias), and the WS-Security headers of the requests that Mediator should pass to the native API.
Set Headers	Specifies the HTTP headers to authenticate the requests.
Set HTTP Authorization	Specifies the authentication scheme (HTTP Basic authentication, NTLM or OAuth).
Straight Through Routing	Routes the requests directly to a native endpoint that you specify.

Security Actions

Allow Anonymous Usage	Allows anonymous users to access the APIs.
Evaluate Client Certificate for SSL Connectivity	Mediator will validate the client's certificate that the consumer application submits to the API in CentraSite. The client certificate that is used to identify the consumer is supplied by the client to the Mediator during the SSL handshake over the transport layer.
Evaluate Hostname	Mediator will try to identify the consumer's hostname against either the Registered Consumers list (the list of consumers available in Mediator) or the Global Consumers list (the list of Registered Consumers).
Evaluate HTTP Basic Authentication	You can select one of the following options: Mediator will try to identify the consumer against either the Registered Consumers list (the list of consumers available in Mediator) or the Global Consumers list (the list of Registered Consumers). Mediator will try to verify the consumer's authentication credentials contained in the request's Authorization header against the list of users registered in the Integration Server on which Mediator is running.
Evaluate IP Address	Mediator will try to identify the consumer's IP address against either the Registered Consumers list (the list of consumers available in Mediator) or the Global Consumers list (the list of Registered Consumers).
Evaluate WSS Username Token	For SOAP APIs. Mediator will try to identify the consumer's WSS username token against either the Registered Consumers list (the list of consumers available in Mediator) or the Global Consumers list (the list of Registered Consumers).
Evaluate X.509 Certificate	For SOAP APIs. Mediator will try to identify the consumer's WSS X.509 token against either the Registered Consumers list (the list of consumers available in Mediator) or the Global Consumers list (the list of Registered Consumers).
Evaluate XPath Address	Mediator will try to identify the consumer's XPath expression against either the Registered Consumers list (the list of consumers available in Mediator) or the Global Consumers list (the list of Registered Consumers).
Require SSL	For SOAP APIs. Requires that requests be sent via SSL client certificates.

Validation Action

Validate Schema

Validates all XML request and/or response messages against an XML schema referenced in the WSDL.

Response Handling Actions

Response Transformation	Invokes an XSLT transformation in the SOAP response payloads from XML format to the format required by the consumer.
Invoke webMethods IS Service	Invokes a webMethods IS service to process the response from the native API before it is returned to the consumer.

Error Handling Action

Custom SOAP Response Message

Returns a custom error message (and/or the native provider's service fault content) to the consumer when the native provider returns a service fault.

Action Evaluation Order and Dependencies for Virtual APIs

When you publish a virtual API, CentraSite automatically validates the API's policy enforcement workflow to ensure that:

Any action that appears in a single message flow multiple times is allowed to appear multiple times.

For those actions that can appear in a message flow only once (for example, Evaluate IP Address), Mediator will choose only one, which might cause problems or unintended results.
All action dependencies are properly met. That is, some actions must be used in conjunction with another particular action.

CentraSite will inform you of any violation, and you will need to correct the violations before publishing the API.

Effective Policies

When you publish a virtual endpoint to Mediator, CentraSite combines the actions specified within the virtual endpoint’s enforcement definition, and generates what is called the effective policy for the virtual endpoint. For example, suppose your virtual endpoint is configured with two run-time actions: one that performs a logging action and another that performs a security action. When you publish the virtual endpoint, CentraSite automatically combines the two actions into one effective policy. The effective policy, which contains both the logging action and the security action, is the policy that CentraSite actually publishes to Mediator with the virtual endpoint.

When CentraSite generates the effective policy, it validates the resulting action list to ensure that it contains no conflicting or incompatible actions. If the list contains conflicts or inconsistencies, CentraSite resolves them according to Policy Resolution Rules.

The effective policy that CentraSite produces for a virtual endpoint is contained in an object called a virtual service definition (VSD). The VSD is given to Mediator when you publish the virtual endpoint. After you publish a virtual endpoint, you can view its VSD (and thus examine the effective policy that CentraSite generated for it) from the Mediator user interface.

The following table shows:

The order in which Mediator evaluates the actions.
Action dependencies (that is, whether an action must be used in conjunction with another particular action).

Evaluation Order	Action	Dependency	Can include multiple times in a policy if the selection criteria is combined using an AND operator, not an OR?
1	Evaluate HTTP Basic Authentication	None.	No. Mediator includes only one action in the effective policy.
2	Evaluate WSS Username Token	None. If you select this action in addition to other actions, you must select the ALL option to join the identifiers with the AND operator.	No. Mediator includes only one action in the effective policy.
3	Evaluate X.509 Certificate	None. If you select this action in addition to other actions, you must select the ALL option to join the identifiers with the AND operator.	No. Mediator includes only one action in the effective policy.
4	Evaluate IP Address	None.	No. Mediator includes only one action in the effective policy.
5	Evaluate XPath Address	None.	No. Mediator includes only one action in the effective policy.
6	Evaluate Hostname	None.	No. Mediator includes only one action in the effective policy.
7	Require SSL	None.	If multiple actions appear, and one of them has its Client Certificate Required parameter set to Yes, only one occurrence of the action appears in the effective policy.
8	Validate Schema	None.	If at least one occurrence of the action is configured to validate requests, and at least one occurrence of the action is configured to validate responses, then Mediator includes in the effective policy an action to validate both requests and responses. Otherwise, an action is chosen which validates only requests or only responses (depending on the value of the Validate SOAP Messages parameter of the action).
9	Log Invocations	None.	No. Mediator includes only one action in the effective policy.
10	Monitor Service Level Agreement	At least one of the Evaluate actions.	Yes. Mediator includes all Monitor Service Level Agreement actions in the effective policy.

Run-Time Actions Reference for Virtual APIs

This section provides an alphabetic list of the built-in run-time actions you can include in run-time governance rules for virtualized APIs:

Allow Anonymous Usage
Custom SOAP Response Message
Endpoint Properties
Evaluate Client Certificate for SSL Connectivity
Evaluate Hostname
Evaluate HTTP Basic Authentication
Evaluate IP Address
Evaluate WSS Username Token
Evaluate WSS X.509 Certificate
Evaluate XPath Address
Invoke webMethods IS Service
Log Invocations
Monitor Service Level Agreement
Response Transformation
Request HTTP Protocol
Request Transformation
Require SSL
Set Headers
Set HTTP Authentication
Straight Through Routing
Validate Schema

Allow Anonymous Usage

This action allows anonymous users to access the APIs.

Input Parameters

`Allow Anonymous Usage`	Boolean. Specifies whether to allow all users to access the API, without restriction.
	Value	Description
	True	Default. Allows only the identified users to access the API.
	False	Allow all users to access the API.

Custom SOAP Response Message

This action returns a custom error response (and/or the native provider’s service fault content) to the consumer when the native provider returns a service fault. Alternatively, you can configure global error responses for all virtual services, using Mediator's Service Fault Configuration page (see Configuring Global Service Fault Responses in the document Administering webMethods Mediator).

Input Parameters

`Failure Message`	String. Returns the fault responses to the consumer, when: When a fault is returned by the native API provider. In this case, the $ERROR_MESSAGE variable in the fault response will contain the message produced by the provider's exception that caused the error. This is equivalent to the getMessage call on the Java Exception. This maps to the faultString element for SOAP 1.1 or the Reason element for SOAP 1.2 catch. Mediator discards the native API provider's fault and does not return this content to the web service caller since it could be considered a security issue, especially if the native provider is returning a stack trace with its response. When a fault is returned by internal Mediator exceptions (such as policy violation errors, timeouts, etc.). In this case, $ERROR_MESSAGE will contain the error message generated by Mediator.
`Send Native Failure Message`	Boolean. Optional. Specifies whether to send native SOAP / REST failure message to the consumer.
	Value	Description
	True	Default. Mediator sends the failure message to the consumer.
	False	Mediator does not send the failure message to the consumer.
`Pre-processing webMethods IS Service`	String. Optional. Invokes one or more webMethods IS services to manipulate the response message before the Custom SOAP Response Message action is invoked. The IS service will have access to the response message context (the axis2 MessageContext instance) before it is updated with the custom error message. For example, you might want to send emails or perform custom alerts based on the response payload.
`Post-processing webMethods IS Service`	String. Optional. Invokes one or more webMethods IS services to manipulate the API fault after the Custom SOAP Response Message action is invoked. The IS service will have access to the entire API fault and the custom error message. You can make further changes to the fault message structure, if needed.

Endpoint Properties

This action defines a set of properties for an endpoint to which you route requests.

Input Parameters

`SOAP Optimization Method`	String. Optional. For a SOAP endpoint. Specifies the optimization methods to optimize the payloads of SOAP requests:
	Value	Description
	MTOM	Default. Indicates that Mediator expects to receive a request with a Message Transmission Optimization Mechanism (MTOM) attachment, and will forward the attachment to the native API.
	SWA	Indicates that Mediator expects to receive a "SOAP with Attachment" (SwA) request, and will forward the attachment to the native API.
`HTTP Connection Timeout`	String. The time interval (in seconds) after which a connection attempt will timeout. If a value is not specified (or if the value 0 is specified), Mediator will use the value of the global property `pg.endpoint.connectionTimeout` located in the file `Integration Server_directory`\packages\WmMediator\config\resources\pg-config.properties . The default of that property is 30 seconds.
`Read Timeout`	Number Optional. The time interval (in seconds) after which a socket read attempt will timeout. If a value is not specified (or if the value 0 is specified), Mediator will use the value of the global property `pg.endpoint.readTimeout` located in the file `Integration Server_directory`\packages\WmMediator\config\resources\pg-config.properties . The default of that property is 30 seconds.
`SSL Configuration`	Object. Enables SSL client authentication for the endpoint.
	Value	Description
	Client Certificate Alias	The client's private key to be used for performing SSL client authentication.
	Truststore Alias	The truststore alias of the instance of Integration Server on which Mediator is running.
	Keystore Alias	The keystore alias of the instance of Integration Server on which Mediator is running. This value (along with the value of Client Certificate Alias) will be used for performing SSL client authentication.
`WSS Header`	String. Specifies WS-Security headers of the incoming requests that Mediator should pass to the native API.

Evaluate Client Certificate for SSL Connectivity

When this action is configured for a virtual API, Mediator validates the client's certificate that the consumer application submits to the API in CentraSite. The client certificate that is used to identify the consumer is supplied by the client to the Mediator during the SSL handshake over the transport layer. In order to identify consumers by transport-level certificates, the run-time communication between the client and the Mediator must be over HTTPS and the client must pass a valid certificate.

To use this action, the following prerequisites must be met:

In Integration Server, create an HTTPS port, as described in Configuring Ports in the webMethods Integration Server Administrator’s Guide.
In Integration Server, create a keystore and truststore, as described in Securing Communications with the Server in the webMethods Integration Server Administrator’s Guide.
Configure Mediator by setting the IS Keystore and IS Truststore parameters, as described in Configuring Mediator > Keystore Configuration in the document Administering webMethods Mediator.
Configure Mediator by setting the HTTPS Ports Configuration parameter, as described in Configuring Mediator > Ports Configuration in the document Administering webMethods Mediator.

Mediator rejects requests that do not include a client certificate during the SSL handshake over the Transport layer.

Input Parameters

`Identify Consumer`	String. The list of consumers against which the client certificate should be validated for identifying requests from a particular consumer.
	Value	Description
	Registered Consumers	Mediator will try to verify the consumer's certificate against the list of consumer applications who are registered as consumers for the API.
	Global Consumers	Default. Mediator will try to verify the consumer's certificate against a list of users registered in the Integration Server on which Mediator is running.

If Mediator cannot identify the consumer, Mediator fails the request and generates a Policy Violation event.

Evaluate Hostname

If you select this action, Mediator will evaluate the request to ensure that the request originated from the particular host machine. Mediator identifies the consumer against the list of users registered in the Integration Server on which Mediator is running.

Input Parameters

`Identify User Using HostName Address`	String. Optional.
	Value	Description
	Registered Consumers	Mediator will try to identify the consumer's hostname against the list of Registered Consumers.
	Global Consumers	Mediator will try to identify the consumer's hostname against the consumers available in Mediator.

If Mediator cannot identify the consumer, Mediator fails the request and generates a Policy Violation event.

Evaluate HTTP Basic Authentication

If you set Validate User Using HTTP Basic Authentication to True, this type of consumer authentication is referred to as "preemptive authentication".

If the user/password value in the Authorization header cannot be authenticated as a valid Integration Server user (or if the Authorization header is not present in the request), a 500 SOAP fault is returned, and the client is presented with a security challenge. If the client successfully responds to the challenge, the user is authenticated. This type of consumer authentication is referred to as "non-preemptive authentication". If the client does not successfully respond to the challenge, a 401 "WWW-Authenticate: Basic" response is returned and the invocation is not routed to the policy engine. As a result, no events are recorded for that invocation, and its key performance indicator (KPI) data are not included in the performance metrics.

Input Parameters

`Identify User Using HTTP Basic Authentication`	String. Optional.
	Value	Description
	Registered Consumers	Mediator will try to identify the consumer against the list of Registered Consumers.
	Global Consumers	Mediator will try to identify the consumer against the consumers available in Mediator.
`Validate User Using HTTP Basic Authentication`	Boolean. Optional.
	Value	Description
	True	Default. Mediator will verify the consumer's authentication credentials contained in the request's Authorization header against the list of users registered in the Integration Server on which Mediator is running.
	False	Mediator will not verify the consumer’s authentication credentials.

If Mediator cannot validate or identify the consumer, Mediator fails the request and generates a Policy Violation event.

Evaluate IP Address

If you select this action, Mediator will evaluate the request to ensure that the request header contains the X-Forwarded-For, which is used for identifying the IP address of a consumer through an HTTP proxy.

Input Parameters

`Identify User Using IP Address`	String. Optional.
	Value	Description
	Registered Consumers	Mediator will try to identify the consumer's IP address against the list of Registered Consumers. Mediator will evaluate whether the request header contains the X-Forwarded-For, which is used for identifying the IP address of a consumer through an HTTP proxy.
	Global Consumers	Mediator will try to identify the consumer's IP address against the consumers available in Mediator.

Evaluate WSS Username Token

If you select this action, Mediator will evaluate the request to ensure that the request header contains the WSS username token, which is used for identifying a consumer.

Input Parameters

`Identify User Using WSS Username Token`	String. Optional.
	Value	Description
	Registered Consumers	Mediator will try to identify the consumer's WSS username token against the list of Registered Consumers.
	Global Consumers	Mediator will try to identify the consumer's WSS username token against the consumers available in Mediator.

If Mediator cannot identify the consumer, Mediator fails the request and generates a Policy Violation event.

Evaluate WSS X.509 Certificate

If you select this action, Mediator will evaluate the request to ensure that the request header contains the WSS X.509 token, which is used for identifying a consumer.

Input Parameters

`Identify User Using WSS X.509 Token`	String. Optional.
	Value	Description
	Registered Consumers	Mediator will try to identify the consumer's WSS X.509 token against the list of Registered Consumers.
	Global Consumers	Mediator will try to identify the consumer's WSS X.509 token against the consumers available in Mediator.

If Mediator cannot identify the consumer, Mediator fails the request and generates a Policy Violation event.

Evaluate XPath Address

If you select this action, Mediator will evaluate the request to ensure that the request header contains an XPath expression, and that expression matches with the expression defined in the consumer details.

Input Parameters

`Identify User Using XPath Address`	String. Optional.
	Value	Description
	Registered Consumers	Mediator will try to identify the consumer's XPath expression against the list of Registered Consumers.
	Global Consumers	Mediator will try to identify the consumer's XPath expression against the consumers available in Mediator.
`Namespace`	The namespace of the XPath expression.
`XPath Expression`	An argument for evaluating the XPath expression.

If Mediator cannot identify the consumer, Mediator fails the request and generates a Policy Violation event.

Invoke webMethods IS Service

This action invokes a webMethods IS service to preprocess the request before it is submitted to the native API.

Input Parameters

IS Service String. Specifies the webMethods IS service.

Log Invocations

This action logs request/response payloads. You can specify the log destination and the logging frequency. This action also logs other information about the requests/responses, such as the API name, operation name, the Integration Server user, a timestamp, and the response time.

Input Parameters

`Request Payloads`	Boolean. Optional. Specifies whether to log all request payloads.
	Value	Description
	True	Log all request payloads.
	False	Do not log request payloads.
`Response Payloads`	Boolean. Optional. Specifies whether to log all response payloads.
	Value	Description
	True	Log all response payloads.
	False	Do not log response payloads.
`Log Generation Frequency`	String. Specifies how frequently to log the payload.
	Value	Description
	None	Default. Do not log payloads.
	Always	Log all requests and/or responses.
	On Success	Log only the successful responses and/or requests.
	On Failure	Log only the failed requests and/or responses.
`Send Data To`	String. Specifies where to log the payload. Important: Ensure that Mediator is configured to log the payloads to the destination(s) you specify here. For details, see Alerts and Transaction Logging in the document Administering webMethods Mediator.
	Value	Description
	CentraSite	Logs the payloads in the API's Events profile in CentraSite. Prerequisite: You must configure Mediator to communicate with CentraSite (in the Integration Server Administrator, go to Solutions > Mediator > Administration > CentraSite Communication). For the procedure, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.
	Local Log	Logs the payloads in the server log of the Integration Server on which Mediator is running. Also choose a value in the `Log Level` field: Info: Logs error-level, warning-level, and informational-level alerts. Warn: Logs error-level and warning-level alerts. Error: Logs only error-level alerts. Important: The Integration Server Administrator's logging level for Mediator should match the logging level specified for this action (go to Settings > Logging > Server Logger).
	SNMP	Logs the payloads in CentraSite's SNMP server or a third-party SNMP server. Prerequisite: You must configure the SNMP server destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > SNMP). For the procedure, see the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.
	Email	Sends the payloads to an SMTP email server, which sends them to the email address(es) you specify here. Mediator sends the payloads as email attachments that are compressed using gzip data compression. To specify multiple addresses, use the button to add rows. Prerequisite: You must configure the SMTP server destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > Email). For the procedure, see the section SMTP Destinations for Run-Time Events in the document Administering webMethods Mediator.
	Audit Log	Logs the payload to the Integration Server audit logger. For information, see the webMethods Audit Logging Guide. Note: If you expect a high volume of events in your system, it is recommended that you select the Audit Log destination for this action.

Monitor Service Level Agreement

Monitors the run-time performance conditions for a virtual API for one or more specified consumers , and then send alerts when the performance conditions are violated

You can configure this action to define a Service Level Agreement (SLA), which is a set of conditions that defines the level of performance that a consumer should expect from a service. You can use this action to identify whether a service's threshold rules are met or exceeded. For example, you might define an agreement with a particular consumer that sends an alert to the consumer if responses are not sent within a certain maximum response time. You can configure SLAs for each virtual service/consumer application combination.

For the counter-based metrics (Total Request Count, Success Count, Fault Count), Mediator sends an alert as soon as the performance condition is violated, without having to wait until the end of the metrics tracking interval. You can choose whether to send an alert only once during the interval, or every time the violation occurs during the interval. (Mediator will send another alert the next time a condition is violated during a subsequent interval.) For information about the the metrics tracking interval, see The Metrics Tracking Interval .

For the aggregated metrics (Average Response Time, Minimum Response Time, Maximum Response Time), Mediator aggregates the response times at the end of the interval, and then sends an alert if the performance condition is violated.

This action does not include metrics for failed invocations.

Note:
To enable Mediator to publish performance metrics, you must configure Mediator to communicate with CentraSite (in the Integration Server Administrator, go to Solutions > Mediator > Administration > CentraSite Communication). For the procedure, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.

Input Parameters

`Action Configuration`	Object. Specifies one or more conditions to monitor. To do this, specify a metric, operator, and value for each metric. To specify multiple conditions, use the button to add multiple rows. If multiple parameters are used, they are connected by the AND operator.
`Name`	String Array. The metrics to monitor.
	Value	Description
	None	Default.
	Availability	Indicates whether the service was available to the specified consumers in the current interval.
	Average Response Time	The average amount of time it took the service to complete all invocations in the current interval. Response time is measured from the moment Mediator receives the request until the moment it returns the response to the caller.

	Fault Count	Indicates the number of faults returned in the current interval.
	Maximum Response Time	The maximum amount of time to respond to a request in the current interval.
	Minimum Response Time	The minimum amount of time to respond to a request in the current interval.
	Successful Request Count	The number of successful requests in the current interval.
	Total Request Count	The total number of requests (successful and unsuccessful) in the current interval.
	String Array. Choose an appropriate operator.
`Operator`	String Array. Choose an appropriate operator.
`Value`	String Array. Specify an appropriate value.
`Alert for Consumers`	Object Array Specify the Application asset(s) to which this Service Level Agreement will apply. To specify multiple Application assets, use the button to add multiple rows.
`Alert Interval`	Number The time period (in minutes) in which to monitor performance before sending an alert if a condition is violated. For information about the metrics tracking interval, see The Metrics Tracking Interval.
`Alert Frequency`	String. Specifies how frequently to issue alerts for the counter-based metrics (Total Request Count, Success Count, Fault Count).
	Value	Description
	None	Default. Do not issue an alert even if one of the specified conditions is violated.
	Every Time	Issue an alert every time one of the specified conditions is violated.
	Only Once	Issue an alert only the first time one of the specified conditions is violated.
`Reply to Destination`	String. Specifies where to log the alert. Important: Ensure that Mediator is configured to send event notifications to the destination(s) you specify here. For details, see Alerts and Transaction Logging in the document Administering webMethods Mediator.
	Value	Description
	CentraSite	Sends the alerts to the virtual API's Events profile in CentraSite. Prerequisite: You must configure Mediator to communicate with CentraSite (in the Integration Server Administrator, go to Solutions > Mediator > Administration > CentraSite Communication). For the procedure, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.
	Local Log	Sends the alerts to the server log of the Integration Server on which Mediator is running. Also choose a value in the `Log Level` field: Info: Logs error-level, warning-level, and informational-level alerts. Warn: Logs error-level and warning-level alerts. Error: Logs only error-level alerts. Important: The Integration Server Administrator's logging level for Mediator should match the logging level specified for this action (go to Settings > Logging > Server Logger).
	SNMP	Sends the alerts to CentraSite's SNMP server or a third-party SNMP server. Prerequisite: You must configure the SNMP server destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > Email). For the procedure, see the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.
	Email	Sends the alerts to an SMTP email server, which sends them to the email address(es) you specify here. To specify multiple addresses, use the button to add rows. Prerequisite: You must configure the SMTP server destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > Email). For the procedure, see the section SMTP Destinations for Run-Time Events in the document Administering webMethods Mediator.
`Alert Message`	String. Optional. Specify a text message to include in the alert.

Response Transformation

This action invokes an XSLT transformation in the SOAP response payloads from XML format to the format required by the consumer.

Input Parameters

Transformation File Object. Specifies the XSLT transformation file.

Request HTTP Protocol

This action specifies the protocol (HTTP or HTTPS), SOAP format, and the HTTP method for the virtual API to accept and process the requests.

Note:
In order to have the API secured, it is mandatory that at least one of the (HTTP / HTTPS) protocol is set to "TRUE".

Input Parameters

`Is SSL Enabled?`	Boolean. Specifies whether the virtual API is secured by HTTPS (Secure Sockets Layer (SSL)) authentication.
	Value	Description
	True	The virtual API is secured by HTTPS (Secure Sockets Layer (SSL)).
	False	Default. The virtual API is not secured by HTTPS.
`SOAP Version`	String. For SOAP APIs. Specifies the SOAP format (None, SOAP 1.1, SOAP 1.2) of the requests that the virtual API will accept. Default: SOAP 1.1.
`HTTP Method`	String. Optional. For REST APIs. Specifies the HTTP methods (GET, POST, PUT, DELETE) that the virtual API should be allowed to perform on a REST resource. Default: POST.
`HTTP Protocol`	Boolean. Specifies whether the virtual API is secured by HTTP authentication.
	Value	Description
	True	The virtual API is secured by HTTP.
	False	Default. The virtual API is not secured by HTTP.

Request Transformation

This action invokes an XSLT transformation in the SOAP request before it is submitted to the native API.

Input Parameters

Transformation File Object. Specifies the XSLT transformation file.

Require SSL

Requires that requests be sent via SSL client certificates. This action supports WSSecurityPolicy 1.2 but can be used for both SOAP and REST services.

When this policy action is set for the virtual service, Mediator ensures that requests are sent to the server using the HTTPS protocol (SSL). The policy also specifies whether the client certificate is required. This allows Mediator to verify the client sending the request. If the policy requires the client certificate, but it is not presented, Mediator rejects the message.

When a client certificate is required by the policy, the Integration Server HTTPS port should be configured to request or require a client certificate.

Input Parameters

`Client Certificate Required`	Boolean. Specifies whether client certificates are required for the purposes of: Verifying the signature of signed SOAP requests or decrypting encrypted SOAP requests Signing SOAP responses or encrypting SOAP responses
	Value	Description
	Yes	Require client certificates.
	No	Default. Do not require client certificates.

Set Headers

This action specifies the HTTP headers to authenticate the incoming requests.

Input Parameters

`Set Headers`	String. Specifies the HTTP headers to authenticate the requests.
	Value	Description
	None	Default. Do not use any HTTP headers to authenticate requests
	Reuse Existing Headers	Use the HTTP headers that are contained in the requests.
	Custom Headers	Use the HTTP headers that you specify in the Name and Value columns below. If you need to specify multiple headers, use the button to add rows.
`Header`	Object. Specifies the custom HTTP header(s) and the values.
	Value	Description
	Name	Name of the HTTP header.
	Value	A value for the HTTP header.

Set HTTP Authentication

This action specifies the authentication scheme for incoming requests.

Input Parameters

`HTTP Authentication`	String. Authenticates requests to the native endpoint.
	Value	Description
	Reuse Existing Credentials	Default. Authenticates requests based on the credentials specified in the HTTP header.
	Is Anonymous	Do not authenticate requests to the native endpoint.
	Custom Credentials	Authenticates requests based on the credentials you specify in the Username, Password and Domain fields.
`Authentication Scheme`	String. Optional. Specifies the mode of authentication: None, Basic Authentication (default), or NTLM (Windows only). If you are choosing None, select the following option: Is Anonymous: Does not authenticate requests. If you are choosing Basic Authentication (default), select the following options: Reuse Existing Credentials: Default. Authenticates requests based on the credentials specified in the HTTP header. Mediator passes the “Authorization” header present in the original client request to the native service. Custom Credentials: Authenticates requests according to the values you specify in the User, Password and Domain fields. If you are choosing NTLM (Currently Windows only), select the following options: Note: Note that if Mediator is used to access a native service protected by NTLM (which is typically hosted in IIS), then the native service in IIS should be configured to use NTLM as the authentication scheme. If the authentication scheme is configured as "Windows", then "NTLM" should be in its list. The "Negotiate" handshake will be supported in the near future. This note applies to all three options for NTLM. Reuse Existing Credentials: Default. Mediator uses the user credentials passed in the request header for an NTLM handshake with the server. Custom Credentials: Mediator uses the values you specify in the User, Password and Domain fields for an NTLM handshake with the server.
`OAuth2 Token`	String. Optional. If you are choosing OAuth2, select the following options: Reuse Existing Credentials: Default. Mediator will pass the OAuth2 Access token (a "Bearer" type token) unchanged to the native OAuth server. Custom Credentials: Specify an OAuth access token to be deployed by Mediator. If you select this option, the consumer need not pass the OAuth token during service invocation. Click the Show Token button to view the OAuth access token. Users who do not have the permissions to create and manage virtual services will not see this button. Notes: You must set the Integration Server property `watt.server.auth.skipForMediator` to "true" and then restart Integration Server for the change to take effect. This property is located in the server configuration file (server.cnf), which is located in the `Integration Server_directory`\config directory. For details, see the webMethods Integration Server Administrator's Guide. The run-time action "Evaluate HTTP Basic Authentication" will not be enforced when using the authentication scheme OAuth2. Specifies an OAuth2 access token to be deployed by Mediator.

Straight Through Routing

This action routes the requests directly to a native endpoint that you specify.

Input Parameters

Endpoint

String. Specifies the URL of the native endpoint to route the request to. For example:

http://mycontainer/creditCheckService

Alternatively, Mediator offers "Local Optimization" capability if the native service and the virtual service (in Mediator) are located on the same machine. With local optimization, service invocation happens in-memory and not through a network hop. In the Default To field the Routing Protocols tab, specify the native service in either of the following forms:

local://<Service-full-path>

local://<server>:<port>/ws/<Service-full-path>

For example:

local://MediatorTestServices:NewMediatorTestServices_Port

which points to the endpoint service NewMediatorTestServices_Port which is present under the folder MediatorTestServices in Integration Server.

Validate Schema

This action validates all XML request and/or response messages against an XML schema referenced in the WSDL.

Mediator can enforce this policy action for messages sent between services. When this policy is set for the virtual service, Mediator validates XML request messages, response messages, or both, against the XML schema referenced in the WSDL.

Input Parameters

`Validate SOAP Message(s)`	Object. Validates request and/or response messages. You may select both Request and Response.
	Value	Description
	Request	Validate all requests.
	Response	Validate all responses.

Important:
Be aware that Mediator does not remove wsu:Id attributes that may have been added to a request by a consumer as a result of security operations against request elements (i.e., signatures and encryptions). In this case, to avoid schema validation failures you would have to add a Request Transformation action or a Response Transformation action to the virtual service so that the requests are passed to an XSLT transformation file that removes the wsu:Id attribute. For details about the Request Transformation and Response Transformation actions, see Request Transformation and Response Transformation.

SEARCH CONTENTS | PDF BOOKS | HOME UP PREV NEXT