Trying to determine proper format for calling a script via API and passing a JSON parameter.

[jasonw75]

Hello.  I'm trying to determine proper format for calling a script via API and passing a JSON parameter.

I'm running the following as a GET via Postman, targeting FMS17:

https://SG-FMS/fmi/data/v1/databases/APITarget/layouts/APIOpen/records/1?script=StoreResults&script.param=TEST

The script is called, and receives the parameter 'TEST'.  However, using only a GET URL , I'm unable to pass a JSON payload.  I'm having trouble finding references to proper syntax for constructing a POST API call to run a script and pass data.  Thanks!

[Wim Decorte]

That's a current limitation of the script endpoint in the Data API:it only supports GET so you cannot use a payload body like you can with POST.  Meaning that everything has to be a URL query parameter.  If you want your param to be json you have to URL encode it and pass it as just text.  And you have to be careful with the URL length restrictions (which we wouldn't have with a POST).

Your URL however does not seem correct if you intend to just run a script, the proper url is:

https://{{server}}/fmi/data/vLatest/databases/{{file_name}}/layouts/{{layout_name}}/script/{{script_name}}?script.param={{param}}

Seems like you are rolling your script call into a data request for a particular record, is that what you want to do?

If you want to call a script and need to pass lots of data, then add a scratch table to your solution and use the POST request to create a record in the scratch table and use the script option in the body.  Or if you don't want to add a table to your solution, use the POST find request instead just to be able to pass the script information in the body.

 

 

[jasonw75]

Thanks, Wim!  Is this script endpoint in the Data API different in FMS18 such that it will support this?  Or perhaps that might be coming in a future version?  The inbound API calls to FM will be from a webserver, not FM.  It will likely be passing in a lot of data, so maybe the POST find request would be best.  Do you have or know an example of a POST Find call, perhaps in a Postman collection?

I hope you're doing well!  Thanks again!

[Wim Decorte]

I take it that you're using 17 then?  The script endpoint is new in 18, I don't think 17 had it.  But in 17 you can tack on the execution of a script through some of the other calls like the find.

I have released postman collections for both 17 and 18, do a quick google and they should turn up.  If not post back here and I'll dig them out.

FMS18's script endpoint is GET only and I'm confident that we'll get a POST one at some point in the future since Claris is aware of this request.  Not sure if it will be in 19 though so don't hold out for that.  After 19 is released Claris has indicated an accelerated version release so hopefully we don't have to wait too long, if it turns out to not be in 19.

 

[jasonw75]

Hi Wim.  Thanks!  I found the FMS Data API 18 collection.  Is that the one you had in mind?

At the moment, we're in FMS17, and not yet able to upgrade to v18.  I tried the following POST in Postman:

https://{{server}}/fmi/data/v1/databases/{{database}}/layouts/{{layout}}/_find

With this body:

{
  "query": [
    {
      "Constant": "1"
    }
  ],
  "script": "SlackNotifyWithParam",
  "script.param": {{param}}
}

 

The variable 'param' is:

 

{"employees":[

{ "firstName":"John", "lastName":"Doe" },

{ "firstName":"Anna", "lastName":"Smith" },

{ "firstName":"Peter", "lastName":"Jones" }

]}

 

And I get the following result:

{

    "messages": [

        {

            "message": "writeString called without a string/Buffer argument: [object Object]"

        }

    ],

    "response": {}

}

 

I think I'm pretty close.  Do you see what may be wrong here?  Thanks!

Edited March 26, 2020 by jasonw75

[Wim Decorte]

There's a 17 collection out there too, there are a few things that were changed in the 18 Data API vs. the 17 one.

You're trying to send a json object to FM but FM expect as string object.  So you need to stringify your json object before you add it to the"script.param" key.

Try it with just a dummy string to verify that it works and then you'll need to find a way to turn your json into string.

[jasonw75]

Hi Wim.  If I were to use FMS18, and the GET method to run a script, is there a character limit or other limit on the parameter, if I stringify it?  Once typical use would be to pass data to create records, and that data content could be large.  Presently, in FMS17, running a POST find, and calling a script works, but takes a few seconds.  Thanks!

[Wim Decorte]

The FMS18 dedicated GET call to run a script won't help you here, since a GET puts everything in a URL you are limited to how long a URL can get.

I would continue to do what you do but with a twist:

don't use a FIND request, but do a CREATE request to a scratch table, and add a script to that call that will read from your scratch table and create the proper records where they belong (or punt that part to a server-side script if it doesn't have to be real-time).   Letting a server-side script take care of creating the actual records may get around your timing issue.  The Data API call would be fast since it wouldn't have to wait for the script to run.

If it has to be real-time then find out where the delay comes from by timing other Data API calls to try and see if all the delay is running the script.  If it is not and just the calls themselves are slow the you need to look at internet speeds and latency between you and the server.  If it is the script is slow then that's a FM optimization task.

[jasonw75]

Great suggestion, thanks!  Would using the FM API to call a script from within FM possibly be faster than PSOS?  I'm struggling to find references to the proper syntax for doing that, while embedding the authentication into the call.  Thanks!

[Wim Decorte]

I don't think it would be faster by default.  Also keep in mind that the Data API script engine is different from the PSoS script engine, they both support different subsets of script steps.  So don't assume that they can both do what is possible client-side.

[jasonw75]

I think I discovered what the latency problem is.  When I call the (small) APITarget database from Postman, the response is quite fast (<30ms), but when I then call a script in the main database from APITarget, the first call from Postman takes 10s, due to a very complicated relationship graph in the main database, which apparently must be loaded.  I discovered that PSOS doesn't get around that problem, but I'm hoping that an API call might.