Question: How do you create multiple records inside the portal? Portal inside the layout is a related record. Thanks! Please see the attached image for the reference

[chicodelacruz]

[davidhamann]

There should be numerous ways to do it. For example with the portals parameter to create_record, or multiple calls to create_record in the context of the portal's TO, or running a script to do it based on some given payload.

Can you post a snippet of your code showing how you are doing it currently for this one record?

[chicodelacruz]

Hi, @davidhamann thank you for the response. Still trying to debug my code on how to make multiple creations on the portal above. Right now I can just create a record within the layout. Here is my code snippet. Please disregard the error in my terminal, still trying to familiarize your library. By the way, its really awesome.

[chicodelacruz]

Update on this issue,

Right now I can just create 1 record(first record) in the porta inside the context of my layout. Do you have any suggestions on how can I pass multiple records inside the portal?

Thanks,

[davidhamann]

The create_record method has a portals parameter you could use to create such data. For example:

{'my_portal': [
                {'TO::field': 'hello', 'TO::field2': 'world'},
                {'TO::field': 'another record'}
            ]

So something like fms.create_record(master_layout_data, portals=portal_data).

[chicodelacruz]

Hi david,

Thank you for your response, I tried your solution in this way but I got an error Record is Missing and your suggested solution can handle multiple requests in the portal in just one call? Please see the attached image for reference.

[davidhamann]

Are you sure the error 101 is a result of the create_record call? It looks like it occurs in a different place!?

Can you check if the related record was created via the "transmital" portal?

If you still have issues, please try to make an isolated example, if possible, so I can try to reproduce it here.

To test record creation via portal I just successfully ran the following code, resulting in two new "Notes" records (Notes is the TO used for the notes portal, which is present on the layout I previously specified):

data = {'name': 'David'}
portals = {
    'notes': [
        {'Notes::note': 'This is the first note'},
        {'Notes::note': 'This is the second note'}
    ]
}
created_record = fms.create_record(data, portals=portals)

PS.: It's generally easier to directly post the code here vs. screenshots. Thanks!

[chicodelacruz]

Hi David,

Okay, you gave me an idea of the issue. The issue was on the FileMaker side, the TO for portal setup was not set to allow to the creation of records. Please see the attached image.

Last question, how do you handle this in a dynamic way?

[davidhamann]

You mean dynamically set the relationship's attributes? You cannot do that via the Data API.

In general:

In some situations it might preferable or even required to create related records via a portal (like you did) and commit them all in one go (I'm generally not a big fan of using UI elements for such things). But if it fits your use-case you could also just set the layout to the target table occurrence and then do multiple individual create_record calls for creating your related records and setting the foreign key yourself (with the disadvantage that you might be left with partial data should your program crash mid-way; although you could also set some sort of completion flag for that at the end).

Another way could be to handle the creation with a FileMaker script which you call via the Data API and give it a payload to create your records.

Both options would not require a portal or specific relationship setups (assuming you don't need to create via a relationship for transactions reasons).

[chicodelacruz]

I mean passing the data to the portal in FileMaker Application. Typically I will make forms in a table so the end-user can input 10 to 20 data and pass it into the transmittal portal.

[davidhamann]

Not sure I follow. If you haven't done so, I would suggest having separate layouts for the Data API access and end-user access, so that you can modify the end-user layout at will without worrying to break the DAPI requests.