Version 9.6	SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT

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

Instructions throughout the remainder of this guide use the term "API" when referring to the Virtual Services, Virtual XML Services and Virtual REST Services; and the term "client" when referring to the Consumer Applications in general.

• Summary of the Run-Time Actions

• The watt.server.auth.skipForMediator Property

• Effective Policies

• Usage Cases for Identifying/Authenticating Clients

• Run-Time Actions Reference

Summary of the Run-Time Actions

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

• Request Handling Actions

• Policy Enforcement Actions

• Response Handling Actions

• Error Handling Action

Request Handling Actions

Request Handling is the process of receiving and transforming the incoming message from a client into the custom format as expected by the native API.

Policy Enforcement Actions

Policy Enforcement is the process of enforcing the adherence to real-time policy compliance identifying/authenticating, monitoring, auditing, and measuring and collecting result statistics for an API.

Mediator provides the following categories of policy enforcement actions:

• Authentication Actions
• JMS Routing Actions
• Logging and Monitoring Actions
• Routing Actions
• Security Actions
• Traffic Management Action
• Validation Action

Authentication Actions

Authentication actions verify that the API client has the proper credentials to access an API.

JMS Routing Actions

JMS Routing actions route the incoming message to an API over JMS. For example, to a JMS queue where an API can then retrieve the message asynchronously.

Logging and Monitoring Actions

Logging and Monitoring actions monitor and collect information about the number of messages that were processed successfully or failed, the average execution time of message processing, and the number of alerts associated with an API.

Routing Actions

Routing actions route the incoming message (e.g., directly to the API, or routed according to the routing rules, or routed to a pool of servers for the purpose of load balancing and failover handling).

Security Actions

Security actions provide client validation (through WSS X.509 certificates, WSS username tokens etc.), confidentiality (through encryption) and integrity (through signatures) for request and response messages.

For the client validation, Mediator maintains a list of consumer applications specified in CentraSite that are authorized to access the API published to Mediator. Mediator synchronizes this list of consumer applications through a manual process initiated from CentraSite.

Generally speaking there are two different lists of consumers in the Mediator:

• List of Registered Consumers

  List of users and consumer applications (represented as Application assets) who are registered as consumers for the API in CentraSite, and available in the Mediator.

  For more information on how to register as consumer for an API, refer to the online documentation section Registering as Consumer for an API in the document Virtualizing APIs Using the CentraSite Business UI.

• List of Global Consumers

  List of all users and consumer applications (represented as consumers) available in the Mediator.

  For more information on how to create a consumer application asset, refer to the online documentation section Managing Consumer Applications for an API > Creating a Consumer Application in the document Virtualizing APIs Using the CentraSite Business UI.

  For more information on how to publish a consumer application to Mediator, refer to the online documentation section Managing Consumer Applications for an API > Publishing a Consumer Application in the document Virtualizing APIs Using the CentraSite Business UI.

Mediator provides "Evaluate" actions that you can include in a message flow to identify and/or validate clients, and then configure their parameters to suit your needs. You use these "Evaluate" actions to perform the following actions:

• Identify the clients who are trying to access the APIs (through IP address or hostname).

• Validate the client's credentials.

Traffic Management Action

Validation Action

Response Handling Actions

Response Handling is the process of transforming the response message coming from the native API into the custom format as expected by the client.

Error Handling Action

Error Handling is the process of passing an exception message which has been issued as a result of a run-time error to take any necessary actions.

The watt.server.auth.skipForMediator Property

This property specifies whether Integration Server authenticates requests for Mediator. You must set this property to true.

No request to Mediator should be authenticated by Integration Server. Instead, authentication should be handled by Mediator. Thus, to enable Mediator to authenticate requests, you must set skipForMediator to true (by default it is false).

When this parameter is set to true, Integration Server skips authentication for Mediator requests and allows the user credentials (of any type) to pass through so that Mediator can authenticate them. If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.

To set skipForMediator to true

1. In the Integration Server Administrator, click Settings > Extended.

2. Click Show and Hide Keys.

   Look for the watt.server.auth.skipForMediator property and ensure it is set to true.

3. If the watt.server.auth.skipForMediator property is not present, add it as follows:

   1. Click Edit Extended Settings.

   2. Type watt.server.auth.skipForMediator=true on a separate line.

   3. Click Save.

   4. Restart Integration Server.

Effective Policies

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

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

When you publish an API to Mediator, CentraSite combines the actions specified within the proxy API's enforcement definition, and generates what is called the effective policy for the API. For example, suppose your API is configured with two run-time actions: one that performs a logging action and another that performs a security action. When you publish the API, 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 API.

When CentraSite generates the effective policy, it validates the resulting action list 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.

If the list contains conflicts or inconsistencies, CentraSite resolves them according to Policy Resolution Rules.

The effective policy that CentraSite produces for an API is contained in an object called a virtual service definition (VSD). The VSD is given to Mediator when you publish the API. After you publish an API to Mediator, 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:

• Action is WS-Security Policy 1.2 compliant.

• Action dependencies (that is, whether an action must be used in conjunction with another particular action).

• Action exclusives (that is, whether an action cannot be used in conjunction with another particular action).

• Action occurrences (that is, whether an action can occur once or multiple times within a message flow stage).

Effective Policies

Usage Cases for Identifying/Authenticating Clients

When deciding which type of identifier to use to identify a client, consider the following points:

• Whatever identifier you choose to identify a client, it must be unique to the application. Identifiers that represent user names are often not suitable because the identified users might submit requests for multiple APIs.

• Identifying applications by IP address or host name is often a suitable choice, however, it does create a dependency on the network infrastructure. If a client moves to a new machine, or its IP address changes, you must update the identifiers in the application asset.

• Using X.509 certificates or a custom token that is extracted from the SOAP message itself (using an XPATH expression), is often the most trouble-free way to identify a client.

Following are some common combinations of actions used to authenticate/identify clients.

• Scenario 1: Identify clients by IP address or host name

  • The simplest way to identify clients is to use the Evaluate IP Address action.

• Scenario 2: Authenticate clients by HTTP authentication token
  Use the following actions:

  • Evaluate HTTP Basic Authentication to identify clients using the token derived from the HTTP Header.

  • HTTP Basic Authentication.

• Scenario 3: Authenticate clients by WS-Security authentication token
  Use the following action:

  • Evaluate WSS Username Token action to identify clients using the token derived from the WSS Header.

• Scenario 4: Authenticate clients by WSS X.509 certificate

  • Evaluate WSS X.509 Certificate action to identify clients using the WSS X.509 certificate.

  • Require SSL action.

Run-Time Actions Reference

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

• Content Based Routing

• Context Based Routing

• Custom SOAP Response Message

• Evaluate Client Certificate for SSL Connectivity

• Evaluate Hostname

• Evaluate HTTP Basic Authentication

• Evaluate IP Address

• Evaluate OAuth2 Token

• Evaluate WSS Username Token

• Evaluate WSS X.509 Certificate

• Evaluate XPath Expression

• HTTP Basic Authentication

• Invoke webMethods Integration Server

• JMS Routing Rule

• Load Balancing and Failover Routing

• Log Invocation

• Monitor Service Level Agreement

• Monitor Service Performance

• NTLM Authentication

• OAuth2 Authentication

• Response Transformation

• Request Transformation

• Require Encryption

• Require HTTP / HTTPS

• Require JMS

• Require Signing

• Require SSL

• Require Timestamps

• Require WSS SAML Token

• Set Custom Headers

• Set JMS Headers

• Set Message Properties

• Straight Through Routing

• Throttling Traffic Optimization

• Validate Schema

Content Based Routing

If you have a native API that is hosted at two or more endpoints, you can use the Content Based Routing to route specific types of messages to specific endpoints.

You can route messages to different endpoints based on specific values that appear in the request message.

