Winter '20 - Warten auf Dreamforce, kleine Zeitenwende für Entwickler

Winter '20 - Warten auf Dreamforce, kleine Zeitenwende für Entwickler

Mein Lieblingssatz aus diesem Release:

Out of an abundance of caution

Aus o.g. Grund wird die Auto-Aktivierung von Lightning Experience für User mit Standardprofilen verschoben. "We’ve discovered a potential technical issue unrelated to Lightning Experience that could impact your general experience with the Winter ‘20 release", heißt es weiter.

Mehr ist nicht zu erfahren und ich will nicht spekulieren. Feststeht, seit sich Salesforce in Richtung hoch regulierter Industrien wie Banken und Versichungswesen bewegt, wird aufgeräumt. Ganz vorne  mit dabei: Berechtigungen. Aufgepaßt bei Profil-  / Perm- / Zugriff-Änderungen in Guest Profile, Custom Settings und Flows. Dicht gefolgt von Metadaten, was nicht nur Scratch Orgs zugute kommt. Für fast alles, was man für eine Org einstellen kann, gibt es ein zugehöriges Setting. DSGVO / GDPR (z.B. Consentmanagement) findet sich innerhalb von PartyDataModelSettings. Alles rund um Apex lest ihr hier.

Kleine Zeitenwende für Entwickler

Apropos Apex, apropos Entwicklung. Man kann sich gar nicht ausmalen, wie viel Zeit draufgeht als Entwickler auf Salesforce zu warten.
Wer in der Developer Console speichert, speichert nicht nur, er stößt ein kleines Deployment an. Auch in einem Salesforce IDE reicht Speichern auf der Festplatte nicht, die Änderungen müssen erst übertragen werden - das ist nichts für Ungeduldige und im Laufe eines Jahres geht dafür eine Menge Zeit drauf.

Es kommt einer Zeitenwende gleich, daß damit jetzt Schluß ist, zumindest für Lightning Web Components.  Man kann sie auf dem eigenen Rechner entwickeln und ausprobieren und denen, die sagen: nutzslos ohne Apex, darf ich antworten: Apex ist dabei, denn eine Scratch Org ist für Local Development nötig und diese ist der Proxy für Apex Aufrufe. Meine Component auf meiner Platte bekommt also sehr wohl Daten aus Salesforce und nicht nur Mocks. Hierzu paßt, daß LWC offiziell Open Source sind und man auch ohne Salesforce Lizenz Applikationen bauen kann. Warum macht Salesforce das? Wer bisher als Entwickler die Plattform verlassen hatte, konnte kaum etwas mitnehmen für andere Technologien. Mal sehen, ob LWC neben vue und anderen einen Platz erhalten wird.

Seit es Lightning Experience gibt, wollte ich wissen, wie das gehandhabt wird und ob eine andere Componente, die zufällig mit meiner eine RecordPage teilt, meiner Componente den Saft wegnehmen kann. Die Antwort verbarg sich bisher im Nimbus des sogenannten Boxcarrying: damit werden allerhand Sachen aus Optimierungsgründen in denselben Server Request (XHR) gepackt. Ich habe mir versichern lassen, wie und warum, will man gar nicht genauer wissen - das ist eine Wissenschaft für sich.
Winter '20 bringt klare Aussagen: Wenn Lightning Apex aufruft, bekommt jeder Call ein eigenes Set an Limits (siehe auch hier). Limits werden nicht mehr auf den gesamten ge-boxcar-ten Kontext bezogen.

Die neue Salesforce App

Bestimmt habt ihr schon von der Neuauflage der Salesforce App gehört, die so langsam einholt, was Salesforce vor 6 Jahren mit Salesforce1 versprochen hat: Lighting Apps so konfigurieren, daß sie entweder für Desktop oder Mobile funktionieren oder beides. In der Tat, ist der neue Wurf wesentlich näher am alten Versprechen. Seit dem Start von Salesforce1 und dem Umweg über die Lightning Experience hat Salesforce viel dazugelernt.  Hier das wichtigste dazu:

