Parameters for connectors - Validation

Q&A
1

I’m trying to use a parameter for a REST client, and I can´t find a way to provide the correct value to the conector.
I’t seems that it is validating the parameter VALUE against this regular expression:([1]+|^$)[a-zA-Z0-9$]*

this is the stacktrace:

org.bonitasoft.engine.expression.exception.SInvalidExpressionException: PROCESS_DEFINITION_ID=5089973527243206230 | PROCESS_NAME=Actualización de Precios Sitio Web | PROCESS_VERSION=1.2 | PROCESS_INSTANCE_ID=17011 | ROOT_PROCESS_INSTANCE_ID=17011 | FLOW_NODE_DEFINITION_ID=7951134039297032835 | FLOW_NODE_INSTANCE_ID=340053 | FLOW_NODE_NAME=Login Oracle | CONNECTOR_IMPLEMENTATION_CLASS_NAME=Login | CONNECTOR_INSTANCE_ID=340022 | The expression content does not matches with (^[a-zA-Z]+|^\$)[a-zA-Z0-9$]* in expression: SExpressionImpl [name=login_form_port, content=login_form_port, returnType=java.lang.String, dependencies=[], expressionKind=ExpressionKind [interpreter=NONE, type=TYPE_PARAMETER]] at org.bonitasoft.engine.expression.ParameterExpressionExecutorStrategy.validate(ParameterExpressionExecutorStrategy.java:90) at org.bonitasoft.engine.expression.impl.ExpressionServiceImpl.validateExpression(ExpressionServiceImpl.java:107) at org.bonitasoft.engine.expression.impl.ExpressionServiceImpl.evaluate(ExpressionServiceImpl.java:81) at org.bonitasoft.engine.core.expression.control.api.impl.ExpressionResolverServiceImpl.evaluateExpressionWithResolvedDependencies(ExpressionResolverServiceImpl.java:213) at org.bonitasoft.engine.core.expression.control.api.impl.ExpressionResolverServiceImpl.evaluateExpressionWithResolvedDependencies(ExpressionResolverServiceImpl.java:208) at org.bonitasoft.engine.core.expression.control.api.impl.ExpressionResolverServiceImpl.evaluateExpressionWithResolvedDependencies(ExpressionResolverServiceImpl.java:208) at org.bonitasoft.engine.core.expression.control.api.impl.ExpressionResolverServiceImpl.evaluateExpressionWithResolvedDependencies(ExpressionResolverServiceImpl.java:208) at org.bonitasoft.engine.core.expression.control.api.impl.ExpressionResolverServiceImpl.evaluateExpressionsFlatten(ExpressionResolverServiceImpl.java:120) at org.bonitasoft.engine.core.expression.control.api.impl.ExpressionResolverServiceImpl.evaluate(ExpressionResolverServiceImpl.java:83) at org.bonitasoft.engine.core.connector.impl.ConnectorServiceImpl.evaluateInputParameters(ConnectorServiceImpl.java:295)

is this really the expected behaviour? Should I provide parameter in another way?

From the source code , I got this comment:

@Override public void validate(final SExpression expression) throws SInvalidExpressionException { super.validate(expression); **// $ can be part of variable name** if (!expression.getContent().matches("(^[a-zA-Z]+|^\\$)[a-zA-Z0-9$]*")) { throw new SInvalidExpressionException("The expression content does not matches with (^[a-zA-Z]+|^\\$)[a-zA-Z0-9$]* in expression: " + expression, expression.getName()); } 
}
so I understand why there is such validation, but it prevents me from using ":" in a parameter, or use a port number (it should start with a letter).

Thank you
Germán

  1. a-zA-Z ↩︎

1 Like
2

This is pretty standard practice, not being able to use special characters. You need to encode/decode them accordingly.

See here - the answer with 731 ups…

http://stackoverflow.com/questions/10786042/java-url-encoding-of-query-string-parameters

regards
Seán

PS: As this reply answers your question, please mark as resolved.

3

This issue is very annoying.
I want for instance to have a documentation url I can point the user to in the emails I am sending.

I am defining a parameters which seems to be the correct solution.

Now settings this parameter (string) to a valid string (such as http://my.url.com/some_doc) fails. I tried encoding the string as well and it fails as well. Where can I change this `(^[a-zA-Z]+|^\$)[a-zA-Z0-9$]*` that sounds way too strict here!

4

I am running into the same issue trying to pass an API_TOKEN to a REST connector.

My token is simple and matches [a-zA-Z0-9$]*.

It is actually an alphanum string of 30 chars. I defined them as parameters and I passe it into the body of my connector:

```
{

  "token": ${my_token_paremeter};

}
```
 

I tried both ${my_token_paremeter} and "${my_token_paremeter}" and both fail telling that my parameter does not match the mentioned regexp whereas it does. This issue is really stupid....

Did anyone figure this out? There has been new version of Bonita, we now have bells and whistle dark theme but the core problems remain...

5

As it turns out, the issue is even more stupid than I thought... the issue is not the CONTENT of the parameter but its NAME.

If your parameter is named as "my_parameter", you are in trouble.

Now if your parameter is named as "myParameter", it works...

Of course, the UI to create parameters does not warn you about that... Moreover, it works in some cases, not in others. Those issues make Bonita a pain in the butt to use as you search for hours for stupid non-sense problems.

Bonita: if you want to be fancy with regexp, put them everywhere or don't use them. But you cannot use them in some places and not in others.

6

A Tip on displaying CODE/LOGS correctly in Posts:

Do not use the Supplied Buttons above, for some reason they refuse to work correctly, and despite bringing it to Bonitasofts attention, it’s low priority.

To Show Code/Logs correctly use

< code >
your code/log
< /code >

removing the spaces to allow the showing of code/logs correctly as here:

your code/log

You should still be able to edit your post to ensure the correct formatting of the code to help us understand it easier.

Thanks and regards
Seán

7

Hi @Seán, thank you for your comment and your answer. This is not an encoding issue, Bonita is expecting that ALL the parameters values are compilant with the java attribute/variable standard, just in case it is used to dinamically create a variable.
Example: I defined a parameter: “endpoint_port” with value “8082”. Since the value starts with a number, it’s not accepted.
Regards

8

what’s the actual REST call you’re trying to make, passing a parameter as a number is perfectly OK…