--- schema_version: "1" id: da111acc9a67986cc9c39c551c600356641a7799fb3fde09bbf8cf25362c5b11 title: Obtaining Flow Output and Sending Responses from a Message Source collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-sdk/latest/sources-response.md canonical_url: https://docs.mulesoft.com/mule-sdk/latest/sources-response source_site: docs.mulesoft.com content_type: documentation content_hash: 2473c39c3b77b7cd0cdbc2a0efaaf360436d83aa9db9dc6f9795dcd6e79c4678 description: MuleSoft Documentation Site release: "1.13" latest: true --- --- product: Mule SDK version: 1.13 is-latest-version: true keywords: mule, sdk, sources, listener, triggers, response, output --- # Obtaining Flow Output and Sending Responses from a Message Source > For the full documentation index, see: https://docs.mulesoft.com/llms.txt One of the main properties of a Source indicates whether it generates a response or not. Examples of sources that do not emit a response: - A File listener - Salesforce streaming API - A Scheduler element - A Source that listens for asynchronous push notifications Sources that do emit a response: - A TCP server - An HTTP server - A JMS server As you can see, this classification is highly non-deterministic, for example: - Although an HTTP server supports sending a response, the user might choose not to do so. - Although a JMS listener might respond by sending a message to a reply queue, it might not, depending on the message headers. Even if a Source can send a response, the Source might not send a response even if the message was processed successfully. There are logic or configuration circumstances that might skip the process of sending the response. To specify that your source can generate the response, it must be annotated with `@EmitsResponse`. Notice that this simply tells the runtime and tooling that the source has the capability of doing so. However, note that the neither the SDK nor the runtime will: - Validate that a source that emits a response actually emits a response. - Prevent a source from sending a response even when the source does not declare that it emits responses. ## Callback Parameters Each time the flow finishes processing a message generated by the source, the source might need to obtain the response that the flow has generated. You do this through _callback methods_. Callback methods are used to tap into the responses generated by the flow that owns the source. You can do this by declaring methods annotated with `@OnSuccess` , `@OnError`, and `@OnTerminate`. These methods are declared in a similar fashion as operations, but they need to be void because they listen for the response but cannot alter it. Each of the parameters in these callback methods is evaluated in the same manner as operations (including auto-transformation). Notice, however, that because these callbacks are executed in response to the runtime processing a message, the callbacks can accept expressions (the default). > [!TIP] Even if the source does not emit responses, it might need callback methods for releasing > resources, logging, auditing, and so on. ## Listening for Successful Outputs The source can declare a method with the `@OnSuccess` annotation so that the method is executed when the flow successfully processes the message (either because no errors were thrown or because they were all handled gracefully). This method can have arguments that are treated as source parameters. Note that the user of the connector cannot (and does not need to) tell the difference between a regular parameter and a callback one. For that use, it is all the same, and Studio shows which parameters accept expressions and which ones do not. The user should not need to worry about anything else. Another important thing to keep in mind is that the processing of the message once the source has pushed it to the flow is asynchronous. So the `@OnSuccess` method will also be invoked asynchronously. Here is another oversimplified example from the HTTP connector: ```java @EmitsResponse (1) public class HttpListener extends Source { @Override public void onStart(SourceCallback sourceCallback) throws MuleException { httpServer = serverProvider.connect(); httpServer.listen(path).onRequest(request -> { SourceCallbackContext ctx = sourceCallback.createContext(); (2) ctx.setVariable("responseContext", new HttpResponseContext(request.getResponseSender())); (3) Result result = requestToResult(request); sourceCallback.handle(result, ctx); (4) }); } @OnSuccess public void onSuccess(@Content String responseBody, @Optional String responseStatusCode, SourceCallbackContext callbackContext) (5) throws Exception { if (hasResponse(responseStatusCode)) { (6) HttpResponseContext responseContext = callbackContext.getVariable("responseContext"); (7) responseContext.sendResponse(responseBody, statusCode); (8) } } } ```
1The example annotates the source with @EmitsResponse because this HttpListener might send a response.
2Because the @OnSuccess method is invoked asynchronously (and most likely in parallel), it is necessary to communicate state to the callback method. More precisely, it is necessary to provide some kind of reference regarding the actual request to reply into. To accomplish that, the example creates a new SourceCallbackContext using the SourceCallback.
3The example adds a variable into the context that holds an HttpResponseContext. This is a custom object defined in the connector that knows how to send responses.
4The example generates and pushes the message through the SourceCallback, using both the Result object and the newly create context.
5The callback method has two parameters, a @Content one for the body of the response to be sent and the HTTP status code of the response. There is a third argument of type SourceCallbackContext. This is not a parameter but a way to tell the SDK that to recover the same context that was passed to the handle() method.
6Because the HTTP protocol does not always send a response, the example checks to see if the response status code requires the response to be sent or not.
7If a response is needed, the example recovers the response context that was originally set on the context.
8The response is sent.
## Listening for Error Outputs Similar to `@OnSuccess`, the `@OnError` is executed when an unhandled error is thrown by the flow, for example: ```java @OnError public void onError(@Optional @DisplayName(ERROR_RESPONSE_SETTINGS) @NullSafe HttpListenerErrorResponseBuilder errorResponseBuilder, SourceCallbackContext callbackContext, Error error) { } ``` In this case, the method is very similar to the success example. It also receives parameters and the callback context, and it sends an error response back to the requester. It can also receive an Error object. This is the Mule Error object that contains information about the obtained failure. > [!TIP] The `Error` object is not a Java `java.lang.Error` object but an SDK > `org.mule.runtime.api.message.Error`. ## Content Parameters Callbacks accept content parameters just like any operation. In the case of the HTTP connector, the `HttpListenerResponseBuilder` uses them so that DataWeave can be used to transform the flow’s result into whatever format the connector intends to return. All the concepts of content and primary contents apply, as well as their associated restrictions. ## On Terminate A source does not need to provide `@OnSuccess` or `@OnError` methods. A source can declare the ones it needs or none at all. However, if at least one of them is defined, then you also need to define an `@OnTerminate` method. This is required because the `@OnSuccess` or `@OnError` might fail. If either of them throws an exception, a remote system might hang as it waits for a response, resources might leak, audit logs might be left uncompleted, and so on. Here is an example of an `onTerminate` method: ```java public void onTerminate(SourceResult sourceResult) { Boolean sendingResponse = (Boolean) sourceResult.getSourceCallbackContext().getVariable(RESPONSE_SEND_ATTEMPT).orElse(false); if (FALSE.equals(sendingResponse)) { sourceResult .getInvocationError() .ifPresent(error -> sendErrorResponse(new HttpListenerErrorResponseBuilder(), sourceResult.getSourceCallbackContext(), error, null)); } } ``` The method receives a `SourceResult` object that contains optional errors that might have occurred in either the `onSuccess` or `onError` methods and the associated `SourceCallbackContext`. In the example above, the method sends a generic error response in case an error was found. ## Next Step - [Sending asynchronous responses from a Message Source](https://docs.mulesoft.com/mule-sdk/latest/sources-async-response)