Managing Workflows
                                                            A custom workflows management endpoint using Spring Actuator is provided to manage workflows. 
To enable the workflows management endpoint:
management: 
  endpoints:
    web:
      exposure:
        include: "workflows"
                                                            After the workflows management endpoint is enabled, the following operations can be performed:
| Endpoint | Operation | Payloads | 
|---|---|---|
| 
 | Read | Request: None. Response: Same payload as the  | 
| 
 | Read  | Request: None. Response: {
  "id": "<workflowId>",
  "enabled": (true | false),
  "state": "(running | stopped | paused | unknown)",
  "inputBindings": [
    "<input-binding>"
  ],
  "outputBindings": [
    "<output-binding>"
  ]
} | 
| 
 | Write | Request: {
"state": "STARTED | STOPPED | PAUSED | RESUMED"
}Response: None. | 
- 
                                                                        Only workflows with SolaceSolace consumers (where the solacebinder is defined in theinput-#) support pause/resume.
- 
                                                                        Some features require the Micro-Integration to manage the workflow lifecycle. If you use write operations to change the workflow state when these features are in use, the workflow state might not persist. For example, when the Micro-Integration is configured in the active-standbymode, workflows automatically transition fromrunningtostoppedwhen the Micro-Integration fails over fromactivetostandby, and vice-versa for a failover in the opposite direction.
Workflow States
A workflow’s state is defined as the aggregate states of its bindings (see the bindings management endpoint) as follows:
| Workflow State | Condition | 
|---|---|
| 
 | All bindings have  | 
| 
 | All bindings have  | 
| 
 | All consumer bindings and all pausable producer bindings have  | 
| 
 | None of the other states. Represents an inconsistent aggregate binding state. | 
When the producer or consumer binding is not implementing Spring’s Lifecycle interface, Spring always reports the bindings as state=N/A. The  state=N/A is ignored when deciding the overall state of the workflow. For example, if the consumer's binding is state=running and the producer's binding is state=N/A (or vice versa), the workflow state is running.
For more information about binding states, see Spring Cloud Stream: Binding visualization and control.