netsuite
Skripttyp-Übersicht

Einführung

Das Client-Skript

Das Client-Skript ist eines der am häufigsten verwendeten und komplexen Skripttypen, die Ihnen zur Verfügung stehen. Wie der Name schon sagt, läuft das Client Script im Browser, dh auf der Client-Seite. Es ist der einzige Skripttyp, der auf der Clientseite ausgeführt wird. Alle anderen werden auf der Serverseite von NetSuite ausgeführt.

Das Client-Skript dient hauptsächlich dazu, auf Benutzerinteraktionen mit Datensatzformularen innerhalb der NetSuite-Benutzeroberfläche zu reagieren.

Sobald der Benutzer ein Datensatzformular im Bearbeitungsmodus lädt, wird ein pageInit Ereignis ausgelöst, mit dem Code ausgeführt werden kann, während das Formular initialisiert wird, bevor der Benutzer damit interagieren kann.

Immer wenn der Benutzer ein Feld im Formular ändert, werden eine Reihe von Ereignissen ausgelöst:

1. Ein validateField Ereignis wird ausgelöst, mit dem wir den Wert überprüfen können, den der Benutzer in das Feld eingeben möchte. Wir können dies verwenden, um die Änderung entweder zu akzeptieren oder zu verhindern.
2. Anschließend wird ein fieldChanged Ereignis fieldChanged , mit dem auf den neuen Wert im Feld reagiert werden kann.
3. Schließlich wird ein postSourcing Ereignis postSourcing , nachdem alle abhängigen Felder ebenfalls in ihren Werten postSourcing . Dadurch können wir auf die Änderung reagieren und sicherstellen, dass wir mit allen korrekten Daten arbeiten.

Diese Reihe von Ereignissen wird unabhängig davon ausgelöst, ob der Benutzer ein Textfeld oder ein Unterlistenfeld ändert.

Wenn der Benutzer Änderungen an den Unterlistenzeilen vornimmt, wird eine weitere Reihe von Ereignissen ausgelöst:

1. Ein lineInit Ereignis wird ausgelöst, wenn der Benutzer anfänglich eine neue oder vorhandene Zeile auswählt, bevor er Änderungen an den Feldern in der Zeile vornehmen kann.
2. Jedes Mal , wenn der Benutzer auf die Schaltfläche Hinzufügen klickt , um eine neue Zeile einzufügen, ein validateLine wird Ereignis ausgelöst , das uns , dass die gesamte Zeile gültig zu überprüfen erlaubt und kann zu dem Datensatz hinzugefügt werden.
3. Wenn der Benutzer auf die Schaltfläche Einfügen klickt, um eine neue Zeile über einer vorhandenen hinzuzufügen, wird ein validateInsert -Ereignis ausgelöst, das genau wie das validateLine -Ereignis funktioniert.
4. Immer wenn der Benutzer versucht, eine Zeile zu entfernen, wird eine validateDelete ausgelöst, die das Entfernen der Zeile entweder zulässt oder ablehnt.
5. [Nur SuiteScript 1.0] Wenn das entsprechende Überprüfungsereignis erfolgreich ist, wird die Änderung der Zeile auch zu einer Änderung des Gesamtbetrags einer Transaktion geführt. Dann wird ein recalc Ereignis ausgelöst, das es uns ermöglicht, auf die Änderung des Betrags unserer Transaktion zu reagieren Transaktion.
6. [Nur SuiteScript 2.0] Nach dem erfolgreichen Validierungsereignis wird schließlich ein sublistChanged ausgelöst, damit wir auf die abgeschlossene sublistChanged reagieren können.

Wenn der Benutzer schließlich im Datensatz auf die Schaltfläche Speichern klickt, wird ein saveRecord Ereignis ausgelöst, mit dem saveRecord kann, ob der Datensatz gültig ist und gespeichert werden kann. Wir können das Speichern entweder verhindern oder mit diesem Ereignis fortfahren.

Das Clientskript hat bei weitem die meisten Ereignisse eines beliebigen Skripttyps und die komplexeste Beziehung zwischen diesen Ereignissen.

Das Benutzerereignisskript

In enger Beziehung zum Client-Skript steht das Benutzerereignisskript. Die Ereignisse dieses Skripttyps werden erneut ausgelöst, wenn ein Datensatz geladen oder gespeichert wird. Stattdessen wird er auf der Serverseite ausgeführt. Es kann daher nicht verwendet werden, um sofort auf Feldänderungen zu reagieren, es ist jedoch nicht nur auf Benutzer beschränkt, die mit dem Datensatz in einem Formular interagieren.