When this action is configured for a proxy API, the requests are routed according to the routing rules you create. That is, they are routed based on the successful evaluation of one or more XPath expressions that are constructed utilizing the content of the request payload. For example, a routing rule might allow requests for half of the methods of a particular service to be routed to Endpoint A, and the remaining methods to be routed to Endpoint B.

Input Parameters

Route To	URI. Mandatory. Enter the URL of the native API endpoint to route the request to in case all routing rules evaluate to False. For example: http://mycontainer/creditCheckService Click the Configure Endpoint Properties icon (next to the Route To field) if you want to configure a set of properties for the specified endpoint. Alternatively, Mediator offers "Local Optimization" capability if the native endpoint is hosted on the same Integration Server as webMethods Mediator. With local optimization, API invocation happens in-memory and not through a network hop. Specify the native API in either of the following forms: local://<Service-full-path> OR local://<server>:<port>/ws/<Service-full-path> For example: local://MyAPIFolder:MyLocalAPI which points to the endpoint API MyLocalAPI which is present under the folder MyAPIFolder in Integration Server.
Add Routing Rule button	Click the Add Routing Rule button and complete the Add Routing Rule dialog box as follows. In the XPath Expression field, specify an argument to evaluate the XPath expression contained in the request. To add a custom Namespace, specify a name and value for the namespace in the Prefix and URI fields. If you need to add additional rows, use the plus button. In the Route To field, specify the URL of the native API to route the request to, if the rule criteria are met. Click the Configure Endpoint Properties icon (next to the Route To field) if you want to configure a set of properties for the specified endpoint individually. Click OK.
Configure Endpoint Properties icon	Optional. This icon displays the Endpoint Properties dialog box that enables you to configure a set of properties for the Mediator to route incoming requests to the native API as follows:
	SOAP Optimization Method	Only for SOAP-Based APIs. Mediator can use the following optimization methods to parse SOAP requests to the native API:
		Value	Description
		MTOM	Mediator will use the Message Transmission Optimization Mechanism (MTOM) to parse SOAP requests to the API.
		SwA	Mediator will use the SOAP with Attachment (SwA) technique to parse SOAP requests to the API.
		None	Default. Mediator will not use any optimization method to parse the SOAP requests to the API.
		Notes: Bridging between SwA and MTOM is not supported. If a client sends a SwA request, Mediator can only forward SwA to the native API. The same is true for MTOM, and applies to responses received from the native API. That is, a SwA or MTOM response received by Mediator from a native API will be forwarded to the client using the same format it received. When sending SOAP requests that do not contain a MTOM or SWA attachment to a native API that returns an MTOM or SWA response, the request 'Accept' header must be set to 'multipart/related'. This is necessary so Mediator knows how to parse the response properly.
	HTTP Connection Timeout	Number. Optional. The time interval (in seconds) after which a connection attempt will timeout. If a value 0 is specified (or if the value is not specified), Mediator will use the value specified in the Connection Timeout field (go to Integration Server Administrator > Settings > Extended). Default: 30 seconds.
	Read Timeout	Number. Optional. The time interval (in seconds) after which a socket read attempt will timeout. If a value 0 is specified (or if the value is not specified), Mediator will use the value specified in the Read Timeout field (Open the Integration Server Administrator. Go to > Settings > Extended.). Default: 30 seconds.
	SSL Configuration	Optional. To enable SSL client authentication that Mediator will use to authenticate incoming requests for the native API, you must specify values for both the Client Certificate Alias field and the IS Keystore Alias field. If you specify a value for only one of these fields, a deployment error will occur. Note: SSL client authentication is optional; you may leave both fields blank. Prerequisite: You must set up the key alias and keystore properties in the Integration Server. For the procedure, see the section Securing Communications with the Server in the documentwebMethods Integration Server Administrator’s Guide. You will use these properties to specify the following fields:
		Value	Description
		Client Certificate Alias	Mandatory. The client's private key to be used for performing SSL client authentication.
		IS Keystore Alias	Mandatory. 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.
	WS Security Header	Only for SOAP-Based APIs. Indicates whether Mediator should pass the WS-Security headers of the incoming requests to the native API.
		Value	Description
		Remove processed security headers	Removes the security header if it is processed by Mediator (i.e., if Mediator processes the header according to the API's security run-time action). Note that Mediator will not remove the security header if both of the following conditions are true: 1) Mediator did not process the security header, and 2) the mustUnderstand attribute of the security header is 0/false).
		Pass all security headers	Default. Passes the security header, even if it is processed by Mediator (i.e., even if Mediator processes the header according to the API's security action).

Context Based Routing

If you have a native API that is hosted at two or more endpoints, you can use the Context Based Routing to route specific types of messages to specific endpoints.

When this action is configured for a proxy API, the requests are routed according to the routing rules you create. A routing rule specifies where requests should be routed, and the criteria by which they should be routed there. For example, requests can be routed according to certain clients, certain dates/times, or according to requests that exceed/fall below a specified metric (Total Count, Success Count, Fault Count, etc.). You can create one or more rules.

Input Parameters

Default Route To	URI. Mandatory. Enter the URL of the native API endpoint to route the request to in case all routing rules evaluate to False. For example: http://mycontainer/creditCheckService Click the Configure Endpoint Properties icon (next to the Route To field) if you want to configure a set of properties for the specified endpoint. Alternatively, Mediator offers "Local Optimization" capability if the native endpoint is hosted on the same Integration Server as webMethods Mediator. With local optimization, API invocation happens in-memory and not through a network hop. Specify the native API in either of the following forms: local://<Service-full-path> OR local://<server>:<port>/ws/<Service-full-path> For example: local://MyAPIFolder:MyLocalAPI which points to the endpoint API MyLocalAPI which is present under the folder MyAPIFolder in Integration Server.
Add Routing Rule button	Click the Add Routing Rule button and complete the Add Routing Rule dialog box as follows. In the Name field, specify a name for the routing rule. In the Condition panel, specify the following as required: In the Variable column, select Time, IP Address Range, Date, Consumer, Predefined Context Variable or Custom Context Variable. For more information, see Using Context Variables in APIs. In the Value column, specify an applicable value. For Date choose Before, After or Equal To and enter a date. For Time choose Before or After and enter a time. For IP Address, enter numeric values for Between and And. For Consumer, enter a consumer application name in the text box. For Predefined Context Variable or Custom Context Variable, choose the String or Integer data type. Select a predefined variable name or custom variable name from the drop-down list. For String, choose Equal To or Not Equal To and enter a value. For Integer, choose Greater Than, Less Than, Not Equal To, Equal To or and enter a value. Notes: For the list of the predefined context variables, see Using Context Variables in APIs. The predefined context variable PROTOCOL_HEADER is not available in the drop-down list; to include PROTOCOL_HEADER in the rule, define the variable as Custom Context Variable. For more information, see The API for Context Variables. If you define a custom context variable in the routing rule, you must write a webMethods IS service and invoke it in the API's Context Based Routing action. In this Integration Server service, use the API to get/set the custom context variable. For more information, see The API for Context Variables. If you need to specify multiple variables, use the plus button to add rows. If you have more than one routing rule, choose an operator for the expression: AND or OR (the default) . In the Route To field, specify the URL of the native API endpoint to route the request to, if the rule criteria are met. Click the Configure Endpoint Properties icon (next to the Route To field) if you want to configure a set of properties for the specified endpoint individually. Click OK.
Configure Endpoint Properties icon	Optional. This icon displays the Endpoint Properties dialog box that enables you to configure a set of properties for the Mediator to route incoming requests to the native API as follows:
	SOAP Optimization Method	Only for SOAP-Based APIs. Mediator can use the following optimization methods to parse SOAP requests to the native API:
		Value	Description
		MTOM	Mediator will use the Message Transmission Optimization Mechanism (MTOM) to parse SOAP requests to the API.
		SwA	Mediator will use the SOAP with Attachment (SwA) technique to parse SOAP requests to the API.
		None	Default. Mediator will not use any optimization method to parse the SOAP requests to the API.
		Notes: Bridging between SwA and MTOM is not supported. If a client sends a SwA request, Mediator can only forward SwA to the native API. The same is true for MTOM, and applies to responses received from the native API. That is, a SwA or MTOM response received by Mediator from a native API will be forwarded to the client using the same format it received. When sending SOAP requests that do not contain a MTOM or SWA attachment to a native API that returns an MTOM or SWA response, the request 'Accept' header must be set to 'multipart/related'. This is necessary so Mediator knows how to parse the response properly.
	HTTP Connection Timeout	Number. Optional. The time interval (in seconds) after which a connection attempt will timeout. If a value 0 is specified (or if the value is not specified), Mediator will use the value specified in the Connection Timeout field (go to Integration Server Administrator > Settings > Extended). Default: 30 seconds.
	Read Timeout	Number. Optional. The time interval (in seconds) after which a socket read attempt will timeout. If a value 0 is specified (or if the value is not specified), Mediator will use the value specified in the Read Timeout field (Open the Integration Server Administrator. Go to > Settings > Extended.). Default: 30 seconds.
	SSL Configuration	Optional. To enable SSL client authentication that Mediator will use to authenticate incoming requests for the native API, you must specify values for both the Client Certificate Alias field and the IS Keystore Alias field. If you specify a value for only one of these fields, a deployment error will occur. Note: SSL client authentication is optional; you may leave both fields blank. Prerequisite: You must set up the key alias and keystore properties in the Integration Server. For the procedure, see the section Securing Communications with the Server in the documentwebMethods Integration Server Administrator’s Guide. You will use these properties to specify the following fields:
		Value	Description
		Client Certificate Alias	Mandatory. The client's private key to be used for performing SSL client authentication.
		IS Keystore Alias	Mandatory. 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.
	WS Security Header	Only for SOAP-Based APIs. Indicates whether Mediator should pass the WS-Security headers of the incoming requests to the native API.
		Value	Description
		Remove processed security headers	Default. Removes the security header if it is processed by Mediator (i.e., if Mediator processes the header according to the API's security run-time action). Note that Mediator will not remove the security header if both of the following conditions are true: 1) Mediator did not process the security header, and 2) the mustUnderstand attribute of the security header is 0/false).
		Pass all security headers	Passes the security header, even if it is processed by Mediator (i.e., even if Mediator processes the header according to the API's security action).

Custom SOAP Response Message

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

Input Parameters

Failure Messages

The failure message is returned in both of the following cases:

• When a failure is returned by the native API provider.

  In this case, the $ERROR_MESSAGE variable in the failure message 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.

• When a failure 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.

Alternatively, you can configure global failure messages for all APIs, using Mediator's Service Fault Configuration page, as described in the document Administering webMethods Mediator.

Mediator returns the following failure message to the consuming application:

Mediator encountered an error:$ERROR_MESSAGE while executing operation:$OPERATION service:$SERVICE at time:$TIME on date:$DATE. The client ip was:$CLIENT_IP. The current user:$USER. The consumer application:$CONSUMER_APPLICATION".

The precedence of the Failure Message configurations is as follows:

• If you configure a Custom SOAP Response Message action for an API, the failure message configurations take precedence over any settings on the global Service Fault Configuration page.

• If you do not configure a Custom SOAP Response Message action for an API, the settings on the Service Fault Configuration page take precedence.

The default failure message contains predefined fault handler variables ($ERROR_MESSAGE, $OPERATION, etc.) which are described in the table below.

You can customize the default failure message using the following substitution variables, where Mediator replaces the variable reference with the real content at run time:

• The predefined context variables listed in The Predefined Context Variables.

• Custom context variables that you declare using Mediator's API (see The API for Context Variables).

  Note:
  If you want to reference a custom context variable that you have already defined in a Context Based Routing action (as opposed to one you have declared using Mediator's API), then you must add the prefix $mx to the variable name in order to reference the variable. For example, if you defined the variable TAXID, you would reference it as $mx:TAXID.

The fault handler variables are described below.

Note:
If no value is defined for a fault handler variable, then the returned value will be the literal string "null". For example, $CONSUMER_APPLICATION will always be "null" if the service's policy does not contain at least one of the "Evaluate" actions.

Evaluate Client Certificate for SSL Connectivity

If you have a native API that requires to authenticate a client to the Integration Server using the Secure Sockets Layer (SSL) client authentication, you can use the Evaluate Client Certificate action to extract the client's identity certificate, and verify the client's identity (certificate-based authentication).

This form of authentication does not occur at the message layer using a user ID and password or tokens. This authentication occurs during the connection handshake using SSL certificates.

This action extracts the client identity certificate supplied by the client to the Mediator during the SSL handshake over the Transport layer. For example, when you have configured this action for a proxy API, the PEP extracts the certificate from the Transport layer. In order to identify clients 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 a keystore and truststore, as described in Securing Communications with the Server in the webMethods Integration Server Administrator’s Guide.

• In Integration Server, create an HTTPS port, as described in Configuring Ports in the webMethods Integration Server Administrator’s Guide.

• 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.

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

Input Parameters

Registered Consumers

Global Consumers

Evaluate Hostname

If you have a native API that requires to authenticate a client to the Integration Server using the hostname, you can use the Evaluate Hostname action to extract the client's hostname from the HTTP request header, and verify the client's identity.

This action extracts the specified hostname from an incoming request and locates the client defined by that hostname. For example, when you have configured this action for an API, the PEP extracts the hostname from the request’s HTTP header at run time and searches its list of consumers for the client defined by the hostname.

Mediator will evaluate the incoming request to identify and validate that the client's request originated from a particular host machine.

Mediator rejects requests that do not include the hostname of an Integration Server user.

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

Input Parameters

Registered Consumers

Global Consumers

Evaluate HTTP Basic Authentication

If you have a native API that requires to authenticate a client to the Integration Server using the HTTP Basic Authentication, you can use the Evaluate HTTP Basic Authentication action to extract the client's credentials (user ID and password) from the Authorization request header, and verify the client's identity.

This action uses HTTP Basic authentication to verify the client's authentication credentials contained in the request's Authorization header. When this action is configured for an API, Mediator validates the credentials against the list of consumers available in the Integration Server on which Mediator is running. If you chosen the checkbox Authenticate User using the HTTP Basic Authentication, this type of client 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 client 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.

If you choose to omit the Authenticate User parameter (and regardless of whether an Authorization header is present in the request or not), then Mediator forwards the request to the native API, without attempting to authenticate the request.

In the case where a client sends a request with transport credentials (HTTP Basic Authentication) and message credentials (WSS Username Token or WSS X.509 Token), the message credentials take precedence over the transport credentials when Integration Server determines which credentials it should use for the session. For more information, see Evaluate WSS Username Token and Evaluate WSS X.509 Certificate.

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

Input Parameters

Registered Consumers

Global Consumers

Do Not Identify

Evaluate IP Address

If you have a native API that requires to authenticate a client to the Integration Server using the IP address, you can use the Evaluate IP Address action to extract the client's IP address from the HTTP request header, and verify the client's identity.

This action extracts the specified IP address from an incoming request and locates the client defined by that IP address. For example, when you have configured this action for a proxy API, the PEP extracts the IP address from the request’s HTTP header at run time and searches its list of consumers for the client defined by the IP address.

Mediator will evaluate the incoming request to identify and validate that the client's request originated from a particular IP address.

Mediator rejects requests that do not include the IP address of an Integration Server user.

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

Input Parameters

Registered Consumers

Global Consumers

Do Not Identify

Evaluate OAuth2 Token

This action extracts the specified OAuth access token from an incoming request and locates the client defined by that access token. For example, when you have configured this action for an API, the PEP extracts the OAuth access token from the request’s HTTP header at run time and searches its list of consumers for the client that is defined by that access token.

Mediator will evaluate the incoming request to identify and validate that the client's access token.

Mediator rejects requests that do not include the OAuth access token of an Integration Server user.

Mediator supports OAuth2.0 using the grant type "Client Credentials".

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

Input Parameters

Registered Consumers

Global Consumers

True

False

Evaluate WSS Username Token

If you have a native API that requires to authenticate a client to the Integration Server using the WS-Security authentication, you can use the Evaluate WSS Username Token action to extract the client's credentials (username token and password) from the WS-Security SOAP message header, and verify the client's identity.

This action extracts the username token and password supplied in the message header of the request and locates the client defined by that username token and password. For example, when you have configured this action for an API, the PEP extracts the username token and password from the SOAP header at run time and searches its list of consumers for the client that is defined by the credentials.

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

• In Integration Server, create a keystore and truststore, as described in Securing Communications with the Server in the webMethods Integration Server Administrator’s Guide.

• In Integration Server, create an HTTPS port, as described in Configuring Ports in the webMethods Integration Server Administrator’s Guide.

• 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 the username token and password of an Integration Server user. Mediator only supports clear text passwords with this kind of authentication.

In the case where a client sends a request with transport credentials (HTTP Basic Authentication) and message credentials (WSS Username Token or WSS X.509 Certificate), the message credentials take precedence over the transport credentials when Integration Server determines which credentials it should use for the session. For more information, see Evaluate HTTP Basic Authentication Action and Evaluate WSS X.509 Certificate Token.

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

Input Parameters

Registered Consumers

Global Consumers

Do Not Identify

Evaluate WSS X.509 Certificate

If you have a native API that requires to authenticate a client to the Integration Server using the WS-Security authentication, you can use the Evaluate WSS X.509 Certificate action to extract the client identity certificate from the WS-Security SOAP message header, and verify the client's identity.

This action extracts the certificate supplied in the header of an incoming SOAP request and locates the client defined by the information in that certificate. For example, when you have configured this action for an API, the PEP extracts the certificate from the SOAP header at run time and searches its list of consumers for the client that is defined by the certificate.

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

• In Integration Server, create a keystore and truststore, as described in Securing Communications with the Server in the webMethods Integration Server Administrator’s Guide.

• In Integration Server, create an HTTPS port, as described in Configuring Ports in the webMethods Integration Server Administrator’s Guide.

• 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 the X.509 token of an Integration Server user.

In the case where a client sends a request with transport credentials (HTTP Basic Authentication) and message credentials (WSS Username Token or WSS X.509 Certificate), the message credentials take precedence over the transport credentials when Integration Server determines which credentials it should use for the session. For more information, see Evaluate WSS Username Token and Evaluate HTTP Basic Authentication Action.

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

Input Parameters

Registered Consumers

Global Consumers

Do Not Identify

Evaluate XPath Expression

Note:
This action does not support JSON-based REST APIs.

If you have a native API that requires to authenticate a client to the Integration Server using the custom authentication, you can use the Evaluate XPath Expression action to extract the custom authentication credentials (tokens, or username and password token combination) from the request header, and verify the client's identity.

This action extracts the custom authentication credentials that is supplied in the request header (which is represented using an XPath expression) and locates the client defined by the credentials. The custom authentication credentials can be in the form of tokens, or a username and password token combination. For example, when you have configured this action for an API, the PEP extracts the custom credentials from the request header (using an XPath expression) at run time and searches its list of consumers for the client defined by the credentials.

Mediator rejects requests that do not include the XPath expression of an Integration Server user.

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

Input Parameters

Registered Consumers

Global Consumers

Do Not Identify

Let's take a look at an example. For the following SOAP message:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
</soap:Header>
  <soap:Body>
    <catalog xmlns="http://www.store.com">
      <name>My Book</name>
      <author>ABC</author>
      <price>100</price>
    </catalog>
  </soap:Body>
</soap:Envelope>

The XPath expression appears as follows:

/soap:Envelope/soap:Body

HTTP Basic Authentication

This action uses the HTTP authentication mechanism to validate incoming requests from clients. Mediator authorizes the basic credentials (username and password) against a list of all global consumers available in the Mediator.

If the username/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. 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.

If none of the authentication actions (HTTP Basic Authentication, NTLM Authentication or OAuth2 Authentication) is configured for a proxy API, Mediator forwards the request to the native API, without attempting to authenticate the request.

Input Parameters

Existing Credentials

Custom Credentials

Invoke webMethods Integration Server

Specifically, you would need to configure the Invoke webMethods Integration Server action to:

• Pre-process the request messages into the format required by the native API, before Mediator sends the requests to the native APIs.

• Pre-process the native API’s response messages into the format required by the clients, before Mediator returns the responses to the clients.

In some cases an API might need to process messages.

For example, you might need to accommodate differences between the message content that a client is capable of submitting and the message content that a native API expects. For example, if the client submits an order record using a slightly different structure than the structure expected by the native API, you can use this action to process the record submitted by the client to the structure required by the native API.

In the Request Handling sequence, this action invokes the webMethods IS service to pre-process the request received from the client and before it is submitted to the native API.

In the Response Processing sequence, this action invokes the webMethods IS service to process the response message received from the native API and before it is returned to the client.

Note:
A webMethods IS service must be running on the same Integration Server as webMethods Mediator. It can call out a C++ or Java or .NET function. It can also call other Integration Server services to manipulate the message.

Input Parameters

JMS Routing Rule

This action allows you to specify a JMS queue to which the Mediator is to submit the request, and the destination to which the native API is to return the response.

To use the JMS Routing Rule action, you publish multiple APIs for a single native API. For example, to make a particular native API available to clients over both HTTP and JMS, you would create two APIs for the native API: one that accepts requests over HTTP and another that accepts requests over JMS. Both APIs would route requests to the same native API on the back end.

Note:
To make it easier to manage APIs, consider adopting a naming convention like the one shown above. Doing so will make it easier to identify APIs and the native API with which they are associated. Keep in mind however, that unlike native APIs, the names of APIs cannot contain spaces or special characters (except _ and -). Consequently, if you adopt a convention that involves using the name of the native API as part of the API name, then the names of the native APIs themselves must not contain characters that are invalid in API names.

To use this action the following prerequisites must be met:

• Create an alias to a JNDI Provider (in the Integration Server Administrator, go to Settings > Web Services). For the procedure, see the section Creating a JNDI Provider Alias in the document Administering webMethods Integration Server.

• To establish an active connection between Integration Server and the JMS provider, you must configure Integration Server to use a JMS connection alias (in the Integration Server Administrator, go to Settings > Messaging > JMS Settings). For the procedure, see the section Creating a JMS Connection Alias in the document Administering webMethods Integration Server.

• Create a WS (Web Service) endpoint alias for provider Web Service Descriptor (WSD) that uses a JMS binder. In the Integration Server Administrator, navigate to Settings > Web Services and complete the Alias Name, Description, Descriptor Type, and Transport Type fields, as described in the section Creating an Endpoint Alias for a Provider Web Service Descriptor for Use with JMS in the document Administering webMethods Integration Server.

• Configure a WS (Web Service) endpoint trigger (in the Integration Server Administrator, go to Settings > Messaging > JMS Trigger Management). For the procedure, see the section Editing WS Endpoint Triggers in the document Administering webMethods Integration Server.

• Create a WS (Web Service) endpoint alias for consumer Web Service Descriptor (WSD) that has a JMS binder. In the Integration Server Administrator, navigate to Settings > Web Services and complete the Alias Name, Description, Descriptor Type, and Transport Type fields, as described in the section Creating an Endpoint Alias for a Consumer Web Service Descriptor for Use with JMS in the document Administering webMethods Integration Server.

• Additionally, in the proxy API's Message Flow area, make sure that you delete the predefined Straight Through Routing and HTTP Basic Authentication actions from the Receive stage. This is because, these actions are mutually exclusive.

Input Parameters

jms:queue:dynamicQueues/MyRequestQueue?
wm-wsendpointalias=MediatorConsumer
&targetService=vs-jms-in-echo

Persistent

Non-Persistent

What Happens if a Queue Includes Multiple JMS Messages?

To determine the order in which to execute the JMS messages in a queue, Mediator examines each message's Priority setting.

The Priority setting contains a non-negative integer that indicates the JMS message's priority. A priority value of 0 represents the highest possible priority.

Note:
A JMS message's Priority property is used only when there are multiple JMS messages to route in the queue. If the queue has only one message to route, the Priority property is ignored entirely.

When a queue includes multiple JMS messages, Mediator routes the messages serially, in priority order from lowest to highest (that is, it routes with message the lowest priority value first). Each messages in the queue is routed to completion before the next one begins.

If two or more messages have the same priority value, their order is indeterminate. Mediator will route these messages in serial fashion after all lower priority messages and before any higher priority messages. However, you cannot predict their order

Example

If Mediator were given the following JMS messages to route for an API:

It would route the messages in the following order:

Load Balancing and Failover Routing

If you have a native API that is hosted at two or more endpoints, you can use the Load Balancing and Failover Routing to distribute requests among the endpoints.

Requests are distributed across multiple endpoints. The requests are intelligently routed based on the "round-robin" execution strategy. The load for a service is balanced by directing requests to two or more services in a pool, until the optimum level is achieved. The application routes requests to services in the pool sequentially, starting from the first to the last service without considering the individual performance of the services. After the requests have been forwarded to all the services in the pool, the first service is chosen for the next loop of forwarding.

Load-balanced endpoints also have automatic Failover capability. If a load-balanced endpoint is unavailable (for example, if a connection is refused), then that endpoint is marked as "down" for the number of seconds you specify in the Timeout field (during which the endpoint will not be used for sending the request), and the next configured endpoint is tried. If all the configured load-balanced endpoints are down, then a failure is sent back to the client. After the timeout expires, each endpoint marked will be available again to send the request.

Input Parameters

Route To	URI. Mandatory. Enter the URLs of two or more endpoints in a pool to which the requests will be routed. The application routes the requests to endpoints in the pool sequentially, starting from the first to the last endpoint without considering the individual performance of the endpoints. After the requests have been forwarded to all the endpoints in the pool, the first endpoint is chosen for the next loop of forwarding. Enter the URL of the endpoint to route the request to. For example: http://mycontainer/creditCheckService To specify additional endpoints, use the plus button next to the field to add rows. Click the Configure Endpoint Properties icon (next to the field) if you want to configure a set of properties for the endpoints individually. Alternatively, Mediator offers "Local Optimization" capability if the native API is hosted on the same Integration Server as webMethods Mediator. With local optimization, API invocation happens in-memory and not through a network hop. local://<Service-full-path> OR local://<server>:<port>/ws/<Service-full-path> For example: local://MyAPIFolder:MyLocalAPI which points to the endpoint API MyLocalAPI which is present under the folder MyAPIFolder in Integration Server.
Configure Endpoint Properties icon	Optional. This icon displays the Endpoint Properties dialog box that enables you to configure a set of properties for the Mediator to route incoming requests to the native API as follows:
	SOAP Optimization Method	Only for SOAP-based APIs. Mediator can use the following optimization methods to parse SOAP requests to the native API:
		Value	Description
		MTOM	Mediator will use the Message Transmission Optimization Mechanism (MTOM) to parse SOAP requests to the API.
		SwA	Mediator will use the SOAP with Attachment (SwA) technique to parse SOAP requests to the API.
		None	Default. Mediator will not use any optimization method to parse the SOAP requests to the API.
		Notes: Bridging between SwA and MTOM is not supported. If a client sends a SwA request, Mediator can only forward SwA to the native API. The same is true for MTOM, and applies to responses received from the native API. That is, a SwA or MTOM response received by Mediator from a native API will be forwarded to the client using the same format it received. When sending SOAP requests that do not contain a MTOM or SWA attachment to a native API that returns an MTOM or SWA response, the request 'Accept' header must be set to 'multipart/related'. This is necessary so Mediator knows how to parse the response properly.
	HTTP Connection Timeout	Number. Optional. The time interval (in seconds) after which a connection attempt will timeout. If a value 0 is specified (or if the value is not specified), Mediator will use the value specified in the Connection Timeout field (go to Integration Server Administrator > Settings > Extended). Default: 30 seconds.
	Read Timeout	Number. Optional. The time interval (in seconds) after which a socket read attempt will timeout. If a value 0 is specified (or if the value is not specified), Mediator will use the value specified in the Read Timeout field (Open the Integration Server Administrator. Go to > Settings > Extended.). Default: 30 seconds.
	SSL Configuration	Optional. To enable SSL client authentication that Mediator will use to authenticate incoming requests for the native API, you must specify values for both the Client Certificate Alias field and the IS Keystore Alias field. If you specify a value for only one of these fields, a deployment error will occur. Note: SSL client authentication is optional; you may leave both fields blank. Prerequisite: You must set up the key alias and keystore properties in the Integration Server. For the procedure, see the section Securing Communications with the Server in the documentwebMethods Integration Server Administrator’s Guide. You will use these properties to specify the following fields:
		Value	Description
		Client Certificate Alias	Mandatory. The client's private key to be used for performing SSL client authentication.
		IS Keystore Alias	Mandatory. 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.
	WS Security Header	Only for SOAP-based APIs. Indicates whether Mediator should pass the WS-Security headers of the incoming requests to the native API.
		Value	Description
		Remove processed security headers	Default. Removes the security header if it is processed by Mediator (i.e., if Mediator processes the header according to the API's security run-time policy). Note that Mediator will not remove the security header if both of the following conditions are true: 1) Mediator did not process the security header, and 2) the mustUnderstand attribute of the security header is 0/false).
		Pass all security headers	Passes the security header, even if it is processed by Mediator (i.e., even if Mediator processes the header according to the API's security action).

Log Invocation

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

Response

Always

On Success

On Failure

CentraSite

Local Log

SNMP

Email

Audit Log

EDA

Monitor Service Level Agreement

This action monitors a set of run-time performance conditions for an API, and sends alerts to a specified destination when the performance conditions are violated. This action enables you to monitor run-time performance for one or more specified clients.

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 client should expect from an API. You can use this action to identify whether an API threshold rules are met or exceeded. For example, you might define an agreement with a particular client that sends an alert to the client (consumer application) if responses are not sent within a certain maximum response time. You can configure SLAs for each API/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 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 Parameters	Specify 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
	Availability	Indicates whether the API was available to the specified clients 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.
	Operator	String. Array. Specifies an operator.
Value	Integer. Array. Specifies an alert value.
Alert for Consumer Applications	Object. Array. Specify the Application asset(s) to which this Service Level Agreement will apply. To specify multiple consumer applications, use the button to add multiple rows.
Alert Configuration Parameters	Specifies the parameters for the alerts that will report on the Service Level Agreement conditions:
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
	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.
Alert 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 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.
	EDA	Mediator can use EDA to log the payloads to a database. Prerequisite: You must configure the EDA destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > EDA). For the procedure, see the section EDA Configuration for Publishing Run-Time Events and Metrics in the document Administering webMethods Mediator.
Alert Message	String. Optional. Specify a text message to include in the alert.

Monitor Service Performance

This action is similar to the Monitor Service Level Agreement action. Both actions can monitor the same set of run-time performance conditions for an API, and then send alerts when the performance conditions are violated. However, this action monitors run-time performance for a specific client.

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 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 Parameters	Specify 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
	Availability	Indicates whether the service was available to the specified clients 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.
	Operator	String. Array. Specify an operator.
Value	Integer. Array. Specify an alert value.
Alert Configuration Parameters	Specify the parameters for the alerts that will report on the Service Level Agreement conditions:
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. Specify how frequently to issue alerts for the counter-based metrics (Total Request Count, Success Count, Fault Count).
	Value	Description
	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.
Alert Destination	String. Specify 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 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.
	EDA	Mediator can use EDA to log the payloads to a database. Prerequisite: You must configure the EDA destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > EDA). For the procedure, see the section EDA Configuration for Publishing Run-Time Events and Metrics in the document Administering webMethods Mediator.
Alert Message	String. Optional. Specify a text message to include in the alert.

NTLM Authentication

This action uses the NTLM authentication to validate incoming requests from clients. Mediator authorizes the NTLM credentials (username and password) against a list of all global consumers available in the Mediator.

If the username/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. If the client does not successfully respond to the challenge, a 401 Unauthorized "WWW-Authenticate: NTLM" (for NTLM authentication) or "WWW-Authenticate: Negotiate" (for Kerberos authentication) is returned in the response header 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.

Note:
Note that if Mediator is used to access a native API protected by NTLM (which is typically hosted in IIS), then the native API 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.

If none of the authentication actions (HTTP Basic Authentication, NTLM Authentication or OAuth2 Authentication) is configured for a proxy API, Mediator forwards the request to the native API, without attempting to authenticate the request.

Input Parameters

Existing Credentials

Custom Credentials

Transparent

OAuth2 Authentication

This action uses the OAuth 2.0 authentication to validate incoming requests from clients. Mediator authorizes the OAuth 2.0 credentials (access token) against a list of all global consumers available in the Mediator.

This action uses the NTLM authentication to validate incoming requests from clients. Mediator authorizes the credentials against a list of all global consumers available in the Mediator.

If the access token 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. If the client does not successfully respond to the challenge, a "WWW-Authenticate: OAuth" 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.

If none of the authentication actions (HTTP Basic Authentication, NTLM Authentication or OAuth2 Authentication) is configured for a proxy API, Mediator forwards the request to the native API, without attempting to authenticate the request.

Input Parameters

Existing Token

Custom Token

Response Transformation

The Response Transformation action specifies:

• The XSLT transformation file to transform response messages from native APIs into a format required by the client.

In some cases a message needs to be transformed prior to sending to the client.

For example, you might need to accommodate differences between the message content that a native API is capable of submitting and the message content that a client expects. For example, if the native API submits an order record using a slightly different structure than the structure expected by the client, you can use this action to transform the record submitted by the native API to the structure required by the client.

When this action is configured for a proxy API, the native API’s response messages are transformed into the format required by the client, before Mediator returns the responses to the clients.

Input Parameters

Request Transformation

The Request Transformation action specifies:

• The XSLT Transformation File to transform request messages from clients into a format required by the native API.

In some cases a native API might need to transform messages.

For example, you might need to accommodate differences between the message content that a client is capable of submitting and the message content that a native API expects. For example, if the client submits an order record using a slightly different structure than the structure expected by the native API, you can use this action to transform the record submitted by the client to the structure required by the native API.

When this action is configured for a proxy API, the incoming requests from the clients are transformed into a format required by the native API, before Mediator sends the requests to the native APIs.

Input Parameters

Require Encryption

This action requires that a request's XML element (which is represented by an XPath expression) be encrypted.

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

1. Configure Integration Server: Set up keystores and truststores in Integration Server, as described in Securing Communications with the Server in the document Administering webMethods Integration Server.

2. Configure Mediator: In the Integration Server Administrator, navigate to Solutions > Mediator > Administration > General and complete the IS Keystore Name, IS Truststore Name and Alias (signing) fields, as described in Keystore Configuration in the document Administering WebMethods Mediator.

When this action is configured for a proxy API, Mediator provides decryption of incoming requests and encryption of outgoing responses. Mediator can encrypt and decrypt only individual elements in the SOAP message body that are defined by the XPath expressions configured for the action. Mediator requires that requests contain the encrypted elements that match those in the XPath expression. You must encrypt the entire element, not just the data between the element tags. Mediator rejects requests if the element name is not encrypted.

Important:
Do not encrypt the entire SOAP body because a SOAP request without an element will appear to Mediator to be malformed.

Mediator attempts to encrypt the response elements that match the XPath expressions with those defined for the action. If the response does not have any elements that match the XPath expression, Mediator will not encrypt the response before sending. If the XPath expression resolves a portion of the response message, but Mediator cannot locate a certificate to encrypt the response, then Mediator sends a SOAP fault exception to the client and a Policy Violation event notification to CentraSite.

How Mediator Encrypts Responses

The Require Encryption action encrypts the response back to the client by dynamically setting a public key alias at run time. Mediator determines the public key alias as follows:

1. If Mediator can access the X.509 certificate of the client (based on the incoming request signature), it will use "useReqSigCert" as the public key alias.

   OR

2. If an "Evaluate" action is present in the message flow (and it successfully identifies a client), then Mediator will look for a public key alias with that client name in the "IS Keystore Name" property. The "IS Keystore Name" property is specified in the Integration Server Administrator, under Solutions > Mediator > Administration > General. This property should be set to an Integration Server keystore that Mediator will use.

   For an "Evaluate" action that allows for anonymous usage, Mediator does not require a client name in order to send encrypted responses. In this case, Mediator can use one of the following to encrypt the response in the following order, depending on what is present in the security element:

   • A signing certificate.

   • Client name.

   • WSS username, SAML token or X.509 certificate.

   • HTTP authorized user.

   OR

3. If Mediator can determine the current IS user from the request (i.e., if an Integration Server WS-Stack determined that Subject is present), then the first principal in that subject is used.

   OR

4. If the above steps all fail, then Mediator will use either the WS-Security username token or the HTTP Basic-Auth username value. There should be a public key entry with the same name as the identified username.

Input Parameters

<sp:SignedElements xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
              <sp:XPath xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">//soapenv:Body</sp:XPath>
            </sp:SignedElements>

Let's take a look at an example. For the following SOAP message:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
</soap:Header>
  <soap:Body>
    <catalog xmlns="http://www.store.com">
      <name>My Book</name>
      <author>ABC</author>
      <price>100</price>
    </catalog>
  </soap:Body>
</soap:Envelope>

The XPath expression appears as follows:

/soap:Envelope/soap:Body

Require HTTP / HTTPS

If you have a native API that requires clients to communicate with the server using the HTTP and/or HTTPS protocols, you can use the Require HTTP / HTTPS protocol action.

This action allows you to bridge the transport protocols between the client and the Mediator. For example, suppose you have a native API that is exposed over HTTPS and an API that receives requests over HTTP. In this situation, you can configure the API’s Require HTTP / HTTPS action to accept HTTP requests and configure its Routing action to route the request to the native API using HTTPS.

Input Parameters

HTTP

HTTPS

SOAP 1.1

SOAP 1.2

GET

PUT

POST

DELETE

Require JMS

If you have a native API that requires clients to communicate with the server using the JMS protocol, you can use the Require JMS protocol action.

This action allows you to bridge protocols between the client and the native API. For example, suppose you have a native API that is exposed over JMS and a client that submits SOAP requests over HTTP. In this situation, you can configure the API’s Require JMS Protocol action to accept SOAP requests over Java Message Service (JMS) and configure its JMS Routing Rule action to route the request to the Web service using JMS.

When this action is configured for a proxy API, you can intentionally expose an API over a JMS protocol. For example, if you have a native API that is exposed over HTTP, you might expose the API over JMS simply to gain the asynchronous-messaging and guaranteed-delivery benefits that one gains by using JMS as the message transport.

To use this action the following prerequisites must be met:

• Create an alias to a JNDI Provider (in the Integration Server Administrator, go to Settings > Web Services). For the procedure, see the section Creating a JNDI Provider Alias in the document Administering webMethods Integration Server.

• To establish an active connection between Integration Server and the JMS provider, you must configure Integration Server to use a JMS connection alias (in the Integration Server Administrator, go to Settings > Messaging > JMS Settings). For the procedure, see the section Creating a JMS Connection Alias in the document Administering webMethods Integration Server.

• Create a WS (Web Service) endpoint alias for provider Web Service Descriptor (WSD) that uses a JMS binder. In the Integration Server Administrator, navigate to Settings > Web Services and complete the Alias Name, Description, Descriptor Type, and Transport Type fields, as described in the section Creating an Endpoint Alias for a Provider Web Service Descriptor for Use with JMS in the document Administering webMethods Integration Server.

• Configure a WS (Web Service) endpoint trigger (in the Integration Server Administrator, go to Settings > Messaging > JMS Trigger Management). For the procedure, see the section Editing WS Endpoint Triggers in the document Administering webMethods Integration Server.

• Create a WS (Web Service) endpoint alias for consumer Web Service Descriptor (WSD) that has a JMS binder. In the Integration Server Administrator, navigate to Settings > Web Services and complete the Alias Name, Description, Descriptor Type, and Transport Type fields, as described in the section Creating an Endpoint Alias for a Consumer Web Service Descriptor for Use with JMS in the document Administering webMethods Integration Server.

• Additionally, in the API's Message Flow, make sure that you delete the predefined Require HTTP / HTTPS Protocol action from the Receive stage. This is because, these actions are mutually exclusive.

Input Parameters

SOAP 1.1

SOAP 1.2

Require Signing

This action requires that a request's XML element (which is represented by an XPath expression) be signed.

Prerequisites

1. Configure Integration Server: Set up keystores and truststores in Integration Server, as described in Securing Communications with the Server in the document Administering webMethods Integration Server.

2. Configure Mediator: In the Integration Server Administrator, navigate to Solutions > Mediator > Administration > General and complete the IS Keystore Name, IS Truststore Name and Alias (signing) fields, as described in Keystore Configuration in the document Administering WebMethods Mediator. Mediator uses the signing alias specified in the Alias (signing) field to sign the response.

When this action is configured for a proxy API, Mediator validates that the requests are properly signed, and provides signing for responses. Mediator provides support both for signing an entire SOAP message body or individual elements of the SOAP message body. Mediator uses a digital signature element in the security header to verify that all elements matching the XPath expression were signed. If the request contains elements that were not signed or no signature is present, then Mediator rejects the request.

Note:
You must map the public certificate of the key used to sign the request to an Integration Server user. If the certificate is not mapped, Mediator returns a SOAP fault to the caller.

Input Parameters

<sp:SignedElements xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
              <sp:XPath xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">//soapenv:Body</sp:XPath>
            </sp:SignedElements>

Let's take a look at an example. For the following SOAP message:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
</soap:Header>
  <soap:Body>
    <catalog xmlns="http://www.store.com">
      <name>My Book</name>
      <author>ABC</author>
      <price>100</price>
    </catalog>
  </soap:Body>
</soap:Envelope>

The XPath expression appears as follows:

/soap:Envelope/soap:Body

Require SSL

This action requires that requests be sent via SSL client certificates.

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

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

Note:
In Integration Server, create an HTTPS port, as described in Configuring Ports in the webMethods Integration Server Administrator's Guide.

Input Parameters

Require Timestamps

When this action is set for the API, Mediator requires that timestamps be included in the request header. Mediator checks the timestamp value against the current time to ensure that the request is not an old message. This serves to protect your system against attempts at message tampering, such as replay attacks.

Mediator rejects the request if either of the following happens:

• Mediator receives a timestamp that exceeds the time defined by the timestamp element.

• A timestamp element is not included in the request.

Note:
This action has no input parameters; you simply drag and drop the action into the Message Flow area.

Input Parameters

None.

Require WSS SAML Token

When this action is configured for a proxy API, Mediator uses a WSS Security Assertion Markup Language (SAML) assertion token to validate clients for an API.

Note:
For information about configuring your system for SAML token processing, see SAML Support in Mediator in the document Administering webMethods Mediator.

Input Parameters

Holder of Key

Bearer

Set Custom Headers

When this action is configured for a proxy API, Mediator includes custom HTTP headers to the client requests before submitting to the native APIs.

Input Parameters

Header	String. Mediator uses 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.
	Value	Description
	Name	String. A name for the HTTP header field. The header field name ($field) is not case sensitive.
	Value	String. A value for the HTTP header field.

Sample

Let's imagine you have a Name field "Authorization". This will be encoded in Base64 scheme as follows: QXV0aG9yaXphdGlvbg==.

Set JMS Headers

Every JMS message includes message header properties that are always passed from provider to client. The purpose of the header properties is to convey extra information to the client outside the normal content of the message body.

When this action is configured for a proxy API, Mediator uses the JMS header properties to authenticate client requests before submitting to the native APIs.

To use this action the following prerequisites must be met:

• Create an alias to a JNDI Provider (in the Integration Server Administrator, go to Settings > Web Services). For the procedure, see the section Creating a JNDI Provider Alias in the document Administering webMethods Integration Server.

• To establish an active connection between Integration Server and the JMS provider, you must configure Integration Server to use a JMS connection alias (in the Integration Server Administrator, go to Settings > Messaging > JMS Settings). For the procedure, see the section Creating a JMS Connection Alias in the document Administering webMethods Integration Server.

• Create a WS (Web Service) endpoint alias for provider Web Service Descriptor (WSD) that uses a JMS binder. In the Integration Server Administrator, navigate to Settings > Web Services and complete the Alias Name, Description, Descriptor Type, and Transport Type fields, as described in the section Creating an Endpoint Alias for a Provider Web Service Descriptor for Use with JMS in the document Administering webMethods Integration Server.

• Configure a WS (Web Service) endpoint trigger (in the Integration Server Administrator, go to Settings > Messaging > JMS Trigger Management). For the procedure, see the section Editing WS Endpoint Triggers in the document Administering webMethods Integration Server.

• Create a WS (Web Service) endpoint alias for consumer Web Service Descriptor (WSD) that has a JMS binder. In the Integration Server Administrator, navigate to Settings > Web Services and complete the Alias Name, Description, Descriptor Type, and Transport Type fields, as described in the section Creating an Endpoint Alias for a Consumer Web Service Descriptor for Use with JMS in the document Administering webMethods Integration Server.

Input Parameters

Name

Value

Settable JMS Header Properties

Set Message Properties

The message property fields are similar to header fields described previously in the Set JMS Headers action, except these fields are set exclusively by the consumer application. When a client receives a message, the properties are in read-only mode. If a client tries to modify any of the properties, a MessageNotWriteableException will be thrown.

The properties are standard Java name/value pairs. The property names must conform to the message selector syntax specifications defined in the Message interface.

Property fields are most often used for message selection and filtering. By using a property field, a message consumer can interrogate the property field and perform message filtering and selection.

When this action is configured for a proxy API, Mediator uses the message properties to authenticate client requests before submitting to the native APIs.

To use this action the following prerequisites must be met:

• Create an alias to a JNDI Provider (in the Integration Server Administrator, go to Settings > Web Services). For the procedure, see the section Creating a JNDI Provider Alias in the document Administering webMethods Integration Server.

• To establish an active connection between Integration Server and the JMS provider, you must configure Integration Server to use a JMS connection alias (in the Integration Server Administrator, go to Settings > Messaging > JMS Settings). For the procedure, see the section Creating a JMS Connection Alias in the document Administering webMethods Integration Server.

• Create a WS (Web Service) endpoint alias for provider Web Service Descriptor (WSD) that uses a JMS binder. In the Integration Server Administrator, navigate to Settings > Web Services and complete the Alias Name, Description, Descriptor Type, and Transport Type fields, as described in the section Creating an Endpoint Alias for a Provider Web Service Descriptor for Use with JMS in the document Administering webMethods Integration Server.

• Configure a WS (Web Service) endpoint trigger (in the Integration Server Administrator, go to Settings > Messaging > JMS Trigger Management). For the procedure, see the section Editing WS Endpoint Triggers in the document Administering webMethods Integration Server.

• Create a WS (Web Service) endpoint alias for consumer Web Service Descriptor (WSD) that has a JMS binder. In the Integration Server Administrator, navigate to Settings > Web Services and complete the Alias Name, Description, Descriptor Type, and Transport Type fields, as described in the section Creating an Endpoint Alias for a Consumer Web Service Descriptor for Use with JMS in the document Administering webMethods Integration Server.

Input Parameters

Name

Value

Straight Through Routing

This action routes the incoming requests to the Mediator directly to the native API.

1. Configure Integration Server: Set up keystores and truststores in Integration Server, as described in Securing Communications with the Server in the document Administering webMethods Integration Server.

2. Configure Mediator: In the Integration Server Administrator, navigate to Solutions > Mediator > Administration > General and complete the IS Keystore Name, IS Truststore Name and Alias (signing) fields, as described in Keystore Configuration in the document Administering WebMethods Mediator.

When this action is configured for an API, Mediator ensures that requests from the client are parsed directly to the native API you specify. This action also includes a set of configuration properties for the Mediator to process the incoming requests for the native API.

Input Parameters

Field	Description
Route To	URI. Mandatory. Enter the URL of the native API endpoint to route the request to in case all routing rules evaluate to False. For example: http://mycontainer/creditCheckService Click the Configure Endpoint Properties icon (next to the Route To field) if you want to configure a set of properties for the specified endpoint. Alternatively, Mediator offers "Local Optimization" capability if the native endpoint is hosted on the same Integration Server as webMethods Mediator. With local optimization, API invocation happens in-memory and not through a network hop. Specify the native API in either of the following forms: local://<Service-full-path> OR local://<server>:<port>/ws/<Service-full-path> For example: local://MyAPIFolder:MyLocalAPI which points to the endpoint API MyLocalAPI which is present under the folder MyAPIFolder in Integration Server.
Configure Endpoint Properties icon	Optional. This icon displays the Endpoint Properties dialog box that enables you to configure a set of properties for the Mediator to route incoming requests to the native API as follows:
	SOAP Optimization Method	For SOAP-based APIs. Specifies the optimization methods that Mediator can use to parse SOAP requests to the native API.
		Value	Description
		MTOM	Mediator will use the Message Transmission Optimization Mechanism (MTOM) to parse SOAP requests to the API.
		SwA	Mediator will use the SOAP with Attachment (SwA) technique to parse SOAP requests to the API.
		None	Default. Mediator will not use any optimization method to parse the SOAP requests to the API.
		Notes: Bridging between SwA and MTOM is not supported. If a client sends a SwA request, Mediator can only forward SwA to the native API. The same is true for MTOM, and applies to responses received from the native API. That is, a SwA or MTOM response received by Mediator from a native API will be forwarded to the client using the same format it received. When sending SOAP requests that do not contain a MTOM or SWA attachment to a native API that returns an MTOM or SWA response, the request 'Accept' header must be set to 'multipart/related'. This is necessary so Mediator knows how to parse the response properly.
	HTTP Connection Timeout	Number. Optional. Specifies the time interval (in seconds) after which a connection attempt will timeout. If a value 0 is specified (or if the value is not specified), Mediator will use the value specified in the Connection Timeout field (go to Integration Server Administrator > Settings > Extended). Default: 30 seconds.
	Read Timeout	Number. Optional. Specifies the time interval (in seconds) after which a socket read attempt will timeout. If a value 0 is specified (or if the value is not specified), Mediator will use the value specified in the Read Timeout field (Open the Integration Server Administrator. Go to > Settings > Extended.). Default: 30 seconds.
	SSL Configuration	Optional. To enable SSL client authentication that Mediator will use to authenticate incoming requests for the native API, you must specify values for both the Client Certificate Alias field and the IS Keystore Alias field. If you specify a value for only one of these fields, a deployment error will occur. Note: SSL client authentication is optional; you may leave both fields blank. Prerequisite: You must set up the key alias and keystore properties in the Integration Server. For the procedure, see the section Securing Communications with the Server in the documentwebMethods Integration Server Administrator’s Guide. You will use these properties to specify the following fields:
		Value	Description
		Client Certificate Alias	Mandatory. The client's private key to be used for performing SSL client authentication.
		IS Keystore Alias	Mandatory. 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.
	WS Security Header	For SOAP-based APIs. Indicates whether Mediator should pass the WS-Security headers of the incoming requests to the native API.
		Value	Description
		Remove processed security headers	Default. Removes the security header if it is processed by Mediator (i.e., if Mediator processes the header according to the API's security run-time action). Note that Mediator will not remove the security header if both of the following conditions are true: 1) Mediator did not process the security header, and 2) the mustUnderstand attribute of the security header is 0/false).
		Pass all security headers	Passes the security header, even if it is processed by Mediator (i.e., even if Mediator processes the header according to the API's security action).

Throttling Traffic Optimization

This action limits the number of API invocations during a specified time interval, and sends alerts to a specified destination when the performance conditions are violated.

Reasons for limiting the API invocation traffic include:

• To avoid overloading the back-end services and their infrastructure.

• To limit specific clients in terms of resource usage (that is, you can use the "Monitor Service Level Agreement" action to monitor performance conditions for a particular client, together with "Throttle API Usage" to limit the resource usage).

• To shield vulnerable servers, services, and even specific operations.

• For API consumption metering (billable pay-per-use APIs).

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

Soft Limit	Number Optional. The maximum number of invocations allowed per Interval Value before issuing an alert. Reaching the soft limit will not affect further processing of requests (until the Hard Limit is reached). Note: The limit is reached when the total number of invocations coming from all all the clients (specified in the Limit Traffic for Applications field) reaches the limit. Soft Limit is computed in an asynchronous manner; thus when multiple requests are made at the same time, it may be possible that the Soft Limit alert will not be strictly accurate.
Alert Message for Soft Limit	String. Optional. A text message to include in the soft limit alert.
Hard Limit	Required. The maximum number of invocations allowed per Interval Value before stopping the processing of further requests and issuing an alert. Typically, this number should be higher than the soft limit. Note: The limit is reached when the total number of invocations coming from all all the clients (specified in the Limit Traffic for Consumers field) reaches the limit. Hard Limit is computed in an asynchronous manner; thus when multiple requests are made at the same time, it may be possible that the Hard Limit alert will not be strictly accurate.
Alert Message for Hard Limit	String. Optional. A text message to include in the hard limit alert.
Alert for Consumer Applications	String. The consumer application(s) that this action applies to. To specify multiple consumers, use the button to add rows, or select Any Consumer to apply this action to any consumer application.
Alert Interval	String. The amount and unit (Minutes, Hours, Days or Weeks) of time for the soft limit and hard limit to be reached.
Alert Frequency	String. Frequency to issue alerts.
	Value	Description
	Every Time	Default. Issues an alert every time the specified condition is violated.
	Only Once	Issues an alert only the first time the specified condition is violated.
Alert Destination	String. Optional. A place to log the alerts. 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 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.
	EDA	Mediator can use EDA to log the payloads to a database. Prerequisite: You must configure the EDA destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > EDA). For the procedure, see the section EDA Configuration for Publishing Run-Time Events and Metrics in the document Administering webMethods Mediator.

Validate Schema

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

Mediator can enforce this action for messages sent between APIs. When this action is configured for a proxy API, Mediator validates XML request messages, response messages, or both, against the XML schema referenced in the WSDL.

Input Parameters

Request

Response

Important:
Be aware that Mediator does not remove wsu:Id attributes that may have been added to a request by a client 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 API so that the requests and responses are passed to an XSL transformation file that removes the wsu:Id attribute.

www.softwareag.com

Copyright © 2005-2014 Software AG, Darmstadt, Germany.

SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT