We just learned today that Custom Transaction Types are not accessible for Boomi for sync between NetSuite and other platforms. Are there any ways around it without having to build a restlet in NetSuite?

Is it accessible via SuiteTalk REST?

Based on this doc, REST web services only support header level CRUD operation on Custom Sale/Purchase Transactions; Custom Sale is what we are using. https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_158100110171.html#Using-CRUD-Operations-on-Cus[…]2C-and-Custom-Transactions-v1

Well, this sort of thing domes up often enough that we have a framework for creating custom APIs on netsuite via either Suitelet or RESTlet. For a variety of reasons, from issues like this (inaccessible records) to missing behavior or just allowing more abstract business operations - all motivations to consider a RESTlet a valuable tool in the toolbox. For us, creating a structured business operation that can be called from any external caller that speaks JSON is trivial.

Thank you for your input! We are leaning towards building a RESTlet, thought I would ask before diving into it. Based on your experience, are RESTlets able to handle multiple requests (~ 100 transactions call) multiple times a day?

As long a you stay within the governance limits it should be fine. I've found the RESTlet infrastructure to be robust across many integrations. Depending on your actual governance usage per transaction, you should be able to handle a batch of 100 easily

To build on what Shawn said, with RESTlets you also get the full power of suitescript at your disposal. So if governance does become an issue, you always have the option of having your restlet call a Map/Reduce script. You lose a little bit of the flexibility in your response from your RESTlet that way, but it would solve any potential governance issue.

Thank you, both! I appreciate your input!

an architectural benefit of RESTlet is it lets you keep more of your NetSuite logic close to NetSuite, rather than bleeding it out all over disparate systems (i.e. Boomi containing business logic that closely couples it with NetSuite). RESTlet operations can act as an abstraction layer, providing simplicity for the caller (e.g. Boomi) while keeping the business logic maleable as long as the interface doesn't change. It's not uncommon for us to have some command like 'doFoo' where 'foo' is a high level business operation - the RESTlet command handles all the details, leaving the caller to pass a simpler data structure tailored to what's easy for them, and provide a similarly pleasant response.

As a developer, I totally share your sentiments. As a consultant though, I have noticed clients like to stay away from custom API as much as they can. 🙂

As a consultant, it's your duty to help guide clients towards the best bang for their buck. IF you're not doing that, you're not a consultant, you're a warm body coding.

Sorry, didn't mean to trigger anything here. What I meant was even though RESTLet/custom code might be the best technical option for the client, they tend to lean towards platforms/services that does not require long term maintenance & ownership.

It is a pet peeve of mine I suppose. I've been consulting for 30 years and have very rarely run into a client that didn't see the light. Not to mention, a RESTlet is likely less to own and maintain than the (generally more complex) Boomi orchestration that it would replace.

Not that you would want to completely switch iPaaS solutions for this one use case (since a single RESTlet would also work), I wanted to note Celigo doesn't have this issue because we ourselves are using RESTlets and not NetSuite's apis.