โ11-28-2017 02:35 PM
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 envelope after the request that gets logged when I call the Netsuite Update snap, which seems like a good option to handle this, but I donโt seem to be able to authenticate using the attached account.
Is there a way to refer to an Accountโs credentials in the SOAP envelope that I can use here? I have a basic SOAP auth account hooked up to the snap but it sure doesnโt seem to want to use it.
EDIT: Just to be clear, manually adding the email and password in the passport is working fine, but is not productionizable for hopefully obvious reason
โ02-22-2019 03:20 PM
Your body statement is invalid as per the SOAP APIโs specs. There is a separate region of null fields you have to declare. Your statement should be:
<SOAP-ENV:Body>
<ns0:update>
<ns0:record ns2:type="ns1:Job" internalId="481756">
<ns1:customFieldList>
<ns4:customField ns4:scriptId="custentity777" ns4:internalId="489" ns2:type="ns4:StringCustomFieldRef">
<ns4:value/>
</ns4:customField>
</ns1:customFieldList>
<ns3:nullFieldList ns2:type="ns3:NullField">
<ns3:name>custentity15</ns3:name>
</ns3:nullFieldList>
</ns0:record>
</ns0:update>
</SOAP-ENV:Body>
EDIT: actually, even this is wrong - both of your values should be in the nullFieldList:
<SOAP-ENV:Body>
<ns0:update>
<ns0:record ns2:type="ns1:Job" internalId="481756">
<ns3:nullFieldList ns2:type="ns3:NullField">
<ns3:name>custentity15</ns3:name>
<ns3:name>custentity777</ns3:name>
</ns3:nullFieldList>
</ns0:record>
</ns0:update>
</SOAP-ENV:Body>
โ02-22-2019 03:22 PM
FYI you can view the WSDL that defines nullFieldList here:
https://webservices.na1.netsuite.com/xsd/platform/v2016_1_0/core.xsd
The main WSDL is here:
https://webservices.na1.netsuite.com/wsdl/v2016_1_0/netsuite.wsdl
โ02-22-2019 04:34 PM
Thanks! I didnโt know this. Itโs odd that it works the way I did it for some types like String. Weโll have to adjust our custom fields code to handle null values this way.
โ02-22-2019 04:57 PM
That would actually be really fantastic, because Iโd love to completely scrap my custom SOAP setup.
While I have your ear, is there any chance you can also file a bug related to the names of custom columns? When you enter raw text for custom columns, it changes the definition after saving & reopening the snap to being [object Object] instead of whatโs expected. The only way to save it properly is to click through the auto completed column name when the Snap processes the SOAP API, which is extremely, extremely painful to do since it takes a long time to load every time.
โ02-22-2019 05:55 PM
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.