NetSuite Connector > Introduction to NetSuite Connector > NetSuite Connector administration
  

NetSuite Connector administration

The administrator can perform the following tasks to ensure that NetSuite fields are available in Data Integration and to optimize performance:

Mapping NetSuite record field names

Map NetSuite record field names with related NetSuite search record field names so that users can use the fields in filters.
Users define filters for fields in the following locations:
NetSuite SearchBasic search records contain the field names used for filtering. When a field name in a NetSuite record matches the related field name in the corresponding SearchBasic search record, users can define a filter for the field in tasks. When a field name in a record does not match the related search record field name, users cannot define a filter for the field in tasks.
You can check the NetSuite schema to see if a field name in a NetSuite record matches the related field name in the SearchBasic search record. NetSuite records are represented as schema types in the NetSuite schema. To view NetSuite field names in the NetSuite schema, you can open the appropriate schema definition file (XSD). You can find a list of XSDs in the following location:
https://webservices.netsuite.com/wsdl/v2019_2_0/netsuite.wsdl
For example, a user wants to define a filter for account name. You review the Account record in NetSuite's browser, which is defined in NetSuite's accounting.xsd file.
The schema contains the field, acctName, as shown in the following sample:
The NetSuite schema includes the Account schema type which includes the acctName field. The Account record is listed in the schema and includes the name field.
You also see that the corresponding SearchBasic field name in the NetSuite's common.xsd file is called name, as shown in the following sample:
The schema includes the AccountSearchRowBasic schema type which includes the name field.
Because the field name is acctName in the Account record and the field name is name in the corresponding SearchBasic record, you map the two field names. The following example shows how you map acctName to name in the connection properties:
[Account]
acctName=name
Use the same syntax if you resolve the issue in the RecordToFieldsMap.ini file.

Creating a configuration file to map NetSuite fields

To ensure that users can define filters for NetSuite fields, map record field names with related NetSuite search record field names. You can map the fields in the Record Filter Fields connection property when you configure a NetSuite connection. Alternatively, if the NetSuite connection uses a Secure Agent group as the runtime environment, you can create a configuration file to map the fields.
If you choose to create a configuration file to map the fields, perform the following steps:
    1Create a text file named RecordToFieldsMap.ini.
    2Use the following guidelines to configure the RecordToFieldsMap.ini file:
    3Copy the RecordToFieldsMap.ini file to the following directory:
    <Secure Agent installation directory>\apps\Data_Integration_Server\ext\deploy_to_main\bin\rdtm-extra\reserved\userfiles\netsuite
    4Update the file as required.

Configuring the NetSuiteCustomFields.ini file

You can specify custom NetSuite fields in the Record Custom Fields connection property when you configure a NetSuite connection so that the fields are available in Data Integration. Alternatively, if the NetSuite connection uses a Secure Agent group as the runtime environment, you can specify the custom NetSuite fields in the NetSuiteCustomFields.ini file.
If you choose to configure the NetSuiteCustomFields.ini file, perform the following steps:
    1Make a copy of the NetSuiteCustomFields.ini file, located in the following directory:
    <Secure Agent installation directory>\downloads\packageNetsuiteConnector.<version>\package\rdtm\javalib
    2Use the following guidelines to change the file to include custom NetSuite fields:
    3Save the NetSuiteCustomFields.ini in the following location:
    <Secure Agent installation directory>\apps\Data_Integration_Server\ext\deploy_to_main\bin\rdtm-extra\reserved\userfiles\netsuite
    Note: The custom segment fields, which you add either in NetSuiteCustomFields.ini or connection properties, are not validated. For example, the metadata and duplicate field names.

Configuring the NetSuiteSavedSearchFields.ini file

You can specify saved search fields in the Saved Search Record Fields connection property when you configure a NetSuite connection to ensure that all saved search fields are available in Data Integration. Alternatively, if the NetSuite connection uses a Secure Agent group as the runtime environment, you can configure the NetSuiteSavedSearchFields.ini file.
If you choose to configure the NetSuiteSavedSearchFields.ini file, perform the following steps:
    1Make a copy of the NetSuiteSavedSearchFields.ini file, located in the following directory:
    <Secure Agent installation directory>\downloads\packageNetsuiteConnector.<version>\package\rdtm\javalib
    2Use the following guidelines to change the file to include all of the saved search fields:
    3Save the NetSuiteSavedSearchFields.ini in the following location:
    <Secure Agent installation directory>\apps\Data_Integration_Server\ext\deploy_to_main\bin\rdtm-extra\reserved\userfiles\netsuite

Fetching field name for saved search with standard join

Perform the following steps to fetch field name for standard join:
    1Go to https://system.netsuite.com/help/helpcenter/en_US/srbrowser/Browser2015_1/script/record/transaction.html.
    2Under Schema Browser, select the object.
    3Under Related Searches, select the search object.
    4Under Fields, select the type for the standard join.
    You will find the name of the standard join field.
    The syntax for saved search INI file with standard join is as follows,
    [SavedSearchScriptIdToFieldsMap]<savedSearchId1>= <StandardJoin>|<FieldName1>, <StandardJoin>|<FieldName2>
    For example,
    [SavedSearchScriptIdToFieldsMap1]
    290= userjoin|accountNumber, contactJoin|address

Fetching script ID for saved search with custom join

Perform the following steps to fetch script ID for custom join:
    1 Log in to your NetSuite account.
    2Select Customization > Record Types.
    3Select the custom object to get the script ID for the custom join field.
    The syntax for saved search INI file with custom join is as follows:
    [SavedSearchScriptIdToFieldsMap]<savedSearchId1>= customSearchJoin|<scriptID1>,customSearchJoin|<scriptID2>
    For example,
    [SavedSearchScriptIdToFieldsMap1]
    290= customSearchJoin|custrecord1423,customSearchJoin|custrecord1421