Benutzerereignisskripts werden unabhängig davon ausgeführt, woher die Lade- oder Übergabeanforderung stammt, ob es sich um einen Benutzer handelt, der auf der Benutzeroberfläche arbeitet, eine Integration eines Drittanbieters ist oder ein anderes internes Skript, das die Anforderung ausgibt.

Immer wenn ein Prozess oder Benutzer versucht, einen Datensatz aus der Datenbank zu lesen, wird das beforeLoad Ereignis des Benutzerereignisses ausgelöst. Wir können dies verwenden, um Daten vorzuverarbeiten, Standardwerte festzulegen oder das Benutzeroberflächenformular zu bearbeiten, bevor der Benutzer es sieht.

Sobald ein Prozess oder Benutzer versucht, einen Datensatz an die Datenbank zu übermitteln, sei es die Erstellung eines neuen Datensatzes, das Bearbeiten eines vorhandenen Datensatzes oder das Löschen eines Datensatzes, wird die folgende Reihenfolge ausgeführt:

1. Bevor die Anforderung tatsächlich in die Datenbank beforeSubmit , wird ein beforeSubmit Ereignis beforeSubmit . Wir können dieses Ereignis beispielsweise verwenden, um den Datensatz zu bereinigen, bevor er in die Datenbank aufgenommen wird.
2. Die Anforderung wird an die Datenbank gesendet und der Datensatz wird entsprechend erstellt / geändert / gelöscht.
3. Nachdem die Datenbankverarbeitung abgeschlossen ist, wird ein afterSubmit Ereignis afterSubmit . Wir können dieses Ereignis beispielsweise verwenden, um E-Mail-Benachrichtigungen über Änderungen zu versenden oder mit integrierten Drittanbietersystemen zu synchronisieren.

Sie können sich auch diese Videoserie ansehen, um die Ereignisse dieses Skripttyps zu visualisieren.

Die geplanten und Map / Reduction-Skripte

Es gibt zwei Arten von Skripts, mit denen Sie die Hintergrundverarbeitung in einem bestimmten, regelmäßigen Intervall ausführen können. Dies sind die Scheduled- und Map / Reduce- Skripte. Beachten Sie, dass der Skripttyp " Map / Reduce" nur in SuiteScript 2.0 verfügbar ist. Das Scheduled- Skript ist sowohl für 1.0 als auch für 2.0 verfügbar.

Das geplante Skript verfügt nur über ein einzelnes execute , das gemäß dem von Ihnen definierten Zeitplan ausgelöst wird. Beispielsweise möchten Sie ein nächtliches Skript ausführen, das Zahlungen auf Rechnungen anwendet, oder ein stündliches Skript, das Daten mit einem externen System synchronisiert. Wenn das Zeitintervall erreicht ist, löst NetSuite dieses execute in Ihrem Scheduled-Skript aus.

Das Map / Reduce-Skript funktioniert ähnlich, aber sobald es ausgelöst wird, wird die Verarbeitung in vier verschiedene Phasen unterteilt:

1. In der getInputData Phase getInputData Sie alle Eingabedaten, die Sie benötigen, um den Geschäftsprozess abzuschließen. In dieser Phase können Sie Suchen durchführen, Datensätze lesen und Ihre Daten in eine entschlüsselbare Datenstruktur packen.
2. NetSuite übergibt die Ergebnisse Ihrer getInputData Phase automatisch an die zweite Phase namens map . In dieser Phase werden Ihre Eingabedaten für die Verarbeitung logisch gruppiert. Wenn Sie beispielsweise Zahlungen auf Rechnungen anwenden, möchten Sie die Rechnungen zuerst nach Kunden gruppieren.
3. Die Ergebnisse der map werden dann an die reduce , in der die eigentliche Verarbeitung stattfindet. Hier würden Sie, in unserem Beispiel, die Zahlungen tatsächlich auf die Rechnungen anwenden.
4. Zuletzt wird eine summary aufgerufen, die Daten zu den Ergebnissen Ihrer gesamten Verarbeitung in den vorherigen drei Phasen enthält. Sie können dies verwenden, um Berichte zu generieren oder E-Mails zu senden, dass die Verarbeitung abgeschlossen ist.

Der Hauptvorteil des Map / Reduce-Skripts besteht darin, dass NetSuite die Verarbeitung für Sie automatisch über mehrere Warteschlangen parallelisiert, sofern verfügbar.

