Как мне узнать, какой вариант интеграции NetSuite выбрать (suiteTalk, suitelet или restlet) для интеграции NetSuite в наше стороннее приложение?

Я бы избегал REST / SOAP. SOAP устарел, а REST неполон и сложен в использовании.

Suitelet предназначены для тех случаев, когда вы хотите представить свой собственный пользовательский интерфейс для внешних пользователей, например, особый новый вид настраиваемой формы, не имеющий отношения к какой-либо конкретной записи. Наверное, не то, что вы хотите.

Вы, вероятно, захотите спроектировать рестлет. Рестлет - это способ настроить ваш собственный URL-адрес внутри NetSuite, с которым ваша программа может взаимодействовать извне NetSuite. Как веб-страница. Вы можете передать данные в рестлет либо внутри URL-адреса, либо внутри тела HTTP-запроса (например, как объект JSON), и вы можете получить данные обратно из тела HTTP-ответа.

Рестлет является частью SuiteTalk. Метод аутентификации рестлета такой же, как и метод аутентификации запроса к REST API. Итак, изучение SuiteTalk полезно. Код, который вы используете для написания рестлета, SuiteScript, представляет собой тот же самый код, который используется для написания наборов программ и других типов сценариев.

Итак, вы захотите узнать о SuiteTalk, а затем, в частности, о рестлетах SuiteTalk.

это действительно субъективный вопрос.

Раньше SOAP / SuiteTalk был немного проще с точки зрения инфраструктуры, и, поскольку предложения Netsuite постоянно меняются, REST / SuiteTalk может заполнить это пространство в будущем.

Поскольку Netsuite не рекомендует использовать роль полного доступа, настройка интеграции почти всегда требует от интегратора предоставления спецификации разрешений. Самый простой способ сделать это - использовать Bundle. Для аутентификации на основе токенов (TBA) также должна быть запись интеграции, из которой вам понадобятся Consumer Id и Secret Tokens.

Итак, на момент написания этой статьи настройки для SOAP / SuiteTalk и RESTLets примерно одинаковы. Самый простой способ передать их - с помощью пакета, поэтому, если вы разработчик Netsuite с учетной записью разработчика, вы можете настроить их в пакете и попросить вашего клиента импортировать их.

Пока все равно, но различия: SOAP / Suitetalk работает медленно. IMO не подходит для интерактивного интерфейса SOAP / Suitetalk, код находится во внешнем приложении, поэтому изменения кода не требуют каких-либо изменений в целевой учетной записи.

RESTlets могут быть довольно быстрыми. Я использовал их для взаимодействия с клиентами. Обновления требуют повторной загрузки вашего пакета или перезаписи файлов пакета в целевой учетной записи (что приводит к хаосу, если администратор обновляет пакет). RESTlets предоставляют вам доступ к функциям учетной записи, в которой вы работаете, чтобы код мог запускать соответствующие фрагменты. Например, такие функции, как матричные элементы, инвентарь с несколькими местоположениями, единый мир, комплектование / упаковка / отгрузка, оптовые цены, мультивалютность - все это изменяет модель данных учетной записи, с которой работает ваш код. RESTlets могут определять, какие функции включены; SOAP / SuiteTalk не может.

Так что на данный момент единственное преимущество SOAP / Suitetalk, которое я вижу, заключается в том, что обновления кода не требуют доступа к целевой учетной записи.

Кто вносит изменения? Если это ваши разработчики NetSuite, тогда ваш выбор - SUITELET или RESTLET.

Если это ваша сторонняя команда разработчиков, они владеют кодом и процессом и выполняют всю свою работу вне NetSuite - ваш вариант - SUITETALK / SOAP. Конечно, им нужно что-то знать о NetSuite, но вашего бизнес-аналитика будет достаточно, чтобы их поддержать. Начиная с версии 2020.1+, в дополнение к SOAP есть поддержка собственных API-интерфейсов REST на тот случай, если вы все еще хотите использовать REST, но не писать свои собственные RESTLETS.

Как упоминалось в приведенных выше комментариях, Suitetalk работает немного медленнее, чем вызов RESTLETS. Так что, возможно, это один из решающих факторов.

Вы можете рассматривать SUITELET для интеграции только в том случае, если вы хотите обойти все схемы аутентификации, установив пакет как общедоступный. Хотя это крайне не рекомендуется.

Если стороннее приложение поддерживает REST API, вы можете вызывать их непосредственно из NetSuite - либо из пользовательских событий, либо из запланированных сценариев.

Вы также можете рассмотреть такие платформы iPAAS, как Dell Boomi, Celigo, Jitterbit и т. Д. Это универсальные интеграционные платформы, которые упрощают подключение одной платформы к другой с минимальным написанием кода. Если ваша компания уже вложила средства в эти платформы iPAAS для других корпоративных приложений, выбор будет намного проще.