I just got off the phone with NetSuite support, after exhausting all efforts to make a client-side call from a page in our SuiteCommerce Advanced website directly to NetSuite. It was getting a CORS (Cross-Origin Resource Sharing) scripting error.
Here’s what’s going on. We were looking for a way to get client-side access to a public Suitelet or Restlet in NetSuite. The problem: It was blowing up with a CORS error. Apparently, Netsuite does not support cross-site scripting, even from one of our own domains, SCA.
Here is the exact scenario which brought on the call to NetSuite support. We wanted to click a button in the SCA page which would fetch additional warehouses with our product. This data comes from custom record types in NetSuite. So the NetSuite developer knows where that data lives, the SCA developer does not. At this point, the conversation went something like this, “Hey, I’ll just make that data available to you through a public Suitelet. It’s not proprietary information. You can see it on the page. Why not?
However, we hit the wall with a CORS error from NetSuite. So… You’d think that since NetSuite and SCA are one and the same, NetSuite’s public Suitelets would carry a response header that looked like this:
Access-Control-Allow-Origin: [URL of SCA website]
However, you’d be wrong. Without the response header (supplied by the web service), all browsers block the AJAX call back to the requested web service.
I’ve asked NetSuite to make this a “feature request.” The reason I believe it is important is that NetSuite and SCA have no mechanism for sharing JavaScript libraries. This forces SCA developers to know things the NetSuite admins and developers have traditionally been responsible for, in this example, custom record types. With shared libraries, all this complexity could be encapsulated in JavaScript namespace. Without it, there needs to be better communication between the two domains, so code isn’t duplicated.
If there were no CORS error, any web developer with little or no SCA training, could make the kind of change we were attempting here. It could live in the Handlebars template, which is basically raw HTML and JavaScript.
Since CORS blocked us, the code had to move to server-side SCA, where an SCA developer had to write it. Darn!
NetSuite Experiences 
As a workaround, perhaps you could configure the SCA page to make a call to an intermediate page (hosted somewhere that you have control over CORS), have that intermediate page make a call to the public Suitelet, and then relay the response?
LikeLike
Thanks, Tim. Great idea. I’d considered that. However, before I could get that in place, my SCA developer got impatient and grabbed my code and ran with it. In his words, “It’s done. Movin’ on!” In this case, it was a read-only operation. So no harm, no foul.
However, It seems NetSuite really needs to address this issue of sharing server-side JavaScript namespaces between NetSuite and SCA. That would make life much simpler for teams like ours where we have an SCA-only developer and a NetSuite-only developer.
Now I’m writing for everyone else that reads this, not necessarily you. Let me add, that I’m under the opinion that there’s a lot to know about writing server-side code which touches NetSuite’s one-and-only-one business system. In my case, I’ve got a 2-year head start on my colleague working with NetSuite. He’s a web developer who’s been tasked with customizing our SCA site. Consider the fact that a NetSuite developer can write event scripts which can easily affect transactions initiated in SCA. An SCA developer would be completely unaware of these. So having an SCA guy hacking away at the database on his own doesn’t seem like a good idea to me. Especially if his code only affects SCA initiated transactions.
LikeLike
I think this article is incorrect.
What do I mean? SCA extensions support communication between front and backend. It’s part of how SCA works.
So, create an extension that talks to the backend, and use SuiteScript to obtain any custom record data you want, and send it back to SCA. It’s how SCA works, and it’s same domain.
There are articles on the developers site. Also, the Newsletter extension is basic ‘hello world’ example of how this works.
LikeLike
Thanks Ted. Sharing data via common data structures is certainly a nice workaround. Excellent idea! However, I believe we are talking apples and oranges. I’m saying that actual code running client-side in your SCA website cannot access a Restlet in NetSuite. How nice would it be if client-side code could have full access to your library of Restlets in regular NetSuite. My point is there is no way to leverage common code between SCA and NetSuite without using your source control to put the code in two source trees. And what I was really after at the time I wrote this article, was skipping the learning curve as an SCA developer (which I am not) and push all the server side logic back into standard NetSuite (Restlets) where I thrive.
LikeLike