Usage of the Message Store and Forward

Here are some considerations to take into account when using the MSF modules.

As shown in the figure, the msf::MessageStoreAndForward has a cancel port and requires a module to be linked to it. Service orders can go to this port for two main reasons:

  • the SO is a probe and has been played too many times (the number of times a probe is tried is configurable, refer to the component documentation),

  • the msf module received a SO that does not contain any WO in status Partial and cannot process it.

The previous note is important when designing a flow that handles resubmission of orders in various states. As a rule, reinjection of orders handled outside should go back directly into the pop::POP module and not into the msf::MessageStoreAndForward. See the figure.
Resubmitting Failed or Processed Orders Directly to POP


Note:

Messages that may have a Failed status can be reinjected directly into pop::POP. Orders whose status is not New or Partial will be rejected by the MSF so reinjection is done into POP. As a rule, an order that has gone out of a monitor should go back directly into POP, not into the msf::MessageStoreAndForward module.

Service Orders waiting for a Network Element to be available again can be blocked for a long time. For a discussion of how to avoid long waiting orders, refer to the component documentation for the msf package. That package's documentation includes a sample implementation of a strategy to avoid long waiting orders.