The NoOp Trick
Generally, the last module of a receiving protocol message flow is a NoOp (provcautil::NoOp) module. As its name indicates, it does nothing. It just absorbs the incoming protocol message.
It is mainly used in a receiving protocol message flow because most of the time, a client adapter internally manages the lifecycle of the protocol message, which goes through the receiving protocol message flow. On the opposite, the protocol message going through a sending protocol message flow, is a regular service order which needs to be put back to the provisioning flow.
A NoOp module is generally deployed in a receiving protocol message flow (where the protocol message is internally handled by the framework) and follows an EndPoint in a protocol message flow.
Handling Asynchronous Events Related to Connectivity
At a client adapter level, a connectivity issue may happen at any time and trigger an asynchronous event. In this case, a possible approach is to generate a specific protocol message and inject it in the protocol message flow. In this flow, a component would route the protocol message to a provcautil::AdminNotifier which, as its name indicates, notifies the framework that the session should be re-enabled. This is the approach taken by the NETMAN Client Adapter.
Redirecting a Protocol Message to the Initial Provisioning Flow
When a service order enters a provca::ClientAdapter module in a provisioning flow, it is considered a protocol message. Once the processing of this protocol message in the protocol message flows is done, it is generally desired to redirect this message through the client adapter ports back to the provisioning flow. This can be achieved by using the provcautil::Redirector module, which can be configured for a static or a dynamic redirection, depending on the protocol message status.