Außerdem

Die Grenze zwischen synchronem und asynchronem wird unwichtiger auf der Plattform. Unterscheidbar - oder besser gesagt: wahrnehmbar ist er in der Lightning Experience kaum noch. Ob eine freundliche Toast Nachricht eine halbe Sekunde früher oder später kommt, ob also ein synchroner Action Aufruf oder ein asynchroner samt Platform Event stattfindet, ist nicht unterscheidbar. Oder ob die Nachricht aus einer Visualforce Seite, einer Lightning Web Component oder einer Aura Component kommt - es zeigt nur, daß Salesforce weiter in Richtung Client geht. Für diesen ist das meiste in der Lightning Experience sowieso asynchron. Alles spricht miteinander auf meinem Rechner statt auf den Salesforce Servern und es würde mich nicht wundern, wenn das bald positive Wirkung auf Limits hätte. Ein bißchen gemein ist das gerade für die Unternehmen, die auf thin clients setzen, denn da ist zu wenig Rechenpower da. Für Classic ist meine Hardware ja recht egal, weil alles vom Server kommt.

Ein ähnlicher Schritt wird auch bei Hammer Tests vollzogen, plötzlich dürfen Kunden (ISVs und Subscriber) die auch durchführen. Alles rund um diesen ISV Hammer Tests Beta leuchtet mir nur halb ein. Die ganze Platform wandert in Richtung Client/Browser Technologie, das Salesforce Marketing pusht Flows und Process Builder und Lightning Data Service und preist es mit "no mandatory tests". Hier hilft es mir vielleicht etwas, als ISV gucken zu können, ob mein nächstes Update auch noch beim Kunden funktioniert, wenn nur genug Apex im Einsatz ist. Für alles Lightning-seitige bringt das kaum Mehrwert und genau dahin bewegen wir uns gerade.

Kennt ihr schon Salesforce Edge? Kümmert sich (u.a.) um das Routing von Eurer MyDomain.

Salesforce Edge uses machine-learning technology to improve connectivity and performance

Ein Schmankerl hat sich noch am Ende versteckt, mal sehen, was daraus wird:

Clone an entity and all related child entities (reserved for future use)
Use the deepCloneable object.

Und sonst?

Nichts weiter. Es scheint als würde viel Kapazität für das Aufräumen verwendet und für die neuen Clouds wie Manufacturing (Sales Agreements sind schon ziemlich cool), Health oder Sustainability, die jeweils eigene Feature bekommen haben. Dennoch, das aktuelle Release ist das ideen-ärmste Winter Release für Overall, Sales und Service, an das ich mich erinnern kann. Für gewöhnlich sind gerade die Winter Releases vollgepackt, diesmal nicht. Ein Grund könnte die baldige Dreamforce sein, für die man sich die großen Nachrichten aufgehoben hat.

Krachmacherpotential

  • Guest User Profil Permissions werden, wir erwähnt, ausgemistet via Critial Updates. Ich warte noch sehnlichst auf eine Option, mit der ScratchOrgs automatisch alle Critical Updates aktiviert haben, wobei einige einzeln über Settings konfigurierbar sind.

    BEHAVIOR CHANGE: You can use Tooling API to query for User object fields in guest user mode in API version 44.0 and earlier. In API version 45.0 and later, use SOAP API to get this data in guest user mode.User fields are exposed in SOAP API version 45.0 and later. User is still exposed in Tooling API to User Profiles with the View Setup permission. Quelle

  • Wie Zahlen, ein Datum oder Währungsbeträge in Salesforce dargestellt werden, bestimmen aktuell die Standards für Internationalisierung aus dem Java 8 Development Kit (JDK8).  Mit einem Critical Update läßt sich das auf ICU umstellen. Dazu müssen aber alle installierten Pakete mitspielen, was ich für unwahrscheinlich halte  - denn Apex spielt erst ab API 45.0 mit. Eine Übersicht, was sich für die einzelnen Locales verändert, findet sich hier - für meine Hauptsprachen Englisch und Deutsch kommt ein Komma hinzu bei Datumswerten (28.01.2008 16:30 wird zu 28.01.2008, 16:30) und negative Werte werden einheitlich als -1.234.567 angezeigt. Die knappen Release Notes hier. Email Adressen kommen im Sommer dran.
  • Alle Aura Komponenten aus dem ui: Namespace werden deprecated, da es entsprechende lightning: Versionen gibt. ui:scrollerWrapper betrifft das noch nicht.

