Order Lifecycle Policy Editor

Use the Order Lifecycle Policy editor to add permissions to order transactions. If you create a policy based on the default configuration, any roles you have defined within Design Studio are automatically preselected for the default transactions. You can add permissions to a group of transactions, or to a single transaction.

The following fields are common among multiple Order Lifecycle Policy editor subtabs.

Field	Use
Display Name	Edit the display name for the order lifecycle policy.
State and Transaction menu tree	This menu tree (at the left side of the Order Lifecycle Policy editor) contains a list of the order states and the transactions that can occur for each order state. Expand an order state folder to reveal the related transactions. Select a transaction in this column to configure permissions for the transaction. Click the Add Permissions button to configure permissions for multiple transactions simultaneously.

Field

Use

Display Name

Edit the display name for the order lifecycle policy.

State and Transaction menu tree

This menu tree (at the left side of the Order Lifecycle Policy editor) contains a list of the order states and the transactions that can occur for each order state.

Expand an order state folder to reveal the related transactions. Select a transaction in this column to configure permissions for the transaction. Click the Add Permissions button to configure permissions for multiple transactions simultaneously.

See the following topics when using the Order Lifecycle Policy editor:

Order Lifecycle Policy Permissions Tab
Order Lifecycle Policy Transition Conditions Tab
Order Lifecycle Policy Editor Grace Periods Tab

Order Lifecycle Policy Permissions Tab

Use the Order Lifecycle Policy editor to add permissions to order transactions.

Field	Use
Permissions	Select a transaction from the left-column order state and transaction menu tree and click the Permissions field Add button to add a new permission for the selected transaction. Select any permission and click Remove to delete the permission from the list. Select the default name and rename the permission, as appropriate. See "Configuring Order Lifecycle Policies" for information about assigning roles to permissions.
Roles	Select a permission in the Permissions field to view the roles assigned to the permission. All of the roles defined in the workspace in the Available Column. To permit a role to perform the transaction associated with the permission, select a role and click the arrow keys to move roles into the Selected area. Click the Create Role button to create and add a new role. See "Creating New Roles" for more information.
Conditions	Define conditions for the permissions. Select a permission and click the Add button in the Condition area. Select the default name condition and the default XPath expression true() to modify the values. Select any condition and click Remove to delete the condition from the list. OSM evaluates the condition for a permission when the transaction is attempted. If it evaluates to true, the assigned roles are able to perform the transaction. If it evaluates to false, the assigned roles are unable to perform the transaction. Note: XPath uses path expressions to select data nodes in XML documents. A path expression with a single dot (.) represents the current node. Two dots (..) represents the parent of the current node. A slash (/) represents the root node. XPath and XQuery fields are limited to 4000 characters.

Field

Use

Permissions

Select a transaction from the left-column order state and transaction menu tree and click the Permissions field Add button to add a new permission for the selected transaction. Select any permission and click Remove to delete the permission from the list.

Select the default name and rename the permission, as appropriate. See "Configuring Order Lifecycle Policies" for information about assigning roles to permissions.

Roles

Select a permission in the Permissions field to view the roles assigned to the permission. All of the roles defined in the workspace in the Available Column. To permit a role to perform the transaction associated with the permission, select a role and click the arrow keys to move roles into the Selected area.

Click the Create Role button to create and add a new role. See "Creating New Roles" for more information.

Conditions

Define conditions for the permissions.

Select a permission and click the Add button in the Condition area. Select the default name condition and the default XPath expression true() to modify the values. Select any condition and click Remove to delete the condition from the list.

OSM evaluates the condition for a permission when the transaction is attempted. If it evaluates to true, the assigned roles are able to perform the transaction. If it evaluates to false, the assigned roles are unable to perform the transaction.

Note: XPath uses path expressions to select data nodes in XML documents. A path expression with a single dot (.) represents the current node. Two dots (..) represents the parent of the current node. A slash (/) represents the root node. XPath and XQuery fields are limited to 4000 characters.

Order Lifecycle Policy Transition Conditions Tab

Use the Order Lifecycle Policy Transition tab to define conditions for transaction transitions.

Field	Use
Conditions	Define conditions for the transaction transition. Click the Add button in the Condition area to add a condition for the selected transaction in the left-column states and transactions menu tree. Select the default name condition and the default XPath expression true() to modify the values. Select any condition and click Remove to delete the condition from the list. OSM evaluates the condition when the order transitions to the selected transaction. If the condition evaluates to false, then the transaction is disabled while the order is in the surrounding order state.
Expression	When you add a condition, the default XPath expression true() is automatically added. Note: XPath uses path expressions to select data nodes in XML documents. A path expression with a single dot (.) represents the current node. Two dots (..) represents the parent of the current node. A slash (/) represents the root node. XPath and XQuery fields are limited to 4000 characters.
Message	Add a human readable message to display in error logs if the condition evaluates to false.
Display as	Add an error severity to associate with a condition that evaluates to false. Select one of the following: VALID: WARNING: ERROR: CRITICAL:

Transition Condition for Checking a Hard Point of No Return

The following XQuery can be used to check whether a hard point of no return has been reached, so that an amendment can be rejected if it is received after a hard point of no return. This XQuery checks to see whether there have been any revisions to significant data for order items that have reached a hard point of no return. Business considerations will determine what state/transition combinations will need to check for the point of no return, but at a minimum it should be defined in the In Progress state for the Submit Amendment transition.

To use this XQuery, follow the standard procedure for updating the lifecycle policy, creating a new transition condition and using the XQuery below in the Expression box for that condition. See "Configuring Order Lifecycle Policies" for more information about updating the lifecycle policy.

declare variable $PONR_NOT_YET := "NOT YET";

