Wednesday, December 23, 2009

Logging into Netsuite with ColdFusion or Java - Code Sample

Every now and then, I get a request about sample code for logging into Netsuite. I often forget that I started working with Netsuite in CF before I commonly used native java objects. It took me some tinkering to figure out, but when dealing with Netsuite specific datatypes and objects in ColdFusion, sometimes CF will often correctly translate an array, integer, string, etc to an equivalent compatible with the SOAP request, however often I just skip the middle man and eliminate risk by casting the variable or creating a native instance of the java stub class.

Here is the full java equivalent (I haven't tried to compile this, so you may need to make some tweaks)

//java pseudo-ish code (meaning I haven't actually tried to compile this)
import com.netsuite.webservices.platform_2009_1.NetSuitePortType;
import com.netsuite.webservices.platform_2009_1.NetSuiteServiceLocator;
import com.netsuite.webservices.platform.core_2009_1.Passport;

String YourNetsuiteAccountNumber = "123456789";

URL endpoint = new URL("" + YourNetsuiteAccountNumber);
NetSuitePortType nsws = NetSuiteServiceLocator.getNetSuitePort(endpoint);
nsws.setMaintainSession(true); // maintain this session
nsws.setTimeout(1000 * 60 * 60 * 2); // set 2 hour timeout period
Passport passport = new Passport();
passport.setEmail(""); // email address used to log into netsuite (must be set up as web service user)

Monday, March 16, 2009

Netsuite web service and ColdFusion 8

I recently posted updates to previous posts regarding problems with web service connections between ColdFusion MX 7 and Netsuite, but thought this matter warranted a post of its own. Perhaps you have experienced issues creating a web service connection with Netsuite, whether it's through the ColdFusion Administrator or through the CFINVOKE tag or CreateObject function. The fact of the matter is that Netsuite's extraordinarily complex and deeply nested WSDL, which references XSD within XSD and beyond, appears to give ColdFusion a headache, and it silently gives up on compiling the stub objects before the job completes (there are over 600 java stub class files generated for Netsuite's 2008_1 WSDL). I have now confirmed that this an issue in CF8 in addition to CFMX7. I get around this by compiling the stub classes from the command line and dumping them into a nice, portable jar file.

I will readily admit that it is possible I am missing something in this problem. There could very well be a timeout issue with ColdFusion compiling the stub classes, but it doesn't throw an error. And while you can easily adjust the timeout for WSDL2Java from the command line, I am not aware of a way to increase the timeout in the ColdFusion Administrator. If anyone else is aware of a way to do this, I'd love to hear from you in the comments or an email. If I get an answer, I'll be certain to post it here.

Sunday, February 15, 2009

Apache Axis ( Non nillable element '[ElementName]' is null)

Much has been written on this frustrating error (seemingly most of it along the lines of "Hey, guys, I have this problem. Anyone know what's up? ... Hello? Guys? Anyone?" Often, the are older posts referencing a known and now-fixed issue in Apache Axis 1.2 involving elements whose "nillable" attribute is set to true. However, when no value is set for that element, the aforementioned is thrown. In my case, I was using ColdFusion MX7, a jar file comprised of java stub classes ripped with WSDL2Java, and a version of Axis 1.2 customized to address an issue in accessing NetSuite's web service. The element in question was a datetime field, of type java.util.Calendar specifically. Due to the web service provider's documented business logic, setting a value in that field would actually result in the request being rejected outright, so setting a dummy value was not an option. Additionally, I tried setting the element to an unitialized Calendar object, but that resulted in the same error as not setting it at alll.


My first course of action was to upgrade to Axis 1.4. No dice. I still was getting the same error. My next step was to delete the jar file I'd made of the WSDL classes from the CFusionMX7/lib directory (if you've read previous posts here regarding ColdFusion and its interactions with Axis, you understand why I tend to lean toward that method instead of using the auto-compiled stub classes in the ColdFusion installation directory), added the stub class file directory I was using to the Java classpath in ColdFusion administrator, and restarted the CF service. Blam! Problem fixed.

Post Mortem

To be honest, I am not 100% certain what the issue was, but I strongly suspect this was an issue between the version of Java that had compiled the Axis jar file distribution, the version of Java our ColdFusion installation was running on, and/or the version of Java I had used to manually compile the stub class jar file I had been using previously. If anyone else has had this issue and has further details into the "why" of the fix, I'd love to hear them.