netsuite
Skripttypöversikt

Introduktion

Klientskriptet

Klientskriptet är en av de mest använda och komplexa skriptyperna tillgängliga för dig. Som namnet antyder körs klientskriptet i webbläsaren, det vill säga på klientsidan. Det är den enda skriptyp som körs på klientsidan; alla andra kommer att köras på serversidan av NetSuite.

Den primära användningen av klientskriptet är för att svara på användarinteraktioner med postformulär inom NetSuite UI.

Så snart användaren laddar ett inspelningsformulär i redigeringsläge pageInit en pageInit händelse som vi kan använda för att köra kod när formen initialiseras, innan användaren kan interagera med den.

När användaren sedan ändrar valfritt fält på formen kommer en serie händelser att avfyras:

1. En validateField händelse avfyras som gör att vi kan validera värdet som användaren försöker ange i fältet. Vi kan använda detta för att antingen acceptera eller förhindra att ändringen sker.
2. En fieldChanged händelse avfyras sedan som gör att vi kan svara på det nya värdet i fältet.
3. Slutligen postSourcing en postSourcing händelse efter att alla beroende fält också har fått sina värden. Detta gör att vi kan svara på förändringen och se till att vi arbetar med alla korrekta uppgifter.

Denna serie av händelser avfyras oavsett om användaren byter ett kroppsfält eller ett sublistfält.

Eftersom användaren gör ändringar i sublistrader, kommer en ny serie av händelser att utlösas:

