Universal Messenger 7.45.0

Datenmodell / Attributkonfiguration

Entry-Types werden Standard

Ab Release 7.45 wird der Universal Messenger bei einer Neuinstallation standardmäßig mit aktivierten Entry-Types ausgeliefert. Die im Standard eingerichteten beiden Entry-Types können in allen Editionen des Universal Messenger genutzt werden. Die Einrichtung weiterer Entry-Types erfordert nach wie vor eine Edition mit Lizenz für Entry-Types.

In cmsbs-conf/cmsbs.properties werden Entry-Types jetzt wie folgt aktiviert:

cmsbs.entrytypes.attribute = "entrytype"

In cmsbs-conf/additional.attributes wird das entrytype-Attribut mit zwei Entry-Type-Werten konfiguriert:

entrytype.type = STRING
entrytype.dbSize = 32
entrytype.isPrimary = true
entrytype.values[] = "customer"
entrytype.values[] = "admin"
entrytype.values[] = ""

additional.attributes[] = entrytype

grp.std_intern.members[] = "entrytype"

# Composite Unique Key (siehe unten)
email.isUnique = false
isUnique = email entrytype

Der Entry-Type customer / Kunde soll für typische Kundendatensätze wie z.B. Newsletter-Abonnenten verwendet werden. Der Entry-Type admin / Backoffice-User soll hingegen für User verwendet werden, die sich in das Backoffice des UM einloggen können sollen.

Die notwendige Primärtabellenspalte user.p_entrytype wird automatisch beim UM-Start angelegt. Ein separater Migrationsschritt ist dazu nicht mehr erforderlich.

Besonderheiten beim UM-Update

Wird eine bestehende UM-Installation aktualisiert, ohne dabei cmsbs.properties bzw. additional.attributes zu ersetzen, ändert sich nichts am Verhalten: Waren vorher Entry-Types nicht in Benutzung, werden sie durch das Update auch nicht automatisch aktiviert.

Entry-Types deaktivieren (wenn Konfigurationsdateien aus Installer verwendet werden)

cmsbs-conf/conf.d/no-entrytypes.properties:

cmsbs.entrytypes.attribute = ""

cmsbs-conf/conf.d/no-entrytypes.attributes:

additional.attributes[-] = entrytype
grp.std_intern.members[-] = entrytype

# email-Attribut soll eindeutig sein (optional!)
email.isUnique = true

# kein Composite Unique Key:
isUnique = ""

Mitgelieferten Entry-Type deaktivieren

Es ist auch möglich, einen oder beide der in der Standardkonfiguration mitgelieferten Entry-Type-Werte zu deaktivieren.

cmsbs-conf/conf.d/entrytypes.attributes:

# Type "customer" entfernen:
entrytype.values[-] = customer

# Type "admin" zum Default machen:
entrytype.default = admin

Composite Unique Key

In der Attributkonfiguration kann nun festgelegt werden, dass zwei oder mehr ID-Attribute nicht mehr nur jedes für sich, sondern alle in Kombination eindeutig (unique) sein müssen.

Somit lässt es sich nun einstellen, dass beispielsweise das email- zusammen mit dem entrytype-Attribut eindeutig sein soll, es aber durchaus mehrere Einträge mit der gleichen E-Mail-Adresse geben darf, sofern sie jeweils unterschiedliche Werte für entrytype haben.

In cmsbs-conf/additional.attributes kann das wie folgt konfiguriert werden:

email.isUnique = false           # email allein muss nicht mehr eindeutig sein,
isUnique = email entrytype       # ... aber die Kombination aus email und entrytype.

Wie üblich sind null-Werte immer erlaubt, so dass im Beispiel sowohl ein leeres email- als auch ein leeres entrytype-Attribut die weitere Eindeutigkeitsprüfung für den jeweiligen Eintrag gleichsam außer Kraft setzt.

Bei einer UM-Neuinstallation wird der Composite Unique Key wie oben gezeigt festgelegt.

Neue Notationen in der Attributkonfiguration

Drei neue Notationen erleichtern das inkrementelle Überschreiben der Attributkonfiguration:

Wert einer Liste hinzufügen

entrytype.values[+] = new_type

# Alternative bisherige Schreibweise:
entrytype.values[] = new_type

Wert aus Liste entfernen

entrytype.values[-] = admin

Liste überschreiben

entrytype.values[!] = customer new_type

Setzt die Liste entrytype.values auf den Wert customer, new_type und überschreibt damit den vorherigen Wert und auch alle inkrementellen Anpassungen, die mittels ...[-] oder ...[+] vorgenommen wurden.

Robusterer Newsletterversand

Beim Newsletterversand werden die Empfänger nun erst dann als “kontaktiert” markiert, wenn das SMTP-Relay die jeweilige E-Mail entweder eindeutig angenommen oder abgelehnt hat. Sollte es beispielsweise zu einem Timeout oder vergleichbaren Problemen kommen, wird der Empfänger beim späteren Fortsetzen des Versands erneut beschickt.

Wenn die Übergabe einer zu versendenden E-Mail an das SMTP-Relay auf Netzwerkebene fehlschlägt, wird die Übergabe nun gemäß der Konfiguration wiederholt versucht, bevor die gesamte Versandaktion abgebrochen wird. In der Standardkonfiguration erfolgen nun bis zu 10 erneute Versuche mit einer jeweils 30-sekündigen Wartezeit vor dem nächsten Versuch. Diese Werte können in cmsbs-conf/cmsbs.properties angepasst werden:

cmsbs.smtp.maxRetries    = 10
cmsbs.smtp.retryDelay    = 30

