Soap Execute snap - Account creds in header

[jamesv]

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

[jamesv]

ptaylor:

<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> <ns4:customField ns4:scriptId=“custentity15” ns4:internalId=“119” ns2:type=“ns4:DateCustomFieldRef”> <ns4:value/> </ns4:customField> </ns1:customFieldList> </ns0:record> </ns0:update> </SOAP-ENV:Body>

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>

[jamesv]

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

[ptaylor]

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.

[jamesv]

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.

[ptaylor]

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.