Forum Discussion

jamesv's avatar
jamesv
New Contributor II
8 years ago

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

21 Replies

  • jamesv's avatar
    jamesv
    New Contributor II
    8 years ago

    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.

  • Jagdish_Manikon's avatar
    Jagdish_Manikon
    New Contributor
    7 years ago

    Hi James,

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

    • ptaylor's avatar
      ptaylor
      Employee
      7 years ago

      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.

      • Jagdish_Manikon's avatar
        Jagdish_Manikon
        New Contributor
        7 years ago

        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

  • ptaylor's avatar
    ptaylor
    Employee
    7 years ago

    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.

    • ptaylor's avatar
      ptaylor
      Employee
      7 years ago

      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?

    • jamesv's avatar
      jamesv
      New Contributor II
      7 years ago

      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.

      • ptaylor's avatar
        ptaylor
        Employee
        7 years ago

        Interesting. Is there a support ticket about that issue?

  • ptaylor's avatar
    ptaylor
    Employee
    7 years ago

    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's avatar
      jamesv
      New Contributor II
      7 years ago

      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's avatar
        ptaylor
        Employee
        7 years ago

        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.