Поиск…


Вступление

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

Сценарии являются одним из основных компонентов, с которыми вы будете разрабатывать и создавать свои приложения. Цель этой статьи - просто познакомиться с типами сценариев и доступными событиями.

Скрипт клиента

Скрипт клиента является одним из наиболее часто используемых и сложных типов сценариев, доступных вам. Как следует из его названия, клиентский скрипт запускается в браузере, то есть на стороне клиента. Это единственный тип скрипта, который работает на стороне клиента; все остальные будут выполняться на стороне сервера NetSuite.

Основное использование Client Script - это ответ на взаимодействие пользователей с формами записей в пользовательском интерфейсе NetSuite.

Как только пользователь загружает форму записи в режиме редактирования, pageInit событие pageInit которое мы можем использовать для запуска кода при инициализации формы, прежде чем пользователь сможет взаимодействовать с ним.

Всякий раз, когда пользователь меняет какое-либо поле в форме, запускается серия событий:

  1. Открывается событие validateField которое позволяет нам проверять значение, которое пользователь пытается ввести в поле. Мы можем использовать это, чтобы принять или предотвратить изменение.
  2. Затем fieldChanged событие fieldChanged которое позволяет нам реагировать на новое значение в поле.
  3. Наконец, событие postSourcing запускается после того, как все и все зависимые поля также получены в их значениях. Это позволяет нам реагировать на изменения и следить за тем, чтобы мы работали со всеми правильными данными.

Эта серия событий срабатывает независимо от того, изменяет ли пользователь поле тела или поле подписок.

Когда пользователь внесет изменения в строки подписок, будет запущена другая серия событий:

  1. Событие lineInit запускается каждый раз, когда пользователь изначально выбирает новую или существующую строку, прежде чем они смогут внести какие-либо изменения в поля в строке.
  2. Всякий раз, когда пользователь нажимает кнопку « Добавить» , чтобы добавить новую строку, запускается событие validateLine которое позволяет нам проверить, что вся строка действительна и может быть добавлена ​​в запись.
  3. Всякий раз, когда пользователь нажимает кнопку « Вставить» , чтобы добавить новую строку над существующей, запускается событие validateInsert , которое работает точно так же, как событие validateLine .
  4. Аналогично, всякий раз, когда пользователь пытается удалить строку, запускается validateDelete которая позволяет либо разрешить, либо запретить удаление строки.
  5. [Только для SuiteScript 1.0]. Наконец, после успешного выполнения соответствующего события проверки, если изменение в строке также повлияло на изменение общей суммы транзакции, то recalc событие recalc которое позволяет нам реагировать на изменение количества наших сделка.
  6. [Только для SuiteScript 2.0] Наконец, после успешного завершения соответствующего события проверки событие sublistChanged будет sublistChanged чтобы мы могли ответить на завершенное изменение строки.

Наконец, когда пользователь нажимает кнопку « Сохранить» в записи, saveRecord событие saveRecord которое позволяет нам проверить правильность записи и ее сохранение. Мы можем либо предотвратить сохранение, либо позволить ему продолжить это событие.

Скрипт клиента, безусловно, является большинством событий любого типа скрипта и наиболее сложной взаимосвязью между этими событиями.

Сценарий пользовательского события

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

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

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

Как только процесс или пользователь попытается отправить запись в базу данных, будь то создание новой записи, редактирование существующей записи или удаление записи, происходит следующая последовательность:

  1. Во-первых, прежде чем запрос действительно пробивается к базе данных, beforeSubmit событие beforeSubmit . Мы можем использовать это событие, например, для очистки записи до ее загрузки в базу данных.
  2. Запрос отправляется в базу данных, и запись создается / модифицируется / удаляется соответствующим образом.
  3. По завершении обработки базы данных afterSubmit событие afterSubmit . Мы можем использовать это событие, например, для отправки уведомлений об изменениях в электронной почте или для синхронизации со встроенными сторонними системами.

Вы также можете посмотреть эту серию видеороликов, которые помогают визуализировать события этого типа сценария.

Запланированные и картографические / сокращенные сценарии

Существует два типа сценариев, которые мы можем использовать для выполнения фоновой обработки на определенном регулярном интервале; это сценарии Scheduled и Map / Reduce . Обратите внимание, что тип сценария Map / Reduce доступен только в SuiteScript 2.0. Сценарий Scheduled доступен для версий 1.0 и 2.0.

Сценарий Scheduled имеет только одно событие execute которое запускается при любом расписании, которое вы определяете. Например, вы можете запустить ночной скрипт, который применяет платежи к счетам или почасовой скрипт, который синхронизирует данные с внешней системой. Когда временной интервал попадает, NetSuite запускает это событие execute в вашем сценарии Scheduled.

Сценарий Map / Reduce работает аналогично, но как только он запускается, он разбивает обработку на четыре различные фазы:

  1. На этапе getInputData вы собираете все входные данные, необходимые для завершения бизнес-процесса. Вы можете использовать этот этап для выполнения поиска, чтения записей и упаковки ваших данных в дешифруемую структуру данных.
  2. NetSuite автоматически передает результаты вашей фазы getInputData во вторую фазу, называемую map . Эта фаза отвечает за логическую группировку ваших входных данных для обработки. Например, если вы применяете платежи к счетам-фактурам, вы можете сначала сгруппировать счета-фактуры Клиентом.
  3. Результаты фазы map затем передаются на фазу reduce , где происходит фактическая обработка. Здесь вы, в соответствии с нашим примером, действительно применяете платежи к счетам-фактурам.
  4. Наконец, вызывается фаза 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


Modified text is an extract of the original Stack Overflow Documentation
Лицензировано согласно CC BY-SA 3.0
Не связан с Stack Overflow