Klassische Business-Regeln
Eine Business Rule ist ein serverseitiges Skript, das ausgeführt wird, wenn ein Datensatz angezeigt, eingefügt, aktualisiert oder gelöscht wird oder eine Tabelle abgefragt wird.
Wie Business Rules funktionieren
Zur Konfiguration einer Business Rule müssen Sie zunächst festlegen, wann die Business Rule ausgeführt werden soll und welche Aktion ausgeführt werden soll.
Wann Business Rules ausgeführt werden
- Wann die Business-Regel in Bezug auf einen Datenbankvorgang ausgeführt werden soll.
- Für welchen Datensatzvorgang die Business-Regel gilt.
| Option | Wann die Regel ausgeführt wird |
|---|---|
| Vor | Nachdem der Benutzer das Formular abgeschickt hat, aber bevor eine Aktion auf dem Datensatz in der Datenbank durchgeführt wird. |
| Nach | Nachdem der Benutzer das Formular übermittelt und eine Aktion für den Datensatz in der Datenbank ausgeführt wurde. |
| Asynchron | Nachdem der Anwender das Formular übermittelt hat und der Zeitplaner die geplante Aufgabe ausgeführt hat, die aus der Business-Regel erstellt wurde. Das System erstellt eine geplante Aufgabe aus der Business-Regel, nachdem der Anwender das Formular übermittelt hat, aber bevor eine Aktion für den Datensatz in der Datenbank ausgeführt wird. Hinweis: Neu erstellte Business-Regeln werden während Upgrades ausgeführt. Wenn ein Datensatz über eine asynchrone Business-Regel verfügt, die Entscheidungen basierend auf den Daten im Datensatz trifft, können mehrere Aktualisierungen des Datensatzes in schneller Folge dazu führen, dass die Business-Regel falsch oder falsch ausgeführt wird. Wenn mehrere asynchrone Business-Regeln denselben Datensatz aktualisieren, können die von einem Skript durchgeführten Updates von einem anderen Skript überschrieben oder in einer unerwarteten Reihenfolge vorgenommen werden, da die Ausführungsreihenfolge nicht garantiert ist. Sie können die Option nach für Business-Regeln oder verwenden System EventsAls Alternative in diesen Situationen. |
| Bildschirm | Bevor das Formular dem Benutzer angezeigt wird, unmittelbar nachdem die Daten aus der Datenbank gelesen wurden. |
- Asynchrone Business Rules haben keinen Zugriff auf die vorherige Version eines Datensatzes. Daher funktionieren die Methoden changes(), changesTo() und changesFrom() GlideElement mit dem asynchronen Regelskript nicht. Der Condition Builder und das Bedingungsfeld (erweiterte Ansicht) unterstützen jedoch die Methoden changes(), changesTo() und changesFrom().
- Business-Regeln berücksichtigen ACLs erst, wenn Sie möchten, dass sie berücksichtigt werden. Weitere Informationen finden Sie unter Beziehung zwischen Geschäftsregeln und Zugriffssteuerungsregeln (ACLs)
| Option | Wann die Regel ausgeführt wird |
|---|---|
| Einfügen | Wenn der Benutzer einen neuen Datensatz erstellt und das System ihn in die Datenbank einfügt. |
| Aktualisieren | Wenn der Benutzer einen vorhandenen Datensatz ändert. |
| Abfrage | Wenn der Anwender eine Abfrage für einen Datensatz oder eine Liste von Datensätzen an die Datenbank sendet. Normalerweise sollten Sie den Abfragevorgang für vor Business-Regeln verwenden. |
| Löschen | Wenn der Benutzer einen Datensatz löscht. |
Business Rule-Aktionen
- Ändern von Feldwerten in einem Formular, das der Benutzer aktualisiert. Als Feldwerte können festgelegt werden: spezifische für das jeweilige Feld verfügbare Werte, aus anderen Feldern kopierte Werte und relative Werte, die sich nach der Benutzerrolle richten.
- Anzeigen von Informationsmeldungen für den Benutzer
- Ändern von Werten untergeordneter Aufgaben basierend auf Änderungen in übergeordneten Aufgaben
- Verhindern, dass Benutzer auf bestimmte Formularfelder zugreifen oder sie ändern
- Abbrechen der aktuell ausgeführten Datenbanktransaktion. Beispielsweise kann bei Zutreffen bestimmter Bedingungen verhindert werden, dass der Benutzer den Datensatz in der Datenbank speichert.
Rekursive Business Rules vermeiden
Vermeiden Sie es, current.update() in Business Rule-Skripts zu verwenden. Die Aktualisieren () Die Methode löst die Ausführung von Business-Regeln in derselben Tabelle für Einfüge- und Aktualisierungsvorgänge aus, was dazu führt, dass sich eine Business-Regel immer wieder aufruft. Änderungen in Business Rules des Typs „Vor“ werden automatisch gespeichert, sobald alle Business Rules des Typs „Vor“ abgeschlossen wurden. Business Rules des Typs „Nach“ eignen sich am besten zur Aktualisierung von zugehörigen Objekten, nicht von aktuellen Objekten. Wenn eine rekursive Business Rule erkannt wird, stoppt das System die Rule und protokolliert den Fehler im Systemprotokoll. Allerdings verursacht current.update() Probleme mit der Leistung des Systems und ist niemals erforderlich.
Sie können rekursive Business Rules vermeiden, indem Sie die Methode setWorkflow() mit dem Parameter „false“ verwenden. Die Kombination von Aktualisieren () Und SetWorkflow() Methoden werden nur in besonderen Fällen empfohlen, in denen die oben genannten normalen Richtlinien für vor und nach Ihren Anforderungen nicht entsprechen.
Business Rules in bereichsbezogenen Anwendungen
Jede Business Rule ist entweder einem privaten Anwendungsbereich oder dem globalen Bereich zugewiesen.
Business Rules für bestimmte Tabellen
Die meisten Business Rules werden auf eine bestimmte Tabelle angewendet, die im Feld Tabelle definiert ist. Sie können Business Rules für Tabellen im selben Bereich erstellen oder für Tabellen, die Konfigurationsdatensätze aus einem anderen Anwendungsbereich zulassen.
Auf Tabellen in einem anderen Bereich als dem des Business Rule-Datensatzes können nur bestimmte Typen von Rules angewendet werden.
- Sie können eine Regel erstellen, die bei Wenn asynchron eine der folgenden Optionen anstößt:
- Datenbankvorgänge Einfügen, Aktualisieren und Löschen. Abfragen lässt sich nicht auswählen.
- Feldwerte festlegen – Aktionen und Skripts (Feld Skript).
- Sie können eine Regel erstellen, in der „Wenn vor“ eine der folgenden Regeln anstößt:
- Datenbankvorgänge Einfügen, Aktualisieren und Löschen. Abfragen lässt sich nicht auswählen.
- Feldwerte festlegen – nur Aktionen Sie können keine Skripts schreiben und die Datenbanktransaktion nicht abbrechen.
- Sie können keine anderen Typen von Business Rules für Tabellen erstellen, die sich in einem anderen Bereich befinden.
Auf Business Rules für bestimmte Tabellen kann nicht von anderen Business Rules oder Skripts zugegriffen werden.
Globale Business Rules
Globale Business Rules sind Business Rules, bei denen das Feld Tabelle auf Global gesetzt ist. Globale Business Rules können je nach Bereichschutz in mehreren Tabellen und in anderen Skripts verfügbar sein. Den Bereichschutz globaler Business Rules definieren Sie im Feld Zugänglich von:
- Nur dieser Anwendungsbereich: Verhindert, dass Anwendungen in einem anderen Bereich als dem der Business Rule die Business Rule aufrufen.
- Alle Anwendungsbereiche: Erlaubt jeder Anwendung, die Business Rule aufzurufen.Hinweis:Globale Business Rules unterstützen keine Domänentrennung.
Skripts in Business Rules mit Bereich
Wenn Sie ein Skript in einer Business Rule schreiben, können Sie auf Folgendes zugreifen:
- Alle Skripteinbindungen und globalen Business Rules im Bereich der Business Rule
- Skripteinbindungen und globale Business Rules, die von Anwendungen in einem anderen Bereich aufgerufen werden dürfen (Zum Aufrufen von Funktionen aus einem anderen Bereich müssen Sie den Bereich der jeweiligen Funktion angeben.)
- Im Falle von Business Rules in einem eindeutigen Bereich können Sie ausschließlich auf die System-APIs in diesem Bereich zugreifen.
Business Rules erstellen
Sie können jeden Typ von Business Rule erstellen und die Rule ausführen lassen, wenn ein Datensatz angezeigt, eingefügt, aktualisiert oder gelöscht wird oder wenn eine Tabelle abgefragt wird.
Warum und wann dieser Vorgang ausgeführt wird
Prozedur
Globale Variablen in Business Rules
Es stehen vordefinierte globale Variablen zur Verfügung, die in Business Rules verwendet werden können.
Verwenden Sie die folgenden vordefinierten globalen Variablen, um in einem Business Rule-Skript auf das System zu verweisen.
| Globale Variable | Beschreibung |
|---|---|
| current | Aktueller Status des referenzierten Datensatzes. Unter „Null-Zeigerausnahmen verhindern“ unten finden Sie Informationen zum Überprüfen auf Nullen, bevor Sie diese Variable verwenden. |
| previous | Status des referenzierten Datensatzes vor Aktualisierungen, die während des Ausführungskontexts vorgenommen wurden, wobei der Ausführungskontext mit dem ersten Update- oder Löschvorgang beginnt und endet, nachdem das Skript und alle referenzierten Business-Regeln ausgeführt wurden. Wenn der Datensatz innerhalb eines Ausführungskontexts mehrfach aktualisiert wird, bleibt für previous der Status des Datensatzes vor dem ersten Aktualisierungs- oder Löschvorgang gesetzt. Die Variable ist nur für Aktualisierungs- und Löschvorgänge verfügbar. Nicht verfügbar für asynchrone Vorgänge. Unter „Null-Zeigerausnahmen verhindern“ unten finden Sie Informationen zum Überprüfen auf Nullen, bevor Sie diese Variable verwenden. |
| g_scratchpad | Das Scratchpad-Objekt ist in Anzeigeregeln verfügbar und wird verwendet, um Informationen an den Client zu übergeben, auf den über Client-Skripts zugegriffen werden kann. |
| gs | Verweise auf GlideSystem Funktionen. |
Die Variablen current, previous und g_scratchpad sind global für alle Business Rules verfügbar, die auf eine Transaktion angewendet werden.
Durch „null“-Zeiger verursachte Ausnahmen vermeiden
if (current == null) // to prevent null pointer exceptions.
return; Variablen definieren
Benutzerdefinierte Variablen haben standardmäßig einen globalen Bereich. Wenn eine neue Variable in einer Business Rule für Auftrag 100 deklariert wird, hat auch die Business Rule Zugriff auf die Variable, die bei Auftrag 200 ausgeführt wird. Dies kann zu unerwartetem Verhalten führen.
Um unerwartetes Verhalten zu verhindern, sollten Sie Ihren Code immer in eine Funktion einschließen. Dies schützt Ihre Variablen vor Konflikten mit Systemvariablen oder globalen Variablen in anderen Business Rules, die nicht in eine Funktion eingeschlossen sind. Zusätzlich müssen Variablen wie current beim Aufrufen einer Funktion verfügbar sein, damit sie verwendet werden können.
var now_GR = new GlideRecord('incident');
now_GR.query();
while(now_GR.next()) {
//do something
}myFunction();
function myFunction() {
var now_GR = new GlideRecord('incident');
now_GR.query();
while(now_GR.next()) {
//do something
} }Feldwerte mit Business Rules und Client-Skripts steuern
Wenn Sie sowohl Business Rules als auch Client-Skripts für ein Feld implementieren, können Benutzer Datensatzwerte mithilfe von Formularen und Listen festlegen und sehen während der Bearbeitung von Formularen sofort alle Änderungen, die an den Werten vorgenommen werden.
Das Problem, wenn Aktualisierungen eines Feldes ausschließlich per Client-Skript oder ausschließlich per Business Rule gesteuert werden: Das zu ändernde Feld kann sich in einem Formular oder in einer Liste befinden. Client-Skripts und UI-Richtlinien werden ausschließlich auf Formulare angewendet (also clientseitig ausgeführt) und greifen nicht bei der Bearbeitung von Listen. Wenn Sie die Bearbeitung von Listen zulassen und gleichzeitig Client-Skripts auf Felder in einem Formular anwenden, kann es passieren, dass falsche Daten im Datensatz gespeichert werden. Werden in Ihrem System Client-Skripts oder UI-Richtlinien auf Formulare angewendet, müssen Sie entweder die Listenbearbeitung deaktivieren oder Business Rules bzw. Zugriffssteuerungen erstellen, die steuern, wie Werte im Listeneditor festgelegt werden. Ein Nebeneffekt dieser Herangehensweise ist, dass in Client-Skripts implementierte Sicherheitsmaßnahmen leicht umgangen werden können. Der Benutzer muss das betreffende Feld lediglich in einer Liste bearbeiten.
Business Rules für Formulare sind nicht dynamisch. Der Benutzer muss den Datensatz aktualisieren, damit Änderungen angezeigt werden. Daher sind Client-Skripts die bevorzugte Methode zur Steuerung von Feldwerten in Formularen.
Wenn Sie zur Steuerung von Feldwerten sowohl eine Business Rule als auch ein Client-Skript verwenden, ist das Aktualisierungsverhalten systemweit gleich. Das bedeutet: Aktualisierte Werte unterscheiden sich nicht, unabhängig davon, ob die Änderung in einer Liste oder einem Formular vorgenommen wurde. Es bedeutet aber auch, dass die gleiche Funktionalität zweimal implementiert werden muss: einmal in einem Client-Skript und einmal in einer Business Rule oder einer Zugriffssteuerung.
Beispiel: Mit Business Rules während des Imports von Benutzerdatensätzen E-Mail-Adressen erstellen
Eine Organisation nutzt ein Client-Skript, das als E-Mail-Adresse von Benutzern vorname.nachname@unternehmen.com festlegt. Administratoren tun dies, damit sie die E-Mail-Adresse sofort sehen können, wenn sie die Informationen des Anwenders eingeben. Nun führt der Administrator einen Massenimport von Benutzern aus einer Tabelle mit den Vor- und Nachnamen der Benutzer durch. Es wird erwartet, dass die E-Mail-Adresse jedes Anwenders automatisch festgelegt wird, wenn er das Formular bearbeitet. Da das Client-Skript nur auf das Formular (also die Schnittstelle zum Datensatz) angewandt wird, hat es keine Auswirkungen auf Daten, die von außerhalb dieser Schnittstelle in den Datensatz importiert werden. Es werden keine E-Mail-Adressen erstellt. Um dieses Problem zu lösen, implementiert der Administrator eine Business Rule, die beim Import ausgeführt wird und die E-Mail-Adressen erstellt.
Beispiel: Listenbearbeitung für im Formular nicht bearbeitbare Felder verhindern
Eine Organisation möchte in einem Incident-Formular das Feld Priorität verbergen, wenn die Zuweisungsgruppe Entwicklung ist. Sie erstellt eine entsprechende UI-Richtlinie für das Incident-Formular, die Benutzer können das Feld Priorität jedoch immer noch im Listeneditor sehen und bearbeiten. Zur Behebung dieses Problems muss die Organisation eine Zugriffssteuerung anwenden, die Lesezugriffe auf das Feld Priorität unterbindet, wenn die Zuweisungsgruppe Entwicklung ist.
„NULL“ als Feldwert verwenden
Die Zeichenfolge „NULL“ spielt eine spezifische Rolle in Skripts und ist ein reserviertes Wort.
Das reservierte Wort lautet „NULL“, geschrieben in Großbuchstaben. Ein Feld mit dem Wert Null oder null ist also beispielsweise zulässig. Verwenden Sie „NULL“ nur, um den Wert bestimmter Felder zu löschen.
Alle Null-Feldwerte, die aus einer Importsatz-Datenquelle abgerufen werden, werden als leere Feldwerte in die Bereitstellungstabelle eingefügt. Sie sollten den Begriff „NULL“ nicht als Feldwert in Transform Maps für Import-Sets oder in Feldern des Typs Vorname oder Nachname an anderer Stelle verwenden. Ebenso sollten Sie „NULL“ nicht in Referenzfeldern verwenden, da das System den Wert dann als Zeichenfolge mit dem Wort „NULL“ statt als reserviertes Wort interpretiert.
Business Rules des Typs „Anzeigen“
Rules des Typs „Anzeigen“ werden verarbeitet, wenn ein Benutzer ein Datensatzformular anfordert.
Die Daten werden aus der Datenbank gelesen, die Rules des Typs „Anzeigen“ werden ausgeführt, und das Formular wird dem Benutzer angezeigt. Das Objekt „current“ ist verfügbar und stellt den aus der Datenbank abgerufenen Datensatz dar. Alle Feldänderungen sind temporär, da sie noch nicht an die Datenbank übermittelt wurden. Für den Client scheinen die Formularwerte die Werte aus der Datenbank zu sein. Es gibt keinen Hinweis darauf, dass die Werte von einer Regel des Typs „Anzeigen“ geändert wurden. Dieses Konzept ähnelt dem Konzept der berechneten Felder.
Der Hauptzweck von Rules des Typs „Anzeigen“ ist die Verwendung eines gemeinsam genutzten Scratchpad-Objekts g_scratchpad, das auch als Teil des Formulars an den Client gesendet wird. Dies kann nützlich sein bei der Erstellung von Client-Skripts, die Serverdaten benötigen, die normalerweise nicht Teil des angezeigten Datensatzes sind. In den meisten Fällen wäre hierzu ein Client-Skript erforderlich, das einen Rückruf an den Server sendet. Wenn die Daten vor der Anzeige des Formulars ermittelt werden können, ist es effizienter, dem Client die Daten bereits beim ersten Laden bereitzustellen. Das Scratchpad-Objekt für Formulare ist standardmäßig ein leeres Objekt und wird nur zum Speichern von Name-Wert-Datenpaaren verwendet.
// From display business rule
g_scratchpad.someName = "someValue";
g_scratchpad.anotherName = "anotherValue";
// If you want the client to have access to record fields not being displayed on the form
g_scratchpad.created_by = current.sys_created_by;
// These are simple examples, in most cases you will probably perform some other
// queries to test or get data// From client script
if(g_scratchpad.someName == "someValue") {
//do something special
}Business Rule „Task Active State Management“
Diese Business Rule entscheidet basierend auf Änderungen im Feld Status, ob der Wert des Felds „Aktiv“ geändert werden muss.
Die Business Rule „Task Active State Management“ wird ausgeführt, wenn das Feld Status eines Aufgabendatensatzes geändert wird. Ihre Ausführungsnummer ist 50, und sie wird vor den meisten anderen Business Rules für Aufgaben ausgeführt.
- Wird der Status von „Aktiv“ in „Inaktiv“ geändert, wird das Feld Aktiv auf „false“ gesetzt.
- Wird der Status von „Inaktiv“ in „Aktiv“ geändert, wird das Feld Aktiv auf „true“ gesetzt. Dadurch wird die Aufgabe erneut aktiviert bzw. erneut geöffnet.
Es wird empfohlen, die zu nutzen (current.active.changesTo([true/false])Aktion in Ihrer Business-Regel im Gegensatz zum Erstellen von Regeln für jede Aufgabentabelle, die Aufgaben als inaktiv oder aktiv markieren.
Beispiele für Business Rule-Skripts
Hier finden Sie Beispiele für Business Rule-Skripts, mit denen Sie Anforderungen Ihrer Organisation erfüllen können.
Datumsfelder in Business Rules vergleichen
Es ist möglich, zwei Datumsfelder oder zwei Datum/Uhrzeit-Felder in einer Business Rule zu vergleichen und eine Datensatzeinfügung abzubrechen oder die Felder zu aktualisieren, wenn sie nicht korrekt sind.
Nehmen wir an, Sie möchten, dass ein Startdatum vor einem Enddatum liegt. Nachfolgend sehen Sie ein Beispielskript:
if ((!current.u_date1.nil()) && (!current.u_date2.nil())) {
var start = current.u_date1.getGlideObject().getNumericValue();
var end = current.u_date2.getGlideObject().getNumericValue();
if (start > end) {
gs.addInfoMessage('start must be before end');
current.u_date1.setError('start must be before end') ;
current.setAbortAction(true);
} }Dieses Beispiel wurde in globalen Skripts getestet und muss vielleicht geändert werden, damit es in Skripts mit Bereich funktioniert. Neben möglicherweise erforderlichen API-Änderungen sind die Sicherheitsanforderungen in Skripts mit Bereich strenger.
- u_date1 und u_date2 sind die Namen der beiden Datumsfelder. Ersetzen Sie diese Namen durch eigene Feldnamen.
- Die erste Zeile prüft, ob beide Felder tatsächlich einen Wert haben.
- Die nächsten beiden Zeilen erstellen Variablen mit den numerischen Werten der Datumsangaben.
- Die nächsten beiden Zeilen erstellen unterschiedliche Warnmeldungen für den Endbenutzer: eine oben im Formular und eine am Feld u_date1 des Formulars.
- Die letzte Zeile bricht das Einfügen oder Aktualisieren ab, wenn die Datumsfelder nicht korrekt sind.
// Enter all start and end date fields you wish to check, as well as the previous values
// Make sure that you keep the placement in the sequence the same for all pairs
var startDate = new Array(current.start_date,current.work_start);
var prevStartDate = new Array(previous.start_date,previous.work_start);
var endDate = new Array(current.end_date,current.work_end);
var prevEndDate = new Array(previous.end_date,previous.work_end);
// The text string below is added to the front of ' start must be before end'
var userAlert = new Array('Planned','Work');
// Set the number of Previous Days you want to check
var pd = 30;
// Set the number of Future Days you want to check
var fd = 365;
// You shouldn't have to modify anything below this line
var nowdt = new GlideDateTime();
nowdt.setDisplayValue(gs.nowDateTime());
var nowMs = nowdt.getNumericValue();
var pdms = nowMs;
// Subtract the product of previous days to get value in milliseconds
pdms -= pd * 24 * 60 * 60 * 1000;
var fdms = nowMs;
// Add the product of future days to get value in miliseconds
fdms += fd * 24 * 60 * 60 * 1000;
var badDate = false;
// Iterate through all start and end date / time fields
for (x = 0; x < startDate.length; x ++) {
if ((!startDate[x].nil()) && (!endDate[x].nil())) {
var start = startDate[x].getGlideObject().getNumericValue();
var end = endDate[x].getGlideObject().getNumericValue();
if (start > end) {
gs.addInfoMessage(userAlert[x] + ' start must be before end');
startDate[x].setError(userAlert[x] + ' start must be before end');
badDate = true; }
else if ((prevStartDate[x]) != (startDate[x])) {
if (start < pdms) {
gs.addInfoMessage(userAlert[x] + ' start must be fewer than ' + pd + ' days ago');
startDate[x].setError(userAlert[x] + ' start must be fewer than ' + pd + ' days ago');
badDate = true; } }
else if ((prevEndDate[x]) != (endDate[x])) {
if (end > fdms) {
gs.addInfoMessage(userAlert[x] + ' end must be fewer than ' + fd + ' days ahead');
endDate[x].setError(userAlert[x] + ' end must be fewer than ' + fd + ' days ahead');
badDate = true ;
} } } }
if (badDate == true ) {
current. setAbortAction ( true ) ; }XML-Payloads analysieren
Felder im XML-Format können mit der Systemfunktion getXMLText analysiert werden.
ecc_event), können mit der Systemfunktion getXMLText analysiert werden. Die Funktion getXMLText erfordert eine Zeichenfolge und einen XPATH-Ausdruck. Beispiel:var name = gs.getXMLText("<name>joe</name>", "//name");Diese Funktion gibt die Zeichenfolge „joe“ zurück.
var name = gs.getXMLText(current.payload, "//name");Informationen zu XPATH finden Sie unter w3schools.
Datenbankaktionen in Business Rules des Typs „Vor“ abbrechen
In einem Business Rule-Skript des Typs „Vor“ können Sie die aktuelle Datenbankaktion abbrechen, indem Sie die Methode setAbortAction() verwenden.
Wenn beispielsweise die Business Rule vom Typ „Vor“ während einer Einfügeaktion ausgeführt wird und das Skript eine Bedingung enthält, die current.setAbortAction(true) aufruft, wird der in „current“ gespeicherte neue Datensatz nicht in der Datenbank erstellt. Die Business Rule läuft nach dem Aufruf von setAbortAction() weiter und alle darauffolgenden Business Rules werden normal ausgeführt. Das Aufrufen dieser Methode verhindert nur, dass die Datenbankaktion für das aktuelle Objekt ausgeführt wird.
Sie können die Methode isActionAborted() verwenden, um zu bestimmen, ob die aktuelle Datenbankaktion (einfügen, aktualisieren, löschen) abgebrochen wird. isActionAborted() wird für neue Threads initialisiert und die Methode next() legt ihren Wert explizit mit „false“ fest.
current.setAbortAction wird nicht berücksichtigt, wenn sie in einer Business Rule ausgeführt wird, die in einem unterschiedlichen Bereich definiert ist.Auslösenden Vorgang von Business Rules ermitteln
Sie können ein Skript für Business Rules schreiben, die bei mehr als einer Datenbankaktion ausgelöst werden.
if(current.operation() == "update") {
current.updates ++; }
if(current.operation() == "insert") {
current.updates = 0; }OR-Bedingungen in Business Rules verwenden
Eine OR-Bedingung kann jedem Abfrageteil innerhalb einer Business Rule hinzugefügt werden.
var inc = new GlideRecord('incident');
var qc = inc.addQuery('priority','1');
qc.addOrCondition('priority','2');
inc.query();
while(inc.next()) {
// processing for the incident goes here
}(priority = 1 OR priority = 2) AND (impact = 2 OR impact = 3) aus. Die Ergebnisse der OR-Bedingung werden mit zwei Variablen ausgeführt: qc1 und qc2. Auf diese Weise können Sie das Abfragebedingungsobjekt später im Skript bearbeiten, z. B. in einer IF-Bedingung oder einer WHILE-Schleife.var inc = new GlideRecord('incident');
var qc1 = inc.addQuery('priority','1');
qc1.addOrCondition('priority','2');
var qc2 = inc.addQuery('impact','2');
qc2.addOrCondition('impact','3');
inc.query();
while(inc.next()) {
// processing for the incident goes here
}Glide Listen in Business Rules referenzieren
Ein als Glide-List definiertes Feld ist ein Array von Werten, die in einem einzelnen Feld gespeichert sind.
Im Folgenden finden Sie einige Beispiele für die Verarbeitung eines Felds des Typs „glide_list“ beim Schreiben von Business Rules. Im Allgemeinen enthält ein Feld des Typs „glide_list“ eine Liste von Referenzwerten, die auf andere Tabellen verweisen.
Beispiele
Das Feld Beobachtungsliste in Aufgaben beispielsweise ist ein Feld des Typs „glide_list“, das Referenzen auf Benutzerdatensätze enthält.
Der Code unten zeigt, wie das Feld referenziert wird.
// list will contain a series of reference (sys_id) values separated by a comma
// array will be a javascript array of reference values
var list = current.watch_list.toString();
var array = list.split(",");
for (var i=0; i < array.length; i++) {
gs.print("Reference value is: " + array[i]);
}*** Script: Reference value is: 62826bf03710200044e0bfc8bcbe5df1
*** Script: Reference value is: c2826bf03710200044e0bfc8bcbe5d45
*** Script: Reference value is: 5f74e421c0a8010e01ec0d74a7ee2cc6
*** Script: Reference value is: 06826bf03710200044e0bfc8bcbe5d57Sie können auch die den Referenzwerten zugeordneten Anzeigewerte abrufen. Hierzu verwenden Sie die Methode getDisplayValue() wie unten demonstriert.
// list will contain a series of display values separated by a comma
// array will be a javascript array of display values
var list = current.watch_list.getDisplayValue();
var array = list.split(",");
for (var i=0; i < array.length; i++) {
gs.print("Display value is: " + array[i]);
}*** Script: Display value is: Abel Tuter
*** Script: Display value is: Ashley Leonesio
*** Script: Display value is: Charles Beckley
*** Script: Display value is: Cherie FuhriZeichenfolgen in Glide Listen suchen mit „indexOf("GesuchteZeichenfolge")“
Verwenden IndexOf (" searchString„) um die Position der an die Methode übergebenen Zeichenfolge zurückzugeben, wenn das Glide-Listenfeld, z. B. eine Beobachtungsliste, mindestens einen Wert enthält.
Wenn das Feld leer ist, wird undefined zurückgegeben. Sie können mit einem der folgenden Schritte vermeiden, dass ein Wert „undefined“ zurückgegeben wird:
- Erzwingen Sie das Feld in eine Zeichenfolge, z. B.: Watch_list.toString().indexOf (" searchString„)
- Suchen Sie nach einem leeren Glide-Listenfeld mit einer Bedingung, bevor Sie verwenden IndexOf() , Z. B. wenn ( Watch_list.nil() || watch_list.indexOf (" searchString„) == -1)
Benutzer-Accounts sperren
Sie können Benutzer-Accounts sperren, wenn der Benutzer nicht aktiv ist.
// Lock accounts if bcNetIDStatus != active in LDAP and user does not
// have self-service, itil or admin role
var rls = current.accumulated_roles.toString();
if(current.u_bcnetidstatus == 'active' && (rls.indexOf(',itil,') > 0 ||
rls.indexOf(',admin,') > 0 ||
rls.indexOf(',ess,') > 0 )) {
current.locked_out = false; }
else {
current.locked_out = true; }
var now_GR = new GlideRecord("sys_user");
now_GR.query();
while(now_GR.next()) {
now_GR.update();
gs.info("updating " + gr.getDisplayValue());
}Standardmäßige Business Rule des Typs „Vor“ zur Ausführung vor Abfragevorgängen
Sie können eine Business Rule des Typs „Abfragen“ verwenden, die vor dem Senden einer Datenbankabfrage ausgeführt wird.
- Name: incident query
- Tabelle: Incident
- Wann: „before“, „query“
- Skript:
if(!gs.hasRole("itil") && gs.isInteractive()) {
var u = gs.getUserID();
var qc = current.addQuery("caller_id",u).addOrCondition("opened_by",u).addOrCondition("watch_list","CONTAINS",u);
gs.print("query restricted to user: " + u); }