Policy Models
Policy Model Basic Principles - Family Policies
A policy model is made up of nodes and connections that define the policy logic. In order to build a functioning policy model, you must understand several basic principles.
Configuring a Policy Model
The following principles apply to working with a policy model:
- The initial nodes in a policy model, that is, nodes with no predecessors, must be Input nodes other than Query nodes.
- A family policy must contain one Current Entity node for entity families, or one Current Relationship node for relationship families.
- A node can use an input from any predecessor node in the same logic path, even if the nodes are not directly connected.
- Any number of nodes can use an input from the same predecessor node.
- With the exception of the Or node and the Case node, a node will be executed only when all necessary preceding nodes have been successfully executed.
- A policy model can often be arranged in various configurations without impacting the execution results. You may want to arrange the policy model in the configuration that provides the best visual representation of the policy.
- A family policy cannot be saved if it contains any errors.
-
Connections that start at a Condition or Logic node can be configured to create separate logic paths in a policy model. Specifically:
- If the connection property is Yes, the corresponding path will be followed when the logical result of the Condition of Logic node is yes. If you do not configure a logic path for a connection, a Yes path is assumed but does not appear on the model.
- If the connection property is No, the corresponding path will be followed when the logical result of the Condition or Logic node is no.
Configuring Node Properties
-
Most nodes have outputs that successor nodes can use as inputs. You must specify inputs for each successor node using the Properties window that appears when you select the node in the policy model.
Note: Outputs and inputs may represent either a single value or a collection of values. The types of outputs that each node generates and the types of inputs that each node accepts is different for each node. When building a policy model, you must use corresponding input and output types. -
Any numeric values entered in Calculation nodes should be entered in the format matching the user's culture setting. For example, a user with German culture would enter 4,5 to represent four and a half, whereas a user with US-English culture would enter 4.5.
- There are specific formats in which you can enter dates and times and amounts of time (that is, time spans). Refer to the respective topics for details.
- When using a policy node to update values in a record:
- If a field has complex behavior defined by field-level rules (for example, rules for valid values) and field-level behaviors, this behavior will not be reflected in the Properties window or detected by policy validation. Therefore, you are responsible for ensuring that the values you specify are valid according to any baseline or custom field-level rules for the corresponding field.
- If a field value is defined by a system code, the value that you specify in the corresponding section must be the system code, not the value that is displayed to the end user.
Policy Model Principles Illustrated
The principles for working with a policy model can be illustrated through the following example model.
In this example model, the Reading in Error node represents records in the Reading in Error family. When this policy is executed, if the Comment field in the Reading in Error record that triggered the policy is something other than test, the APM system will send an email message to the email address that is specified in the Properties window for the Email Contact node.
The following table explains each of the policy model basic principles in the context of this example.
Policy Model Principle | Example |
---|---|
The initial nodes in a policy model, that is, nodes with no predecessors, must be Input nodes other than Query nodes.
A family policy must contain one Current Entity node for entity families, or one Current Relationship node for relationship families. |
The Reading in Error node is a Current Entity node, which is a type of Input node. The Current Entity node is required for an entity family policy. |
Most nodes have outputs that successor nodes can use as inputs. You must specify inputs for each successor node using the Properties window that appears when you select the node in the policy model. Note: Outputs and inputs may represent either a single value or a collection of values. The types of outputs that each node generates and the types of inputs that each node accepts is different for each node. When building a policy model, you must use corresponding input and output types.
|
The output Comment from the Reading in Error node is used as an input to the Condition node. This output represents a single value, which corresponds to the type of input that the Condition node accepts. The value test is used as the second input to the Condition node, but it is not an output from another node. Instead, it is a constant value that is specified directly in the Properties window for the Condition node. |
A node can use an input from any predecessor node in the same logic path, even if the nodes are not directly connected. | The Email Contact node can use an input from the Reading in Error node even though the two nodes are not directly connected. |
Any number of nodes can use an input from the same predecessor node. | The Email Contact node and the Condition node can both use inputs from the Reading in Error node. |
With the exception of the Or node and the Case node, a node will be executed only when all necessary preceding nodes have been successfully executed. |
The Email Contact node will be executed only when all of the nodes preceding it have been successfully executed. If, for example, the condition defined in the Condition node was not met, the Email Contact node would not be executed. |
A policy model can often be arranged in various configurations without impacting the execution results. You may want to arrange the policy model in the configuration that provides the best visual representation of the policy. |
The execution results of the policy would be identical even if the nodes were connected at different points. |
Connections that start at a Condition or Logic
node can be configured to create separate logic paths in a
policy model. Specifically:
|
A property is not defined for the connection between the Condition node and the Email Contact node, therefore, a value of Yes is assumed. This means that an email message is sent only if the preceding condition is true. If the condition is false, policy execution will not continue. |
Add Nodes to the Model Canvas in Family Policies
Before You Begin
- Create a policy.
- Make sure you understand the basic principles of working with a policy model.
Procedure
What To Do Next
Enable Grid in Model Canvas
About This Task
Procedure
Connect Nodes in a Policy Model in Family Policies
Before You Begin
- Make sure you understand the basic principles of working with a policy model.
- Add at least two nodes to the model canvas.
- Note the following limitations that apply to connections:
- You cannot add connections in a circular path (e.g., if Node 1 is connected to Node 2, and Node 2 is connected to Node 3, you cannot connect Node 3 to Node 1).
- You cannot connect a node to itself.
- You cannot connect a node to same node more than once.
Procedure
What To Do Next
Configure Node Properties in Family Policies
Before You Begin
- Make sure you understand the basic principles of working with a policy model.
- Add and connect nodes in the policy model.
Procedure
What To Do Next
Define Input Values in Family Policies
Before You Begin
- Make sure you understand the basic principles of working with a policy model.
- If you want the input value to be defined by a predecessor node, the nodes must be connected, either directly or indirectly.
About This Task
Procedure
- Specify a user-defined constant value:
- Specify a value or collection that is an output of a predecessor node:
Example
To illustrate the different ways to define input values, consider the following nodes and connections.
In this example, the Equipment Entity node is connected to an Equal Condition node. The Properties window for the Condition node, therefore, allows you to select the Equipment family and one of its fields. As shown in the following image:
- The icon appears in the first input section, indicating that the input is defined by a predecessor node.
- The icon appears in the second input section, indicating that the input is a user-defined constant value.
Together, the Equipment Entity node and the Condition node to which it is connected indicate that an email message should be sent when an Equipment record has a value of A in the Criticality Indicator field.
What To Do Next
Configure Logic Paths in Family Policies
Before You Begin
- Make sure you understand the basic principles of working with a policy model.
- Add and connect nodes in the policy model.
About This Task
Procedure
Example
Consider the following policy model.
- The Condition node evaluates the DA Reading Value that is associated with the OPC Tag record to determine if it is greater than or equal to 900.
- The Condition node is connected to the following successor nodes:
- Email Analyst (through the Yes connection)
- Create Recommendation (through the No connection)
- If the DA Reading Value is greater than or equal to 900, an email message will be sent. This logic is determined by the Yes logic path specified for the connection to the Email Analyst node.
- If the DA Reading Value is not greater than or equal to 900, a Policy Recommendation record will be created. This logic is determined by the No logic path specified for the connection to the Create Recommendation node.
What To Do Next
Copy and Paste Nodes and Connections in Family Policies
Before You Begin
- Make sure you understand the basic principles of working with a policy model.
-
Note:
- If you copy a node that contains a mapped field value from another node, the mapped field value will not be copied unless you also copy the node from which the values are mapped and the connector node between the two nodes.
- Connections will be copied only if you select the connection and both nodes that it connects.
- After you paste a node that requires a unique name (e.g., Point Value node), you must change the name of the copied node before you can save the policy.
- You cannot copy nodes and connections from one policy to another.