netsuite
Présentation du type de script

Introduction

Le script client

Le script client est l'un des types de script les plus utilisés et les plus complexes à votre disposition. Comme son nom l'indique, le script client s'exécute dans le navigateur, c'est-à-dire côté client. C'est le seul type de script qui s'exécute du côté client. tous les autres s'exécuteront du côté serveur de NetSuite.

La principale utilisation du script client est de répondre aux interactions des utilisateurs avec les formulaires d’enregistrement dans l’interface utilisateur de NetSuite.

Dès que l'utilisateur charge un formulaire d'enregistrement en mode Edition, un événement pageInit est déclenché, que nous pouvons utiliser pour exécuter du code lorsque le formulaire est initialisé, avant que l'utilisateur puisse interagir avec lui.

Chaque fois que l'utilisateur modifie un champ du formulaire, une série d'événements se déclenche:

1. Un événement validateField déclenche pour nous permettre de valider la valeur que l'utilisateur tente d'entrer dans le champ. Nous pouvons l'utiliser pour accepter ou empêcher le changement.
2. Un événement fieldChanged se déclenche puis nous permet de répondre à la nouvelle valeur dans le champ.
3. Enfin, un événement postSourcing - postSourcing déclenche après que tous les champs dépendants ont également été inclus dans leurs valeurs. Cela nous permet de réagir au changement et de nous assurer que nous travaillons avec toutes les données correctes.

Cette série d'événements se déclenche, que l'utilisateur modifie un champ de corps ou un champ de sous-liste.

Lorsque l'utilisateur modifie les lignes de sous-liste, une autre série d'événements sera déclenchée:

1. Un événement lineInit est déclenché à chaque fois que l'utilisateur sélectionne initialement une ligne nouvelle ou existante avant de pouvoir apporter des modifications aux champs de la ligne.
2. Chaque fois que l'utilisateur clique sur le bouton Ajouter pour ajouter une nouvelle ligne, un événement validateLine est déclenché, ce qui nous permet de vérifier que la ligne entière est valide et peut être ajoutée à l'enregistrement.
3. Chaque fois que l'utilisateur clique sur le bouton Insérer pour ajouter une nouvelle ligne au-dessus d'une ligne existante, un événement validateInsert est déclenché, ce qui fonctionne exactement comme l'événement validateLine .
4. De même, chaque fois que l'utilisateur essaie de supprimer une ligne, un validateDelete qui permet d'autoriser ou de refuser la suppression de la ligne est déclenché.
5. [SuiteScript 1.0 uniquement] Enfin, après la réussite de l’événement de validation approprié, si la modification de la ligne a également modifié le montant total d’une transaction, un événement de recalc est déclenché, ce qui nous permet de répondre à la modification du montant de notre transaction. transaction.
6. [SuiteScript 2.0 uniquement] Enfin, après la sublistChanged événement de validation approprié, un événement sublistChanged est déclenché pour nous permettre de répondre au changement de ligne terminé.

Enfin, lorsque l'utilisateur clique sur le bouton Enregistrer de l'enregistrement, un événement saveRecord est déclenché, ce qui nous permet de valider si l'enregistrement est valide et peut être enregistré. Nous pouvons empêcher la sauvegarde de se produire ou lui permettre de poursuivre cet événement.

Le script client a de loin le plus grand nombre d’événements de tout type de script et la relation la plus complexe entre ces événements.

Le script d'événement utilisateur

Le script d'événement utilisateur est étroitement lié au script client. Les événements de ce type de script sont à nouveau déclenchés lors du chargement ou de l'enregistrement d'un enregistrement, mais s'exécutent plutôt du côté du serveur. En tant que tel, il ne peut pas être utilisé pour répondre immédiatement aux changements de champs, mais il ne se limite pas aux seuls utilisateurs qui interagissent avec l'enregistrement sur un formulaire.

