Policies overview

Policies can control particular node properties, such as connection credentials, and certain aspects of message flow behavior, including flow rate. Policies provide a shared and managed definition that you can reuse.

Policies contain defined operational properties, and enable the following user capabilities:

Developers can use policies to control runtime behavior and reuse configuration information in multiple places, therefore eliminating duplication of effort. Where policies are used to override message flow properties at run time, information like connection details can be updated without having to update message flows.
Administrators can use policies to define key configuration data for each environment and to override properties that were specified by message flow developers. This ability is useful if connection details are different for different environments (such as development, test, and production systems.) Administrators can also update policies with sensitive data that might not be available to developers.
Operators can use policies to monitor and modify configuration data dynamically.

You can attach a policy to one or more entities that you want to control, such as message flows, message flow nodes, or integration servers. For example, if you add an AggregateControl node to your flow, the Aggregate name property on the message flow node can be used to associate fan-in and fan-out flows. Alternatively, it can specify the name of an Aggregation policy. If you specify just the name of the policy in the Aggregate name property, the policy is retrieved from the default policy project. Alternatively, specify a policy in a different policy project by using the following format in the message flow node property:

{PolicyProjectName}:PolicyName

If the named policy cannot be found, the message flow cannot be started.

You can also reference a policy from a JavaCompute node by using the name of the policy in the Java code; for example,

MbPolicy myUserPolicy = getPolicy("UserDefined", "{MyPolicyProject}:MyUserPolicy");

Policies are XML documents, which are defined by an XML Schema Definition (Policy.xsd) that is found in the default installation directory. For example, on Windows, you can find the policy definition file at C:\Program Files\IBM\ACE\version\common\schemas\Policy.

Configurable services

Policies replace configurable services in App Connect Enterprise. You can migrate your existing configurable services to policies by using the mqsiextractcomponents command (see mqsiextractcomponents command).

The mqsicreateconfigurableservice command is deprecated in App Connect Enterprise, and no longer creates configurable services. However, if you use the mqsicreateconfigurableservice command in your IBM Integration Bus scripts, this command creates equivalent policies (where supported) in App Connect Enterprise (see mqsicreateconfigurableservice command (deprecated)).

Policies that are created by the mqsicreateconfigurableservice command are created in the default policy project (DefaultPolicies) and are associated with an integration node. These policies are inherited by all integration servers on that integration node. You can override a policy that is inherited by an integration server from the integration node by deploying an updated version of the policy to that integration server. Alternatively, you can put an updated policy in the overrides subdirectory of the integration server work directory (see Order of precedence for overrides).

Policy projects

When you run the mqsicreateworkdir command, a configuration file that is called server.conf.yaml is created, which contains default settings for your integration server. This configuration file defines a default policy project, which is used to store unqualified policies. When you create a policy in the IBM App Connect Enterprise Toolkit, you must create it in a policy project. When you reference a policy from a message flow or message flow node, use the policy name if the policy is in the default policy project. If the policy is in a different policy project, prefix the name of the policy with the name of the policy project, with the format {policyProject}:PolicyName. You can use policy projects to organize your resources, and you can add as many policies to a policy project as you want. For example, your policy project might organize policies in the following ways:

Your policy project might contain all policies for a particular integration server.
The project might contain all policies of a particular type (for example, all JDBC Providers policies) for an integration server.
It might contain all policies for a specific application.

For more information about creating policies, see Creating policies with the IBM App Connect Enterprise Toolkit.

Default policy project and policies

A default policy project that is called DefaultPolicies is defined in the server.conf.yaml file for the integration server. Policies that are created by the mqsicreateconfigurableservice command are created in this default policy project. You can also specify certain default policies to control resources on an integration server by setting them in the server.conf.yaml file for that integration server (see Configuring an integration server by modifying the server.conf.yaml file). The following excerpt from the server.conf.yaml file shows that you can provide default policies that control the following settings:

Specify a default Monitoring Profile policy to configure monitoring for message flows. For more information, see Monitoring profiles.

Defaults:
 defaultApplication: ''       # Name a default application under which independent resources will be placed
 policyProject: 'DefaultPolicies'   # Name of the Policy project that will be used for unqualified Policy references
 Policies:
   # Set default policy names, optionally qualified with a policy project as {policy project}:name
      monitoringProfile: ''       # Default Monitoring profile

After you create the policy, set the name of the policy in the server.conf.yaml file. If the default policy is in the default policy project, you do not need to specify the name of the policy project. If the default policy is in a non-default policy project, qualify the name of the policy with the name of the policy project ({policyProject}:PolicyName).

Policy deployment

You deploy policies in policy projects in an independent BAR file, or in a BAR file with the associated message flow. As an administrator, you can also override deployed policies by using the overrides subdirectory of the integration server. For more information, see Overriding deployed policies at run time with the overrides directory. If a policy name is set specifically on a message flow or message flow node, you must deploy the policy before the message flow can be started. If a policy is not specified explicitly on a message flow or message flow node, you must deploy the policy before or with the message flow.

You can change and redeploy some types of policy after they are deployed, by redeploying the policy project. When you redeploy the policy project, all message flows that are using the policy are stopped and restarted. For more information about the types of policy that can be redeployed, see Policy properties.

For other types of policy, which cannot be redeployed, you must delete all deployed resources from the integration server by using the IBM App Connect Enterprise Toolkit or the -m parameter on the mqsideploy command. Then, you must deploy a new version of the policy project and message flows. Alternatively, you can put an updated copy of the policy in the overrides subdirectory of the integration server work directory, then restart the integration server to pick up the new values.

Deployed policies are shown in the run subdirectory of the integration server work directory, within a subdirectory that has the name of the policy project. You can see the properties of deployed policies in the Integration Explorer of the IBM App Connect Enterprise Toolkit or on the Policies tab of the web user interface (see Accessing the web user interface). You can also see which properties are being used by the deployed flow at run time by using the REST API or web user interface.

For more information about policy deployment, see "What to do next" in Creating policies with the IBM App Connect Enterprise Toolkit.

Order of precedence for overrides

You can override a deployed policy by putting an updated policy project in the overrides subdirectory of the integration server work directory and restarting the integration server (see Overriding deployed policies at run time with the overrides directory).

The following precedence rules apply to operational property values:

The properties in HTTP or HTTPS Connector policies completely override those properties that were set by the HTTP or HTTPS Connector in the ResourceManagers section of the server.conf.yaml file.
A value in a policy in the overrides subdirectory of the work directory overrides a value in a deployed policy.
A value in a deployed policy overrides a value in an integration node-level policy that is created by the mqsicreateconfigurableservice command .
A value in an integration node-level policy takes precedence over a value that is overridden in a BAR file or set on the node.
When no policy exists for an operational property value, the value that is overridden in a BAR file takes precedence over the value that is set on the node.
When no policy or BAR file override exists for an operational property value, the value that is set on the node takes precedence.

Tip: If you designed your message flow to include a local environment override, any property value that is set by the local environment override overrides a value that is set by a policy, a BAR file override, or on the node.

Policies replace configurable services in IBM App Connect Enterprise Version 11.0. In previous versions, if you used a configurable service to override node properties at run time, a blank property in a configurable service overrode a node property with an empty value. However, when you use a policy, an empty property in a policy does not override the node property with an empty value. In this case, the value that is set by the node property is used.

Policy types

In addition to the policy types that are listed in Policy properties, monitoring profiles and policy sets and bindings are forms of policy that can be used to override properties at run time. For more information about these types of policy, see Monitoring profiles and Policy sets.