Zoeken…


Syntaxis

  • beforeSubmit (type) // Before Submit, 1.0
  • beforeSubmit (scriptContext) // Before Submit, 2.0
  • afterSubmit (type) // After Submit, 1.0
  • afterSubmit (scriptContext) // Na verzenden, 2.0

parameters

Parameter Details
SuiteScript 2.0 -
scriptContext {Object}
scriptContext.newRecord {N/record.Record} Een verwijzing naar het record dat wordt gelezen uit de database. We kunnen het gebruiken om de veldwaarden in het record te wijzigen
scriptContext.oldRecord {N/record.Record} Een alleen-lezen verwijzing naar de vorige status van het record. We kunnen het gebruiken om te vergelijken met de nieuwe waarden
scriptContext.type {UserEventType} Een opsomming van het type schrijfactie dat wordt uitgevoerd
SuiteScript 1.0 -
type {String} Het type schrijfactie dat wordt uitgevoerd

Opmerkingen

beforeSubmit en afterSubmit

Deze twee gebeurtenissen worden geactiveerd door elke database-schrijfbewerking op een record. Telkens wanneer een gebruiker, een script, een CSV-import of een webservice-aanvraag probeert een record naar de database te schrijven, worden de Submit-evenementen ontslagen.

Neem acties op die beide Submit evenementen activeren:

  • creëren
  • Bewerk
  • Delete
  • XEdit (inline bewerken)
  • Goedkeuren
  • afwijzen
  • annuleren
  • pak
  • Schip

Neem acties op die eerder zijn geactiveerd Alleen beforeSubmit :

  • Markeren als voltooid
  • Opnieuw toewijzen (ondersteuningsgevallen)
  • Prognose bewerken

Neem acties op die alleen activeren na afterSubmit :

  • Dropship
  • Speciale bestelling
  • Bestel artikelen
  • Rekeningen betalen

Typische use cases voor beforeSubmit

  • Valideer record voordat het wordt vastgelegd in de database
  • Toestemming en restrictiecontroles
  • Last-minute wijzigingen voor database-commit
  • Updates ophalen van externe systemen

Typische use cases voor afterSubmit

  • E-mailmelding van recordwijzigingen
  • Browseromleiding
  • Maak / update afhankelijke records
  • Wijzigingen doorvoeren in externe systemen

Gebruikersevents ketenen niet

Code geschreven in Gebruikersgebeurtenissen zal geen Gebruikersgebeurtenissen in andere records activeren. Als u bijvoorbeeld het gekoppelde beforeSubmit uit de beforeSubmit van een beforeSubmit de beforeSubmit van het beforeSubmit niet geactiveerd .

NetSuite doet dit om te voorkomen dat gebruikersgebeurtenissen elkaar in een oneindige lus activeren. Als u wel gebruikersevenementen nodig hebt om in een kettingreeks te schieten, moeten andere scripttypen (bijv. RESTlets, Suitelets, Geplande scripts) tussen de gebeurtenissen worden geïnjecteerd.

Event Handlers keren void terug

Het retourtype van de Event-handlers is void . Gegevens die worden geretourneerd door onze gebeurtenishandler hebben geen effect op het systeem. We hoeven niets te retourneren vanuit onze handlerfunctie, omdat we eigenlijk niets kunnen doen met de geretourneerde waarde.

!! VOORZICHTIG !!

Wees zeer voorzichtig bij het vergelijken van waarden tussen oude en nieuwe records. Lege velden uit het oude record worden als null geretourneerd, terwijl lege velden uit het nieuwe record als een lege string worden geretourneerd. Dit betekent dat je niet eenvoudig het oude met het nieuwe kunt vergelijken, anders krijg je valse positieven. Elke logica die u schrijft, moet geschikt zijn voor het geval dat er een null en de juiste een lege string is.

Minimaal: een bericht loggen

// 1.0, Revealing Module pattern
var myNamespace = myNamespace || {};

