---
schema_version: "1"
id: 38d204f4c2fb80d5f20c3cdcb56b41993ea19884af1fc8ed92dd633678fb66c2
title: Triggering Flows in Your Development Environment
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/anypoint-code-builder/int-trigger-flows.md
canonical_url: https://docs.mulesoft.com/anypoint-code-builder/int-trigger-flows
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 432176f81d2a3e3ff5c08954e36808c05596173f0bf60fe5313b9a046e7b9748
description: MuleSoft Documentation Site
latest: true
---
---
product: Anypoint Code Builder
version: master
---

# Triggering Flows in Your Development Environment

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

When your integration or implementation builds successfully within Anypoint Code Builder, the
application deploys to your local development environment.

Configure the **HTTP Listener** from [Anypoint Connector for HTTP](https://docs.mulesoft.com/http-connector/latest/) (HTTP
Connector) to trigger the execution of a flow in a deployed application. Or trigger the flow locally
from the built-in terminal in Anypoint Code Builder, or from a VS Code extension like Thunder
Client.

A **Scheduler**, a **Flow Ref**, or any connector trigger or message source can initiate a flow
execution. These components serve as entry points that listen for specific events or time intervals
to start the flow logic.

## Before You Begin

- Complete [Getting Started with Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/start-acb).

- Make sure an integration or implementation project with an HTTP Listener (`<http:listener/>`) is
  available in Anypoint Code Builder.

  To create a project, see [Creating Integrations](https://docs.mulesoft.com/anypoint-code-builder/int-create-integrations) or
  [Implementing APIs](https://docs.mulesoft.com/anypoint-code-builder/imp-implementing-apis), or follow
  [Take Your API Specification from Design Through Deployment](https://docs.mulesoft.com/anypoint-code-builder/tutorials#modular-learning-paths).

## URLs for Triggering a Flow from an HTTP Listener

For integrations and implementations that you build and deploy during the development process, the
URL to use for triggering an HTTP Listener differs depending on whether the listener is within the
configuration XML for a scaffolded interface that is generated from an API specification or within a
configuration XML file that does not implement a scaffolded interface.

Typically, for apps that use an HTTP Listener, you configure the host to `0.0.0.0` and the port to
`8081`. If port `8081` is in use by another application, you can use a similar port, such as `8082`.

- Trigger a flow within a configuration XML that _does not_ contain a scaffolded interface by using
  a URL similar to this one from the terminal:

  http://localhost:8081/mypath

  The port and host are defined in the `<http:listener-connection/>` element, and the endpoint is
  defined by the `path` attribute in the `<http:listener/>` element:

  ```xml
  <http:listener-config name="inbound-request"
        doc:name="Listener Config" doc:id="b5c62f">
    <http:listener-connection host="0.0.0.0" port="8081"/>
  </http:listener-config>
  <flow name="myFlow">
      <http:listener path="mypath" config-ref="inbound-request" doc:name="HTTP /flights" />
      ...
  </flow>
  ```

- Trigger a flow from the listener within a scaffolded interface by using a URL similar to this one
  from the terminal:

  http://localhost:8081/api/my-endpoint

  Notice `/api/my-endpoint` in the example. For this case, the endpoint is defined within the `name`
  attribute of a `<flow/>` element in the interface, and `api` is defined in an HTTP Listener in the
  interface.

  For example, assume that a flow in a scaffolded interface references a flow (`getFlights`):

  ```xml
  <flow name="get:\flights:american-flights-api-config">
      <flow-ref name="getFlights"/>
      <logger level="INFO" message="get:\flights:american-flights-api-config" />
  </flow>
  ```

  Also assume that the `getFlights` flow resides in an XML configuration file for the
  implementation:

  ```xml
  <flow name="getFlights" >
      <set-payload value="Hello Flights!" doc:name="Set payload" doc:id="gwdsmi" />
      <logger doc:name="Logger" doc:id="dnitvb" message="#[payload]"/>
  </flow>
  ```

  The URL to trigger this flow uses `flights` as the endpoint:

  http://localhost:8081/api/flights

  The URL adds `/api` before the `/flights` endpoint to make the request through the
  `<http:listener/>` in the interface. Generally, a listener is located before the router, as in
  this example:

  ```xml
  <apikit:config name="american-flight-api-config"
                 api="resource::bc64acc7-41ad-43b7-9e0a-092182b03271:American-Flight-API:1.0.0:raml:zip:american-flight-api.raml"
                 outboundHeadersMapName="outboundHeaders"
                 httpStatusVarName="httpStatus" />
  <flow name="american-flight-api-main">
      <http:listener config-ref="inbound-request" path="/api/*"> (1)
          <http:response statusCode="#[vars.httpStatus default 200]">
              <http:headers>#[vars.outboundHeaders default {}]</http:headers>
          </http:response>
          <http:error-response statusCode="#[vars.httpStatus default 500]">
              <http:body>#[payload]</http:body>
              <http:headers>#[vars.outboundHeaders default {}]</http:headers>
          </http:error-response>
      </http:listener>
      <apikit:router config-ref="american-flight-api-config" /> (2)
      ...
  </flow>
  ```

  <table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Within the listener (<code>&lt;http:listener/&gt;</code>), the attribute <code>path="/api/*"</code> is set automatically during the scaffolding process.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>The router (<code>&lt;apikit:router/&gt;</code>) is located after the listener in the scaffolded interface within the configuration XML.</td></tr></tbody></table>

## Trigger a Flow

Use the terminal in Anypoint Code Builder to trigger a flow through an HTTP Listener in an
integration or implementation project that is deployed locally.

> [!TIP] The examples in this procedure show how to trigger the flow with a `curl` command from the
> terminal. You can also use Thunder Client, a third-party extension for VS Code, to trigger a flow
> with the same URLs.

Before attempting to trigger a flow, review
[URLs for Triggering a Flow from an HTTP Listener](#trigger-urls), and verify that you meet the
prerequisites in [Before You Begin](#before-you-begin).

1.  Before starting your Mule app, confirm that the connection to the listener is successful:

    From the code editor, above the HTTP Listener configuration (`<http:listener-config/>`), click
    **Test Connection**.

    - If the test succeeds, you see a **Connection is valid** message.

    - If the connection fails, an error message indicates that the connection was unsuccessful. If
      the app is running when you click **Test Connection**, this error message appears:
      `Invalid Connection Got status code: 500 when trying to resolve a Mule Runtime operation. Reason: 'Internal Server Error.`

2.  Open the Run and Debug panel.

    Show me how

    - Click the ![](/mulesoft/current/en-us/anypoint-code-builder/_images/icon-run-debug.png) (**Run and Debug**) icon in the activity bar.

    - Use the keyboard shortcuts:

      - Mac: Cmd+Shift+d

      - Windows: Ctrl+Shift+d

    - Select **View** > **Run**.

3.  Click the ![](/mulesoft/current/en-us/anypoint-code-builder/_images/icon-start-debug.png) (**Start Debugging (F5)**) icon for **Debug Mule
    Application**.

    Alternatively, if the **Start Debugging (F5)** icon is not present:

    1.  Click **Run and Debug**.

    2.  If a **Select debugger** dropdown menu appears, select **Mule Xml Debugger** to initiate the
        debugging session:

        ![Run and Debug button and Mule XML Debugger menu item](/mulesoft/current/en-us/anypoint-code-builder/_images/run-debug-imported-folder.png)

        When the application deploys successfully, you see a `DEPLOYED` log message in the output
        panel:

        \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
        \* - - + DOMAIN + - - \* - - + STATUS + - - \*
        \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
        \* default \* DEPLOYED \*
        \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

4.  Open the Terminal window in the console:

    - Select **View** > **Terminal**.

    - Alternatively, press Ctrl and then press the backtick key (\`).

5.  In the terminal, click the name of the shell to use, such as PowerShell (for Windows), Bash
    (`bash`), or Z shell (`zsh` for Mac).

    Alternatively, click the **+** icon in the terminal to open a new command prompt.

6.  At the command prompt, provide a `curl` command to trigger the flow.

    - To trigger a flow from an HTTP Listener that doesn’t reside within an interface, use `curl`
      with a URL similar to this one:

      $ curl localhost:8081/mypath

      Use `localhost` instead of `0.0.0.0`. Get [more information](#trigger-url-no-interface) about
      triggering the endpoint.

      If successful, the command returns a response.

    - To trigger a flow from an HTTP Listener that resides in a scaffolded interface, use `curl`
      with a URL similar to this one:

      $ curl http://localhost:8081/api/mypath2

      Use `localhost` instead of `0.0.0.0`, and add the listener `path` for before the router (such
      as `api` for most scaffolded interfaces) and the endpoint (such as `mypath2`) to the URL. Get
      [more information](#trigger-url-interface) about triggering the endpoint.

## Trigger a Scheduler Component On Demand

A Scheduler component waits for its configured fixed frequency or cron expression to elapse before
triggering a flow. Instead of waiting for that interval during local testing, you can trigger a
Scheduler on demand while your Mule application is running, whether or not you’re in a debug
session.

This feature invokes the Scheduler’s own trigger, it doesn’t bypass the Scheduler or create a
temporary schedule. The flow runs exactly as it would on a natural tick, so breakpoints and
interceptors behave the same way.

The on-demand trigger is for local testing only. It’s not available for applications deployed to a
remote environment. In a multi-project workspace, the trigger is scoped to the app that owns the
Scheduler, so triggering a Scheduler in one app doesn’t affect Schedulers in other running apps.

### Trigger a Single Scheduler

To trigger one Scheduler on demand from the canvas:

1.  Open the Run and Debug panel.

    Show me how

    - Click the ![](/mulesoft/current/en-us/anypoint-code-builder/_images/icon-run-debug.png) (**Run and Debug**) icon in the activity bar.

    - Use the keyboard shortcuts:

      - Mac: Cmd+Shift+d

      - Windows: Ctrl+Shift+d

    - Select **View** > **Run**.

2.  Click ![](/mulesoft/current/en-us/anypoint-code-builder/_images/icon-start-debug.png) (**Start Debugging** (F5)) to start your application,
    either in Run or Debug mode.

3.  Open the configuration XML file that contains the Scheduler, and switch to the canvas view.

4.  On the Scheduler component, click the **Trigger** (![](/mulesoft/current/en-us/anypoint-code-builder/_images/icon-trigger-scheduler-play.svg))
    button.

    After triggering the Scheduler, the button changes to **Re-trigger**
    (![](/mulesoft/current/en-us/anypoint-code-builder/_images/icon-trigger-scheduler-retrigger.svg)) so you can fire the Scheduler again.

The flow runs exactly as it does when the Scheduler triggers naturally. If you set a breakpoint on a
processor in the flow, execution pauses there just as it does for a scheduled run.

> [!TIP] To trigger every Scheduler in the running application at once, use the **Trigger All
> Schedulers** button on the **Run and Debug** toolbar instead of triggering each Scheduler
> individually.

## See Also

- [Add a Breakpoint](https://docs.mulesoft.com/anypoint-code-builder/int-debug-mule-apps#add-breakpoint)

- [Scheduler Component](https://docs.mulesoft.com/anypoint-code-builder/acb-component-scheduler)
