netsuite
Overzicht scripttype

Invoering

Het client-script

Het clientscript is een van de meest gebruikte en complexe scripttypen die voor u beschikbaar zijn. Zoals de naam al aangeeft, wordt het clientscript in de browser uitgevoerd, dwz aan de clientzijde. Het is het enige scripttype dat aan de clientzijde wordt uitgevoerd; alle anderen worden uitgevoerd aan de serverkant van NetSuite.

Het primaire gebruik van het Client Script is voor het reageren op gebruikersinteracties met recordformulieren in de NetSuite UI.

Zodra de gebruiker een pageInit in de bewerkingsmodus laadt, wordt een gebeurtenis pageInit die we kunnen gebruiken om code uit te voeren terwijl het formulier wordt geïnitialiseerd, voordat de gebruiker ermee kan communiceren.

Wanneer de gebruiker vervolgens een veld in het formulier wijzigt, wordt een reeks gebeurtenissen geactiveerd:

1. Er wordt een validateField gebeurtenis geactiveerd waarmee we de waarde kunnen valideren die de gebruiker in het veld probeert in te voeren. We kunnen dit gebruiken om de wijziging te accepteren of te voorkomen.
2. Een gebeurtenis fieldChanged wordt vervolgens fieldChanged waardoor we kunnen reageren op de nieuwe waarde in het veld.
3. Ten slotte vuurt een postSourcing evenement af nadat alle afhankelijke velden ook hun waarden hebben gevonden. Dit stelt ons in staat om op de verandering te reageren en ervoor te zorgen dat we met alle juiste gegevens werken.

Deze reeks gebeurtenissen wordt geactiveerd, ongeacht of de gebruiker een bodyveld of een sublijstveld wijzigt.

Terwijl de gebruiker wijzigingen aanbrengt in sublijstregels, wordt een andere reeks gebeurtenissen geactiveerd:

1. Een lineInit gebeurtenis wordt lineInit wanneer de gebruiker in eerste instantie een nieuwe of bestaande regel selecteert, voordat deze wijzigingen in de velden op de regel kan aanbrengen.
2. Wanneer de gebruiker op de knop Toevoegen klikt om een nieuwe regel toe te voegen, wordt een gebeurtenis validateLine geactiveerd waarmee we kunnen controleren of de hele regel geldig is en aan de record kan worden toegevoegd.
3. Wanneer de gebruiker op de knop Invoegen klikt om een nieuwe regel boven een bestaande toe te voegen, wordt een gebeurtenis validateInsert geactiveerd, die precies hetzelfde werkt als de gebeurtenis validateLine .
4. Op dezelfde manier wordt telkens wanneer de gebruiker een lijn probeert te verwijderen een validateDelete geactiveerd waarmee de lijn kan worden verwijderd of verwijderd.
5. [Alleen SuiteScript 1.0] Ten slotte, als de juiste validatiegebeurtenis slaagt, en als de wijziging in de regel ook een wijziging van het totale bedrag van een transactie heeft veroorzaakt, wordt een recalc waarmee we kunnen reageren op de wijziging van het bedrag van onze transactie.
6. [Alleen SuiteScript 2.0] Ten slotte wordt, nadat de juiste validatiegebeurtenis slaagt, een sublistChanged gebeurtenis sublistChanged om ons in staat te stellen te reageren op de voltooide sublistChanged .

Als de gebruiker ten slotte op de knop Opslaan op het record klikt, wordt een gebeurtenis saveRecord waarmee we kunnen valideren of het record geldig is en kan worden opgeslagen. We kunnen voorkomen dat de opslag plaatsvindt of toestaan dat deze doorgaat met deze gebeurtenis.

Het Client-script heeft verreweg de meeste gebeurtenissen van elk Script-type en de meest complexe relatie tussen die gebeurtenissen.

Het gebruikersgebeurtenisscript

Nauw verwant aan het Client Script is het User Event Script. De gebeurtenissen van dit Script-type worden opnieuw geactiveerd wanneer een record wordt geladen of opgeslagen, maar wordt in plaats daarvan aan de serverzijde uitgevoerd. Als zodanig kan het niet worden gebruikt om onmiddellijk op veldwijzigingen te reageren, maar het is ook niet beperkt tot alleen gebruikers die interactie hebben met het record op een formulier.

