Modeling Behaviors

9 Modeling Behaviors

This chapter describes how to model behaviors in an Oracle Communications Order and Service Management (OSM) solution.

Modeling Behaviors Overview

You can use behaviors to specify how OSM manages data. For example:

You can specify the maximum allowed number of characters for text string data.
You can add the values of multiple fields and display the sum in another field.
You can specify the minimum and maximum times that a data element can be used in an order. For example, an order might require that exactly two IP addresses are added.

You can model behaviors in tasks and in orders. Figure 9-1 shows how behaviors are modeled in a task that enters payment information. In this figure, the field that shows the payment total uses two behaviors:

A Calculation behavior that adds values in multiple other fields to create the total payment value.
A Read Only behavior that makes the field read-only in the Task web client.

Note:

The examples are for illustrative purposes only; OSM is not typically used for payment handling.

Figure 9-1 Behaviors Used in a Task

Description of "Figure 9-1 Behaviors Used in a Task"

Figure 9-2 shows a behavior modeled in an order. This behavior is used by an order to display a tool tip for the payment information field.

Figure 9-2 Information Behavior Modeled in Oracle Communications Design Studio

Description of "Figure 9-2 Information Behavior Modeled in Oracle Communications Design Studio"

Table 9-1 lists the OSM behaviors.

Table 9-1 OSM Behaviors

Behavior Name	Descriptions
Calculation	Computes the value of a field value based on a formula that references order data. See "Using the Calculation Behavior" for more information.
Constraint	Specifies a condition that must be met for the data to be considered valid. See "Using the Constraint Behavior to Validate Data" for more information.
Data Instance	Declares an instance that can be used by other behaviors. See "Using the Data Instance Behavior to Retrieve and Store Data" for more information.
Event	Specifies an action that is performed when data is modified. See "Using the Event Behavior to Re-evaluate Data" for more information.
Information	Specifies the label, hint, and help information for the data element instance. See "Using the Information Behavior to Display Data and Online Help" for more information.
Lookup	Specifies a set of dynamically generated choices from which you can select. See "Using the Lookup Behavior to Display Data Selection Lists" for more information.
Read Only	Specifies whether a value can be modified or not. See "Using the Read-Only Behavior" for more information.
Relevant	Specifies whether data is visible or hidden. See "Using the Relevant Behavior to Specify if Data Should Be Displayed in the Web Client" for more information.
Style	Specifies the visual appearance of fields. See "Using the Style Behavior to Specify How to Display Data in the Task Web Client" for more information.

About Behavior Evaluation

It is possible that multiple behaviors can be applied to the same data. At run-time, OSM determines which behavior should be applied by evaluating the conditions defined for behaviors using a combination of server rules and behavior attributes that you model by using Design Studio configuration options. The following configuration options affect the manner in which OSM evaluates behaviors at run-time:

The level at which you define the behavior. See "Evaluating Behavior Levels" for more information.
The manner in which you define the Design Studio Override and Final configuration options. See "Evaluating Design Studio Final and Override Options" for more information.
The type of behavior defined for the element. See "Evaluating Behavior Type Precedence and Sequence" for more information.
Whether multiple behaviors of the same type are defined for an element at the same level.

Note:

The style behavior is the only behavior applied to Redo, Undo, and Do Nothing compensation strategies and the historical order perspective displayed in the Task web client. See "Modeling Compensation for Tasks" for more information about compensation strategies and the historical order perspective.

Evaluating Behavior Levels

In Design Studio, you can create behaviors for data nodes at three levels:

Data element level (most general)
Order level (more specific)
Task level (most specific)

OSM evaluates behaviors from the general level to the specific level. For example, OSM evaluates behavior conditions defined at the data element level first, and evaluates behaviors defined for data nodes at the task level last. At run-time, OSM determines which level to use for a behavior type and data node combination and evaluates rules from that level only.

For example, consider that you create a Calculation behavior at the data element level, and for the same data node you create a Calculation behavior at the order level. In this scenario, OSM would never evaluate the conditions defined for the Calculate behavior at the order level (unless you force evaluation using the Override or Final options), even if all of the conditions defined for the behavior at the data element level evaluate to false.

OSM does, however, evaluate different types of behaviors defined for a data node at different levels. For example, if for the same data node you define a Calculation behavior at the data element level and a Constraint behavior at the order level, OSM evaluates the conditions for both behaviors at run-time.

Note:

The Constraint behavior is an exception to the way in which behaviors are evaluated. When the run-time environment evaluates Constraint behaviors, it evaluates all of them, regardless of the level at which they are declared.

Evaluating Design Studio Final and Override Options

You can force local, specific exceptions to the way behaviors are evaluated for a given node by selecting the Override and Final check boxes on the appropriate Properties view Behaviors tab Details subtab in Design Studio. You can select the Override attribute to allow the behavior to take precedence over any other behavior:

Of the same type
For the same node
Declared at the same or more general level

