Yes.
Awesome. When you invoke the method from console, what does the request body look like?
It’s simply -d $‘“mystring”’
In the old method, it would be a lone string parameter. This worked in the backendless console just fine, but failed on the client.
Changing the schema to -d $‘{“requestId”: “mystring”}’ works in both the console and on the client
If you want to review the difference between the working and not-working functions, under our application I have deployed 2 almost identical cloud code functions: pingRequestForResult and pingRequestForResultOLD
The old one would fail to invoke on the client when given a String as a parameter.
Thank you for the information, Brandon. I am writing up a ticket for the development team. Here’s a summary:
When a method is declared as shown below:
/**
* @param {String} requestId
* @returns {Promise<Object>}
*/
async pingRequestForResultOLD(requestId) {
The following approach to invoke it fails:
However, changing the client code to the following works:
Please confirm if I captured it correctly.
Regards,
Mark
You also have to change the @param declaration to Object for it to work.
It would be more accurate to say:
When a method is declared as shown below:
/**
* @param {String} requestId
* @returns {Promise<Object>}
*/
async pingRequestForResultOLD(requestId) {
The following approach to invoke it fails:
Backendless.APIServices.invoke(
"MyService",
"MyCloudCodeFunction",
"paramaterstring"
).then((result) => {
Instead it must be declared like so:
/**
* @param {Object} requestId
* @returns {Promise<Object>}
*/
async pingRequestForResultOLD(requestId) {
Backendless.APIServices.invoke(
"MyService",
"MyCloudCodeFunction",
{paramaterName: "paramaterstring"}
).then((result) => {
So in order to pass a String as a single parameter you must wrap it in an object.
Thanks.