myNamespace.example = (function () {

    /**
     * User Event 1.0 example detailing usage of the Submit events
     *
     * @appliedtorecord employee
     */
    var exports = {};

    function beforeSubmit(type) {
        nlapiLogExecution("DEBUG", "Before Submit", "action=" + type);
    }

    function afterSubmit(type) {
        nlapiLogExecution("DEBUG", "After Submit", "action=" + type);
    }

    exports.beforeSubmit = beforeSubmit;
    exports.afterSubmit = afterSubmit;
    return exports;
})();

// 2.0
define(["N/log"], function (log) {

    /**
     * User Event 2.0 example showing usage of the Submit events
     *
     * @NApiVersion 2.x
     * @NModuleScope SameAccount
     * @NScriptType UserEventScript
     * @appliedtorecord employee
     */
    var exports = {};

    function beforeSubmit(scriptContext) {
        log.debug({
            "title": "Before Submit",
            "details": "action=" + scriptContext.type
        });
    }

    function afterSubmit(scriptContext) {
        log.debug({
            "title": "After Submit",
            "details": "action=" + scriptContext.type
        });
    }

    exports.beforeSubmit = beforeSubmit;
    exports.afterSubmit = afterSubmit;
    return exports;
});

Before Submit: Valideer record voordat het wordt vastgelegd in de database

Voor dit voorbeeld willen we ervoor zorgen dat voor elke werknemer die is gemarkeerd als een projectresource, ook de juiste arbeidskosten zijn gedefinieerd.

// 1.0, Revealing Module pattern
var myNamespace = myNamespace || {};
myNamespace.example = (function () {

    /**
     * User Event 1.0 example detailing usage of the Submit events
     *
     * @appliedtorecord employee
     */
    var exports = {};

    function beforeSubmit(type) {
        if (!isEmployeeValid(nlapiGetNewRecord())) {
            throw nlapiCreateError("STOIC_ERR_INVALID_DATA", "Employee data is not valid", true);
        }
    }

    function isEmployeeValid(employee) {
        return (!isProjectResource(employee) || hasValidLaborCost(employee));
    }

    function isProjectResource(employee) {
        return (employee.getFieldValue("isjobresource") === "T");
    }

    function hasValidLaborCost(employee) {
        var laborCost = parseFloat(employee.getFieldValue("laborcost"));

        return (Boolean(laborCost) && (laborCost > 0));
    }

    exports.beforeSubmit = beforeSubmit;
    return exports;
})();

// 2.0
define(["N/error"], function (err) {

    var exports = {};

    /**
     * User Event 2.0 example detailing usage of the Submit events
     *
     * @NApiVersion 2.x
     * @NModuleScope SameAccount
     * @NScriptType UserEventScript
     * @appliedtorecord employee
     */
    function beforeSubmit(scriptContext) {
        if (!isEmployeeValid(scriptContext)) {
            throw err.create({
                "name": "STOIC_ERR_INVALID_DATA",
                "message": "Employee data is not valid",
                "notifyOff": true
            });
        }
    }

    function isEmployeeValid(scriptContext) {
        return (!isProjectResource(scriptContext.newRecord) || hasValidLaborCost(scriptContext.newRecord));
    }

    function isProjectResource(employee) {
        return (employee.getValue({"fieldId" : "isjobresource"}));
    }

    function hasValidLaborCost(employee) {
        var laborCost = employee.getValue({"fieldId" : "laborcost"});

        return (Boolean(laborCost) && (laborCost > 0));
    }

    exports.beforeSubmit = beforeSubmit;
    return exports;
});

Merk op dat we verwijzingen naar het nieuwe record in onze validatie opnemen, omdat het ons niet kan schelen wat de waarden waren; we houden ons alleen bezig met de waarden die op het punt staan naar de database te worden geschreven. In 2.0 doen we dat via de scriptContext.newRecord referentie en in 1.0 noemen we de globale functie nlapiGetNewRecord .