Les scripts d'événements utilisateur s'exécuteront peu importe d'où provient la demande de chargement ou d'envoi, qu'il s'agisse d'un utilisateur travaillant dans l'interface utilisateur, d'une intégration tierce ou d'un autre script interne effectuant la requête.

Lorsqu'un processus ou un utilisateur tente de lire un enregistrement hors de la base de données, l'événement beforeLoad événement utilisateur est déclenché. Nous pouvons l'utiliser pour pré-traiter des données, définir des valeurs par défaut ou manipuler le formulaire d'interface utilisateur avant que l'utilisateur ne le voit.

Une fois qu'un processus ou un utilisateur tente de soumettre un enregistrement à la base de données, qu'il s'agisse de créer un nouvel enregistrement, de modifier un enregistrement existant ou de supprimer un enregistrement, la séquence suivante se produit:

1. Tout d'abord, avant que la demande ne beforeSubmit réellement à la base de données, un événement beforeSubmit déclenche. Nous pouvons utiliser cet événement, par exemple, pour nettoyer l’enregistrement avant qu’il entre dans la base de données.
2. La demande est envoyée à la base de données et l'enregistrement est créé / modifié / supprimé en conséquence.
3. Une fois le traitement de la base de données terminé, un événement afterSubmit déclenche. Nous pouvons utiliser cet événement, par exemple, pour envoyer des notifications par courrier électronique des modifications ou pour vous synchroniser avec des systèmes tiers intégrés.

Vous pouvez également regarder cette série de vidéos qui aident à visualiser les événements de ce type de script.

Les scripts programmés et de mappage / réduction

Nous pouvons utiliser deux types de scripts pour exécuter le traitement en arrière-plan sur un intervalle spécifique et régulier. Ce sont les scripts Scheduled et Map / Reduce . Notez que le type de script Map / Reduce est uniquement disponible dans SuiteScript 2.0. Le script programmé est disponible pour les versions 1.0 et 2.0.

Le script planifié ne comporte qu'un seul événement d' execute qui est déclenché selon le planning que vous définissez. Par exemple, vous pouvez exécuter un script de nuit qui applique des paiements aux factures ou un script horaire qui synchronise les données avec un système externe. Lorsque l'intervalle de temps est écoulé, NetSuite déclenche cet événement d' execute sur votre script planifié.

Le script Map / Reduce fonctionne de la même manière, mais une fois déclenché, il divise le traitement en quatre phases distinctes:

1. La phase getInputData est l'endroit où vous collectez toutes les données d'entrée dont vous aurez besoin pour terminer le processus technique. Vous pouvez utiliser cette phase pour effectuer des recherches, lire des enregistrements et regrouper vos données dans une structure de données déchiffrable.
2. NetSuite transmet automatiquement les résultats de votre phase getInputData à la deuxième phase, appelée map . Cette phase est responsable du regroupement logique de vos données d'entrée pour le traitement. Par exemple, si vous appliquez des paiements à des factures, vous pouvez d'abord regrouper les factures par le client.
3. Les résultats de la phase de map sont ensuite transmis à la phase de reduce , qui correspond au traitement proprement dit. C'est ici que, conformément à notre exemple, vous appliquez réellement les paiements aux factures.
4. Enfin, une phase summary contenant des données sur les résultats de tous vos traitements au cours des trois phases précédentes est appelée. Vous pouvez l'utiliser pour générer des rapports ou envoyer des e-mails dont le traitement est terminé.

Le principal avantage du script Map / Reduce est que NetSuite met automatiquement le traitement en parallèle pour vous sur plusieurs files d'attente, le cas échéant.

Ces deux types de script ont une limite de gouvernance extrêmement étendue. Vous pouvez donc également les utiliser pour le traitement en bloc ou les processus d'arrière-plan généralement longs.

L'intervalle le plus court de ces types de script peut être configuré pour s'exécuter toutes les 15 minutes.

