Software AG Products 10.5 | Using CentraSite | Runtime Governance | Virtual Service Asset Management | Managing Virtual Service Assets through CentraSite Business UI | General Procedures across Assets | Assigning Run-Time Actions to a Virtual Service
 
Assigning Run-Time Actions to a Virtual Service
This section describes how to use the Virtualize action to configure the policy actions for the Virtual Service.
Note:
This section is not applicable if the CentraSite run-time aspects are not enabled. By default, run-time aspects configured from CentraSite are disabled. However, you can enable them if required. To enable the CentraSite run-time aspects, see Enabling CentraSite Run-Time Aspects.
To access the Virtualize action, you must have the following roles or permissions:
*CentraSite Administrator
*Organization Administrator
*Asset Provider
*Instance-level Modify permission on the Native Service or Virtual Service
In addition to the above described roles and permissions for accessing the Virtualize action in the details page of a particular Virtual Service, make sure that you have the specific API Runtime Provider role for reconfiguring the run-time actions of the Virtual Services.
Before You Begin
The Virtualize <Service_Name> (Step 2 of 3) wizard specifies the list of actions to govern the run-time behavior for the Virtual Service.
When you define the actions for a Virtual Service, keep the following points in mind:
*A run-time policy configuration is valid if:
*it consists of at least one action in each of these stages - Receive and Routing.
*there is a valid endpoint configured in the Route to field of the Routing action.
*When you drag an action from the Policy Actions area, the respective step in the Message Flow area highlights where the action fits in, thus making the navigation from Policy Actions area to the Message Flow area more intuitive.
*Not all stages support the full set of actions. Every action happens only within a respective step. For example, the “Evaluate” actions occur only on the Enforce stage; while the “Routing” actions occur only on the Routing stage.
*Mediator executes the policy actions configured for the Virtual Service in a predefined order.
*Some actions are mutually dependent. That is, a specific action must be used in conjunction with another particular action. For example, a Message Flow area that includes the Set JMS Headers action must also include the JMS Routing Rule action.
*Some actions are mutually exclusive. That is, a specific action cannot be used in conjunction with another particular action. For example, a Message Flow area that includes the JMS Routing Rule action cannot include the Straight Through Routing action.
*Some of the actions are allowed to appear multiple times within a message flow step.
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.
*You can view a tooltip text for any accordion by moving the cursor over the accordion name. The tooltip text gives a summary of the accordion’s purpose.
*If you modify the policy action for a Virtual Service which is already published to a Mediator gateway, CentraSite automatically republishes the modified Virtual Service.
*If you want to enable the REST support for a Virtual Web Service, ensure that the Enable REST Support action is included in the Receive stage for the Service.
If you include the Enable REST Support policy action in a SOAP Service configuration, clients who can only send REST requests can now invoke a REST-enabled SOAP Service using both a SOAP request and a REST request in Mediator, and using a REST request in API Portal.
*If you are using Mediator as your gateway, you must include at least one Evaluate * action in order to identify or validate the consumers.
*Be aware that actions from the WS-I category cannot be combined with other types of actions. Also be aware that when you add a WS-I action to the action list, CentraSite will automatically add dependent actions to the list as necessary.
*When you configure certain policy actions, for example, a Context Based Routing action, a Throttling Traffic Optimization action, or a Monitor Service Level Agreement (SLA) action, the action's Configure dialog would exhibit the following behavior:
*If the API provider has configured API Key Consumption Settings for API Key and/or OAuth2 token authentication, the Consumer Applications drop-down list displays the available the consumer applications that are identified by asset instances of the API Key and/or OAuth2 Client type and that are linked to the API, and all of the consumer applications that are identified by asset instances of the type Application in the CentraSite registry.
*If the API provider has not configured API Key Consumption Settings for API Key and/or OAuth2 token authentication, the Consumer Applications drop-down lists all of the consumer applications that are identified by asset instances of the type Application in the CentraSite registry.
Ways in Which You Assign Run-Time Actions to Virtual Services
You can assign run-time actions to an existing Virtual Service in the following two ways:
*Using the Virtualize action in the details page of the Native Service.
*Using the Virtualize action in the details page of the Virtual Service.