This chapter is from the book
This chapter is from the book
This chapter is from the book
Track and Trace
The Track-and-Trace pattern (Figure 3-8) is a special case of the Situation Recognition pattern. This pattern involves two contextual elements: a model of the expected process and the state of an existing instance of that process. If the triggering event marks the beginning of a new process execution, an initial process state is created. For other events, information in the event is used to locate the state of the process already being executed (there may be many instances of the process being executed at any given point in time). Once the current state has been identified, the process model is then used to interpret the triggering event in the context of that state.
)
Figure 3-8: Track-and-Trace Pattern
This simplified example omits a common challenge: the handling of out-of-sequence events. In many real-world situations, events may arrive out of sequence. In some cases, the first event that arrives may not be the initial event in the process. In a full solution, additional logic must be added to handle these situations. Chapter 14 discusses some of the design considerations.
The state machine approach provides for a rich and varied interpretation of the process execution. If the triggering event corresponds to an expected transition in the state machine (given the current state), the conclusion is that the process is executing in an expected manner—at least at this time. The analysis can be designed to announce business events when particular states have been achieved (i.e, announce that a milestone has been reached).
If the triggering event does not correspond to an expected transition, something unexpected has happened. Again, the analysis can be designed to emit business events announcing this unexpected situation.
This type of analysis is appropriate for monitoring any type of unmanaged process. Tracking of a package from initial pickup to final delivery is one example. Tracking your luggage from the time you drop it off at the departure airport ticket counter until the time you pick it up at the baggage carousel at your final destination is another.
In general, this approach is well suited for monitoring any process in which there is a hand-off of responsibility from one participant to another. You give your luggage to the counter agent—one hand-off of responsibility. The counter agent places the bag on the conveyer as a means of handing off responsibility to the baggage handlers. The process continues until the final hand-off, which begins when the baggage handler at your final destination places the bag on the conveyer leading to the baggage carousel and ends when you pick up your luggage.
The events being monitored in track-and-trace situations are the evidence that individual hand-offs have been successful. The challenge in most situations is finding the evidence. In the days before security requirements mandated scanning and tracking luggage on airplanes, the evidence was scanty: You got your receipt for your bag when you dropped it off (that is, when you handed it off to the airline) and you (hopefully) picked up your bag at its destination. There was little evidence available for any intermediate progress.
The security requirement that luggage not travel on a plane unless the associated passenger is also on board has resulted in better tracking—better evidence—of your luggage’s progress. The luggage tracking tag is scanned when the luggage is loaded on the plane or placed in a bin that will subsequently be loaded on the plane. It is scanned again when it comes off. These scans provide intermediate evidence of progress.
Your challenge in designing a Track-and-Trace solution is going to be finding appropriate evidence of progress. It is not uncommon that the full set of evidence you would like to have is simply not available. When this occurs, you may want to implement the degree of tracking that is supported by the currently available evidence and independently begin an initiative that will eventually provide more detailed evidence of progress. This is exactly what happened in the telecommunications case study described back in Chapter 2.