Introduction to the Problem

In OutSystems, screens can have input parameters. These parameters are entered in the browser in the form of URL query parameters (for example: www.yourdomain.com/yourapp/yourscreen?InputParameter=123).

These query parameters are case-sensitive by design, and usually this is ok. But also what this means is that if a parameter in the URL uses an incorrect casing, the values will not be received by the screen (it’s also worth mentioning that the rest of the URL is correctly interpreted even if the casing is changed).

Whatever the reason that leads to an incorrect parameter casing, whether caused by user error or other factors, the point is that it happens, creating the need to fix the issue.

In a high-code React application this issue is easily solved by checking the casing of the existing parameters, and reassigning the corresponding variables with the correct values.

In OutSystems things are a little bit more difficult, and if you have already tried to solve this issue you have stumbled upon problems regarding screen lifecycle and the fact that when the OnInitialize event runs, the screen URL is not yet available (when performing internal navigation, the OnInitialize event of the destination screen runs while the browser is still on the origin screen).

Solution

So how can we address this issue? With a bit of JavaScript and ingenuity! Don’t worry, if you don’t want to code your own solution, I have a handy Forge component ready to be implemented in your app :)

In this article I will present two approaches, one that is a bit slower to act but easier to implement, and another that is much faster but a bit more involved to implement (hint: one redirects to a corrected URL, and the other one reassigns the values of the screen input parameters to the respective variables).

The key to solving this issue in OutSystems is to first check if there is an issue with the URL parameters, and then to only take action if there is an issue with them. This check is done by comparing the parameter names received in the URL with the expected ones.

Both methods are implemented on the OnInitialize event, at the very start of the flow, and both will only kick in if external navigation is used (when the user uses a link to navigate to the screen).

Method 1: In this method we will use the client action from the component to check each query parameter individually, and take action only if needed (with an if and an assign).

The Client Action CheckAndGetParamWithWrongCasing has one input parameter:

• ParameterName: type text, expects the name of the parameter to be checked

and two outputs:

• ExistsButWithDifferentCasing: type Boolean, this parameter returns TRUE if the casing of the parameter on the URL is incorrect, or FALSE if there is no issue with the parameter name.
• ParameterValue: type text, this parameter returns the data value of the parameter as read from the URL

Regarding the used pattern, here are the steps and reasoning behind them:

• Call the CheckAndGetParamWithWrongCasing, using the one of the parameter names as an input.
• Use an ‘if’ node, and on its condition use the output parameter ExistsButWithDifferentCasing from the previous Action. This will let the flow reassign the variable or to skip the Assign node.
• On the TRUE branch place an Assign. This will assign the output ParameterValue from the Action to the corresponding parameter. Remember to convert to the correct type if needed, as the output of the action is always text.
• Repeat these steps for all input parameters of the screen.

Note: This method should be used in such a way that no assign will happen if the parameter name is correct. If this pattern is not followed then navigation issues are likely to arise (because of the already mentioned OutSystems screen lifecycle).

Method 2: This method is super simple to implement as you only have to add a single Client Action and the beginning of the OnInitialize handler, and feed it a text list of parameter names. It will check if any query parameter is incorrect, and if so, it will correct the URL and redirect the screen to it. If all query parameters are correct no action is taken.

As you can see from the above image, you only have to add the CorrectAlteredParametersAndRedirect Client Action to the OnInitialize, and to write a comma-separated list of parameters (in the case above “ParamOne,ParamTwo,ParamThree”).

Because it works by forcing a redirect to the URL with the corrected query parameter names, it is a bit slower to act when wrong parameters exist. On the upside, because a redirect exists, the URL on the browser will also be corrected. Also, no type infering is needed for the corrected parameters.

Possible Issues

First of all, this is a fallback method, probably it’s on the verge of being considered an anti-pattern, and as such some problems may arise. On the other hand if you really need to implement case insensitive query parameters in OutSystems, there are not many other ways to do it.

As mentioned before, we are acting on the input parameters of a screen, from the OnInitialize handler, and because of the way the screen life cycle works in OutSystems this can be tricky.

Through testing is advised, focused on the input variables of the screens that use this component, but if the described patterns are used, no problems are to be expected.