netsuite
Обзор типа скрипта
Поиск…
Вступление
Вы создаете настройки SuiteScript с помощью управляемой событиями системы. Вы определяете различные типы записей сценариев, каждый из которых имеет свой собственный уникальный набор событий, а в исходном файле вы определяете функции, которые будут вызываться для обработки этих событий по мере их возникновения.
Сценарии являются одним из основных компонентов, с которыми вы будете разрабатывать и создавать свои приложения. Цель этой статьи - просто познакомиться с типами сценариев и доступными событиями.
Скрипт клиента
Скрипт клиента является одним из наиболее часто используемых и сложных типов сценариев, доступных вам. Как следует из его названия, клиентский скрипт запускается в браузере, то есть на стороне клиента. Это единственный тип скрипта, который работает на стороне клиента; все остальные будут выполняться на стороне сервера NetSuite.
Основное использование Client Script - это ответ на взаимодействие пользователей с формами записей в пользовательском интерфейсе NetSuite.
Как только пользователь загружает форму записи в режиме редактирования, pageInit
событие pageInit
которое мы можем использовать для запуска кода при инициализации формы, прежде чем пользователь сможет взаимодействовать с ним.
Всякий раз, когда пользователь меняет какое-либо поле в форме, запускается серия событий:
- Открывается событие
validateField
которое позволяет нам проверять значение, которое пользователь пытается ввести в поле. Мы можем использовать это, чтобы принять или предотвратить изменение. - Затем
fieldChanged
событиеfieldChanged
которое позволяет нам реагировать на новое значение в поле. - Наконец, событие
postSourcing
запускается после того, как все и все зависимые поля также получены в их значениях. Это позволяет нам реагировать на изменения и следить за тем, чтобы мы работали со всеми правильными данными.
Эта серия событий срабатывает независимо от того, изменяет ли пользователь поле тела или поле подписок.
Когда пользователь внесет изменения в строки подписок, будет запущена другая серия событий:
- Событие
lineInit
запускается каждый раз, когда пользователь изначально выбирает новую или существующую строку, прежде чем они смогут внести какие-либо изменения в поля в строке. - Всякий раз, когда пользователь нажимает кнопку « Добавить» , чтобы добавить новую строку, запускается событие
validateLine
которое позволяет нам проверить, что вся строка действительна и может быть добавлена в запись. - Всякий раз, когда пользователь нажимает кнопку « Вставить» , чтобы добавить новую строку над существующей, запускается событие
validateInsert
, которое работает точно так же, как событиеvalidateLine
. - Аналогично, всякий раз, когда пользователь пытается удалить строку, запускается
validateDelete
которая позволяет либо разрешить, либо запретить удаление строки. - [Только для SuiteScript 1.0]. Наконец, после успешного выполнения соответствующего события проверки, если изменение в строке также повлияло на изменение общей суммы транзакции, то
recalc
событиеrecalc
которое позволяет нам реагировать на изменение количества наших сделка. - [Только для SuiteScript 2.0] Наконец, после успешного завершения соответствующего события проверки событие
sublistChanged
будетsublistChanged
чтобы мы могли ответить на завершенное изменение строки.
Наконец, когда пользователь нажимает кнопку « Сохранить» в записи, saveRecord
событие saveRecord
которое позволяет нам проверить правильность записи и ее сохранение. Мы можем либо предотвратить сохранение, либо позволить ему продолжить это событие.
Скрипт клиента, безусловно, является большинством событий любого типа скрипта и наиболее сложной взаимосвязью между этими событиями.
Сценарий пользовательского события
Сквозное отношение к скрипту клиента - это сценарий пользовательского события. События этого типа сценария снова запускаются, когда запись загружается или сохраняется, но вместо этого выполняется на стороне сервера. Таким образом, он не может быть использован для немедленного реагирования на изменения поля, но он также не ограничивается только пользователями, взаимодействующими с записью в форме.
Скрипты пользовательских событий будут выполняться независимо от того, откуда приходит запрос на загрузку или отправку, независимо от того, работает ли пользователь в пользовательском интерфейсе, сторонняя интеграция или другой внутренний скрипт, делающий запрос.
Всякий раз, когда процесс или пользователь пытается прочитать запись из базы данных, beforeLoad
событие beforeLoad
события. Мы можем использовать это для предварительной обработки данных, установки значений по умолчанию или манипулирования формой пользовательского интерфейса перед тем, как пользователь увидит его.
Как только процесс или пользователь попытается отправить запись в базу данных, будь то создание новой записи, редактирование существующей записи или удаление записи, происходит следующая последовательность:
- Во-первых, прежде чем запрос действительно пробивается к базе данных,
beforeSubmit
событиеbeforeSubmit
. Мы можем использовать это событие, например, для очистки записи до ее загрузки в базу данных. - Запрос отправляется в базу данных, и запись создается / модифицируется / удаляется соответствующим образом.
- По завершении обработки базы данных
afterSubmit
событиеafterSubmit
. Мы можем использовать это событие, например, для отправки уведомлений об изменениях в электронной почте или для синхронизации со встроенными сторонними системами.
Вы также можете посмотреть эту серию видеороликов, которые помогают визуализировать события этого типа сценария.
Запланированные и картографические / сокращенные сценарии
Существует два типа сценариев, которые мы можем использовать для выполнения фоновой обработки на определенном регулярном интервале; это сценарии Scheduled и Map / Reduce . Обратите внимание, что тип сценария Map / Reduce доступен только в SuiteScript 2.0. Сценарий Scheduled доступен для версий 1.0 и 2.0.
Сценарий Scheduled имеет только одно событие execute
которое запускается при любом расписании, которое вы определяете. Например, вы можете запустить ночной скрипт, который применяет платежи к счетам или почасовой скрипт, который синхронизирует данные с внешней системой. Когда временной интервал попадает, NetSuite запускает это событие execute
в вашем сценарии Scheduled.
Сценарий Map / Reduce работает аналогично, но как только он запускается, он разбивает обработку на четыре различные фазы:
- На этапе
getInputData
вы собираете все входные данные, необходимые для завершения бизнес-процесса. Вы можете использовать этот этап для выполнения поиска, чтения записей и упаковки ваших данных в дешифруемую структуру данных. - NetSuite автоматически передает результаты вашей фазы
getInputData
во вторую фазу, называемуюmap
. Эта фаза отвечает за логическую группировку ваших входных данных для обработки. Например, если вы применяете платежи к счетам-фактурам, вы можете сначала сгруппировать счета-фактуры Клиентом. - Результаты фазы
map
затем передаются на фазуreduce
, где происходит фактическая обработка. Здесь вы, в соответствии с нашим примером, действительно применяете платежи к счетам-фактурам. - Наконец, вызывается фаза
summary
которая содержит данные о результатах всей вашей обработки в течение предыдущих трех фаз. Вы можете использовать это для создания отчетов или отправки электронных писем, которые завершают обработку.
Основным преимуществом сценария Map / Reduce является то, что NetSuite автоматически распараллеливает обработку для нескольких очередей, если они доступны.
Оба эти типа сценариев имеют чрезвычайно большой лимит управления, поэтому вы также можете использовать их для массовой обработки или, как правило, длительных фоновых процессов.
Самый короткий интервал любого из этих типов сценариев можно настроить для запуска каждые 15 минут.
Оба эти типа сценариев также могут быть вызваны по требованию пользователями или другими скриптами, если это необходимо.
Сценарии Suitelet и Portlet
Часто мы хотим создавать пользовательские страницы пользовательского интерфейса в NetSuite; войдите в Suitelet. Сценарий Suitelet предназначен для создания внутренних пользовательских страниц пользовательского интерфейса. Страницы могут быть свободными формами HTML, или они могут использовать API-интерфейсы UI Builder NetSuite для построения форм, которые следуют за внешним видом NetSuite.
Когда он развертывается, Suitelet получает свой собственный уникальный URL-адрес. Затем в Suitelet есть одно событие render
которое вызывается всякий раз, когда этот URL-адрес попадает с запросом HTTP GET
или POST
. Как правило, ответ на GET
заключается в том, чтобы отобразить форму самостоятельно, а затем форма POST
вернется к себе для обработки данных формы.
Мы также можем использовать Suitelets для создания прогрессивных пользовательских интерфейсов в стиле мастера с использованием компонентов интерфейса «Помощник» NetSuite.
Портлеты чрезвычайно похожи на Suitelets, за исключением того, что они специально используются для создания пользовательских виджетов панели управления, а не для полных пользовательских страниц. Кроме того, два типа сценариев очень похожи.
RESTlet
RESTлеты позволяют нам создавать пользовательские конечные точки на основе REST в NetSuite; Таким образом, RESTлеты образуют основу почти любой интеграции в NetSuite.
RESTлеты предоставляют отдельные обработчики событий для четырех наиболее часто используемых методов HTTP-запроса:
-
GET
-
POST
-
PUT
-
DELETE
Когда RESTlet получает запрос, он направляет запрос соответствующей функции обработчика событий на основе используемого метода HTTP-запроса.
Аутентификация RESTlet может выполняться через пользовательский сеанс, HTTP-заголовки или токены OAuth.
Скрипт массового обновления
Используя скрипт Mass Update, мы можем создавать пользовательские массовые обновления для пользователей. Это работает так же, как обычное массовое обновление, когда пользователь выбирает тип массового обновления, строит поиск, который возвращает обновляемые записи, а затем каждый результат поиска передается индивидуально в настраиваемый сценарий массового обновления.
Скрипт предоставляет один обработчик each
события, который получает внутренний идентификатор и тип записи записи, которая должна быть обновлена.
Скрипты массового обновления должны запускаться вручную пользователями через стандартный интерфейс Mass Update.
Скрипты массового обновления имеют предельно высокий уровень управления и предназначены для широко используемой, настраиваемой массовой обработки.
Скрипт действия рабочего процесса
Рабочие процессы могут быть несколько ограниченными по своей функциональности; например, рабочие процессы не могут взаимодействовать с позициями. Тип сценария действия Workflow предназначен для вызова Workflow для добавления функций сценариев для выполнения того, что сам рабочий процесс не может.
Действия Workflow имеют один onAction
события onAction
который будет вызываться Workflow.
Сценарий установки Bundle
Наконец, у нас есть тип сценария установки Bundle, который предоставляет несколько событий, которые позволяют нам взаимодействовать с установкой, обновлением и удалением определенного пакета. Это редко встречающийся тип скрипта, но важно знать, тем не менее.
Установка Bundle включает в себя следующие обработчики событий, которые должны быть достаточно понятными:
-
beforeInstall
-
afterInstall
-
beforeUpdate
-
afterUpdate
-
beforeUninstall