Proposal: Bruno Workflows

This is a proposal for implementing workflows in Bruno.

Somewhat related to Bruno Test Script RFC #46

Workflows:

1. A workflow is an ordered sequence of API calls
2. Data from the previous response can be used in the current request
3. A developer can easily setup and run a sequence of api calls, as opposed to painfully copy pasting response snippets one by one before executing the next collection method
4. This could also be used in test scripts to assert the final response.

Examples:

1. Login and pass the auth token in further API calls
2. A Shopping flow would search for products, add product(s) to the cart, encrypt payment method then checkout

A workflow would be a first class concept in Bruno similar to collections.

├── collections
│   ├── POST /login
│   └── PUT  /profile
└── workflows
    ├── Update Profile
    │   ├── 1. login
    │   └── 2. update profile
    └── Shop
        ├── 1. search products
        ├── 2. add item
        ├── 3. encrypt card
        └── 4. checkout

Defining a workflow is simple enough, but how do we pass variables over is the interesting part of this proposal.

In Postman after an API call we can run a “post request script” to set collection variables, which are then reused in rest of API calls. But usually it is difficult to understand what the script does, what variables are set, since these are well… scripts 😃

Workflow implementation

1. Every workflow runs in a new session
2. A session holds a set of variables that can be embedded in request body or headers
3. Each step in the workflow can declare a post request json config
4. This config updates the session variables (using say json query) which are further used down the chain

The idea is… look ma, no scripts!

Update profile workflow steps

1. login post script config

   {
      "token": "$res.data.token"
   }
   

2. update profile schema

   {
     "method": "PUT",
     "url": "/profile",
     "headers": {
       "Authorization": "Bearer $token"
     },
     "body": {
     }
   }
   

Tests:

• Rather than complex asserts in scripts, the workflow could define the expected json at the end of the workflow
• Bruno would compare the final response to the expected json
• The workflow runner could capture and show intermediate step failures.
  • Step gave a non 2xx response
  • Step succeeded but did not contain a value that was supposed to populate a variable

Everything being simple json provides a lot of benefits and opportunities.

@helloanoop I can do a PR if this is something you’d be interested in.

[ajaishankar]

Sorry for late response… on question 2 on how we know if a var is a response var?

Postman has a list of dynamic vars, and for us similarly $res is a special var checked here.

Any expression that refers to $res should be evaluated after a response, others before request…

[helloanoop]

Would it make sense to have the Assert configuration only in the right hand pane? The right hand pane (response pane) only becomes visible after the response arrives

Also we can show the actual values side by side in that Assert tab itself… Not able to visualize the side by side in Assert tab given that right hand pane becomes active after response arrives

@ajaishankar it’d be great if you want to take a stab at implementing this, I feel we are both aligned here on the assertions part. I was thinking we will use the request tab to code the assertions, and the response tab to show the assertion results (kind of like of how postman allows to write scripts in request pane, and displays test results in response pane).