Reading custom record standard fields with custom join

To read custom record standard fields with custom join, configure the DumpSavedSearchMetadata property.
    1Go to Administrator > Runtime Environments.
    The Runtime Environments page appears.
    2Select the Secure Agent for which you want to set the custom configuration flag.
    3Click Edit Secure Agent in Actions.
    The Edit Secure Agent page appears.
    4Select the Service as Data Integration Server in the Custom Configuration Details section.
    5Select the Type as Tomcat in the Custom Configuration Details section.
    6Add DumpSavedSearchMetadata in the Name field.
    7Specify a file path in the Value field where you want to generate the DumpSavedSearchMetadata file.
    For example, C:\\Dump.txt. The path should contain "\\".
    The following image shows the Custom Configuration Details section.
    Note: If the path contains only the file name, then the Secure Agent generates the DumpSavedSearchMetadata file in the following folder: <Secure Agent installation directory>\apps\Data_Integration_Server\<DIS Version>\ICS\main\tomcat. If the path is not valid, the Secure Agent does not generate the DumpSavedSearchMetadata file.
    8Click OK.
    9Create a task with saved search object to read custom record standard fields with custom join.
    When you save or run the task, the Secure Agent generates the DumpSavedSearchMetadata file and writes the metadata to this file. The Secure Agent fetches the metadata for the custom record standard fields in the following format:
    <script Id of custom record>__<standard search column name1>__CSJ,
    <script Id of custom record>__<standard search column name2>__CSJ
    For example:
    custbody_cseg1__internalId__CSJ,custbody_cseg1__name__CSJ
    Note: When you specify a field name, ensure that the length of the field name does not exceed 64 characters.
    If you want to override the metadata, you can copy the metadata in the NetSuiteSavedSearchFields.ini file and modify the metadata accordingly. Use the following format to add the search custom record standard fields in the NetSuiteSavedSearchFields.ini file:
    [SavedSearchScriptIdToFieldsMap<version>]
    <savedSearchId1>=CustomSearchJoin|<scriptId of custom record>__<standard field name>
    For example:
    [SavedSearchScriptIdToFieldsMap1]
    356=CustomSearchJoin|uss_custom_code__internalId
    Alternatively, you can specify saved search fields in the Saved Search Record Fields connection property when you configure a NetSuite connection.

Internalid and externalid in saved search

When you create a new task or edit or refresh an existing task to read data from NetSuite saved search that contains an internalid or externalid field, the agent does not drill down the internalid or externalid field if you do not specify the saved search fields in the NetSuiteSavedSearchFields.ini file or Saved Search Record Fields connection property. The agent writes the internalid field as internalid and externalid field as externalid.
If you specify the saved search fields in the NetSuiteSavedSearchFields.ini file or Saved Search Record Fields connection property, the agent drills down the internalid or externalid field. The agent drills down the internalid field as internalid_internalid, internalid_externalid, internalid_type, and internalid_name. The agent drills down the externalid field as externalid_externalid, externalid_internalid, externalid_type, and externalid_name.
Note: If you edit or refresh an existing task, you must remap the internalid or externalid field or create a new target file.

Increasing heap size for concurrency in synchronization tasks

Users can configure synchronization tasks to use concurrent threads. If the NetSuite connection for synchronization tasks uses a Secure Agent group as the runtime environment, you can adjust heap size to optimize performance for concurrency.
You can adjust heap size in the Edit Secure Agent page or you can edit the pmrdtm configuration file.

Increasing heap size in the Edit Secure Agent page

You can adjust heap size in the Edit Secure Agent page to optimize performance for concurrency.
    1Click Administrator > Runtime Environments.
    2On the Runtime Environments page, if necessary, expand the Secure Agent groups to see the list of Secure Agents. Click the Secure Agent name from the list.
    3Click Edit Secure Agent in Actions.
    The Edit Secure Agent page appears.
    4In the System Configuration Details section, for Type, select DTM. Modify the JVMOption parameter to specify the heap size.
    For example, you might want to adjust the heap size to 512 MB if the concurrency thread setting is 10.
    The following example shows the heap size set to 512 MB:
    JVMOption6=-Xmx512m
    JVMOption5=-XX:+HeapDumpOnOutOfMemoryError
    JVMOption4=-Xloggc:jvm_heap_stats_Clou_App.log
    JVMOption3=-XX:+PrintGCDetails
    JVMOption2=-XX:+PrintGCTimeStamps
    JVMOption1=-verbose:gc

Handling parent and child or sibling objects with similar column name

If the parent object and the child or sibling object have similar column names, data from parent column is written to the parent column, and data from child or sibling column is written to the child or sibling column. You can set the UseJumbledDataForFieldsWithSameName property to control this behavior.
If you set the UseJumbledDataForFieldsWithSameName property to true, data from parent column is written to the child or sibling column, and data from child or sibling column is written to the parent column.
If you set the UseJumbledDataForFieldsWithSameName property to false, data from parent column is written to the parent column, and data from child or sibling column is written to the child or sibling column.
    1Go to Administrator > Runtime Environments.
    2On the Runtime Environments page, if necessary, expand the Secure Agent groups to see the list of Secure Agents. Click the Secure Agent name from the list.
    3Click Edit Secure Agent in Actions.
    The Edit Secure Agent page appears.
    4In the Custom Configuration Details section, for Type, select DTM.
    5Set the UseJumbledDataForFieldsWithSameName parameter to true or false as shown in the following image:
    6Restart the Secure Agent.