netsuite
Descripción general del tipo de script

Introducción

El script del cliente

El script del cliente es uno de los tipos de script más comúnmente utilizados y complejos disponibles para usted. Como su nombre lo indica, el script del cliente se ejecuta en el navegador, es decir, en el lado del cliente. Es el único tipo de script que se ejecuta en el lado del cliente; todos los demás se ejecutarán en el lado del servidor de NetSuite.

El uso principal de Client Script es para responder a las interacciones de los usuarios con los formularios de registro dentro de la interfaz de usuario de NetSuite.

Tan pronto como el usuario carga un formulario de registro en el modo de edición, se pageInit un evento pageInit que podemos usar para ejecutar el código cuando se inicializa el formulario, antes de que el usuario pueda interactuar con él.

Cada vez que el usuario cambia un campo en el formulario, se activarán una serie de eventos:

1. Se validateField evento validateField que nos permite validar el valor que el usuario está tratando de ingresar en el campo. Podemos usar esto para aceptar o evitar que se produzca el cambio.
2. Luego se dispara un evento fieldChanged que nos permite responder al nuevo valor en el campo.
3. Por último, se postSourcing un evento postSourcing después de que todos y cada uno de los campos dependientes también hayan obtenido sus valores. Esto nos permite responder al cambio y asegurarnos de que estamos trabajando con todos los datos correctos.

Esta serie de eventos se activa sin importar si el usuario está cambiando un campo de cuerpo o un campo de sublista.

A medida que el usuario realice cambios en las líneas de sub-listas, se activará otra serie de eventos:

1. Se lineInit evento lineInit cada vez que el usuario selecciona inicialmente una línea nueva o existente, antes de que puedan realizar cambios en los campos de la línea.
2. Cuando el usuario hace clic en el botón Agregar para agregar una nueva línea, se validateLine un evento validateLine que nos permite verificar que toda la línea es válida y se puede agregar al registro.
3. Cuando el usuario hace clic en el botón Insertar para agregar una nueva línea por encima de una existente, se validateInsert un evento validateInsert , que funciona exactamente igual que el evento validateLine .
4. De forma similar, siempre que el usuario intente eliminar una línea, se validateDelete un validateDelete que permite permitir o denegar la eliminación de la línea.
5. [Solo SuiteScript 1.0] Finalmente, después de que el evento de validación apropiado tenga éxito, si el cambio en la línea también recalc el monto total de una transacción, se recalc un evento de recalc que nos permite responder al cambio en el monto de nuestra transacción. transacción.
6. [Solo para SuiteScript 2.0] Finalmente, después de que el evento de validación apropiado tenga éxito, se sublistChanged un evento sublistChanged para permitirnos responder al cambio de línea completado.

Finalmente, cuando el usuario hace clic en el botón Guardar en el registro, se saveRecord un evento saveRecord que nos permite validar si el registro es válido y se puede guardar. Podemos evitar que ocurra el guardado o permitir que continúe con este evento.

La secuencia de comandos del cliente tiene, con mucho, la mayoría de los eventos de cualquier tipo de secuencia de comandos, y la relación más compleja entre esos eventos.

El script de eventos del usuario

Muy relacionado con el script del cliente está el script de eventos del usuario. Los eventos de este tipo de script se activan nuevamente cuando se carga o guarda un registro, pero en su lugar se ejecuta en el lado del servidor. Como tal, no se puede utilizar para responder inmediatamente a los cambios de campo, pero tampoco se limita a los usuarios que interactúan con el registro en un formulario.

Los scripts de eventos de usuario se ejecutarán sin importar de dónde venga la carga o la solicitud de envío, ya sea un usuario que trabaja en la interfaz de usuario, una integración de terceros u otro script interno que realiza la solicitud.

Cada vez que un proceso o usuario intenta leer un registro fuera de la base de datos, se desencadena el evento beforeLoad del Evento de beforeLoad . Podemos usar esto para preprocesar datos, establecer valores predeterminados o manipular el formulario de UI antes de que el usuario lo vea.

Una vez que un proceso o usuario intenta enviar un registro a la base de datos, ya sea la creación de un nuevo registro, la edición de un registro existente o la eliminación de un registro, se produce la siguiente secuencia:

1. Primero, antes de que la solicitud beforeSubmit a la base de datos, se beforeSubmit un evento beforeSubmit . Podemos usar este evento, por ejemplo, para limpiar el registro antes de que llegue a la base de datos.
2. La solicitud se envía a la base de datos y el registro se crea / modifica / elimina en consecuencia.
3. Una vez que se completa el procesamiento de la base de datos, se afterSubmit un evento afterSubmit . Podemos usar este evento, por ejemplo, para enviar notificaciones de cambios por correo electrónico o para sincronizar con sistemas de terceros integrados.

También puede ver esta serie de videos que ayudan a visualizar los eventos de este tipo de script.

Los scripts programados y mapear / reducir

Hay dos tipos de scripts que podemos aprovechar para ejecutar el procesamiento en segundo plano en un intervalo regular específico; estos son los scripts Programados y Mapa / Reducir . Tenga en cuenta que el tipo de script Map / Reduce solo está disponible en SuiteScript 2.0. El script programado está disponible tanto para 1.0 como para 2.0.