For example, consider that you have a data element called customer that you declare twice: at the data element level and at the task level. For each occurrence of customer, you create a behavior called styleBehaviorType. At the specific task level, you select the behavior's Override check box. At run-time, OSM evaluates the behavior conditions defined at the task level, as the task-level version of styleBehaviorType overrides the data element-level version of the same behavior type.

Note:

Override does not function if the behavior that you are trying to override has the Final check box selected.

When selected, the Final check box prevents another behavior of the same type, for the same node, declared at the same or more specific level, from overriding that behavior.

For example, you define the element customer at the data dictionary level (highest), and add it at the task level (lowest). For each occurrence of customer, you define a Style behavior. On the data dictionary level (most general) of the behavior definition, you select the Final check box. On the task level (lowest) of the behavior definition, you select the Override check box. When OSM evaluates the behaviors, the selection of the Final check box at the data dictionary level prevents the task level (lowest) definition of the Style behavior from overriding the data dictionary level (highest) definition of the behavior.

Evaluating Behavior Type Precedence and Sequence

OSM automatically evaluates behaviors whenever you retrieve, save, or transition an order. OSM evaluates the behaviors in a specific nested sequence, as outlined below:

The system evaluates all behaviors for a given node before moving to the next node in the order.

The next node in the order is based on a depth first, left-to-right traversal.

Figure 9-3 shows the element selection order.

Figure 9-3 Element Selection

Description of "Figure 9-3 Element Selection"
Behaviors within a given node are evaluated based on the following precedence of type:
- 1st: Calculate
- 2nd: Style
- 3rd: Information
- 4th: Relevant
- 5th: Lookup
- 6th: Constraint
- 7th: Read-only
- 8th: Event
Note:

Relevant rules can prevent other rules from being evaluated. For example, if the Relevant rule of a data node evaluates to false, then rule types with a precedence lower than the Relevant rule are not evaluated (the Lookup, Constraint, Read-only, and Event rules). Additionally, if a data node's Relevant rule evaluates to false, no rule evaluation is done for any descendants of that node.
Within an order, within an element, within a specific behavior type, all behaviors defined at a specific data level are evaluated before moving to the next data level.

The evaluation process prioritizes data levels, which are evaluated in the following order:
- Data dictionary level
- Order level
- Task level
Behaviors defined on a task can override behaviors defined on an order if you have enabled the behavior's Override option at the task level and if you have disabled the behavior's Final option at the order level.

Note:

The Constraint behavior is an exception to the way behaviors are evaluated: When OSM evaluates Constraint behaviors, it evaluates all of them, regardless of the level at which they are defined.

Evaluation Process

Within an order, within an element, within a behavior type, within a data level, the evaluation proceeds as follows:

Is the behavior enabled?
- If the behavior is enabled, the final and override options are evaluated simultaneously.
- If the behavior is not enabled, the behavior is not applied.
Is the behavior finalized or overridden?
- If the behavior is not finalized and not overridden at a lower level, the condition defined for the behavior is evaluated.
- If the behavior is finalized and not overridden at a lower level, the behavior is final and the condition defined for the behavior is evaluated.
- If the behavior is finalized and overridden at a lower level, the override has no affect; the behavior is final and the condition defined for the behavior is evaluated.
- If the behavior is not finalized and is overridden at a lower level, the condition defined for the overridden behavior is evaluated (not the condition defined for the behavior that is currently being evaluated). If the condition is met, the overridden behavior is applied.
- If the behavior is not finalized and is overridden by more than one lower level, the condition defined for the lowest level overridden behavior is evaluated (not the condition defined for the behavior that is currently being evaluated). If the condition is met, the overridden behavior is applied.
Is the condition defined for the behavior met?
- If the condition is met, the behavior is applied.
- If the condition is not met, the behavior is not applied.
  
  Note:
  
  If you define two or more behaviors for an element at the same level, to avoid unpredictable behavior you should define mutually exclusive conditions. OSM does not guarantee the order of evaluation for the same behavior types defined at the same level.
The evaluation process continues.
- If a condition is met, and a behavior is applied, the evaluation process no longer checks lower levels; it moves to the next occurrence of the behavior.
- If a condition is not met, the evaluation process continues with the next occurrence of this behavior type defined at this data level. If there are no more at this level, the evaluation process moves to the next lower level. If there are no lower levels, the evaluation process continues with the next occurrence of this behavior type defined at the highest level, and so on. When there are no more occurrences of the behavior type, the evaluation process moves to the next behavior type, and so on. When there are no more behavior types, the evaluation process moves to the next element.

When the evaluation process determines that a behavior is to be applied at a particular level, some behavior types stop evaluating behaviors of the same type, while others continue evaluating behaviors of the same type at that level for the same element.

For example, you define three behaviors of the same type on the same data element at the same level, and all go through the evaluation process ending with the condition being met (the behavior is applied). For behaviors that stop evaluating, only the first behavior is applied. For behaviors that continue evaluating, multiple behaviors of the same type may be applied, and their effect on the UI is cumulative.

