The administrator can perform the following tasks to ensure that NetSuite fields are available in Data Integration and to optimize performance:
• If field names in the NetSuite record and the related NetSuite search record do not match, the fields cannot be used in filters. This must be configured before NetSuite objects can be used as sources in tasks.
You can associate NetSuite record field names with related NetSuite search record field names when you set up a NetSuite connection in Data Integration. Alternatively, you can configure the RecordToFieldsMap.ini file if the connection uses a Secure Agent group for the runtime environment.
•Some custom fields in NetSuite custom objects might not appear in Data Integration, particularly transaction body fields and transaction column fields.
To ensure that all custom fields are available in Data Integration, you can configure custom fields when you set up a NetSuite connection in Data Integration. Alternatively, you can configure the NetSuiteCustomFields.ini file if the connection uses a Secure Agent group for the runtime environment.
•Saved search fields in NetSuite do not appear in Data Integration if they have a null value.
You can specify saved search fields when you configure a NetSuite connection so that the saved search fields appear in Data Integration even when they have a null value. Alternatively, you can add the saved search fields to the NetSuiteSavedSearchFields.ini file if the connection uses a Secure Agent group for the runtime environment.
•To optimize performance for concurrent threads in synchronization tasks, you might need to adjust heap size.
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:
•Data Filters page of the Synchronization Task wizard
•Query options in a Source transformation in the Mapping Designer
•Query options in the Sources page of the Mapping Task wizard when the source object is parameterized
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:
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:
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:
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:
- Create a separate section for each NetSuite record.
- In each section, list the record field names and related SearchBasic field names, as follows:
[<record 1>] <record field name>=<SearchBasic field name> <record field name2>=<SearchBasic field name2>
[<record 2>] <record field name>=<SearchBasic field name> <record field name2>=<SearchBasic field name2> <record field name3>=<SearchBasic field name3>
For example:
[Account] acctName=name addr1=address1
- To read transactional data from NetSuite when memorized transaction is enabled in the NetSuite account, add the record field names and related SearchBasic field name in the following format:
[<record 1>] <record field name>=<SearchBasic field name>
For example:
If you want to enable memorized transaction for JournalEntry object, add the following value in the RecordToFieldsMap.ini file:
[JournalEntry] reversalEntry=memorized
3Copy the RecordToFieldsMap.ini file to the following directory:
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:
- Add the custom fields for NetSuite advanced search using the following format, where the value of scriptId is the ID field in the NetSuite user interface for each custom field:
[<Object Name>] scriptIds = <custom field name1>,<custom field name2>,<custom field name3>
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:
The savedSearchId1 is ID field in the NetSuite user interface that specify the saved search record. The savedSearchDeclaredField1Name and savedSearchDeclaredField2Name are standard field names in the NetSuite user interface. The savedSearchCustomFieldScriptId1 and savedSearchCustomFieldScriptId2 are ID fields in the NetSuite user interface for custom fields. The StandardJoin|FieldName1 is the standard join field and customSearchJoin|scriptID1 is the custom join field.
In the example, 1000 is the saved Search ID, phone and email are standard field names, custentity78 and custentity65 are the script IDs of a custom field. userJoin|email is the standard join field and customSearchJoin|custrecord1424 is the custom join field script ID.
Note: When you use custom join, script ID appears in the Data Integration user interface.
- If you want to read custom segment data, use the following format to add the search custom segment fields:
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
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>
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:
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: