ProcessRequirements

The ProcessRequirements business rule is attached to a Policy level transaction/activity in order to trigger Requirement status processing outside of the Requirement's schedule. This is a supplement to the Requirement's processing schedule. The rule can process one or more Requirements identified in a variety of ways, but all Requirements must be associated to the Policy. The rule may process the Requirement with their current status or a new status in order to process with a different Requirement status logic.

The ProcessRequirements business rule should be configured in the TransactionBusinessRulePacket business rule.

Element Attributes Parent Element Description Element / Attribute Values
<ProcessRequirements>     This is the root element for the rule.  
<TriggerOnTransactionFailure>   <ProcessRequirements>

Optional:

This element determines whether the Requirements identified by this rule will process as the parent Activity fails.  This allows customers to create a dependency on the success of the activity that then allows requirement processing initiation.

  • No

    • default

    • processing is not triggered as the activity fails

  • Yes

    • processing is triggered as the activity fails
<Process>   <ProcessRequirements>

Required, Repeatable:

This element provides a structure to identify the Requirement or Requirements to conditionally process.  This element is repeated to provide another set of requirements with its own set of conditions to initiate processing.  Each <Process> element is independent of other <Process> elements in the rule and each can use different child elements to identify what to process.

It is mandatory that at least one of the following three child elements be configured in a single <Process> element. 

<RequirementGUID><RequirementName><RequirementGUIDArray>		  
<Tests>   <Process>

Optional:

This element expresses one or more conditions that, when evaluating to true, will allow the remainder of the parent element's configuration to process.

  
<Test>   <Tests>

Required, Repeatable:

This element provides a condition for the system to evaluate.  The element is repeated to express more than one condition.  All conditions must evaluate to true to allow the remainder of the parent element's configuration to process.

  • condition

    • Activity fields and math variables are available to construct a condition
<RequirementGUID>   <Process>

Optional:

This element identifies the Requirement to process. 

  • math variable

  • activity field

    • syntax is Activity:[field name]

  • literal
<RequirementGUIDArray>   <Process>

Optional:

This element identifies one or more Requirements to begin processing using an array of Requirement GUIDs. 

  • math variable

    • all values in the array must be valid RequirementGUIDs
<RequirementName>   <Process>

Optional:

This element identifies the Requirement(s) to process by a RequirementDefinition's name.  If a Requirement with that name does not exist on an associated entity (Policy, Client), no requirement will be processed and processing moves on to the next <Process> element or the end of the rule.

  • math variable

  • activity field

    • syntax is Activity:[field name]

  • literal
<ClientGUID>   <Process>

Optional:

This element identifies the Requirements to process by providing an identity to the associated Client using a ClientGUID.  This is mandatory for Policy-Client and Client level Requirements and must correctly identify the associated Client.

  • math variable

  • activity field

    • syntax is Activity:[field name]

  • literal
<NewStatus>   <Process>

Optional:

This element provides a Requirement status value upon which processing is initiated.  When this is not added to the configuration, Requirement processing uses the Requirement's current status value.

  • math variable

  • activity field

    • syntax is Activity:[field name]

  • literal

    • valid value comes from AsCodeRequirementStatus

XML Schema

<ProcessRequirements>
    <TriggerOnTransactionFailure>[No | Yes]</TriggerOnTransactionFailure>
    <Process>
        <Tests>
            <Test>[condition]</Test>
            <Test>...</Test>
        </Tests>
        <RequirementName>[literal | activity field | variable]</RequirementName>
        <NewStatus>[literal | activity field | variable]</NewStatus>
    </Process>
    <Process>
        <Tests>
            <Test>[condition]</Test>
            <Test>...</Test>
        </Tests>
        <RequirementGUIDArray>[variable]</RequirementGUIDArray>
        <NewStatus>[literal | activity field | variable]</NewStatus>
    </Process>
    <Process>
        <Tests>
            <Test>[condition]</Test>
            <Test>...</Test>
        </Tests>
        <RequirementGUID>[activity field | variable]</RequirementGUID>
        <NewStatus>[literal | activity field | variable]</NewStatus>
    </Process>
    <Process>
        <Tests>
            <Test>[condition]</Test>
            <Test>...</Test>
        </Tests>
        <ClientGUID>[activity field | variable]</ClientGUID>
        <NewStatus>[literal | activity field | variable]</NewStatus>
    </Process>
    <Process>...</Process>
</ProcessRequirements>

XML Example 

<ProcessRequirements>
    <TriggerOnTransactionFailure>Yes</TriggerOnTransactionFailure>
    <Process>
        <ClientGUID>OwnerClientMV</ClientGUID>
    </Process>
    <Process>
        <RequirementGUIDArray>PolicyRequirementArray</RequirementGUIDArray>
        <NewStatus>StatusMV</NewStatus>
    </Process>
    <Process>
        <Tests>
            <Test>PolicyStatusMV = IssueAcceptableStatusMV</Test>
        </Tests>
        <RequirementName>Issue Checklist</RequirementName>
    </Process>
</ProcessRequirements>