Scripts voor gebruikersgebeurtenissen worden uitgevoerd, ongeacht waar het verzoek voor laden of indienen vandaan komt, of het nu een gebruiker is die in de gebruikersinterface werkt, een integratie met derden of een ander intern script dat het verzoek indient.

Wanneer een proces of gebruiker probeert een record uit de database te lezen, wordt de gebeurtenis beforeLoad de gebruiker geactiveerd. We kunnen dit gebruiken om gegevens voor te verwerken, standaardwaarden in te stellen of het UI-formulier te manipuleren voordat de gebruiker het ziet.

Zodra een proces of gebruiker probeert een record naar de database te verzenden, of het nu gaat om het maken van een nieuw record, het bewerken van een bestaand record of het verwijderen van een record, vindt de volgende volgorde plaats:

1. Eerst, voordat het verzoek daadwerkelijk zijn weg vindt naar de database, wordt een beforeSubmit gebeurtenis beforeSubmit . We kunnen deze gebeurtenis bijvoorbeeld gebruiken om het record op te schonen voordat het in de database komt.
2. Het verzoek wordt naar de database verzonden en het record wordt dienovereenkomstig gemaakt / gewijzigd / verwijderd.
3. Nadat de databaseverwerking is voltooid, wordt een afterSubmit gebeurtenis afterSubmit . We kunnen deze gebeurtenis bijvoorbeeld gebruiken om e-mailmeldingen van wijzigingen te verzenden of om te synchroniseren met geïntegreerde systemen van derden.

Je kunt ook deze serie video's bekijken die helpen de gebeurtenissen van dit scripttype te visualiseren.

De Geplande en Map / Verminder Scripts

Er zijn twee soorten scripts die we kunnen gebruiken om achtergrondverwerking op een specifiek, regelmatig interval uit te voeren; dit zijn de Geplande en de Map / Verkleinen- scripts. Merk op dat het scripttype Map / Reduce alleen beschikbaar is in SuiteScript 2.0. Het geplande script is beschikbaar voor zowel 1.0 als 2.0.

Het Geplande script heeft slechts één execute gebeurtenis die wordt geactiveerd volgens het schema dat u definieert. U wilt bijvoorbeeld een nachtelijk script uitvoeren dat betalingen op facturen toepast, of een elk uur script dat gegevens synchroniseert met een extern systeem. Wanneer het tijdsinterval toeslaat, vuurt NetSuite deze execute naar uw Geplande script.

Het script Map / Reduce werkt op dezelfde manier, maar zodra het is geactiveerd, wordt de verwerking in vier verschillende fasen onderverdeeld:

1. In de fase getInputData verzamelt u alle invoergegevens die u nodig hebt om het bedrijfsproces te voltooien. U kunt deze fase gebruiken om zoekopdrachten uit te voeren, records te lezen en uw gegevens te verpakken in een ontcijferbare gegevensstructuur.
2. NetSuite geeft de resultaten van uw getInputData fase automatisch door aan de tweede fase, de map genaamd. Deze fase is verantwoordelijk voor het logisch groeperen van uw invoergegevens voor verwerking. Als u bijvoorbeeld betalingen op facturen toepast, wilt u misschien eerst de facturen per klant groeperen.
3. De resultaten van de map fase vervolgens naar het reduce fase, waar de eigenlijke verwerking plaatsvindt. Dit is waar u, in overeenstemming met ons voorbeeld, de betalingen daadwerkelijk op de facturen zou toepassen.
4. Ten slotte wordt een summary ingeroepen die gegevens bevat met betrekking tot de resultaten van al uw verwerking in de voorgaande drie fasen. U kunt dit gebruiken om rapporten te genereren of e-mails te verzenden dat de verwerking is voltooid.

Het grote voordeel van het Map / Reduce-script is dat NetSuite de verwerking automatisch voor u parallel zal laten verlopen over meerdere wachtrijen, indien beschikbaar.