Beide Skripttypen haben ein extrem großes Governance-Limit, sodass Sie sie auch für die Massenverarbeitung oder generell langwierige Hintergrundprozesse verwenden können.

Das kürzeste Intervall, für das einer dieser Skripttypen konfiguriert werden kann, ist alle 15 Minuten.

Diese beiden Skripttypen können bei Bedarf auch von Benutzern oder anderen Skripts aufgerufen werden.

Die Suitelet- und Portlet-Skripts

Häufig möchten wir benutzerdefinierte UI-Seiten in NetSuite erstellen. Geben Sie das Suitelet ein. Das Suitelet-Skript dient zum Erstellen interner, benutzerdefinierter Benutzeroberflächenseiten. Seiten können HTML-Formulare sein oder sie können die UI Builder-APIs von NetSuite verwenden, um Formulare zu erstellen, die dem Erscheinungsbild von NetSuite entsprechen.

Bei der Bereitstellung erhält ein Suitelet eine eigene eindeutige URL. Die Suitelet hat dann ein einziges render Ereignis , das aufgerufen wird , wenn die URL mit einem HTTP getroffen wird GET oder POST Anfrage. Typischerweise wird die Reaktion auf die GET würde Anforderung sein , die Form selbst zu machen , und dann würde die Form POST zur Verarbeitung der Formdaten auf sich selbst zurück.

Wir können auch Suitelets nutzen, um UI-Progressions im Assistenten-Stil mit den "Assistant" -UI-Komponenten von NetSuite zu erstellen.

Portlets sind Suitelets sehr ähnlich, außer dass sie speziell zum Erstellen von benutzerdefinierten Dashboard-Widgets und nicht von vollständigen benutzerdefinierten Seiten verwendet werden. Ansonsten funktionieren die beiden Skripttypen sehr ähnlich.

Das RESTlet

Mit RESTlets können wir benutzerdefinierte REST-basierte Endpunkte in NetSuite integrieren. RESTlets bilden somit das Rückgrat für nahezu jede Integration in NetSuite.

RESTlets bieten individuelle Ereignishandler für vier der am häufigsten verwendeten HTTP-Anforderungsmethoden:

• GET
• POST
• PUT
• DELETE

Wenn ein RESTlet eine Anforderung empfängt, leitet es die Anforderung basierend auf der verwendeten HTTP-Anforderungsmethode an die entsprechende Ereignisbehandlungsfunktion weiter.

Die Authentifizierung bei einem RESTlet kann über Benutzersitzung, HTTP-Header oder OAuth-Token erfolgen.

Das Massen-Update-Skript

Mit dem Massenaktualisierungsskript können wir benutzerdefinierte Massenaktualisierungen für die Benutzer erstellen. Dies funktioniert wie eine normale Massenaktualisierung, bei der der Benutzer die Art der Massenaktualisierung auswählt, eine Suche erstellt, in der die zu aktualisierenden Datensätze zurückgegeben werden, und jedes Suchergebnis einzeln in das benutzerdefinierte Massenaktualisierungsskript übergeben wird.

Das Skript stellt eine einzelne each Event - Handler, der die interne ID und Datensatztyp des Datensatzes erhält , die aktualisiert werden soll.

Massenaktualisierungsskripts müssen manuell von Benutzern über die standardmäßige Massenaktualisierungsoberfläche ausgelöst werden.

Massenaktualisierungsskripte haben ein enorm hohes Governance-Limit und sind für die üblicherweise verwendete, benutzerdefinierte Massenverarbeitung vorgesehen.

Das Workflow-Aktionsskript

Workflows können in ihrer Funktionalität etwas eingeschränkt sein. Workflows können beispielsweise nicht mit Werbebuchungen interagieren. Der Workflow-Action-Skripttyp soll von einem Workflow aufgerufen werden, um Skriptfunktionen hinzuzufügen, um den Workflow selbst zu erreichen.

Workflow-Aktionen haben einen einzigen onAction Ereignishandler, der vom Workflow aufgerufen wird.

Das Installationsskript für das Bundle

Schließlich gibt es noch den Skripttyp für die Bundle-Installation, der verschiedene Ereignisse bereitstellt, mit denen wir mit der Installation, Aktualisierung und Deinstallation eines bestimmten Bundles interagieren können. Dies ist ein selten anzutreffender Skripttyp, der jedoch dennoch beachtet werden muss.

Die Bundle-Installation enthält die folgenden Ereignishandler, die ziemlich selbsterklärend sein sollten:

• beforeInstall
• afterInstall
• beforeUpdate
• afterUpdate
• beforeUninstall