Nicht geschafft

  • REMOVED: Manage Delivery Settings for Field Service
  • REMOVED: Share CSS Style Rules in Lightning Web Components
  • REMOVED: Guardrails Added for Quoting, Amendment, and Renewal Job Requests (CPQ)
  • REMOVED: Critical Updates Release Note Now Includes Security Updates

Lieblingsfeatures

  • Das mit Profilen, Permission Sets und Custom Permissions skaliert nicht gut. Mit der Beta zu Permission Set Groups, die viele durchdachte Features mitbringen, wird das geändert. Erstmals lassen sich Berechtigungen auch wieder beschneiden aka 'muten'.
  • Ich find's witzig: Anders als bei Apex, darf jeder selbst entscheiden, wie viel Test Coverage die eigenen Flows brauchen.
  • Mass Actions auf eine durch Suchbegriff gefilterte ListView anwenden. Großartig.
  • Callouts werden nicht mehr zum Concurrent Long Running Request Limit gezählt.
  • Einstein Search (Beta) könnte zum "Google fürs Interne" werden
  • ChangeDataCapture Header bekommen das Attribute changedFields, womit unsere Trigger schlanker werden. Mindestens so klug ist ein Pilot, der für CDC erlaubt, Felder zu deklarieren, die immer mitkommen. Spart Queries.
  • Die Learning Adventure App für Einstein ist grandios zum Einstieg und wird konstant aktuell gehalten. Einstein Analytics ist mit Winter '20, den positiven Auswirkungen auf Reporting, der Möglichkeit SOQL statt SAQL zu nutzen (Salesforce Direct) und auf Grund der Angleichungen in der Fachsprache (Steps heißen endlich Queries) auf der Plattform angekommen.
  • .click() für zB lightning:button oder und andere klickbare Elemente  hinzugefügt. Auch für LWC.
  • Dynamische required fields so einfach wie in Visualforce für Aura/LWC: das required Attribut für lightning:inputField bedeutet das Ende von komischen Workarounds.
  • Herausfinden, wie gut sich meine Einstein Vorhersagen über die Zeit schlagen, etwas anders auch in Echtzeit und natürlich ein Template.

einstein over time

  • Bisher hat nur Apex die Gewährleistung, intellectual property zu schützen. Einstein Strategy ist Mitglied Nummer 2 in dem erlesenen Club. Achtung: Strategy Templates gehören nicht dazu.
  • Flow Support für Lightning Web Components mittels eigenem Modul. Hier und hier. Auf den ersten Blick mehr programmatisch machbar als bei Aura.
  • Flow Fans bitte hier genau nachsehen, es gibt einige den Alltag erleichternden Neuerungen. Darunter auch: Umspeichern von Screen Flows zu Autolaunched Flows und umgekehrt, Flows im Builder selbst statt nur über Setup aktivieren, Custom Notifications und mein Favorit: Dynamisch Felder in Screens aus/einblenden. Außerdem Flows schedulen.
  • Es wird immer einfacher, in Apex auf Field Level Security Rücksicht zu nehmen. Hinzugekommen diesmal ist stripInaccessible()  als Beta, womit alles Wichtige auf Production Orgs angekommen ist.