The following behaviors stop evaluating behaviors of the same type after a condition is met and a behavior of the type is applied:

Calculation
Lookup

The following behaviors continue evaluating behaviors of the same type after a condition is met and a behavior of the type is applied:

Constraint
Event
Information
Read Only
Relevant
Style

Note:

The behaviors in both lists above are presented in alphabetical order, not in behavior type evaluation order.

For example, if three Constraint behaviors are defined, and all go through the evaluation process ending with the behavior being applied, all three Constraint violation messages display in OSM. In another example, if three Read Only behaviors are defined, if any of them get applied, the field is set to read-only (even if prior and/or subsequent Read Only behaviors evaluate to false). Style and Information behaviors are a bit more complicated in that they have multiple facets. The end result is the cumulative effect of these facets. For example, you can define hints and labels with an Information behavior. If one behavior has a hint and another behavior has a label, the end result is that both are applied. If two behaviors define hints, then the second behavior's hint is applied.

Evaluating Multiple Behaviors of Similar Type and Level

When modeling behaviors of the same type, at the same level, for the same data node, ensure that the conditions you define for each behavior are mutually exclusive. When evaluating behaviors of the same type and defined on the same data node and level, the OSM run-time server has no ability to guarantee a predicable order of evaluation. When modeling behaviors for a data node, when it's necessary to define behaviors of the same type at the same level, ensure that you configure conditions that do not rely on a specific order of evaluation.

Additionally, the OSM server evaluates the conditions of each behavior until the conditions of one behavior evaluate to true. Subsequently, OSM does not continue to evaluate any conditions defined for behaviors of the same type and for the same data node.

About Setting Conditions in Behaviors

Conditions enable you to specify when a behavior should function. You set a condition by defining an XPath expression. If the XPath expression evaluates to false at run time, the condition is not met and the behavior is not applied. If the XPath expression evaluates to true at run time, the condition is met and the behavior may or may not be applied, depending on the outcome of evaluation of the behavior at run time.

If no conditions are defined, OSM considers the condition to be met. If multiple conditions are defined, all conditions must evaluate to true for the condition to be met.

Note:

The Constraint behavior is the only exception to the way conditions are handled.

Constraint behaviors specify a condition that must be met for the data to be considered valid.

XPath Examples

This section provides XPath examples that are applicable to setting a condition on any behavior type.

This example shows a condition that evaluates to true when the value of myNumericField is less than 100, and evaluates to false when the value of myNumericField is 100 or greater:
```
../myNumericField<100
```
This example shows a condition that evaluates to true when the value of myTextField is populated, and evaluates to false when the value of myTextField is an empty String:
```
../myTextField!=""
```
This example shows a condition that evaluates to true when the value of all three fields are zero, and evaluates to false if any one of three fields are greater than or less than 0:
```
../myNumericField1=0 and myNumericField2=0 and myNumericField3=0
```

Using the Calculation Behavior

You use the Calculation behavior to calculate a field's value based on a formula that references other field values. You can perform numeric operations and string concatenations.

OSM supports the Calculation behavior in the Task web client and in the Order Management web client Data tab.

For example, you can use the following expression in a Calculation behavior to calculate the current balance for a customer:

../amount_owing - sum(../../payment_information/payment_amount)

In this example, the current balance displays the value from the amount_owing field after subtracting the value from the payment_amount field; the balance = (amount owed) - (amount paid).

Figure 9-4 shows an XPath expression that combines the first_name field and the last_name field. The Calculation behavior is applied to a field that contains the card-holder name field, where the first and last names are combined into a single field value.

Figure 9-4 Calculate Behavior Formula for Combining String Values

Description of "Figure 9-4 Calculate Behavior Formula for Combining String Values"

Calculation Behavior XPath Examples

The following examples show how to use XPath statements in the Calculation behavior.

This example shows how to set a constant value of 100 for a numeric field (whatever number you specify is the number that displays for the field):
```
100
```
This example shows how to prefix a constant value to a text field (whatever text you define is the text that displays along with the text value of the field):
```
append("any text here",../fieldName)
```
This example shows how to display a numeric field as a result of adding three other numeric fields:
```
../fieldName1 + ../fieldName2 + ../fieldName3
```
This example shows how to see the user name of the user who accepted a task:
```
/GetOrder.Response/AcceptedUserName
```

Calculation Behavior Overview

Table 9-2 shows Calculation behavior attributes.

Table 9-2 Calculation Behavior Attributes

Attributes	Value
Order of evaluation	1st
Default value	None
Applies to	All elements
Parent/child inheritance	Does not inherit (This applies to element relationships within a structure, which is different than the inheritance of behaviors between the data dictionary, order, and task levels.)

Using the Constraint Behavior to Validate Data

You can use the Constraint behavior to validate data that is entered in an order. For example:

Validate the format of a field. For example, 10 digits for a telephone number, 5 digits for a ZIP code, or an IP address format.
Validate the range of a field. For example, ensure that a numeric value is between 0 and 100.
Validate the field value is within a valid list.