In diesem Zusammenhang könnte auch die folgende Konfigurationsoption hilfreich sein, mit welcher die TTL des Java-eigenen DNS-Caches angepasst werden kann. Wird ein Load Balancing per DNS-Anpassung realisiert, ist ggf. eine Verringerung der TTL sinnvoll:

# DNS-Cache-TTL auf 10 Sekunden herabsetzen:
cmsbs.networkaddress.cache.ttl = 10

Bouncebehandlung / E-Mail-Empfang

Verschiedene Fehlersituationen in der Bounceerkennung werden nun besser abgefangen und führen nicht mehr zu einem Abbruch bzw. zu einer Endlosschleife.

Die Zuordnung von Bounces ohne die Verwendung von VERP wurde verbessert: Sofern die Originalmail als Anhang in der Bounce-Mail enthalten ist, erfolgt die präzise Zuordnung der Bouncemail zu Empfänger und Versandvorgang nun anhand der Headerinformationen aus dieser angehängten E-Mail. Die Bouncemail muss dazu einen Anhang vom Typ message/rfc822 enthalten.

Alternativ wird nun auch ein Anhang vom Typ text/rfc822-headers ausgewertet, der nicht die gesamte Originalmail, sondern nur deren Headerinformationen im Textformat enthält.

Tracking von Conversions

Conversion beim Linktracking

Beim Linktracking per REST-Proxy kann nun durch einfaches Hinzufügen von URL-Parametern an den zu trackenden Link automatisch ein Conversiontracking implementiert werden.

Beispiel: Ein Link im Newsletter enthält folgenden Link:

<a href="https://www.acme.com/shop/?umc.what=enter-shop&umc.value=1&x=true">Shop</a>

Wenn für den Newsletter das Linktracking aktiviert ist, wird hier beim Klick auf den Link im Newsletter nicht nur der Klick gezählt, sondern auch eine Conversion mit dem Schlüsselwort enter-shop und dem Wert 1 gespeichert. Beim folgenden Redirect werden die beiden umc.*-Parameter entfernt, so dass der Nutzer auf die Seite https://www.acme.com/shop/?x=true weitergeleitet wird.

Delivery-Ticket / msgid an Links anhängen

Die globale Konfigurationsoption cmsbs.tracker.alwaysAppendMsgid aktiviert das automatische Anhängen des Delivery-Tickets an jeden vom Linktracking behandelten Link. Das Delivery-Ticket wird vor dem Redirect als URL-Parameter msgid an die gegebene URL angehängt.

Conversion per Backend-API

Ein neuer REST-Endpunkt ermöglicht das programmatische Tracken einer Conversion:

POST http://localhost:8080/cmsbs/rest/de.pinuts.cmsbs.api.tracking.Application/conversion?msgid=[MSGID]&umopen=[cmsbs.open]&what=[KEY]&value=VALUE]

Newsletterarchiv

Die globale Option cmsbs.gui.newsarchive.minContacts ist nun standardmäßig so gesetzt, dass im Newsletterarchiv eine Filtermöglichkeit angeboten wird, mit der sich die Liste nach der Anzahl der Empfänger filtern lässt:

Siehe auch https://www.universal-messenger.de/knowledge-base/intern/doc-de/Developer/Allgemeine_Einstellungen.html

Core Scripting Engine

Die verwendete JavaScript-Engine Rhino und der für die Transpilierung von .es6- und .mjs-Quelldateien verwendete Google Closure Compiler wurden aktualisiert. Damit stehen nun auch die neuen Features von ECMAScript 2020 und 2021 zur Verfügung:

• ?.-Operator (“optional chaining”)
  Liefert undefined, wenn der Wert links null oder undefined ist; z.B.:

  const a = null;
  console.log(a?.length);  // -> undefined

• ??-Operator (“nullish coalescing operator”)
  Liefert den Wert links, sonfern er nicht null oder undefined ist, andernfalls den Wert rechts; z.B.:

  null ?? 'string'      // -> 'string'
  undefined ?? 'string' // -> 'string'
  false ?? 'string'     // -> false
  'foo' ?? 'string'     // -> 'foo'
  0 ?? 'string'         // -> 0

• ||=, &&=, ??=-Operator
  Logische Verknüpfung mit Zuweisung analog zu += oder *=; z.B.

  let a = false; a ||= true;    // -> a == true
  let a = false; a &&= true;    // -> a == false
  let a = null; a ??= 'string'; // -> a == 'string'
  let a = null; a ??= true;     // -> a == true
  let a = false; a ??= true;    // -> a == false

• **-Operator
  Der Potenzoperator; z.B.

  12 ** 2 // -> 144

• globalThis
  Globaler Scope. War bisher schon unter dem Namen __rootScope erreichbar.

• BigInt
  Für Rechenoperationen mit beliebig großen Ganzzahlen kann die Klasse BigInt genutzt werden. Das Suffix n wandelt Zahlenliterale in BigInts. Außerdem können _-Zeichen als optionales Trennsymbol in Zahlenliteralen verwendet werden; z.B.:

  1_000_000_000_000n ** 2n + 12345n // -> 1000000000000000000012345n
  BigInt('1000000000000') + 12345n  // -> 1000000012345
  typeof 1_000_000_000_000n         // -> 'bigint'

HTTP-Client

Beim Instanziieren per HttpClientBuiler kann nun auch der Timeout gesetzt werden:

import HttpClientBuilder from '@de.pinuts.http/shared/HttpClientBuilder.es6';

let client = new HttpClientBuilder()
    .setConnectTimeout(30)
    .setConnectionRequestTimeout(60)
    .build();

Aktualisierte Bibliotheken

• Rhino 1.7.14

• Closure Compiler v20220405

• HSQLDB 1.8.1.1