3945982 Green Ribbon

You might want to ensure your SSL cert is issued by a CA that NetSuite trusts. To add to this, the machine we are connecting to is an Amazon AWS EC2. with multiple sites behind a single IP address with SSL's bound to private IP's on the NICs of the virtual machine. several weeks on, it still doesnt work via SSL, but works…

Glad you got it working, but that sounds like a good example of why to avoid nlapiYieldScript() ;)

I recommend looking at the tried and true http://momentjs.com for all your date manipulation needs (only writing functions yourself when necessary, and even then doing so in terms of momentjs).

I just tested searching a custom record's name field using the is operator in the UI and it seems to work fine (returned the record with the exact matching name). You might want to double check that the search you're doing in script works in the UI.

var r = nlapiLoadRecord(...); var field = r.getField("custevent_date_field"); // the field type, e.g. "datetime" var fieldType = field.getType();

I suggest avoiding nlapiYieldScript() and just reschedule the script yourself in code if possible. For most applications I've done the nlapiYieldScript is only a convenience and with slight adjustment to the script design it works without that call. In addition, you may end up with code that's easier to understand rather…

I'd think this is by design. My take on it is the Token Auth is targeted at computers talking to computers, not acting as login for customers or employees - 'trusted subsystem' scenarios. However, I think RESTlets still honor JSESSIONID login (I know suitelets do, and I generally use suitelets for APIs rather than restlets…

momentjs for the win.

I'm about to do this for FedEx. I realize that statement alone may not help much but thought I'd let you know you're not alone!

Ignore the last post. Just had to set cols to [0] instead of [1] thanks. Sounds like a good reason not to use the columns array syntax you've chosen and perhaps use getValue('fieldname').

Eeek, assigning to the window object is not a recommended practice. I assume that code you pasted is NS's own? Also, "window" as defined by the browser has no meaningful analogue server side, does it? It would be nice if someone from NS kindly chimed in. I might have to file a case?

I recommend you convert the search results into a native javascript collection, from which point you can do most anything you like to it (such as add an element) We have started doing this as a regular practice to make it easier to work with search results.

Similar to Carlo's answer, we have used RESTlets called from an external (Scala/Spray app in our case) client. You might want to rethink your process - running something every 5 minutes is starting to approach "real-time" for a line of business app. You might want to invert your architecture and consider a lightweight…

I don't see the relation to FTP? Might want to update your post title.

After seeing those several lines of code I want to share a arguably more readable approach: var eta = po_record.item[0].expectedreceiptdate.add(90, 'days'); I'm still working on getting our company to open source the library that makes the line above possible. It is relatively simple but makes working with NetSuite…

10 days of silence. Has anyone else observed this behavior? I've seen it on every 2014.2 client so far.

I've found 5 concurrent calls to be fairly stable, much more than that and it gets less so.

I recommend momentjs for date manipulation.

My impression is that the RESTlet limit is 50 only if you have the fancier (Cloud+?) user that gives you 5 scheduled script queues and more concurrent web services connections as well. Can a NetSuite employee confirm?

Find anything interesting in your bombardment Richard?

I just noticed that myself... Has anyone seen the referenced error code from the help?

we unit test logic in isolation when possible and sometimes use mocks/stubs to replace some of the nlapiXXX calls. as for frameworks, we use jstestdriver and karma/jasmine.

As a general approach to speeding things up, we sometimes turn slow internal scripts into a RESTlet which does a smaller chunk of work. Then call that RESTlet in parallel to whatever extent you need to get the desired speed.

When run within a restlet (which is naturally stateless) I worry about the new nlobjSearch.runSearch() operation with regards to read consistency. Say you load a page of results 0 - 1000 and return them to the caller. Some time later the callers asks for results 1000-2000. Well, I fear the result set may have changed…

I took a quick look at the Pacejet API and it seems straightforward. What is the issue/problem?

Can you modify your design to be more message-oriented and less synchronous with respect to user interaction? One example would be to provide the user an immediate indication (no timeout) that their request is being processed and let them continue working with the app. Then on your backend process the request…

I've seen wildly varying response times for restlets. I'd recommend designing for such variance from the start if you can.

I made sure nothing else was attached to the record type before I posted here. I filed a case and it's been logged as a defect. Thanks for trying to help Marlon!

Thanks for the tips Marlon - it's good to know I shoudl be able to do it either via createRecord initialization or setting the property manually. However, on my account it's still failing with unexpected_error for both techniques. I've filed a case and hopefully will get resolution!

Clever, Sean. Are you suggesting it doesn't log the name of the field for select or checkbox fields?