netsuite
Panoramica sul tipo di script

introduzione

Lo script client

Lo script client è uno dei più comuni e complessi tipi di script disponibili. Come suggerisce il nome, lo script client viene eseguito nel browser, cioè sul lato client. È l'unico tipo di script che viene eseguito sul lato client; tutti gli altri verranno eseguiti sul lato server di NetSuite.

L'uso principale dello script client è per rispondere alle interazioni dell'utente con i moduli di registrazione nell'interfaccia utente di NetSuite.

Non appena l'utente carica un modulo di registrazione in modalità Modifica, viene pageInit un evento pageInit che è possibile utilizzare per eseguire il codice non appena il modulo viene inizializzato, prima che l'utente possa interagire con esso.

Ogni volta che l'utente modifica qualsiasi campo nel modulo, verrà attivata una serie di eventi:

1. Viene generato un evento di convalida Campo di validateField che ci consente di convalidare il valore che l'utente sta tentando di immettere nel campo. Possiamo usare questo per accettare o impedire che il cambiamento avvenga.
2. fieldChanged evento fieldChanged che ci consente di rispondere al nuovo valore nel campo.
3. Infine, un evento postSourcing dopo che tutti i campi dipendenti hanno anche acquisito i loro valori. Questo ci consente di rispondere al cambiamento e di assicurarci che stiamo lavorando con tutti i dati corretti.

Questa serie di eventi si attiva indipendentemente dal fatto che l'utente stia modificando un campo corpo o un campo sottolista.

Quando l'utente apporta modifiche alle linee di sottolista, verrà attivata un'altra serie di eventi:

1. Un evento lineInit viene lineInit ogni volta che l'utente seleziona inizialmente una linea nuova o esistente, prima che sia in grado di apportare modifiche ai campi sulla linea.
2. Ogni volta che l'utente fa clic sul pulsante Aggiungi per aggiungere una nuova riga, viene validateLine un evento validateLine che consente di verificare che l'intera riga sia valida e possa essere aggiunta al record.
3. Ogni volta che l'utente fa clic sul pulsante Inserisci per aggiungere una nuova riga sopra una esistente, viene validateInsert un evento validateInsert , che funziona esattamente come l'evento validateLine .
4. Allo stesso modo, ogni volta che l'utente tenta di rimuovere una linea, viene validateDelete un validateDelete che consente di consentire o negare la rimozione della linea.
5. [Solo SuiteScript 1.0] Infine, dopo che l'evento di convalida appropriato ha avuto esito positivo, se la modifica apportata alla linea ha anche apportato una modifica all'importo totale di una transazione, viene recalc un evento di recalc che consente di rispondere alla variazione di importo della nostra transazione.
6. [Solo SuiteScript 2.0] Infine, dopo il successo dell'evento di convalida appropriato, viene sublistChanged un evento sublistChanged per consentirci di rispondere alla modifica della linea completata.

Infine, quando l'utente fa clic sul pulsante Salva sul record, viene saveRecord un evento saveRecord che consente di verificare se il record è valido e può essere salvato. Possiamo impedire che il salvataggio si verifichi o consentirgli di procedere con questo evento.

Lo script Client ha di gran lunga la maggior parte degli eventi di qualsiasi tipo di Script e la relazione più complessa tra questi eventi.

Lo script degli eventi utente

Strettamente correlato allo script client è lo script evento utente. Gli eventi di questo tipo di script vengono nuovamente attivati ​​quando un record viene caricato o salvato, ma viene eseguito sul lato server. In quanto tale, non può essere utilizzato per rispondere immediatamente alle modifiche sul campo, ma non è limitato ai soli utenti che interagiscono con il record su un modulo.

Gli script degli eventi utente verranno eseguiti indipendentemente da dove viene il carico o la richiesta di invio, indipendentemente dal fatto che si tratti di un utente che lavora nell'interfaccia utente, di un'integrazione di terze parti o di un altro script interno che effettua la richiesta.

Ogni volta che un processo o un utente tenta di leggere un record dal database, viene attivato l'evento beforeLoad dell'evento utente. Possiamo usarlo per pre-elaborare i dati, impostare valori predefiniti o manipolare il modulo di interfaccia utente prima che l'utente lo veda.

Una volta che un processo o un utente tenta di inviare un record al database, che si tratti della creazione di un nuovo record, della modifica di un record esistente o della cancellazione di un record, si verifica la seguente sequenza:

1. Innanzitutto, prima che la richiesta beforeSubmit effettivamente al database, viene beforeSubmit un evento beforeSubmit . Possiamo usare questo evento, ad esempio, per ripulire il record prima che entri nel database.
2. La richiesta viene inviata al database e il record viene creato / modificato / cancellato di conseguenza.
3. Al termine dell'elaborazione del database, viene afterSubmit un evento afterSubmit . Possiamo utilizzare questo evento, ad esempio, per inviare notifiche via email di modifiche o per sincronizzarci con sistemi integrati di terze parti.

Puoi anche guardare questa serie di video che aiutano a visualizzare gli eventi di questo tipo di script.

The Scheduled e Map / Reduce Scripts

Esistono due tipi di script che possiamo sfruttare per eseguire l'elaborazione in background su un intervallo regolare specifico; questi sono gli script Programmato e Mappa / Riduci . Si noti che il tipo di script Mappa / Riduci è disponibile solo in SuiteScript 2.0. Lo script programmato è disponibile per 1.0 e 2.0.

Lo script pianificato ha solo un singolo evento di execute che viene attivato in qualsiasi pianificazione definita. Ad esempio, potresti voler eseguire uno script notturno che applica i pagamenti alle fatture o uno script orario che sincronizza i dati con un sistema esterno. Quando arriva l'intervallo di tempo, NetSuite attiva questo evento di execute nello script Programmato.

