Netsuite REST Exporter

📘

The Netsuite REST API documentation can be accessed here

🚧

Important Note on Data Management

• We recommend testing this connector using credentials from a staging environment to ensure data flows as intended. Given that the reports can overwrite existing data or create new entries, please proceed with caution when executing them to prevent any unintended changes.

---

Set up

To get set up with the Netsuite connector, you will need to setup Token-based Authentication (TBA) in your Netsuite account:

• Enable the Token-based Authentication Feature. (Docs)
  TBA is a compulsory setting to access the Netsuite2.com Data Source

• Set Up Token-based Authentication Roles. (Docs)
  The Role used to authenticate must have TBA set as an authentication method, this can be done by creating a new role or modifying an existing one

• Assign Users to Token-based Authentication Roles. ( Docs)
  The User used to authenticate must have a Role with TBA authentication set to true.

• Create Integration Records for Applications to Use TBA ( Docs)
  The system displays the consumer ID and consumer secret only the first time you save the integration record. In cases where an application previously used user credentials as an authentication method, you must reset the consumer ID and consumer secret. Resetting the consumer ID and client secret invalidates the previous consumer ID and client secret.

• Create and Assign Access Token (Docs)
  For security reasons, the only time the Token ID and Token Secret values are displayed is on the confirmation page after creation. After you leave this page, these values cannot be retrieved from the system. If you lose or forget these credentials, you will need to create a new token and obtain new values.

• Manage TBA Tokens in the NetSuite UI. (Docs)
  You can see your existing TBA Tokens through the Netsuite UI by going to Setup > Users/Roles > User Management > Access Tokens

Features

---

Reports detail

---

Source Table Creation

• For the Create Record report, to create a specific record (available here), the connector expects the record to be provided as a JSON string. An example for the Account record is shown below with the required column data, with object keys defined under the Schema Definitions section.

  SQ

  -- Table creation
  CREATE OR REPLACE TABLE DB_NAME.Schema_name.NETSUITE_ACCOUNT (
      data VARCHAR NOT NULL
  );
  
  -- Inserting JSON records as strings
  INSERT INTO DB_NAME.Schema_name.NETSUITE_ACCOUNT (data)
  VALUES 
  ('{
     "acctNumber": 169557570919,
    "acctName": "Test Account333 16922457016",
    "acctType": { "id": "Expense" },
    "cashFlowRate": { "id": "AVERAGE" },
    "description": "description text 1",
    "eliminate": false,
    "generalRate": { "id": "CURRENT" },
    "includeChildren": false,
    "inventory": true,
    "isInactive": true,
    "isSummary": true,
    "revalue": true,
    "subsidiary": { "items": [ { "id": 2 }, { "id": 4 } ] }
  }');
  
  

• For the Update Record report, you need to include the id field and its corresponding value in the record's JSON string. An example for the Customer object is shown below.

  SQ

  -- Table creation
  CREATE OR REPLACE TABLE DB_NAME.Schema_name.UPDATE_NETSUITE_CUSTOMER (
      data VARCHAR NOT NULL
  );
  
  -- Inserting JSON records as strings with IDs
  INSERT INTO DB_NAME.Schema_name.UPDATE_NETSUITE_CUSTOMER (data)
  VALUES 
  ( '{
       "id": 1,
      "companyName": "Company 1615554322",
      "email": "[email protected]"
  }');
  
  
  

📘

Records Schema Definitions

For each record, the list of valid keys is available under the record object, as defined in the schema definitions here.

📘

Behaviour of exporter (and additional table for logging)

Whenever you run these reports the connector will store the requests in a table in the same schema with the same name as the destination table + _responses

so if you export little_pond.big_fish, it’ll be little_pond.big_fish_responses

The rows will contain the first level of the request map flattened (like url, method, headers, etc) as columns, and then a response and error columns with the response or error that came from that request.

In subsequent runs, the new rows will be appended to that same table.