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 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

I worked with Snaplogic support to solve this, shout out to Mina!

I basically just set up a simple AES encryption passport as an account, encrypted a file and saved it to the specific project to limit permissions, and set up the pipeline to join in the password so everything stays in memory only.

Unfortunately this still logs the password with the SOAP request, but we consider this a good enough solution that avoids storing the password directly in the definition of the pipeline! If anyone has a tip on how to obfuscate the password in the logs that’d be rad to hear but for now this problem is effectively solved.

Hi James,

Did you set up the soap snap with the token based credentials inorder to connect to NetSuite ?

Can you please say more about this? I’m not sure what you mean. If you set a custom field to null, the previous value is removed.

Have you tried doing this with the 4.16 version of the custom field functionality, where the values are mapped like standard fields in a Mapper in front of the NetSuite snap?

Unfortunately, using token based authentication with SOAP Execute is infeasible due to the complexity and time-based nature of that form of authentication. You’re limited to credentials-based authentication with SOAP Execute and NetSuite.

When i am trying to use the credential based authentication it asking me for a two factor authentication if i make my roles less then it prompting with insufficient permissions.

I am really finding hard time to connect with credential based authentication

Ugh, yes. NetSuite has started to enforce 2FA for credentials-based access. If your account requires that now, then yes, I’m afraid the SOAP Execute workaround may not work for you. Have you tried adding permissions to the other role?

I tried permissions to other roles but it doesn’t have access to the specific pages or objects i am looking for it needs full access or Admin previleges inorder to view the pages but the full Access or admin previleges need 2FA.

But you did try to add the permissions you need to an existing role that doesn’t require 2FA?

Date types are not parsed properly in custom body fields and thus if you want to use the standard snaps you cannot use null values.

Interesting. Is there a support ticket about that issue?

IIRC I tried to report this as a part of asking for help with a workaround.

I think there was another issue relating to null fields still not being updated properly which is why I also did this. I mean, I asked this over a year ago, lol.

It’s probably worth checking it out as it is definitely still a problem or is at least ticketed - I almost did this workaround again very for a much more complicated series of Netsuite SOAP calls but gave up when I realized I didn’t actually have to change the number of date columns we’re already splitting calls across, and it doesn’t need proper updates as we expect only to create new Netsuite objects using the process.

yes i did it didn’t work

James, I just tested this. The error is happening on the NetSuite side. I verified that by sending a request via Postman. Here’s the SOAP request (the body of it):

<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>

and the response:

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>
soapenv:Body
soapenv:Fault
soapenv:Server.userException
java.text.ParseException: Invalid dateTime format:

<ns1:hostname xmlns:ns1=“http://xml.apache.org/axis/”>partners002.prod.svale.netledger.com</ns1:hostname>

</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>

The other custom field is a string. Setting that to null works fine.

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>

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

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.

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.

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.