AnsweredAssumed Answered

Netsuite "Convenience Lookup" Bug

Question asked by GuinScholl3001 on May 14, 2016

I'm hoping someone from Boomi can take a look at the following details and perhaps suggest a fix.  I know the work-around is to simply do the custom list lookups manually and  not rely on the "Convenience Lookup".  However, this is a pretty nasty bug as it doesn't throw any errors, and returns a Success response from Netsuite, but the custom list value does not get updated because the Boomi process is NOT performing the "getCustomizationID" and individual "get" operations (presumably because it thinks it already has them cached).   What's the point of having the "convenience lookup" if it doesn't work properly?

 

I have spent many hours trying to figure out what Boomi is doing, but before detailing everything out, I will note that running the process in a cloud Atom versus a local Atom seems to force the Convenience Lookup to occur each time the process is run.

 

In addition, making a simple change to the process (like moving a shape), saving, closing and re-opening the process and running a Test from the local ATOM also seems to force the convenience lookups to re-occur.  However when the process is running in production on the local ATOM, the convenience lookups are NOT occurring after the first time the process is run.

 

So maybe there is a simple setting that can force the local ATOM to always perform the lookups?

 

At any rate, here is a detailed description of the issue that I am seeing:

 

I'm doing a Netsuite Item UPSERT.   The source data is coming from another source system via an http call.  A MAP shape is mapping those 4 fields below from Source to Target.  The last field is a field who's values are sourced from a Netsuite Custom List.

 

Partial Source Data:

SKU:  "TestSKU"

SKU: "TestSKU"

cost: 23.00

Graded By: "N/A"

 

Target Netsuite Fields

externalId

itemId

Current_Replacement_Cost

custitem_lc_graded_by    (values come from customlist_lc_graded_by)

 

 

The first time the process runs, everything works fine, Netsuite performs the convenience lookups ("getCustomizationId", and all the "get" operations), and performs the UPSERT and Netsuite is updated.

 

Here is a screenshot of what the NetSuite WebServices Log looks like. (It's performing several gets because there are other custom list values it is retrieving that I did not include in the sample source data for brevity)

 

One of the "get" operations returned the list of values to use for the custitem_lc_graded_by" field by grabbing all the values from the customlist_lc_graded_by Custom List.    Here is a partial XML fragment.  The Source value was the string "N/A", so NetSuite looks like it will be able to correctly look up the string "N/A".

 

 

And here is a partial fragment of what the final XML looked like for the "correct" UPSERT api call.  We can see that the "get" above worked because the MAP operation was able to supply the internalId value of "9" for the field "custitem_lc_graded_by".

 

Now, let's say I update the source record and change it's Graded By value to a new value that was not in the original convenience lookup "get"?  NOTE!  The value "Test" was added to Netsuite's Custom List before the process ran for the second time

 

Partial Source Data:

SKU:  "TestSKU"

SKU: "TestSKU"

cost: 99.00

Graded By: "Test"

 

Target Netsuite Fields

externalId

itemId

Current_Replacement_Cost

custitem_lc_graded_by (values come from customlist_lc_graded_by)

 

Here is a screenshot of the API calls that Netsuite makes during the second time this process is run after the Graded By value has been changed.   NOTE!  there are no customlist item lookups (no "gets") being requested this time.

 

 

Here is a partial fragment of what the final XML looked like for the UPSERT call during this second pass.  Notice that the MAP operation must have attempted to lookup the value "Test" in it's local cache, but couldn't determine the "internalID" value for it, so it just tried to send the string "Text" and didn't even set an internalId for that field.

 

 

The worst part about all of this is that Netsuite returned a response of "Success".  It simply ignored the "custitem_lc_graded_by" field presumably because no internalId was given.

 

On the NetSuite side, that Item Record had all other values updated, but the "custitem_lc_graded_by" field still shows a value of "N/A", not the new value of "Test" that it should contain.

 

Obviously not a good thing.

 

Hopefully someone is able to take a look at the whole "convenience lookup" functionality at some point in the future.  It would be better to NOT have it rather than have it work that way it is currently working.

 

Thanks for any insight the Boomi team can provide.

Outcomes