Lo script Mappa / Riduci funziona in modo simile, ma una volta attivato, interrompe l'elaborazione in quattro fasi distinte:

1. La fase getInputData è dove raccogli tutti i dati di input necessari per completare il processo di business. È possibile utilizzare questa fase per eseguire ricerche, leggere record e impacchettare i dati in una struttura di dati decifrabile.
2. NetSuite passa automaticamente i risultati della fase getInputData alla seconda fase, chiamata map . Questa fase è responsabile del raggruppamento logico dei dati di input per l'elaborazione. Ad esempio, se stai applicando i pagamenti alle fatture, potresti voler raggruppare prima le fatture per Cliente.
3. I risultati della fase map vengono quindi passati alla fase di reduce , che è il luogo in cui avviene l'elaborazione effettiva. Questo è dove vorresti, mantenendo il nostro esempio, applicare effettivamente i Pagamenti alle Fatture.
4. Infine, viene invocata una fase di summary che contiene i dati relativi ai risultati di tutte le elaborazioni effettuate nelle tre fasi precedenti. È possibile utilizzare questo per generare report o inviare e-mail che l'elaborazione è completa.

Il vantaggio principale dello script Map / Reduce è che NetSuite eseguirà automaticamente il parallelismo dell'elaborazione su più code, se disponibile.

Entrambi questi tipi di script hanno un limite di governance estremamente ampio, quindi è possibile utilizzarli anche per l'elaborazione di massa o in genere per processi in background di lunga durata.

L'intervallo più breve di questi tipi di script può essere configurato per l'esecuzione ogni 15 minuti.

Entrambi questi tipi di script possono anche essere richiamati su richiesta dagli utenti o da altri script, se necessario.

Gli script Suitelet e Portlet

Spesso vorremmo costruire pagine di interfaccia utente personalizzate in NetSuite; entra nella Suitelet. Lo script Suitelet è progettato per la creazione di pagine dell'interfaccia utente personalizzate interne. Le pagine possono essere in formato HTML, oppure possono utilizzare le API di UI Builder di NetSuite per costruire moduli che seguano l'aspetto di NetSuite.

Quando viene distribuito, Suitelet riceve il proprio URL univoco. La Suitelet ha quindi un singolo evento di render che viene chiamato ogni volta che l'URL viene colpito con una richiesta HTTP GET o POST . In genere, la risposta alla GET richiesta sarebbe quella di rendere la forma stessa, e quindi la forma sarebbe POST a se stesso per l'elaborazione dei dati del modulo.

Possiamo anche sfruttare Suitelets per costruire progressioni dell'interfaccia utente in stile wizard utilizzando i componenti dell'interfaccia utente "Assistente" di NetSuite.

I portlet sono estremamente simili a Suitelet, tranne per il fatto che sono specificamente utilizzati per creare widget dashboard personalizzati piuttosto che pagine personalizzate complete. Oltre a questo, i due tipi di script funzionano in modo molto simile.

The RESTlet

Gli RESTlet ci consentono di creare endpoint personalizzati basati su REST in NetSuite; quindi, RESTlet costituisce la spina dorsale di quasi ogni integrazione in NetSuite.

RESTlet fornisce gestori di eventi individuali per quattro dei metodi di richiesta HTTP più comunemente utilizzati:

• GET
• POST
• PUT
• DELETE

Quando un RESTlet riceve una richiesta, instraderà la richiesta alla funzione di gestore eventi appropriata in base al metodo di richiesta HTTP utilizzato.

L'autenticazione su un RESTlet può essere eseguita tramite sessione utente, intestazioni HTTP o token OAuth.

Lo script di aggiornamento di massa

Utilizzando lo script di aggiornamento di massa, possiamo creare aggiornamenti di massa personalizzati per gli utenti. Funziona esattamente come un normale aggiornamento di massa, in cui l'utente seleziona il tipo di aggiornamento di massa, crea una ricerca che restituisce i record da aggiornare e quindi ogni risultato di ricerca viene passato singolarmente nello script personalizzato di aggiornamento di massa.

Lo script fornisce un unico each gestore di eventi che riceve l'ID e registrare tipo interno del record che deve essere aggiornata.

Gli script di aggiornamento di massa devono essere attivati ​​manualmente dagli utenti tramite l'interfaccia standard di Mass Update.

Gli script di aggiornamento di massa hanno un limite di governance estremamente elevato e sono destinati all'elaborazione in blocco personalizzata di uso comune.

Lo script di azione del flusso di lavoro

I flussi di lavoro possono essere alquanto limitati nella loro funzionalità; ad esempio, i flussi di lavoro non possono interagire con gli elementi pubblicitari. Il tipo di script Action del flusso di lavoro è destinato ad essere richiamato da un flusso di lavoro per aggiungere funzionalità di scripting per realizzare ciò che il flusso di lavoro stesso non può.

Le azioni del flusso di lavoro hanno un singolo gestore di eventi onAction che verrà richiamato dal flusso di lavoro.

Lo script di installazione del pacchetto

Infine, abbiamo il tipo di script Installazione bundle, che fornisce diversi eventi che ci consentono di interagire con l'installazione, l'aggiornamento e la disinstallazione di un particolare pacchetto. Questo è un tipo di script incontrato raramente, ma è importante essere comunque a conoscenza.

L'installazione del pacchetto include i seguenti gestori di eventi, che dovrebbero essere abbastanza auto-esplicativi:

• beforeInstall
• afterInstall
• beforeUpdate
• afterUpdate
• beforeUninstall