Netsuite - Search Example

This walkthrough will, using an example, explain how to construct the input for the Search records operation in the NetSuite connector, although the construction methodology will be applicable to other pertinent operations.

In essence, the construction method configures the JSON objects in such a way that can be translated into XML, as required by NetSuite (SOAP) requests.

Additionally, please reference NetSuit's Help Centre, in particular the SuiteTalk (Web Services) Platform Guide (in particular, Web Services Operations) and SuiteTalk (Web Services) Records Guide sections, as they will indicate and guide how to form the inputs as XML.

Search Records

The aim of this example: find customers whose email ends with "gmail.com".

It should be noted that the NetSuite connector predefines some of the JSON that are generic and always required in each requests. For the Search records operation in particular, this can be referenced to a Basic Search example, where the XML up to <searchRecord /> is already generated. i.e:

<platformmsgs:search xmlns="urn:messages_2017_1.platform.webservices.netsuite.com">
<searchRecord xsi:type="recordRef:..." xmlns:recordref="...">

...

</searchRecord>

</platformmsgs:search>

Search record type and Search record type xmlns

The first and second fields, Search record type and Search record type xmlns required in the properties panel, fill in the

<searchRecord xsi:type="..." xmlns:recordRef="...">

parts of the XML body, (while the Search Criteria field fills the rest of the XML input onwards).

Since the aim of the example is to find Customers, the Customer entity needs to be referenced here. This can be found under the Records Guide, in Entities: Customer. According to the documentation here, it is noted that the Customer entity is defined under listRel, pointing to the Relationships XSD. In this schema document, it can be found that in order to search Customers, that listRel:CustomerSearch (found in correspondence to contactSearch) is needed.

Now, in order to accommodate any type of search, it is necessary for the Search records operation to remain generic; in order to facilitate this, a generic pointer, recordRef, has been used to point to the xmlns. Therefore in this example, it should be considered that listRel has been swapped for recordRef (as a pointer to the schema). It follows then that the values for the fields Search record type and Search record type xmlns are CustomerSearch and urn:relationships_2017_1.lists.webservices.netsuite.com respectively, forming the respective XML element:

<searchRecord xsi:type="recordRef:CustomerSearch" xmlns:recordRef="urn:relationships_2017_1.lists.webservices.netsuite.com.">
...

<searchRecord />

Search Criteria

From here on, for the Search Criteria field, the entire XML must be created in a JSON format, which will follow the construction methodology outlined here.

Referring to the Relationships XSD once more, under the CustomerSearch complexType, a basic element can be found, with an attribute type="platformCommon:ContactSearchBasic". This basic part is needed in order to perform a query about a customer's email, since email is contained within the ContactSearchBasic definition, while the platformCommon part is a reference to the Common XSD, which is where further details on the ContactSearchBasic definition can be found, including email.

Viewing the Basic Search example code example once more, there are two things to note: the operator attribute and the platformCore:searchValue element. The operator attribute denotes the type of search/filter to perform, while the searchValue element, as implied, indicates the value to use in the search/filter. The valid operator values can be found in CoreTypes XSD, under SearchStringFieldOperator definition.

Finally, with all this information the Search Criteria field can be populated. It should be noted that listRel will need to be referenced, and therefore another reference to Relationships XSD will be needed. Additionally, a reference for platformCore:SearchStringField will also be needed, which can be referenced to the Core XSD

The JSON input for the Search Criteria field is as follows:

{

"name": "listRel:basic",

"attributes": {

"xmlns:platformCommon": "urn:common_2017_1.platform.webservices.netsuite.com",

"xmlns:listRel": "urn:relationships_2017_1.lists.webservices.netsuite.com"

},

"value": {

"name": "platformCommon:email",

"attributes": {

"operator": "contains",

"xsi:type": "platformCore:SearchStringField",

"xmlns:platformCore": "urn:core_2017_1.platform.webservices.netsuite.com"

},

"value": {

"name": "platformCore:searchValue",

"value": "gmail.com"

}

}

}

Not how in value field, another object with fields name, value, and attributes is needed, as described by the construction methodology mentioned previously.

Final Input

The final (JSON) input for this example should look like the following in the Input section of the logs:

{

"search_record_type": "CustomerSearch",

"search_record_type_xmlns": "urn:relationships_2017_1.lists.webservices.netsuite.com",

"search_criteria": {

"name": "listRel:basic",

"value": {

"name": "platformCommon:email",

"value": {

"name": "platformCore:searchValue",

"value": "gmail.com"

},

"attributes": {

"operator": "contains",

"xsi:type": "platformCore:SearchStringField",

"xmlns:platformCore": "urn:core_2017_1.platform.webservices.netsuite.com"

}

},

"attributes": {

"xmlns:listRel": "urn:relationships_2017_1.lists.webservices.netsuite.com",

"xmlns:platformCommon": "urn:common_2017_1.platform.webservices.netsuite.com"

}

},

"email": "co... <**--removed--**>",

"account": "TS... <**--removed--**>",

"password": "bT... <**--removed--**>",

"role": "<**--removed--**>"

}

which produces the following compliant JSON:

{

"name": "searchRecord",

"attributes": {

"xsi:type": "recordRef:CustomerSearch",

"xmlns:recordRef": "urn:relationships_2017_1.lists.webservices.netsuite.com"

},

"value": {

"name": "listRel:basic",

"value": {

"name": "platformCommon:email",

"value": {

"name": "platformCore:searchValue",

"value": "gmail.com"

},

"attributes": {

"operator": "contains",

"xsi:type": "platformCore:SearchStringField",

"xmlns:platformCore": "urn:core_2017_1.platform.webservices.netsuite.com"

}

},

"attributes": {

"xmlns:listRel": "urn:relationships_2017_1.lists.webservices.netsuite.com",

"xmlns:platformCommon": "urn:common_2017_1.platform.webservices.netsuite.com"

}

}

}

and this finally transforms into the following XML:

<searchRecord xsi:type="recordRef:CustomerSearch" xmlns:recordref="urn:relationships_2017_1.lists.webservices.netsuite.com">

<listrel:basic xmlns:platformcommon="urn:common_2017_1.platform.webservices.netsuite.com" xmlns:listrel="urn:relationships_2017_1.lists.webservices.netsuite.com">

<platformcommon:email operator="contains" xsi:type="platformCore:SearchStringField" xmlns:platformcore="urn:core_2017_1.platform.webservices.netsuite.com">

<platformcore:searchvalue>gmail.com</platformcore:searchvalue>

</platformcommon:email>

</listrel:basic>

</searchRecord>

The rest of the necessary XML is generated by the connector before making the request to NetSuite.

Last updated 25th January 2018