In addition to specifying how data is validated, you can:

Configure messages that indicate the results of the validation; for example, a warning or error message.
Specify how the order should be processed if the validation fails; for example, stop processing or continue processing.

For example, you might want to ensure that value in a Payment Amount field is less than the amount owed and greater than 0. The Constraint behavior would include this condition:

. <= ../../account_information/amount_owing and . >= 0

The same Constraint behavior would include the following message to display if the behavior was not met:

concat('Invalid payment amount[',.,']. Payment must be greater than 0 and less than amount owing of [',../../account_information/amount_owing,']')

OSM supports constraint rules in the Task web client.

Displaying Constraint Behavior Error Messages

OSM only displays a Constraint behavior error message if there is a constraint violation caused by the failure of a Constraint behavior condition or by an exception that occurred during the behavior evaluation while you are attempting to either:

Save an order with invalid field content
Transition an order with invalid or null values

Otherwise, OSM cues you that a field requires some value by placing a red dot to the left of the field label.

Note:

The red dot behavior does not apply to read-only fields. If an error occurs in a read-only field (for example, a failed lookup prevents the display of data) OSM always displays an error message.

The red dot is the same UI element that OSM uses to alert you that a field is mandatory, as defined in the order template. If the field fails the constraint condition and is defined as mandatory, only one red dot appears.

Evaluating Constraint Behaviors

OSM always evaluates Constraint behaviors except when the element or parent element is not relevant, as defined through the Relevant behavior. OSM does not evaluate the Constraint behavior when the task to which the Constraint behavior is associated is at the rollback status. In cases when data is rolled back, it is understood that the Constraint behavior was already evaluated.

Constraint behavior evaluation is different from that of other behaviors. Constraint behaviors are evaluated only when one or more specified conditions evaluate to false. All other behaviors are either:

Always evaluated
Evaluated only when one or more specified conditions evaluate to true.

In addition, when OSM does evaluate Constraint behaviors, it always evaluates all of the Constraint behaviors, regardless of where they are defined. This is different from other types of behaviors, where only the first instance of each behavior is selected and applied. However, the Override and Final check boxes give you control over inheritance. See "Evaluating Design Studio Final and Override Options" for more information.

Using Task Statuses to Control Process Transitions

You can use task status Constraint values to determine how Constraint behavior violation severity return values affect whether or not a process can make a transition to the next task or activity. Task status Constraint values include:

Critical
Error
Warning
None
Valid

The task status Constraint value represents the highest allowable Constraint behavior violation value with which the task transition will be allowed to occur. When Update is clicked, in the Task web client Order editor, the transition action taken depends on the task status Constraint severity value in conjunction with the Constraint behavior violation severity level, if any.

For example, if the task status Constraint value is set to Error, then Error is the highest allowable Constraint behavior violation value with which the task can be transitioned. The task is not allowed to transition if a Constraint behavior violation of Critical occurs, but is allowed if an Error, a Warning, or a Valid Constraint violation occurs.

The following table explains whether task transition is allowed for all combinations of Constraint behavior violation severities and task status Constraint values.

Table 9-3 Constraint Behavior Actions

Task status Constraint value (highest allowable constraint violation):	Task transition allowed for Critical constraint violation?	Task transition allowed for Error constraint violation?	Task transition allowed for Warning constraint violation?	Task transition allowed for Valid constraint violation?
Critical	Yes	Yes	Yes	Yes
Error	No	Yes	Yes	Yes
Warning	No	No	Yes	Yes
Valid	No	No	No	Yes
None	No	No	No	No

Task Statuses and Constraint Behavior Violation Severity Levels

You can use task statuses in combination with Constraint behaviors to specify the conditions under which a process can make a transition to the next task or activity in the process.

You use Constraint behaviors to validate order data. For example, you can validate that a telephone number has 10 digits or ensure that a numeric value is between 0 and 100.

Constraint behaviors include a Display as violation severity level and a message to be displayed in the Task web client when a constraint behavior violation occurs. When Save is clicked in the Task web client Order editor, the save action taken depends on the constraint behavior violation severity level.

Table 9-4 Constraint Behavior Actions

Constraint behavior violation severity levels, from highest severity to lowest	Message display:	When Save is clicked:
Critical	OSM displays the message in bold red text, with the label "ERROR".	The data is not saved.
Error	OSM displays the message in red text, with the label "ERROR".	The data is saved.
Warning	OSM displays the message in yellow text, with the label "WARNING".	The data is saved.
Valid	OSM displays the message in green text, with the label "INFO".	The data is saved.

Constraint Behavior Overview

Table 9-5 shows Constraint behavior attributes.

Table 9-5 Constraint Behavior Attributes

Attributes	Value
Order of evaluation	6th
Default value	True
Applies to	All elements and structures
Parent/child inheritance	Does not inherit (This applies to element relationships within a structure, which is different than the inheritance of behaviors between the data dictionary, order, and task levels.)

Using the Data Instance Behavior to Retrieve and Store Data