Für Entwickler

  • AuthorizationFormConsent, ContactPointTypeConsent und Individual in ChangeDataCapture aufgenommen
  • Wofür hab ich mehrere Pakete mit verschiedenem Namespace, wenn die Lightning Components da drinnen keinen public Apex Code teilen dürfen?
  • Toll, daß sowohl Aura als auch LWC auf eine Page innerhalb einer App navigieren können. Nicht so toll, daß an dieser Stelle ein Beispiel für diese pageRef fehlt. Findet sich woanders: /lightning/app/standard__LightningSales/o/Case/home
  • Aura oder LWC war es bisher egal, ob ein Apex Object ein private Attribut deklariert hatte, die Componenten konnten darauf zugreifen. Läßt sich abschalten.
  • Deep Linking für den Mobile Publisher, mit dem man Communities in iOS oder Android Apps verwandeln kann.
  • force:package:version:create erreicht Parität mit der Package Upload UI, was damit zu tun hat, daß Packaging2 mit Winter20 generally available ist.
  • Locker Service läßt sich versionieren, d.h. auch auf eine nicht-aktuelle Version zurückstellen. Ruft bei mir Kopfkratzen hervor, worher wissen, worin sich Locker Versionen unterscheiden?
  • Da sich Packaging2 Pakete einen Namespace teilen können, erlauben Custom Metadata Types das Absichern der Einstellungen auf Paketebene.
  • Was sich in Apex ändert, ist überschaubar. Es gibt eine neue Formula Klasse, mit der man Formeln auf sObjekten berechnen kann. Ähnlich schon möglich via sObject.recalculateFormulas(), ist aber auf In-Memory Formeln beschränkt, mit Fehlern behaftet und hat gegen die SOQL Limits gezählt. Sebastian Kessel hat die neue Klasse und auch ihre Grenzen hier zusammengefaßt.
  • LWCs als Custom Tab einsetzen, was sie auch für programmatische Navigation erreichbarer macht.
  • Programmatischer Zugriff auf Einstein Dashboards. Hier und hier und hier.
({
init : function(cmp, event, helper) {
  var sdk = cmp.find('wave-sdk');
  var context = {apiVersion: '47'};
  
  var methodName = 'executeQuery';
  var methodParameters = {
      'query': 'q = load \"0Fbxx0000004JVUCA2/0Fcxx0000004KZcCAM\"; q = group q by \'Industry\';'
           + ' q = foreach q generate \'Industry\' as \'Industry\', sum(\'AnnualRevenue\') as \'sum_AnnualRevenue\';' 
           + ' q = order q by \'Industry\' asc; q = limit q 2000;'  
  };
  
  sdk.invokeMethod(context, methodName, methodParameters, $A.getCallback(function (err, data){
      if (err !== null) {
          console.error('executeQuery error', err);
      } else {
          var result = data;
          
          var obj = JSON.parse(result);
          
          var results = obj.results;
          var records = results.records;
          
          cmp.set('v.recordsList', records);
          cmp.set('v.queryResult', JSON.stringify(records));
      }
  }))
}
})
  • Neues Event in Aura, um in Communities mit Google Analytics zu sprechen. Nur für template basierte Communities.
  • Klug: Failover für Transaction Policies, indem der automated process user die Ausführung übernimmt.
  • Gerade für RecordPages mit empAPI ein (Performance) Segen, Filter auf CometD Subscriptions
  • Bulk Query Jobs Support in Bulk API 2.0
  • Wer bisher in Aura Components in API < 39.0 vor Locker gedrückt hat, bekommt es jetzt mit dem Shadow DOM zu tun. Browsertests auch.
  • OData Tracer hilft beim Debuggen von OData 2.0 / 4.0 Verbindungen

odata tracer

Für Administratoren

verify email

notification settings

Für Nutzer

Formeln in Berichten

expand all

one click view
better view