Ces deux types de script peuvent également être appelés à la demande par les utilisateurs ou par d'autres scripts, si nécessaire.

Les scripts Suitelet et Portlet

Nous souhaitons souvent créer des pages d’interface personnalisées dans NetSuite; entrez la Suitelet. Le script Suitelet est conçu pour générer des pages d'interface utilisateur personnalisées internes. Les pages peuvent être du format HTML libre ou utiliser les API de Builder UI de NetSuite pour créer des formulaires conformes à l'apparence de NetSuite.

Lorsqu'il est déployé, Suitelet reçoit sa propre URL unique. Suitelet possède alors un événement de render unique appelé chaque fois que cette URL est frappée avec une requête HTTP GET ou POST . En règle générale, la réponse à l' GET demande serait de rendre la forme elle - même, et la forme serait POST à lui - même pour le traitement des données de formulaire.

Nous pouvons également tirer parti de Suitelets pour créer des progressions d'interface de type assistant à l'aide des composants de l'interface utilisateur "Assistant" de NetSuite.

Les portlets sont extrêmement similaires à Suitelets, sauf qu'ils sont spécifiquement utilisés pour créer des widgets de tableau de bord personnalisés plutôt que des pages personnalisées complètes. En dehors de cela, les deux types de script fonctionnent de manière très similaire.

Le RESTlet

Les RESTlets nous permettent de créer des points de terminaison personnalisés basés sur REST dans NetSuite; ainsi, les RESTlets constituent la colonne vertébrale de presque toutes les intégrations dans NetSuite.

Les RESTlets fournissent des gestionnaires d'événements individuels pour quatre des méthodes de requête HTTP les plus utilisées:

• GET
• POST
• PUT
• DELETE

Lorsqu'un RESTlet reçoit une demande, il achemine la demande vers la fonction de gestionnaire d'événements appropriée en fonction de la méthode de requête HTTP utilisée.

L'authentification à un RESTlet peut être effectuée via une session utilisateur, des en-têtes HTTP ou des jetons OAuth.

Le script de mise à jour de masse

En utilisant le script de mise à jour de masse, nous pouvons créer des mises à jour de masse personnalisées pour les utilisateurs. Cela fonctionne comme une mise à jour de masse normale, où l'utilisateur sélectionne le type de mise à jour de masse, crée une recherche qui renvoie les enregistrements à mettre à jour, puis chaque résultat de recherche est transmis individuellement au script de mise à jour de masse personnalisé.

Le script fournit un each gestionnaire d'événements qui reçoit l'ID interne et le type d' enregistrement de l'enregistrement qui doit être mis à jour.

Les scripts de mise à jour en masse doivent être déclenchés manuellement par les utilisateurs via l'interface de mise à jour standard.

Les scripts de mise à jour en masse ont une limite de gouvernance extrêmement élevée et sont destinés au traitement en masse personnalisé, couramment utilisé.

Le script d'action de workflow

Les flux de travail peuvent être quelque peu limités dans leurs fonctionnalités. Par exemple, les flux de travail ne peuvent pas interagir avec les éléments de campagne. Le type de script Action de flux de travail est destiné à être appelé par un flux de travail pour ajouter une fonctionnalité de script afin de réaliser ce que le flux de travail lui-même ne peut pas.

Les actions de workflow ont un seul onAction événement onAction qui sera onAction par le workflow.

Le script d'installation de l'ensemble

Enfin, nous avons le type de script Installation de l'ensemble, qui fournit plusieurs événements qui nous permettent d'interagir avec l'installation, la mise à jour et la désinstallation d'un ensemble particulier. C'est un type de script rarement rencontré, mais il est important d'en être conscient.

L'installation de l'ensemble inclut les gestionnaires d'événements suivants, qui doivent être assez explicites:

• beforeInstall
• afterInstall
• beforeUpdate
• afterUpdate
• beforeUninstall