Skip Headers
Oracle® Communications Order and Service Management Concepts
Release 7.2.2

E35415-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

9 About Behaviors

This chapter describes how to use behaviors to manipulate data used by orders and tasks.

About Behaviors

You can use behaviors to specify how Oracle Communications Order and Service Management (OSM) manages data. For example:

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:

Note:

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

Figure 9-1 Behaviors Used in a Task

Shows how behaviors are modeled 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

Shows a behavior modeled in an order.

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:

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 "Managing Changes to Orders" 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 Behaviors Properties view Details tab 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:

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

    Shows how behaviors are modeled in a task
  2. 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 descendents of that node.
  3. 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:

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

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

  3. 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.
  4. 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.

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

Shows an XPath expression.

Figure 9-5 Shows how the fields appear in the Task Web client.

Figure 9-5 Values from Two Fields Combined into One Field

Shows how fields appear in Task Web client.

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
    

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:

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

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.

Constraint Behavior Overview

Table 9-3 shows Constraint behavior attributes.

Table 9-3 Constraint 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

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:

When you use the Data Instance behavior, you need to specify the data provider that you get data from. 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 Product Specifications" 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-4 shows Data Instance behavior attributes.

Table 9-4 Data Instance Behavior Attributes

Attributes Value

Order of evaluation

Not applicable

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-6 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-6 Event Behavior Defined in Design Studio

Shows an 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-5 shows Event behavior attributes.

Table 9-5 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:

Note:

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 client implementation, which uses a hyperlinked icon in each table cell to load the help in a separate browser window.

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-6 shows Information behavior attributes.

Table 9-6 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 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.

Figure 9-7 shows a Lookup behavior that creates a choice of cities. The upper part of the figure shows the behavior in Design Studio, and the lower part of the figure shows how the data displays in the Task Web client.

Figure 9-7 Example of Defining a Lookup Behavior

Shows example Lookup behavior that creates a choice

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 OM 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-7 shows Constraint behavior attributes.

Table 9-7 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:

Read-Only Behavior Overview

Table 9-8 shows Read-Only behavior attributes.

Table 9-8 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:

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

Figure 9-10 Address Fields in Design Studio

Shows address fields in Design Studio.

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

Figure 9-11 Relevant Behavior Properties

Shows an XPath expression.

In the Order Management Web client, if a group instance displayed with a table style beharior 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-9 shows Relevant behavior attributes.

Table 9-9 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:

Important:

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-12 shows how the Style behavior changes the appearance of the Current Account Balance field in the Task Web client.

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

Graphic is described in surrounding text.

Figure 9-13 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 less than zero or greater than the amount owed.

Figure 9-13 Condition Defined in a Style Behavior

Graphic is described in surrounding text.

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

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

Graphic is described in surrounding text.

Figure 9-15 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-15 How Style Behavior Conditions Are Used for Determining the Display Colors

Graphic is described in surrounding text.

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. Each figure shows the same structure with a different layout type:

  • Figure 9-16, "No Layout" 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-17, "Page Layout" 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-18, "Table Layout" 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-16 No Layout

Graphic is described in surrounding text.

Figure 9-17 Page Layout

Graphic is described in surrounding text.

Figure 9-18 Table Layout

Graphic is described in surrounding text.

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

  1. 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).

  2. If OSM does not evaluate a field as password field, the data history values are shown in plain text.

  3. 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).

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

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

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

  3. If you create and delete the password field values through the XML API/Automator, OSM displays the data history values as plain text.

  4. 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-10 shows Style behavior attributes.

Table 9-10 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.)