SuiteTalk upgrades: How to upgrade your Java applications

When NetSuite will release version 2014.1, the SuiteTalk interface from 2009.2 and earlier will be decommissioned. For more information on this, please refer to the Help section of NetSuite, right at the beginning of the SuiteTalk documentation.

This will mean that if you have any integrations running on platform 2009.2 or below, they will stop functioning next year. It's therefore a good idea to upgrade your applications now!

Here are the steps required to update your Java applications. This example demonstrates how to upgrade from 2009.1 to 2013.x. (Yes, it is suggested to update to 2013.1 or 2013.2, and not to wait for 2014.1 because it could be too late). Performing the update now will allow your enterprise to make sure that your applications can be tested and migrated beforehand.

This blog post is originating from a question asked on the NetSuite user group (link here), and we thought that sharing it here would benefit our readers.

1) First, the WSDL needs to be updated. Here's the URL for the 2013.# WSDL:

The main reason for updating the WSDL is to regenerate the NetSuite domain classes. They can be regenerated using wsdl2java utility (NetSuite provides an Ant script for that), or, a simplest path is to simply download them from the SuiteTalk Sample Applications in the Java sample app found here: . In the application, these classes are under the src.generated folder (and the compiled classes in build.generated folder). Replace your soon-to-be-deprecated classes in your application by these new ones.

2) In your configuration files, you probably have the NetSuite service endpoint URL (Let's say ). Replace this with the new one, for example .

3) Your client application calls the classes you replaced in Step 1. You may perform a search in the source code on "com.netsuite.webservices" to check where these calls are made if you are not sure. The package of these classes are tagged with the SuiteTalk version. (e.g. the fully qualified class name of a SalesOrder in 2009.1 is: com.netsuite.webservices.transactions.sales_2009_1 .SalesOrder, therefore the action item here is to replace all 2009.1 occurrences in your import statements by 2013.x .

4) Recompile your application, fix any compilation errors (for example the Country list has changed from one version to another), test, validate, re-deploy.

Hope this helps! Feel free to contact us for more information.


1 comment:

  1. Please note that when using 2013.2 or above, the field used to reference custom fields on records is no more internalId, but instead it is scriptId.