Contact Us 1-800-596-4880
  1. Homepage
  2. Anypoint Code Builder
  3. Developing Integrations

  4. Triggering Flows in Your Development Environment

Triggering Flows in Your Development Environment

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 (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

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:

    <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):

    <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:

    <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:

    <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>
    1 Within the listener (<http:listener/>), the attribute path="/api/*" is set automatically during the scaffolding process.
    2 The router (<apikit:router/>) is located after the listener in the scaffolded interface within the configuration XML.

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.

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, and verify that you meet the prerequisites in 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 (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 (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

      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 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 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 (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 (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 () button.

    After triggering the Scheduler, the button changes to Re-trigger () 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.

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