Queries

...

Query's

Wanneer je queries uitvoert in Axxerion in scripting, or when debugging performance issues, be aware of the following aspects that negatively effect performance.

Client specific fields

Do not use JUST client specific fields in queries if you can. For doing this, Workplace will have to always combine two data tables, which will require the system to always search a larger table (the one with client specific fields) than the core objects. Always try to add a Workplace core field (most commonly scriptvorm of wanneer je performance problemen debugt, let dan op de volgende aspecten die de performance negatief beïnvloeden.

Klantspecifieke velden

Gebruik JUIST geen klantspecifieke velden in query's als dat mogelijk is. Hiervoor moet Workplace altijd twee gegevenstabellen combineren, waardoor het systeem altijd in een grotere tabel moet zoeken (die met clientspecifieke velden) dan de kernobjecten. Probeer altijd een Workplace kernveld toe te voegen (meestal createTime, updateTime, externalReference, closeTime, categoryFolderId).

If you do need to use client specific fields, try to limit them. The more fields you add, the more data that will need to be integrated, which in turn might take more time to run. So if you have a slow query, check if removing client specific fields has a positive effect (or vice versa, adding them has an adverse effect).

Empty query parameters

When using variables in a query, make sure they have values added to them. See the below Als je toch klantspecifieke velden moet gebruiken, probeer ze dan te beperken. Hoe meer velden je toevoegt, hoe meer gegevens er geïntegreerd moeten worden, wat weer meer tijd kan kosten om uit te voeren. Dus als je een langzame query hebt, controleer dan of het verwijderen van klantspecifieke velden een positief effect heeft (of andersom, ze toevoegen heeft een negatief effect).

Lege query parameters

Als je variabelen in een query gebruikt, zorg er dan voor dat er waarden aan worden toegevoegd. Zie het onderstaande script.

contact = this;
manager = contact.managerContactId;
colleagues = find Contact by managerContactId == manager;

What you expect the script to do is to get the manager from the current contact. Then you use that manager to find all the other contacts assigned to that manager. There is a catch though: if this script runs on a contact that does not have a manager, the script will then search for ALL contacts. A better solution is to do the followingJe verwacht dat het script de manager van de huidige contactpersoon ophaalt. Vervolgens gebruik je die manager om alle andere contactpersonen te vinden die aan die manager zijn toegewezen. Er zit echter een addertje onder het gras: als dit script wordt uitgevoerd op een contactpersoon die geen manager heeft, zoekt het script naar ALLE contactpersonen. Een betere oplossing is om het volgende te doen.

contact = this;
manager = contact.managerContactId;
if (!isEmpty manager) {
  colleagues = find Contact by managerContactId == manager;
}

The above will check if the value for manager is empty. If that is not the case, then you start the rest of the logic. A better option is to actually make break clauses in your scripting, which stops the script if it is not necessary anymore. See belowHet bovenstaande controleert of de waarde voor manager leeg is. Als dat niet het geval is, dan start je de rest van de logica. Een betere optie is om break-clausules in je script te maken, waardoor het script stopt als het niet meer nodig is. Zie hieronder.

contact = this;
manager = contact.managerContactId;
if (isEmpty manager) {
  return;
}
colleagues = find Contact by managerContactId == manager;

This will make the script more readable and “safe”, as it terminates the logic once it should stop.

Find versus Get

In scripting, when using a “Find”, all items that match the parameters will be returned. When using a “Get”, only one item is returned. Even though only one item is returned, the “Get”-query is not quicker. Behind the screens, Workplace does a “Find” and just returns 1 item. So be aware that using this is not quicker.

Combine queries

In Workplace, it is possible to “link through” in queries. See the below Dit maakt het script leesbaarder en "veiliger", omdat het de logica beëindigt zodra het zou moeten stoppen.

Vinden versus krijgen

Bij scripting worden bij gebruik van een "Find" alle items die overeenkomen met de parameters geretourneerd. Als je een "Get" gebruikt, wordt slechts één item geretourneerd. Hoewel er slechts één item wordt geretourneerd, is de "Get"-query niet sneller. Achter de schermen doet Workplace een "Find" en retourneert slechts 1 item. Wees je er dus van bewust dat dit niet sneller is.

Query's combineren

In Workplace is het mogelijk om "door te linken" in query's. Zie de onderstaande scripting.

contact = this;
manager = contact.managerContactId;
if (isEmpty manager) {
  return;
}
colleagues = find Contact by managerContactId == manager;
properties = [];
for each colleague in colleagues {
  properties = properties + find Property by ownerContactId == colleague;
}

Assuming the query on line 6 returns 10 colleagues, the “for each” will execute the properties query 10 times. A more optimal way is to combine the separate queriesErvan uitgaande dat de query op regel 6 10 collega's retourneert, zal de "for each" de eigenschappen query 10 keer uitvoeren. Een meer optimale manier is om de afzonderlijke query's te combineren.

contact = this;
manager = contact.managerContactId;
if (isEmpty manager) {
  return;
}
properties = find Property by ownerContactId == NULL, Contact.managerContactId == manager;

What the scripting does here is to go from the object Property to the ownerContactId and then searches all the Contact who belong to a certain manager. This effectively lowers the total query amount from 11 to 1.

Queries with client specific fields/attributes

When performing a query using a client-specific field, this would potentially be quite small when using large numbers of objects (i.e. CodeTypes). In some cases, it might be quicker to collect all items and check on the specific value that you are interested in, instead of directly searching for the client-specific field value. This should be decided on a case-by-case basisWat het script hier doet, is van de Object Property naar de OwnerContactId gaan en dan alle Contacten doorzoeken die bij een bepaalde manager horen. Dit verlaagt het totale aantal zoekopdrachten van 11 naar 1.

Query's met klantspecifieke velden/attributen

Bij het uitvoeren van een query met behulp van een klantspecifiek veld, zou dit potentieel vrij klein zijn bij gebruik van grote aantallen objecten (bijv. CodeTypes). In sommige gevallen kan het sneller zijn om alle items te verzamelen en te controleren op de specifieke waarde waarin je geïnteresseerd bent, in plaats van direct te zoeken naar de client-specifieke veldwaarde. Dit moet per geval worden besloten.

reference = "REF-12345";
category = get Folder by reference == "CAT-12345";
var oneSpecificObject;

# Normally, you would do something like this:
if (!isEmpty reference) {
  oneSpecificObject = get CodeType by categoryFolderId == category, "acme-ExternalReference" == reference;
}

# But sometimes, this is quicker:
if (!isEmpty reference) {
  objects = find CodeType by categoryFolderId == category;
  for each object in objects {
    if (object."acme-ExternalReference" != reference) {
      continue;
    }
    oneSpecificObject = object;
    break;
  }
}

...

Echo's in scripting

It turns out that echo’s in scripting add to the used heap space on the server. So removing echo’s after you are done debugging is a great way to prevent issues on the server. If want a big bang to clean this up inside a client environment, you can run the following script in that environmentHet blijkt dat echo's in scripts bijdragen aan de gebruikte heapruimte op de server. Dus het verwijderen van echo's nadat je klaar bent met debuggen is een goede manier om problemen op de server te voorkomen. Als je een grote klap wilt om dit op te ruimen in een clientomgeving, kun je het volgende script in die omgeving uitvoeren:

client = user.clientId;
scripts = find Script by clientId == client, scriptVersionId == NULL, ScriptVersion.scriptText contains "echo";
activeScriptVersions = [];
for each script in scripts {
    activeScriptVersions = activeScriptVersions + script.scriptVersionId;
}

for each scriptVersion in activeScriptVersions {
    scriptText = scriptVersion.scriptText;
    newScriptText = scriptText ~r/\s*echo.*//;
    newScriptVersion = copy scriptVersion;
    set newScriptVersion.scriptText = newScriptText;
    set newScriptVersion.description = "Automatic echo removal";
    set newScriptVersion.scriptStatusCode = Enums.ScriptStatus.active;
    script = newScriptVersion.scriptId;
    set script.scriptVersionId = newScriptVersion;
}

The above scripts does the following:

...

It gets all the scripts in which the latest script version creates the word “echo”

...

From that, it retrieves the active script versions

...

For each active version, it searches for all the echo’s in the script through a regular expression (line 10)

...

It then copies the existing version and replaces it with the echo-free text

...

Het bovenstaande script doet het volgende:

• Het krijgt alle scripts waarin de laatste scriptversie het woord "echo" maakt

• Daaruit worden de actieve scriptversies opgehaald

• Voor elke actieve versie zoekt het naar alle echo's in het script via een reguliere expressie (regel 10)

• Vervolgens wordt de bestaande versie gekopieerd en vervangen door de tekst zonder echo

• Het voegt een beschrijving toe aan deze versie en activeert de nieuwste versie