Jeopardy Services

The Jeopardy services ensure that planned tasks stay on track, there are minimal risks, and the orders are completed on time.

Calculating all possible paths from the plan and identifying the critical path is a time-consuming task. Jeopardy must perform this task every time a state change notification is sent from the orchestrator. Since these lengthy calculations are resource-intensive, users can consider that Jeopardy effectively monitors long-running orders. However, Jeopardy is not designed to monitor orders that complete very quickly.

Let us refer to orders that complete very quickly as short orders. You can update the definition of short orders by modifying the "propName": "shortLivedThresholdInMinutes" in the configuration of the Jeopardy service. By default, it is set to one minute.

Let us understand how the Jeopardy service calculates short-lived orders.

Suppose you have defined the following PlanFragments in the PlanFragment catalog, and the plan is generated such that there is only one plan item containing the following planFragment:

<pf:PlanFragmentModels xmlns:pf="http://www.tibco.com/AFF/V4.0.0/classes/planFragment">
  <pf:planFragment>
    <pf:planFragmentID>PF01</pf:planFragmentID>
    <pf:planFragmentName>PF01</pf:planFragmentName>
    <pf:planFragmentVersion>V01</pf:planFragmentVersion>
    <pf:owner/>
    <pf:record_Type>Process</pf:record_Type>
    <pf:errorHandler/>
    <pf:retry>
      <pf:retryOverride>true</pf:retryOverride>
      <pf:retryFailed>true</pf:retryFailed>
      <pf:retryCount>3</pf:retryCount>
      <pf:retryDelay>60000</pf:retryDelay>
    </pf:retry>
    <pf:section>
      <pf:startMilestoneID>START</pf:startMilestoneID>
      <pf:endMilestoneID>END</pf:endMilestoneID>
      <pf:typicalDuration>1000</pf:typicalDuration>
      <pf:maximumDuration>6000</pf:maximumDuration>
    </pf:section>
  </pf:planFragment>
</pf:PlanFragmentModels>

Here, the configured maximumDuration is 6000 milliseconds, which is less than one minute (default configuration for short-lived orders). The Jeopardy service does not monitor this plan as this order is short-lived.

For short-lived orders, on the planTimeLine tab, the following message is displayed:

Timeline cannot be computed for a short-lived plan.
Note: If you do not want to deploy the Jeopardy service, delete all the bridges and channels by using the DeleteJeopardyEMSChannel.txt script.

Following aspects play important roles in the Jeopardy service:

Durations

Jeopardy service handles the following types of durations:

  • Typical Duration: The expected or standard amount of time required for the completion of the activity represented by the task under normal or average conditions, without any unforeseen delays or exceptional circumstances.

  • Hazard Duration: The Hazard duration represents the projected upper limit of time for the completion of an activity, accounting for the specified risk threshold. It is derived by adjusting the Typical duration with the risk threshold percentage, allowing for a margin that considers potential hazards or risks that might extend the task duration beyond the standard expectation.

  • Maximum Duration: The standard upper limit of time allocated for the completion of the activity is represented by the task under optimal conditions. This duration represents the maximum permissible time frame within which the task is expected to be completed without unforeseen delays or exceptional circumstances.

  • OutOfScope Duration: The OutOfScope duration signifies the expected upper boundary of time allocated for task completion, incorporating the out-of-scope threshold. This is calculated by modifying the maximum duration based on the out-of-scope threshold percentage. This duration accommodates potential extensions arising from conditions or requirements beyond the originally defined scope of the task.

Sections

Sections or milestone to milestone relationships, represent combinations of milestone pairs that might appear in the execution plan generated by AOPD (Automated Order Processing and Design).

For example, if START, M1, M2, and END are four milestones of a plan fragment, the following milestone combinations can be possible:

  • START, M1, END

  • START, M2, END

  • START, M1, M2, END

To support any of these milestone combinations, the plan fragment contains the following section information:

  • START to M1

  • START to M2

  • M1 to M2

  • M1 to END

  • M2 to END

  • START to END

Plan Path

A Plan Path refers to a sequence of plan item sections in an execution plan. The plan paths are computed based on the dependencies between plan item sections by following a specific sequence.

  • Starting Point: Initiate the path at a START milestone without any point dependencies.

  • Path Traversal: Navigate through the plan item section for which this is the starting milestone. During traversal, determine if the terminating milestone has any dependencies. If a terminating milestone has multiple trailing dependencies, the path is divided and created a path of execution.

  • Terminating Point: At the terminating milestone, no plan item section has a dependency on the trailing milestone of the current plan item.

Critical Path

The critical path in the plan is the longest path. It is determined by analyzing all available paths and selecting the one with the longest design duration. This path plays a crucial role in both SLA (Service Level Agreement) and predicting jeopardy, serving as a key aspect for monitoring a plan.