FoMS Experts

News / Technology

EASY TO GET LOST

HTTP Request in the middle: Crossing the boundary

HTTP Request in the middle: Crossing the boundary
Share
FacebookGoogle plusLinkedInStumbleuponTwitter
M. Petricevic24.6.2021

There is an HTTP Request in the middle of a flow. Which values are available within the same flow after the application steps to the processor following the HTTP Request?

Let's take a look at an example. There is an HTTP Request in the first flow named, well, firstFlow followed by a Logger. The role of the Logger in this case is simply to show which values are available in the flow after the HTTP Request. Quite trivial, one might think. Why would any values be added or lost in the first flow after the HTTP request is submitted? Let's take a closer look at what happens in this situation.

A web client submits a request with query parameters to the HTTP Listener in the first flow. Let us call these query parameters the original query parameters. Right after, the Set Variable and the Set Payload processors are used to create a variable with an assigned value and perhaps to manipulate the payload received from the request, respectively.

The payload received by the HTTP Listener in the first flow will be there no matter if the Set Payload processor is there. The Set Variable processor is of more importance for this example though. Without it, no variable would be created by itself.

At this point, the HTTP Listener in the second flow will receive the request submitted by the POST HTTP Request in the first flow and return a response. The Logger processor in the second flow will do its job and display the values available in this flow – namely the payload and any query parameters sent from the first (not to be confused with the original query parameters submitted to the first by the web client). The application then steps back to the first flow. Now it's time for the first flow's Logger to display the available values.

Surprise, surprise! The Logger in the first flow displays the variable and the payload but not the original query parameters! Had we used Flow Reference instead of POST HTTP Request and POST HTTP Listener, the original query parameters would not have been lost. This is because an HTTP Request crosses the boundary.

The two flows in the image are not within each other's boundaries. Flows connected by the Flow Reference processor instead of the HTTP Request-Listener pair may be seen as a single flow even though they are not. Rather, we say that they are within the same boundary and nothing is lost. It's just a matter of jargon. Remember, the main point of using Flow Reference is reusability.

Boundary is hardly a fancy IT word but works well to illustrate the difference between flows connected by Flow Reference and those connected by an HTTP Request-Listener pair. The second flow in the image is irrelevant to what query parameters’ values the Logger in the first flow will show, but it serves a purpose. The HTTP Request from the first might direct to an external website and the Logger in the first flow would still not show the original query parameters.

If there is one thing to take home, please remember that query parameters are lost in the original flow after an HTTP Request.

RELATED ARTICLES

OTHER ARTICLES

Relax, some like it soft-coded

KEPT IN ONE PLACE FOR ALL TO USE

Relax, some like it soft-coded

MUnit testing: Basics

MOCKER, TESTER, SETTER, SPY

MUnit testing: Basics

Tough Choices: How to route the app

CHOICE ROUTER IN A MULE APP

Tough Choices: How to route the app

OLDER ARTICLES

Register now