La secuencia de comandos programada solo tiene un único evento de execute que se activa en cualquier programación que defina. Por ejemplo, es posible que desee ejecutar un script nocturno que aplique los pagos a las facturas, o un script por hora que sincronice los datos con un sistema externo. Cuando llega el intervalo de tiempo, NetSuite dispara este evento de execute en su script programado.

El script Map / Reduce funciona de manera similar, pero una vez que se activa, divide el procesamiento en cuatro fases distintas:

1. La fase getInputData es donde recopila todos los datos de entrada que necesitará para completar el proceso de negocios. Puede usar esta fase para realizar búsquedas, leer registros y empaquetar sus datos en una estructura de datos descifrable.
2. NetSuite pasa automáticamente los resultados de su fase getInputData a la segunda fase, llamada map . Esta fase es responsable de agrupar los datos de entrada de forma lógica para su procesamiento. Por ejemplo, si está aplicando pagos a las facturas, es posible que desee agrupar primero las facturas por Cliente.
3. Los resultados de la fase del map se pasan luego a la fase de reduce , que es donde se lleva a cabo el procesamiento real. Aquí es donde usted, siguiendo nuestro ejemplo, aplicaría los pagos a las facturas.
4. Por último, se invoca una fase de summary que contiene datos sobre los resultados de todo su procesamiento en las tres fases anteriores. Puede usar esto para generar informes o enviar correos electrónicos con el procesamiento completo.

La principal ventaja de la secuencia de comandos Map / Reduce es que NetSuite paralelizará automáticamente el procesamiento para usted en múltiples colas, si está disponible.

Ambos tipos de script tienen un límite de gobierno extremadamente grande, por lo que también puede usarlos para procesos en masa o procesos en general de larga ejecución.

El intervalo más corto que se puede configurar para ejecutar cada uno de estos tipos de script es cada 15 minutos.

Ambos tipos de secuencias de comandos también pueden ser invocados a pedido por los usuarios o por otras secuencias de comandos, si es necesario.

Los scripts Suitelet y Portlet

A menudo, desearemos crear páginas de IU personalizadas en NetSuite; entrar en la Suitelet. El script de Suitelet está diseñado para crear páginas de UI internas y personalizadas. Las páginas pueden ser HTML de forma libre, o pueden utilizar las API de UI Builder de NetSuite para construir formularios que sigan la apariencia de NetSuite.

Cuando se implementa, un Suitelet recibe su propia URL única. El Suitelet luego tiene un solo evento de render que se invoca cada vez que esa URL recibe un GET HTTP GET o POST . Normalmente, la respuesta a la solicitud GET sería representar el formulario en sí, y luego el formulario se POST a POST para procesar los datos del formulario.

También podemos aprovechar los Suitelets para crear progresiones de UI de estilo asistente usando los componentes de UI "Asistente" de NetSuite.

Los portlets son extremadamente similares a los Suitelets, excepto que se usan específicamente para crear widgets de tablero personalizados en lugar de páginas personalizadas completas. Aparte de eso, los dos tipos de scripts funcionan muy parecidos.

El RESTlet

Los RESTlets nos permiten crear puntos finales personalizados basados ​​en REST en NetSuite; por lo tanto, los RESTlets forman la columna vertebral de casi cualquier integración en NetSuite.

Los RESTlets proporcionan controladores de eventos individuales para cuatro de los métodos de solicitud HTTP más utilizados:

• GET
• POST
• PUT
• DELETE

Cuando un RESTlet recibe una solicitud, la enrutará a la función apropiada del controlador de eventos en función del método de solicitud HTTP utilizado.

La autenticación a un RESTlet se puede realizar a través de una sesión de usuario, encabezados HTTP o tokens OAuth.

El guión de actualización masiva

Usando el script de actualización masiva, podemos crear actualizaciones masivas personalizadas para que los usuarios realicen. Esto funciona igual que una actualización masiva normal, donde el usuario selecciona el tipo de actualización masiva, crea una búsqueda que devuelve los registros a actualizar, y luego cada resultado de búsqueda se pasa individualmente al script personalizado de actualización masiva.

La secuencia de comandos proporciona un solo controlador de each evento que recibe la identificación interna y el tipo de registro del registro que se actualizará.

Los usuarios deben activar manualmente los scripts de actualización masiva a través de la interfaz estándar de actualización masiva.

Los scripts de actualización masiva tienen un límite de gobierno masivamente alto y están diseñados para el procesamiento masivo personalizado de uso común.

El script de acción de flujo de trabajo

Los flujos de trabajo pueden ser algo limitados en su funcionalidad; por ejemplo, los flujos de trabajo no pueden interactuar con artículos de línea. El tipo de secuencia de comandos de acción de flujo de trabajo está destinado a ser invocado por un flujo de trabajo para agregar funcionalidad de secuencias de comandos para lograr lo que el flujo de trabajo en sí no puede.

Las acciones de flujo de trabajo tienen un único controlador de eventos onAction que será invocado por el flujo de trabajo.

El script de instalación de paquete

Por último, tenemos el tipo de script de instalación de paquete, que proporciona varios eventos que nos permiten interactuar con la instalación, actualización y desinstalación de un paquete en particular. Este es un tipo de script raramente encontrado, pero es importante tenerlo en cuenta.

La instalación del paquete incluye los siguientes controladores de eventos, que deberían explicarse por sí mismos:

• beforeInstall
• afterInstall
• beforeUpdate
• afterUpdate
• beforeUninstall