(: Checks for Hard Point Of No Return, return = true means no PONR 
   has been reached. Raise an error if PONR has been reached. :)
declare function local:allowRevision(
    $taskData as element()) as xs:boolean {
    let $rootData := $taskData/_root
    let $changes := $taskData/RevisionPerspective/Changes
    return
        if (fn:exists($rootData) and fn:exists($changes))
        then (
            let $changedOrderItems as element()* := 
                    local:getChangedOrderItems($rootData, $changes)
            let $revisionOrderItemsPastHardPONR as xs:string* :=
                for $orderItem in $changedOrderItems
                    return local:getOrderItemsPastHardPONR($orderItem)
            return fn:not(fn:exists($revisionOrderItemsPastHardPONR)))
        else fn:true() };

declare function local:getChangedOrderItems(
    $root as element(), 
    $changes as element()) as element()* {
    let $indices := local:getOrderItemIndicesForChecking($changes)
    let $distinctIndicies := fn:distinct-values($indices)
    for $index in $distinctIndicies
        return local:getOrderItem($root, $index) };

declare function local:getOrderItemIndicesForChecking(
    $changes as element()) as xs:string* {
    for $change in $changes/*[@significant = "true"]
        return local:getOrderItemIndex($change) };

declare function local:getOrderItemIndex(
    $changeNode as element()) as xs:string* {
    let $changeType := local-name($changeNode)
    let $tokens := fn:tokenize($changeNode/@path, "/")
    let $t1 := $tokens[position() = 2]
    let $t2 := $tokens[position() = 3]
    let $t3 := $tokens[position() = 4]
    let $t4 := $tokens[position() = 5]
    return
        if (fn:starts-with($t1, "ControlData") 
            and fn:starts-with($t2, "Functions")) then
            (: /ControlData/Functions/*Function/orderItem/... :)
            local:getOrderItemIndexInFunction(
                fn:root($changeNode)/GetOrder.Response/_root,
                (: Functions/@index, if exists :)
                fn:substring-before(fn:substring-after($t2,"'"), "'"),
                (: e.g. SyncCustomerFunction/@index :)
                fn:substring-before(fn:substring-after($t3,"'"), "'"),
                (: e.g. orderItem/@index :)
                fn:substring-before(fn:substring-after($t4,"'"), "'"))
        else
                ""   };

declare function local:getOrderItemIndexInFunction(
    $root as element(),
    $functionsIndex as xs:string,
    $functionIndex as xs:string,
    $orderItemIndex as xs:string) as xs:string* {
    if (fn:boolean($functionsIndex)) then 
        $root/ControlData/Functions[@index = $functionsIndex]/*[@index = 
            $functionIndex]/orderItem[@index = 
            $orderItemIndex]/orderItemRef/@referencedIndex
    else
        $root/ControlData/Functions/*[@index = $functionIndex]/orderItem[@index =
            $orderItemIndex]/orderItemRef/@referencedIndex    };

declare function local:getOrderItem(
    $root as element(), 
    $orderItemIndex as xs:string) as element()* {
    $root/ControlData/OrderItem[@index = $orderItemIndex]    };

declare function local:getOrderItemsPastHardPONR(
    $orderItem as element()) as xs:string* {
    let $lineId as xs:string := local:getLineId($orderItem)
    let $pointOfNoReturn as xs:string := local:getPointOfNoReturn($orderItem)
    let $isHardPONRReached := if ($pointOfNoReturn = "HARD") 
                                 then true() 
                                 else false()
    return
        if ($isHardPONRReached)
        then $lineId
        else () };

declare function local:getLineId(
    $orderItem as element()) as xs:string {
    fn:normalize-space($orderItem/LineID/text()) };

declare function local:getPointOfNoReturn(
    $orderItem as element()) as xs:string {
    let $ponrData := fn:normalize-space($orderItem/PoNR/text())
    let $ponrCode :=
        if (fn:empty($ponrData))  
        then $PONR_NOT_YET
        else (
            let $lastPonrValue := 
                fn:normalize-space($orderItem/PoNR[last()]/text())
            return
                (: We are looking for strings with either [xxxx]xxxx or 
                   xxxx format. Return what is in the [] or the whole string 
                   if no brackets. :)
                let $hard1 := fn:tokenize($lastPonrValue, "\[|\]") 
                return fn:concat( $hard1[1] , $hard1[2] )
        )
    return
        $ponrCode   };

(: Detect false revision order. return = true means 
   there are significant data changes in the revision order :)
declare function local:doSignificantChangesExist(
    $taskData as element()) as xs:boolean {
    let $dataChanges := 
        $taskData/RevisionPerspective/Changes/*[@significant='true']
    return
        if (fn:exists($dataChanges))
        then true()
        else false() };

(: Only do the complex calculation for a valid revision.:)
let $taskData := fn:root(.)/GetOrder.Response
let $isValidRevision := local:doSignificantChangesExist($taskData)
return if ($isValidRevision) 
then
    local:allowRevision($taskData)
else
    fn:true()

Order Lifecycle Policy Editor Grace Periods Tab

Use the Order Lifecycle Policy Editor Grace Periods tab to specify a period of time that the system should wait before suspending, amending, or canceling an order.

A grace period specifies a period of time to wait for all accepted tasks to complete before transitioning an order. You can specify a grace period for the Suspend Order, Process Amendment, and Cancel Order transactions. Grace periods are defined by a wait duration and an event frequency.

Field	Use
Wait Duration	Select Indefinitely (the default setting) or specify a time frame using the minimum and maximum times that the system waits before forcing the transition.
Event Frequency	Specify the frequency at which the system should generate a jeopardy notification (defined as every hour, by default) while the wait duration remains unsatisfied.