Soap Execute snap - Account creds in header
I’m building a custom SOAP Execute snap to replace Netsuite snaps to work around a limitation with custom fields in Netsuite snaps that require fields entered to not be null.
I’ve modeled my SOAP e...
Forum Discussion
Our custom fields support has been overhauled in our new release. The full names of the custom fields (not their script IDs) are now integrated into the input schema of the snap so that you can map them in the Mapper attached to its input, just like standard fields. They appear under “customFields” where applicable, at the root level and inside any applicable sublists. Basically, wherever you would have previously seen the standard but unusable “customFieldList” array, which we now hide. When you map values to “customFields”, the snap will transparently map them to the right places in the “customFieldList” in the SOAP request, along with their internalIds, etc. I think you’ll find this is a great improvement over the Custom Fields table in the snap settings, which still works but is now deprecated – you won’t even see that table for a new instance of a snap, or for an instance which didn’t already have values in the table.
Awesome, glad to hear it! I’ll come running back here if I ever have any issues 😉
James, I’m happy to say we’ve released a patch for the NetSuite snap pack, netsuite7779, which addresses this issue. The NetSuite update/create snaps now handle null field values correctly, for both standard and custom fields, by sending a request with these fields listed in the nullFieldList. Your workaround to set the nullFieldList explicitly should no longer be necessary. This build is available as the Latest netsuite version in the production and uat environments.