You can use the Data Instance behavior to get data from external sources. For example, an order processor using the Task web client can retrieve a set of available ports in real time from an ADSL inventory system.

This behavior differs from all other behaviors in that it has no affect on the UI display of the element for which the behavior is defined. You can think of the Data Instance behavior as a “supporting" behavior because it provides functionality that can be used with other behaviors.

You can use the Data Instance behavior to:

Store data from an external system and make it accessible to other behaviors.
Store data that is defined in-line in an XML or XQuery and make it accessible to other behaviors.
Store data from OSM that is housed in multiple fields but commonly referenced collectively as a single field and make it accessible to other behaviors. For example, the fields first_name and last_name can be combined in a new data instance customer_name.

When you use the Data Instance behavior, you need to specify the data provider that you get data from (see "Using Data Providers to Retrieve Data" for more information). OSM supports several data providers; for example, Oracle Communications Unified Inventory Management (UIM), XML files, and data in the incoming customer order. You can also configure your own data provider.

See "About Mapping Order Items to Fulfillment Patterns" for an example of how to use a Data Instance behavior.

Evaluating Data Instance Behaviors

When a Data Instance behavior is defined for an element, regardless of the data level, the container is available to the element on all data levels. Because of this:

The Override and Final check boxes have no effect on the Data Instance behavior.
The Data Instance behavior is not part of the evaluation process in terms of prioritization of behavior type, or in terms of prioritization of data level.

Data Instance Behavior XML, XPath, and XQuery Examples

This section provides XML, XPath, and XQuery examples that are applicable to defining a Data Instance behavior.

This example shows an in-line XML that defines constant values (this could be used to define the values that appear in a dropdown field):

<bookStore>
  <books>
    <titles>
      <AlgebraForDummies> <price>30</price> </AlgebraForDummies>
      <GeometryForDummies> <price>35</price> </GeometryForDummies>
      <TrigonometryForDummies> <price>40</price> </TrigonometryForDummies>
    </titles>
  </books>
</bookStore>

This example shows an XPath expression that selects data from an XML file that defines elements (nodes) of bookstore, book, price, and title. This example returns a list of titles with a price greater than $30:
```
xmlDoc=new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.async=false;
xmlDoc.load("books.xml");
xmlDoc.selectNodes(/bookstore/book[price>35]/title );
```
This example shows an XQuery expression that selects data from an XML file that defines elements (nodes) of bookstore, book, price, and title. This example returns a list of ordered titles with a price greater than $30. The list is returned in variable x:
```
for $x in doc("books.xml")/bookstore/book
where $x/price>30
order by $x/title
return $x/title
```

Data Instance Behavior Overview

Table 9-6 shows Data Instance behavior attributes.

Table 9-6 Data Instance Behavior Attributes

Attributes	Value
Order of evaluation	Not applicable. The data instance type is unique in that it doesn't perform any action. It's just a container for data provider instances.
Default value	None
Applies to	All elements and structures
Parent/child inheritance	Children inherit instances declared on parent (This applies to element relationships within a structure, which is different than the inheritance of behaviors between the data dictionary, order, and task levels.)

Using the Event Behavior to Re-evaluate Data

You can use the Event behavior to save or refresh data when the data changes. This is useful when a change in a field can cause a behavior to automatically occur in the same field or in another field. For example, you might include an Event behavior in the account_information/country field, that causes the data to refresh. That refreshed data might in turn be used by a Relevant behavior assigned to the address details fields that display address information based on the country.

Refreshing causes OSM to re-evaluate all the behaviors associated with the task but does not save the order. Saving re-evaluates the behaviors and automatically saves the contents of the order.

Figure 9-5 shows an Event behavior defined in Design Studio. In this figure, the Event behavior refreshes the data in the account_information/country field.

Figure 9-5 Event Behavior Defined in Design Studio

Description of "Figure 9-5 Event Behavior Defined in Design Studio"

See "Using the Relevant Behavior to Specify if Data Should Be Displayed in the Web Client" for more information on the Relevant behavior, and this scenario in particular.

OSM supports the Event behavior in the Task web client.

Event Behavior Overview

Table 9-7 shows Event behavior attributes.

Table 9-7 Event Behavior Attributes

Attributes	Value
Order of evaluation	8th
Default value	None
Applies to	All elements
Parent/child inheritance	Does not inherit (This applies to element relationships within a structure, which is different than the inheritance of behaviors between the data dictionary, order, and task levels.)

Using the Information Behavior to Display Data and Online Help

You can use the Information behavior to specify how data is displayed in the OSM Task web client. You can do the following:

Set an alternative label for the field. For example, instead of the standard label State, the field can be changed to State or Province when processing the type of order that uses this behavior setting.
Localize the field label to one or more different languages.
Set a tool tip on a field.
Provide an online help topic for the field.

