Properties State/Status Transition View

Use the Properties State/Status Transition view to define the condition against which OSM evaluates (at run time) a state or status transition for a service action response.

Field Use

Condition Name Displays the condition name as defined on the Response Data tab in the Transition to State or Status table.

State/Status Displays a user-defined state or status transition as defined on the Response Data tab in the Transition to State or Status table. Click Select to change the state or status.

Field	Use
Condition Name	Displays the condition name as defined on the Response Data tab in the Transition to State or Status table.
State/Status	Displays a user-defined state or status transition as defined on the Response Data tab in the Transition to State or Status table. Click Select to change the state or status.
Condition	Define the condition against which OSM evaluates the transition. At run time, OSM evaluates the conditions in an order you define and stops evaluating when a condition evaluates to true. For example, consider that you want to define a condition for the orderFailEvent to transition the task to a suspended state (NEUnknown) because of a network element error. You can define the condition in the following manner: `contains($osmOrderDocument/osm:GetOrder.Response/osm:_root/osm:ASAPResponse/osm:EventData/osm:reason[starts-with(.,'orderFailEvent')], 'SARM_MSG:Routing Error')` Note: The `$osmOrderDocument` is a variable that represents the OSM order data. Completion events and exceptions must include a default transition should all specified conditions fail. You can change or delete the predefined default values, or you can create your own. However, if you define no default conditions for ASAP completion events and exceptions (no condition is defined with XPath expression `true()`) Design Studio creates a problem marker.

Condition

Define the condition against which OSM evaluates the transition. At run time, OSM evaluates the conditions in an order you define and stops evaluating when a condition evaluates to true.

For example, consider that you want to define a condition for the orderFailEvent to transition the task to a suspended state (NEUnknown) because of a network element error. You can define the condition in the following manner:

contains($osmOrderDocument/osm:GetOrder.Response/osm:_root/osm:ASAPResponse/osm:EventData/osm:reason[starts-with(.,'orderFailEvent')], 'SARM_MSG:Routing Error')

Note: The $osmOrderDocument is a variable that represents the OSM order data. Completion events and exceptions must include a default transition should all specified conditions fail. You can change or delete the predefined default values, or you can create your own. However, if you define no default conditions for ASAP completion events and exceptions (no condition is defined with XPath expression true()) Design Studio creates a problem marker.