The FileMaker API > Create Record

Lounge (Discussions)
, , ,
1

Hi All,

The FileMaker API docs for Create Record defines the Payload as...

{

"fieldData": {},
"portalData": {},
"script": "string",
"script.param": "string",
"script.prerequest": "string",
"script.prerequest.param": "string",
"script.presort": "string",
"script.presort.param": "string"

}

Some Questions...

  1. The Payload is an Object and NOT an Array.
    Does that mean that “Create Record” is only used to create one parent record per Request?

  2. When you want to create one parent record with associated child records, it would seem that doing it with a single call would be the most efficient (rather than creating the parent record and the related child records as separate calls. Is that true?

  3. When you want to create more than one parent record with associated child records, is the best practice to Post one by one, or to send a JSON Array and process the Array with a script and script.param?

2 Likes
2

#1: yes

#2: depends on your definition of "most efficient", what's the efficiency you have in mind? Minimizing the # of calls to the API? Speed?

#3: best practice? No. Because it depends immensely on whether your server can handle the scripting engine load you want to put on it. By invoking the DAPI script engine you're adding one more session to the server in addition to the pure DAPI session.
Plus it delays the response to the caller which usually is a big no-no in the world of calling APIs, you don't want to block the calling thread for that long.

1 Like
3

On Question #1
Thank you.

On Question #2
I was thinking in terms of minimizing https calls and associated overhead.

In the use case that I am working on a parent record might have 0 to 50 child records.

That would seem to fit reasonable well within a single call. Light use so we should be OK.

On the original posted, I did not want to overload it with the following question…

Q4) I have heard that the FileMaker Data API is “transactional". Is that confirmed? Documented? (This would apply more to Edit Record.)

On Question #3
Make sense! Sounds like refraining from scripting when possible can give you a better architecture.

Single calls it is. Easier to code as well.

This DATA API thing is pretty cool.

Thanks again.

1 Like
4

That got me curious now:

  • Are child & parent part of the same transaction?
  • does portalData require a portal or would any related field do? No Portal Required
  • can you write to more than one portal? Yes
  • if you need a transactional approach, would you create a transaction record with portals to everything you need to create at the same time, or do you need to put something together using the modId?

Sorry for being lazy and not looking up the official documentation first, but I suspect it won't say much about transactions.

Ended up looking at FileMaker 19 Data API Guide and choose to answer some myself, please correct me if I am wrong.

5

Q #1

They are part of the same Get Records and/or Create Record call (if you have a portal on the layout)

Q #2

Not sure. Tested and working here for both Get Records and Create Record with 1 portal on the layout

Tip: Create Record requires "allow creation…” checkbox (on the relationship level) to be checked

Tip: Use Get Records to deduce the "portalData": {}, syntax for Create Record

Q #3

Good question. Not yet tested here.

Q #4

Good Question. Similar to mine above. One cool thing that I am seeing about the Data API, is how much it can do by itself.

Much less parsing of JSON and setting of fields. Data gets set auto-magically.

1 Like