Beide scripttypen hebben een extreem grote governance-limiet, dus u kunt ze ook gebruiken voor bulkverwerking of over het algemeen langlopende achtergrondprocessen.

Het kortste interval dat elk van deze scripttypen kan worden geconfigureerd om te worden uitgevoerd, is elke 15 minuten.

Beide scripttypen kunnen indien nodig ook door gebruikers of door andere scripts worden opgeroepen.

De Suitelet- en Portlet-scripts

Vaak willen we aangepaste UI-pagina's maken in NetSuite; voer het Suitelet in. Het Suitelet-script is ontworpen voor het bouwen van interne, aangepaste UI-pagina's. Pagina's kunnen HTML in vrije vorm zijn, of ze kunnen de UI Builder API's van NetSuite gebruiken om formulieren te bouwen die het uiterlijk van NetSuite volgen.

Wanneer het wordt ingezet, ontvangt een Suitelet zijn eigen unieke URL. De Suitelet heeft dan een enkele render evenement dat wordt aangeroepen wanneer die URL wordt getroffen door een HTTP GET of POST aanvraag. Doorgaans zou het antwoord op het GET verzoek zijn om het formulier zelf weer te geven en vervolgens zou het formulier naar zichzelf POST voor het verwerken van de formuliergegevens.

We kunnen ook Suitelets gebruiken om UI-progressies in tovenaarstijl te bouwen met behulp van de "Assistent" UI-componenten van NetSuite.

Portlets lijken erg op Suitelets, behalve dat ze specifiek worden gebruikt om aangepaste dashboardwidgets te maken in plaats van volledige aangepaste pagina's. Anders dan dat, lijken de twee scripttypen erg op elkaar.

Het RESTlet

Met RESTlets kunnen we op maat gemaakte REST-gebaseerde eindpunten in NetSuite bouwen; RESTlets vormen dus de ruggengraat van vrijwel elke integratie in NetSuite.

RESTlets bieden individuele event-handlers voor vier van de meest gebruikte HTTP-aanvraagmethoden:

• GET
• POST
• PUT
• DELETE

Wanneer een RESTlet een aanvraag ontvangt, zal deze de aanvraag routeren naar de juiste gebeurtenishandlerfunctie op basis van de gebruikte HTTP-aanvraagmethode.

Verificatie voor een RESTlet kan worden gedaan via gebruikerssessie, HTTP-headers of OAuth-tokens.

Het script voor massa-updates

Met behulp van het script Mass Update kunnen we aangepaste massa-updates bouwen die gebruikers kunnen uitvoeren. Dit werkt net als een normale massa-update, waarbij de gebruiker het type massa-update selecteert, een zoekopdracht samenstelt die de te retourneren records retourneert en vervolgens elk zoekresultaat afzonderlijk doorgeeft aan het aangepaste massa-update-script.

Het script biedt één each gebeurtenisafhandelaar de interne id en documenttype van de plaat die moet worden bijgewerkt ontvangt.

Mass Update-scripts moeten handmatig door gebruikers worden geactiveerd via de standaard Mass Update-interface.

Mass Update-scripts hebben een enorm hoge governance-limiet en zijn bedoeld voor veelgebruikte, aangepaste bulkverwerking.

Het workflow-actiescript

Workflows kunnen enigszins beperkt zijn in hun functionaliteit; Werkstromen kunnen bijvoorbeeld niet interageren met regelitems. Het scripttype Workflow-actie is bedoeld om door een workflow te worden aangeroepen om scriptfunctionaliteit toe te voegen om te bereiken wat de workflow zelf niet kan.

Workflowacties hebben één onAction gebeurtenishandler die door de workflow wordt aangeroepen.

Het bundelsysteem

Ten slotte hebben we het scripttype Bundle-installatie, dat verschillende gebeurtenissen biedt waarmee we kunnen communiceren met de installatie, update en verwijdering van een bepaalde bundel. Dit is een zeldzaam scripttype, maar toch belangrijk om te weten.

De bundelinstallatie bevat de volgende gebeurtenishandlers, die redelijk voor zichzelf spreken:

• beforeInstall
• afterInstall
• beforeUpdate
• afterUpdate
• beforeUninstall