1. En lineInit händelse avfyras när användaren ursprungligen väljer en ny eller befintlig linje innan de kan göra några ändringar i fälten på linjen.
2. När användaren klickar på knappen Lägg till för att lägga till en ny rad avfyras en validateLine händelse som gör att vi kan verifiera att hela linjen är giltig och kan läggas till posten.
3. När användaren klickar på knappen Infoga för att lägga till en ny rad ovanför en befintlig, avfyras en validateInsert händelse, som fungerar precis som validateLine händelsen.
4. På samma sätt, när användaren försöker ta bort en rad, avfyras en validateDelete som gör det möjligt att antingen tillåta eller förneka borttagningen av linjen.
5. [Endast [SuiteScript 1.0] Slutligen, efter att lämplig valideringshändelse har lyckats, om ändringen av linjen också åstadkom en förändring av det totala beloppet för en transaktion, recalc en recalc händelse som gör att vi kan svara på förändringen i belopp för transaktion.
6. [Endast SuiteScript 2.0] Slutligen, efter att lämplig valideringshändelse har lyckats, sublistChanged en sublistChanged händelse så att vi kan svara på den färdiga radändringen.

Slutligen, när användaren klickar på Save- knappen på posten, saveRecord en saveRecord händelse som gör att vi kan validera om posten är giltig och kan sparas. Vi kan antingen förhindra att sparandet inträffar eller låta det fortsätta med den här händelsen.

Klientskriptet har överlägset flest händelser av någon skriptyp och det mest komplexa förhållandet mellan dessa händelser.

Användarhändelseskriptet

Nära besläktat med klientskriptet är användarhändelseskriptet. Händelserna av denna skriptyp avfyras igen när en post laddas eller sparas, men den körs istället på serversidan. Som sådan kan det inte användas för att reagera omedelbart på fältförändringar, men det är inte heller begränsat till endast användare som interagerar med posten på ett formulär.

Användarhändelseskript kommer att köras oavsett var lasten eller skicka begäran kommer från, vare sig det är en användare som arbetar i UI, en tredjepartsintegration eller ett annat internt skript som gör begäran.

Varje gång en process eller användare försöker läsa en post ur databasen, beforeLoad händelse. Vi kan använda detta för att förbereda data, ställa in standardvärden eller manipulera UI-formuläret innan användaren ser det.

När en process eller användare försöker skicka en post till databasen, vare sig det är skapandet av en ny post, redigering av en befintlig post eller radering av en post, sker följande sekvens:

1. Först, innan begäran faktiskt tar sig till databasen, beforeSubmit händelse beforeSubmit . Vi kan till exempel använda denna händelse för att rensa upp posten innan den kommer i databasen.
2. Begäran skickas till databasen och posten skapas / modifieras / raderas i enlighet därmed.
3. När databasbehandlingen är klar afterSubmit händelse efter afterSubmit . Vi kan till exempel använda den här händelsen för att skicka e-postmeddelanden om ändringar eller för att synkronisera med integrerade tredjepartssystem.

Du kan också titta på den här serien av videor som hjälper till att visualisera händelserna i denna skriptyp.

De schemalagda och kartlägga / minska skript

Det finns två typer av skript som vi kan utnyttja för att köra bakgrundsbearbetning på ett specifikt, regelbundet intervall; det här är schemalagda och Map / Reduce- skript. Observera att skriptypen Map / Reduce är endast tillgänglig i SuiteScript 2.0. Det schemalagda skriptet är tillgängligt för både 1.0 och 2.0.

Det schemalagda skriptet har bara en enda execute som aktiveras på vilket schema du definierar. Till exempel kanske du vill köra ett nattligt skript som tillämpar betalningar på fakturor eller ett timskript som synkroniserar data med ett externt system. När tidsintervallet träffar avfyrar NetSuite denna execute ditt schemalagda skript.

Map / Reduce-skriptet fungerar på samma sätt, men när det har utlösts bryter det behandlingen i fyra distinkta faser:

1. getInputData fasen är där du samlar in alla inmatningsdata som du behöver för att slutföra affärsprocessen. Du kan använda den här fasen för att utföra sökningar, läsa poster och paketera dina data i en avskiljbar datastruktur.
2. NetSuite överför automatiskt resultaten från din getInputData fas till den andra fasen, kallad map . Denna fas ansvarar för att gruppera dina inmatningsdata logiskt för bearbetning. Om du till exempel tillämpar betalningar på fakturor kan du först gruppera fakturorna efter kund.
3. Resultaten av map fasen skickas sedan till den reduce fasen, som är där den faktiska bearbetningen äger rum. Det är här du, med vårt exempel, faktiskt tillämpar betalningarna på fakturorna.
4. Slutligen åberopas en summary som innehåller data om resultaten av all din behandling i de tre föregående faserna. Du kan använda detta för att generera rapporter eller skicka e-postmeddelanden om att behandlingen är klar.

Den största fördelen med Map / Reduce-skriptet är att NetSuite automatiskt kommer att parallellisera behandlingen för dig över flera köer, om de är tillgängliga.

Båda dessa skripttyper har en extremt stor styrningsgräns, så du kan också använda dem för bulkbearbetning eller i allmänhet långvariga bakgrundsprocesser.

Det kortaste intervallet som någon av dessa skripttyper kan konfigureras för att köras är var 15: e minut.

Båda dessa skripttyper kan också åberopas på begäran av användare eller av andra skript om det behövs.

Suitelet- och portlet-skript

Ofta vill vi bygga anpassade UI-sidor i NetSuite; ange Suitelet. Suitelet-skriptet är utformat för att bygga interna, anpassade UI-sidor. Sidor kan vara HTML-format med fritt format, eller de kan använda NetSuites UI Builder API: er för att konstruera former som följer NetSuites utseende.

När den distribueras får en Suitelet sin egen unika URL. Suitelet har sedan en enstaka render som kallas när denna URL träffas med en HTTP GET eller POST begäran. Normalt skulle svaret på GET begäran vara att återge formuläret själv, och sedan skulle formuläret POST tillbaka till sig själv för att bearbeta formulärdata.

Vi kan också utnyttja Suitelets för att bygga UI-framsteg i guiden-stil med hjälp av NetSuites "Assistant" UI-komponenter.

Portlets liknar extremt Suitelets, förutom att de specifikt används för att bygga anpassade instrumentpaneler i stället för fullständiga anpassade sidor. Utöver det fungerar de två skripttyperna mycket lika.

RESTlet

RESTlets tillåter oss att bygga anpassade REST-baserade slutpunkter i NetSuite; alltså bildar RESTlets ryggraden i nästan all integration i NetSuite.

RESTlets tillhandahåller enskilda evenemangshanterare för fyra av de mest använda HTTP-förfrågningsmetoderna:

• GET
• POST
• PUT
• DELETE

När en RESTlet tar emot en begäran, kommer den att dirigera begäran till lämplig händelsehanteringsfunktion baserad på den HTTP-begärningsmetod som används.

Autentisering till en RESTlet kan göras via användarsession, HTTP-rubriker eller OAuth-symboler.

Massuppdateringsskriptet

Med hjälp av Mass Update-skriptet kan vi bygga anpassade massuppdateringar för användare att utföra. Detta fungerar precis som en normal massuppdatering, där användaren väljer typen av massuppdatering, bygger en sökning som returnerar posterna för att uppdateras och sedan skickas varje sökresultat individuellt till det anpassade Mass Update-skriptet.

Skriptet ger en enda each händelseshanterare som får det interna ID och posttyp för posten som ska uppdateras.

Massuppdateringsskript måste utlösas manuellt av användare via det vanliga Mass Update-gränssnittet.

Massuppdateringsskript har en massivt hög styrningsgräns och är avsedda för vanligt anpassad bulkbehandling.

Workflow-handlingsskriptet

Arbetsflöden kan vara något begränsade i sin funktionalitet; arbetsflöden kan till exempel inte interagera med rader. Skripttypen Workflow Action är avsedd att åberopas av ett Workflow för att lägga till skriptfunktioner för att utföra vad själva arbetsflödet inte kan.

Workflow-åtgärder har en enda onAction händelseshanterare som kommer att åberopas av Workflow.

Bundle Installation Script

Slutligen har vi skriptypen Bundle Installation, som tillhandahåller flera händelser som gör att vi kan interagera med installationen, uppdateringen och avinstallationen av ett visst paket. Detta är en skriptyp som sällan uppträder, men viktigt att vara medveten om det.

Paketinstallationen inkluderar följande evenemangshanterare, som borde vara ganska självförklarande:

• beforeInstall
• afterInstall
• beforeUpdate
• afterUpdate
• beforeUninstall