# Dataflow

## Bootup flow when the Barbican API service begins

This is the sequence of calls for booting up the Barbican API server:

1. `bin/barbican.sh start`: Launches a WSGI service that performs a PasteDeploy process, invoking the middleware components found in `barbican/api/middleware` as configured in `etc/barbican/barbican-api-paste`. The middleware components invoke and then execute the Pecan application created via `barbican/api/app.py:create_main_app()`, which also defines the controllers (defined in `barbican/api/controllers/`) used to process requested URI routes.

## Typical flow when the Barbican API executes

For synchronous calls, the following sequence is generally followed:

1. A client sends an HTTP REST request to the Barbican API server.

2. The WSGI server and routing invokes a method on one of the `XxxxController` classes in `barbican/api/controllers/xxxx.py`, keyed to an HTTP verb (so one of POST, GET, DELETE, or PUT).

   1. Example - GET /secrets:

      1. In `barbican/api/controllers/secrets.py`, the `SecretController`’s `on_get()` is invoked.

      2. A `SecretRepo` repository class (found in `barbican/model/respositories.py`) is then used to retrieve the entity of interest, in this case as a `Secret` entity defined in `barbican/model/models.py`.

      3. The payload is decrypted as needed, via `barbican/plugin/resources.py`’s `get_secret()` function.

      4. A response JSON is formed and returned to the client.

For asynchronous calls, the following sequence is generally followed:

1. A client sends an HTTP REST request to the Barbican API server.

2. The WSGI server and routing again invokes a method on one of the `XxxxcController` classes in `barbican/api/controllers/`.

3. A remote procedure call (RPC) task is enqueue for later processing by a worker node.

   1. Example - POST /orders:

      1. In `barbican/api/controllers/orders.py`, the `OrdersController`’s `on_post()` is invoked.

      2. The `OrderRepo` repository class (found in `barbican/model/respositories.py`) is then used to create the `barbican/model/models.py`’s `Order` entity in a ‘PENDING’ state.

      3. The Queue API’s `process_type_order()` method on the `TaskClient` class (found in `barbican/queue/client.py`) is invoked to send a message to the queue for asynchronous processing.

      4. A response JSON is formed and returned to the client.

4. The Queue service receives the message sent above, invoking a corresponding method on `barbican/queue/server.py`’s `Tasks` class. This method then invokes the `process_and_suppress_exceptions()` method on one of the `barbican/tasks/resources.py`’s `BaseTask` implementors. This method can then utilize repository classes as needed to retrieve and update entities. It may also interface with third party systems via plugins`. The `barbican/queue/client.py`’s `TaskClient` class above may also be invoked from a worker node for follow on asynchronous processing steps.

   1. Example - POST /orders (continued):

      1. Continuing the example above, the queue would invoke the `process_type_order()` method on `barbican/queue/server.py`’s `Tasks` class. Note the method is named the same as the `TaskClient` method above by convention.

      2. This method then invokes `process_and_suppress_exceptions()` on the `barbican/tasks/resources.py`’s `BeginTypeOrder` class. This class is responsible for processing all newly-POST-ed orders.

this page last updated: 2026-08-18 22:10:53

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug