Flushing the system
Applicable user role: Operator
A flush command is used in a panic case and can be issued with the Admin controller on LPAR_1 by an Operator. If issued, the Admin controller internal state is changed to FLUSH and is queried by the Conductor on LPAR_2 during its iteration flow when connection between LPAR_1 and LPAR_2 is established. When the Conductor determines a flush command was issued, the orchestration flow is interrupted and all deployed components are DESTROYED, including the Preconfirmation queue, Postconfirmation queue, Frontend plug-in, and Admin controller. The Preconfirmation queue, Postconfirmation queue, and Frontend plug-in will automatically be re-created after all components are DESTROYED.
In the Flush state, IBM Digital Asset Offline Signing Orchestrator makes sure that:
- The Preconfirmation queue and Postconfirmation queue are DESTROYED, and the Output plug-in has no destination to push data to.
- The Conductor is made aware of the
FLUSHstate to destroy other components.
Guarantee options
IBM Digital Asset Offline Signing Orchestrator tries to guarantee that data is volatile. The Operator can issue a flush command to stop any active iterations that are running, remove all current documents from the components, and bring the state of the system back to a post-init state. Note that if HiperSocket is down between LPAR_1 and LPAR_2 at the time when a flush is issued, after the HiperSocket is back online, it will perform the flush task that was previously performed by the Operator. For more information, see Flushing the system.
As a final line of defense, an Operator with HMC access can shut down each LPAR to delete the data that each component contains.
Flush end state
At the end of issuing a flush command, every component is back to what it is in the initial state. For more information, see Initial state.
Flush by OSO Operator
oso-cli.py operator --cert ../path/to/admin1.crt --key \ /path/to/admin1-key.pem --cacert ca.pem flushSwimlanes
Normal operation
Online flush
Networking flush
The following are the swimlanes for networking operations and interactions between components in a FLUSH state.
The following figure illustrates the communication between the output bridge and the conductor to ensure that the data is not sent to the Postconfirmation queue from the Backend plug-in when the system is in a Flush state. The Postconfirmation queue is also DESTROYED so that if somehow the Output bridge were to start sending data, the data has no destination. The following scenario also shows the process if the Operator did not follow the redirect. 
The following figure illustrates that when the HiperSocket12 is reCONNECTED, the conductor must make a check of the solution state. If it is Flush state, flush operations are done immediately. 