Wanneer de ingediende gegevens ongeldig zijn, maken we een fout. In een beforeSubmit geval, met het oog op de veranderingen die voorkomen dat geschreven naar de database, uw functie moet throw een uitzondering. Vaak proberen ontwikkelaars de functie return false te return false , in de verwachting dat dit voldoende is, maar dat is niet voldoende. nlapiCreateError worden gemaakt in 2.0 met behulp van de N/error module en in 1.0 met behulp van de globale nlapiCreateError functie; we verhogen vervolgens een uitzondering met behulp van ons gemaakte foutobject met het trefwoord throw .

Na verzenden: bepalen of een veld is gewijzigd

Nadat het record in de database is opgeslagen, willen we controleren wat er in het record is gewijzigd. We zullen deze inspectie uitvoeren door waarden tussen de oude en nieuwe recordinstanties te vergelijken.

// 1.0, Revealing Module pattern
var myNamespace = myNamespace || {};
myNamespace.example = (function () {

    /**
     * User Event 1.0 example detailing usage of the Submit events
     *
     * @appliedtorecord employee
     */
    var exports = {};

    function afterSubmit(type) {
        notifySupervisor();
    }

    function notifySupervisor() {
        // Old and New record instances are retrieved from global functions
        var employee = nlapiGetNewRecord();
        var prevEmployee = nlapiGetOldRecord();

        // If Employee Status didn't change, there's nothing to do
        if (!didStatusChange(employee, prevEmployee)) {
            return;
        }

        // Otherwise, continue with business logic...
    }

    function didStatusChange(employee, prevEmployee) {
        var status = employee.getFieldValue("employeestatus");
        var prevStatus = prevEmployee.getFieldValue("employeestatus");

        /* !! Caution !!
         * Empty fields from the Old record come back as `null`
         * Empty fields from the New record come back as an empty String
         * This means  you cannot simply compare the old and new
         */
        return ((prevStatus || status) && (status !== prevStatus));
    }

    exports.afterSubmit = afterSubmit;
    return exports;
})();

// 2.0
define(["N/runtime"], function (runtime) {

    /**
     * User Event 2.0 example detailing usage of the Submit events
     *
     * @NApiVersion 2.x
     * @NModuleScope SameAccount
     * @NScriptType UserEventScript
     * @appliedtorecord employee
     */
    var exports = {};

    function afterSubmit(scriptContext) {
        notifySupervisor(scriptContext);
    }

    function notifySupervisor(scriptContext) {
        // Old and New records are simply properties on scriptContext
        var employee = scriptContext.newRecord;
        var prevEmployee = scriptContext.oldRecord;

        // If Employee Status didn't change, there's nothing to do
        if (!didStatusChange(employee, prevEmployee)) {
            return;
        }

        // Otherwise, continue with business logic...
    }

    function didStatusChange(employee, prevEmployee) {
        var status = employee.getValue({"fieldId" : "employeestatus"});
        var prevStatus = prevEmployee.getValue({"fieldId" : "employeestatus"});

        /* !! Caution !!
         * Empty fields from the Old record come back as `null`
         * Empty fields from the New record come back as an empty String
         * This means  you cannot simply compare the old and new
         */
        return ((prevStatus || status) && (status !== prevStatus));
    }

    exports.afterSubmit = afterSubmit;
    return exports;
});

Wees zeer voorzichtig bij het vergelijken van waarden tussen oude en nieuwe records. Lege velden uit het oude record worden als null geretourneerd, terwijl lege velden uit het nieuwe record als een lege string worden geretourneerd. Dit betekent dat je niet eenvoudig het oude met het nieuwe kunt vergelijken, anders krijg je valse positieven. Elke logica die u schrijft, moet geschikt zijn voor het geval dat er een null en de juiste een lege string is.



Modified text is an extract of the original Stack Overflow Documentation
Licentie onder CC BY-SA 3.0
Niet aangesloten bij Stack Overflow