netsuite
Gebeurtenis gebruiker: voor en na Gebeurtenissen verzenden
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.