In the Order Management web client, any information rule on the first instance of a group node that uses a table layout style is used to determine the text of the table panel header. The first instance of each of this group instance's child field nodes are used to determine the column header text for that field node. Hint text for the group instance row and child field instance cells are displayed as tooltip text. Help defined for the group can be executed with either a menu item in the table's Actions menu or a row-level context menu and displays help in a modal window in the page containing the table. The implementation of this help behavior differs from the Task web client implementation, which uses an icon in each table cell to load the help in a separate browser window.

OSM triggers information rules when the data element or structure contains data, (for example, from the incoming order or derived from other data sources). If the data element or structure is empty, OSM does not display any label, hint, or help topic information behaviors associated with the empty element or structure. For example, if you defined a label for an element, the label does not appear when the element does not contain a value. Instead, the OSM uses the Display Name of the element as defined in the data dictionary.

Information Behavior XPath Examples

This section provides XPath examples that are applicable to defining an Information behavior.

This example shows an Information behavior label that could be used in conjunction with a Calculation behavior that calculates the current balance based on other fields such as endingBalance + currentCharges + fees - payments:
```
"Current Balance"
```
This example shows an Information behavior label that displays in place of the existing label assigned to the element. For example, the existing label “State" can be changed to display as:
```
"State or Province"
```

This example shows an Information behavior hint that displays when you hover over the Current Balance data field:

"The current balance reflects the customer's ending balance, plus any current charges and fees, minus any applied payments."

This example shows an Information behavior hint that displays when you hover over the Billing Address data field:

"The billing address is the address of the party responsible for payment of account. The billing address may differ from the service address. For example, the service address may be a college student's address, and the billing address may be the student's parents address."

Information Behavior Overview

Table 9-8 shows Information behavior attributes.

Table 9-8 Information Behavior Attributes

Attributes	Value
Order of evaluation	3rd
Default value	None
Applies to	All elements and structures
Parent/child inheritance	Does not inherit (This applies to element relationships within a structure, which is different than the inheritance of behaviors between the data dictionary, order, and task levels.)

Using the Lookup Behavior to Display Data Selection Lists

You can use the Lookup behavior to display data in a GUI field that users can select from. You can specify the order of the labels in the list, such as alphabetically.

You can look up data from the following sources:

Data that is in the incoming customer order.
Data from an internal source, such as an XML file.
Data from an external data provider.

Data can be retrieved dynamically based on input. For example, you can look up and populate a list of phones that cost less than $100, where $100 is a value obtained from another field in the order.

Note:

The Task web client supports two types of lookups: simple lookups with single label value entries, and table lookups, where a single lookup value has multiple associated labels. This latter lookup type is displayed as a text field with an associated icon that launches a secondary window which displays a table of label/value relationships.

In the Order Management web client, simple lookups are fully supported, but complex lookups are rendered as if they were simple: the first-defined label is shown as the display label. In both cases, the field is displayed as a read-only list of values.

Lookup Behavior XPath Example

This section provides an XPath examples that is applicable to defining a Lookup behavior.

This example shows an XPath expression that selects data from an XML file that defines elements (nodes) of bookstore, book, price, and title. This example returns a list of titles with a price greater than $35:

xmlDoc=new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.async=false;
xmlDoc.load("books.xml");
xmlDoc.selectNodes(/bookstore/book[price>35]/title );

Lookup Behavior Overview

Table 9-9 shows Constraint behavior attributes.

Table 9-9 Lookup Behavior Attributes

Attributes	Value
Order of evaluation	5th
Default value	The static lookup values (if any) that are specified in the data dictionary.
Applies to	Elements of data type: Lookup Number Text
Parent/child inheritance	Does not inherit (This applies to element relationships within a structure, which is different than the inheritance of behaviors between the data dictionary, order, and task levels.)

Using the Read-Only Behavior

You can use the Read Only behavior to specify that data displayed in the Task web client is read only. You can specify that data can be read only based on conditions; for example, data can be read only depending on other data in the order.

You typically create read-only fields for fields where the value is derived from other fields. For example, in your order display, you might have two windows: an account window and a payment window. Both windows might have an Amount Owed field, which displays the same data. However, you could make the Amount Owed field in the payment window the field where the data is collected, and the Amount Owed field in the account window read only. In that case, the field in the account window uses two behaviors:

A Calculate behavior, to get the data from the payment window.
A Read Only behavior.

Read-Only Behavior Overview

Table 9-10 shows Read-Only behavior attributes.

Table 9-10 Read-Only Behavior Attributes

Attributes	Value
Order of evaluation	7th
Default value	The default specified by the static read-only value.
Applies to	All elements and structures
Parent/child inheritance	If any ancestor evaluates to true, this value is treated as true. Otherwise, the local value is used. (This applies to element relationships within a structure, which is different than the inheritance of behaviors between the data dictionary, order, and task levels.)

Using the Relevant Behavior to Specify if Data Should Be Displayed in the Web Client

You can use the Relevant behavior to specify if data should be displayed in the Task web client or in the Order Management web Client Data tab, based on specified conditions.

For example, you can use the Relevant behavior to display address-input fields appropriate to the country that the order applies to. In this example, the Relevant behavior can be used as follows:

The data for the customer's country is included in the order's account_information/country field. This data is displayed in the Task web client in the Country/Region field.
Based on the data in the account_information/country field, the customer address fields (address_information) can include different values, depending on the country.

Note:

The account_information/country field includes an Event behavior, which refreshes the data in the field, making it available to the Relevant behavior.

Figure 9-6 shows the address fields for the United States (address_details_us) and Canada (address_details_ca). The Relevant behavior applies to the selected data, address_details_ca.

Figure 9-6 Address Fields in Design Studio

Description of "Figure 9-6 Address Fields in Design Studio"

Figure 9-7 shows the XPath expression that specifies the condition (country = Canada) under which the Relevant18 behavior is enabled.

Figure 9-7 Relevant Behavior Properties

Description of "Figure 9-7 Relevant Behavior Properties"

In the Order Management web client, if a group instance displayed with a table style behavior is not relevant, then the entire associated table row is omitted. If a particular field is not relevant, the associated table cell is rendered empty.

Relevant Behavior Overview

Table 9-11 shows Relevant behavior attributes.

Table 9-11 Relevant Behavior Attributes

Attributes	Value
Order of evaluation	4th
Default value	True
Applies to	All elements and structures
Parent/child inheritance	If any ancestor evaluates to false, this value is treated as false. Otherwise, the local value is used. (This applies to element relationships within a structure, which is different than the inheritance of behaviors between the data dictionary, order, and task levels.)

Using the Style Behavior to Specify How to Display Data in the Task Web Client

You can use the Style behavior to specify where and how to display data in the Task web client. You can do the following:

Control the placement of an element on a specific page.
Specify to display data on tabbed pages. You can display data in columns and tables.
Hide or mask sensitive data; for example, passwords or credit-card information. You can specify who can read passwords, and you can display a history of password changes. Masked data appears similar to *******.
Control the layout of a multi-valued field, such as a list of buttons to choose from.
Apply cascading style sheets (CSS style sheets) to specify how to display data. For example, you could make the current account balance display in red when the data value is greater than zero.

Note:

If you define a behavior that contains an apostrophe (') character, OSM will throw an exception error when loading the data. To prevent this from happening, you must include the escape character before and after the apostrophe.

Example:

'L'Information De Carte de credit'

should be

"'"L"'"Information De Carte de credit"'"

Figure 9-8 shows how the Style behavior changes the appearance of the Current Account Balance field in the Task web client.

Figure 9-8 Style Behavior Used in the Current Account Balance Field

Description of "Figure 9-8 Style Behavior Used in the Current Account Balance Field"

Figure 9-9 shows the condition that determines if the Style behavior should be applied. In this case, the Style behavior is applied if the account balance is the same as the amount owed.

Figure 9-9 Condition Defined in a Style Behavior

Description of "Figure 9-9 Condition Defined in a Style Behavior"

Figure 9-10 shows the style definitions to apply to a field.

Figure 9-10 Field Display Colors Defined in a Style Behavior

Description of "Figure 9-10 Field Display Colors Defined in a Style Behavior"

Figure 9-11 shows how three different conditions can change how the field is displayed. If the balance is zero, the field is green. If the balance is the same as the amount that the customer owes, the field is orange. If the balance is less than zero, or greater than the customer owes, the field is red.

Figure 9-11 How Style Behavior Conditions Are Used for Determining the Display Colors

Description of "Figure 9-11 How Style Behavior Conditions Are Used for Determining the Display Colors"

About Style Behavior Layouts

This section provides additional information on table layouts, which you can choose to set as None, Page Layout, or Table Layout.

The Page Layout option gives you the ability to organize structures elements onto separate pages that you can access directly, through the use of tabs. This is particularly useful for improving access where there are numerous large structures by eliminating the need to scroll through a single page to find the required structure.

The Table Layout option displays multi-instance structures in a grid format. By default, Table Layout displays all of the child elements in the structures. However, you can prevent a given child element from being used as a column by setting its hidden attribute to true.

Child elements within the structure are represented by columns, and instances of the structure are represented by rows. Table Layout displays the columns from left to right in the same order that they appear from top to bottom when displayed without a table layout. If you need to change the order in which the columns appear, you do so by changing their order in the Design Studio order template. The table uses the same child element label to form the column header that it does when displayed without a table layout.

Note:

If you use an Information behavior to dynamically change the child element labels, Table Layout uses the label associated with the first data instance it encounters.

If you need to hide the value of an individual cell in the resulting table, you can do so by declaring a Relevant behavior for the corresponding child element. See "Using the Relevant Behavior to Specify if Data Should Be Displayed in the Web Client."

Note:

Table Layout does not support nested structures in the Task web client but does support nested structures in the Order Management web client data tab.

In the Order Management web client data tab, multi-instance child values can be displayed within the corresponding parent value table cell and stacked vertically. You cannot access data history or behavior help from within the cell, but the information about the child multi-instance values can be accessed from the data history for the row. You can access the data history for a row by right clicking on the row and selecting data history or by selecting data history from the table drop down menu.

OSM uses the first instance of the table group node to determine the CSS style and class of the header text in the Order Management web client. All other style rule attributes of the group instances are ignored. CSS style and class rules, appearance rules, and secret rules are applied to child field (table cell) instances. No other style rules will be applied.

The following figures illustrate the different types of available layouts for the Task web client. Each figure shows the same structure with a different layout type:

Figure 9-12 shows the structure with no layout applied. With this option, the elements in the structure display within a group box on the original page.
Figure 9-13 shows the structure with the Page Layout option applied. With this option, the elements in the structure display within a group box on a new page that is accessed through a tab on the original page.
Figure 9-14 shows the structure with the Table Layout option applied. With this option, the elements in the structure display within a grid on a new page that is accessed through a tab on the original page.

Figure 9-12 Task with No Layout in the Task Web Client

Description of "Figure 9-12 Task with No Layout in the Task Web Client"

Figure 9-13 Page Layout in the Task Web Client

Description of "Figure 9-13 Page Layout in the Task Web Client"

Figure 9-14 Table Layout in the Task Web Client

Description of "Figure 9-14 Table Layout in the Task Web Client"

The following figures illustrate the different types of available layouts for the Order Management web client. Each figure shows the same structure with a different layout type:

Figure 9-15 shows the structure with no layout applied.
Figure 9-16 shows the structure with the Table Layout option applied.

Figure 9-15 No Layout in the Order Management Web Client

Description of "Figure 9-15 No Layout in the Order Management Web Client"

Figure 9-16 Table Layout in the Order Management Web Client

Description of "Figure 9-16 Table Layout in the Order Management Web Client"

About Style Behavior Password Fields

Behaviors that define password fields can ensure unauthorized users cannot view the contents of elements containing sensitive information. For example, by using this feature you can define a password field in such a way that users in an activation work group can not see the information, but users in the system administrator's work group can.

How Password Fields Display

If you define a password behavior on a writable field, OSM displays the contents of the field as specified by the browser, such as a line of asterisks (*) within a text box. If you define this feature on a read only field, OSM displays the data as specified by the browser, such as line of eight asterisks next to the field label, but not within a text box.

If you open the data history, OSM displays when and by whom the data was modified. When this feature is applied to a field, OSM displays the password field values as specified by the browser, such as a line of eight asterisks.

While you can define a Style behavior on all types of elements, this feature of the Style behavior has no effect on structures.

Do Not Use Password Field Feature with Boolean and Lookup Fields

Because this feature is designed for use with free form entry fields, as opposed to fields that force you to select from a limited number of choices, Oracle recommends that you do not use this feature with Boolean and lookup fields. If you do, you risk exposing confidential information to unauthorized users. This is because OSM displays the value that was previously set in a Boolean or lookup field, even if the field defines this feature through a Style behavior.

Displaying the Data History of Password Fields

OSM only evaluates behaviors at the web UI level, so any password field that you save (that is, create, update, or delete) through the XML API/Automator is not treated as a password field, even if it is defined as such. This can introduce some complexity into how OSM displays the data history for password fields. Use the following general guidelines and examples to understand how OSM displays password field data history.

General Guidelines

OSM displays a line of eight asterisks in the data history for any field that it evaluates as a password field (providing the field actually contains data; if the field is empty, OSM displays nothing).
If OSM does not evaluate a field as password field, the data history values are shown in plain text.
If OSM evaluates a data field as a password field at the time of saving, and the field is later deleted, OSM displays a line of eight asterisks in the data history (providing the field actually contains data; if the field is empty, OSM displays nothing).
If OSM evaluates a data field as a non-password field at the time of saving, and the field is later deleted and evaluated as a non-password field at the time of deletion, the data history is displayed as plain text.

Examples

If you save the value of a password field through OSM, and OSM is still evaluating the field as a password field when you display the data history, OSM displays the value of the password field as eight asterisks.
If you save the value of a password field through the XML API/Automator, and it is still present in the order editor (that is, it has not been deleted by the XML API/Automator) when you display the data history, OSM displays the value as eight asterisks.
If you create and delete the password field values through the XML API/Automator, OSM displays the data history values as plain text.
If you enter data in a non-password field through OSM and a user subsequently deletes the value through OSM or the XML API/Automator (and OSM evaluates the field as a non-password field at the time of deletion), the history values of this field are displayed as plain text.

Style Behavior Overview

Table 9-12 shows Style behavior attributes.

Table 9-12 Style Behavior Attributes

Attributes	Value
Order of evaluation	2nd
Default value	Data type specific: For Boolean type fields: Compact For Lookup type fields: Minimal
Applies to	Elements of data type: Boolean Lookup Elements with Lookup behaviors that display only one column.
Parent/child inheritance	Does not inherit (This applies to element relationships within a structure, which is different than the inheritance of behaviors between the data dictionary, order, and task levels.)