Visualforce und Lightning Experience
Nutzen Sie noch Salesforce Classic oder bereits die (nicht mehr ganz so) neue Salesforce Lightning Experience? Viele haben noch Bedenken nach Lightning zu migrieren. Nachvollziehbar - Gerade bei größeren oder komplexen Salesforce-Umgebungen mit vielen Visualforce-Seiten ist die Befürchtung groß, Funktionalitäten bei einer Migration zu verlieren. Das würde die Migration nach Lightning noch aufwendiger machen und hindert daher viele daran.
Wir haben uns selber mit der Thematik "Visualforce migrieren" intensiv auseinander setzten müssen. Zwar nutzen wir schon lange Lightning, allerdings hatten auch wir bislang Bedenken unseren Visualforce-Seiten zu migrieren. Am Schluss stand jedoch die Erkenntnis, dass viele Anforderungen die vor Kurzem noch dafür gesorgt hätten die Lightning-Migration weiter in die Zukunft zu verschieben, heute verhältnismäßig schnell umgesetzt werden können.
Dabei muss man zwischen zwei Lösungsmöglichkeiten unterscheiden: Zum einen die Möglichkeit, die Visualforce-Seiten durch Standard Lightning-Komponenten und/oder -Funktionalitäten zu ersetzen, und zum anderen, dass Funktionalitäten auf den Visualforce-Seiten für eine "Lightning Readiness" angepasst werden müssen.
Teil 1 von "Visualforce und Lightning" beschäftigt sich mit den Punkten, die man mit Salesforce Boardmitteln lösen kann, in Teil 2 beschäftigen wir uns mit dem Code.
Erste Erkenntnisse
Bis vor etwas mehr als einem halben Jahr hieß es in vielen Blogs „Visualforce vs. Lightning“ oder es wurde mit „Visualforce oder Lightning“ suggeriert, dass man sich für die eine oder andere Plattform entscheiden muss. Salesforce Vertreter haben u. a. mit Webinaren wie „Using Visualforce in Lightning Experience ‚Just Works‘ – mostly“ versucht, der Verunsicherung entgegenzusteuern.
Vor allem mit den letzten beiden Releases wurden einige Entwickler-Tools verbessert und ergänzt, die uns helfen, Visualforce-Seiten schneller und einfacher „lightning ready“ zu machen: z. B. können wir seit dem Winter '18 Release Visualforce-Seiten relativ schnell aussehen lassen, als wären es Lightning Seiten – und mit dem Spring '18 Release noch unkomplizierter. Ein weiteres Tool unterstützt bei der Lightning-Migration: der Lightning Experience Visualforce Report. Dieser soll eine Übersicht über diejenigen Seiten geben, an welchen wir für eine Migration ein paar Anpassungen vornehmen müssen.
Wir wollen nun starten und lassen uns für unsere Salesforce Org den Lightning Experience Visualforce Report - mit zwar nur knapp 20 aktiven Nutzern, aber doch ein paar Besonderheiten - erstellen. Eigentlich sollte nicht viel zu überarbeiten sein - wir nutzen Lightning ja schon seit einer Weile.
Tja. Und dann sinkt die Motivation auf der zweiten Seite der Report-PDF gegen Null:
62 Stunden für Entwicklung, Konfiguration und Administration – ohne die übrigen Stunden für Doku, Deployment, UATs, etc. - Das erscheint mir nicht als "mostly works".
Was brauchen wir?
Tief Luft holen und weiterlesen. Schnell ist erkannt, dass 6 der 20 Seiten zu Managed Packages, also AppExchange Apps, gehören. Da hilft nur ein kurzer Abstecher zu AppExchange, um zu prüfen, ob die Apps mittlerweile Lightning Ready sind und um ggf. ein Update einzuspielen. Heißt: ein wenig Zeit für Konfiguration und Administration, mehr Zeit für die Anwender-Schulung.
Noch viel besser: 4 Seiten werden gar nicht genutzt. Eine weitere Seite ist die „FileNotFound“-Seite, bei der ich davon ausgehen kann, dass Salesforce mir eine gute Alternative bereitstellt.
Damit sollte das Pensum schon Mal gewaltig reduziert sein. Zeit, sich mit den restlichen 20 Report-Seiten zu befassen.
Der Report führt 3 Kategorien für potenzielle Problem-Kategorien:
- "Maybe Supported, Refer to Readiness Report for Managed Package Details"
- "Supported, but Requires Some Attention"
- "Not Supported, Requires A Lot of Attention"
Zwei der „Not Supported, Requires A Lot of Attention“-Meldungen kann ich vernachlässigen: Hier schlägt der Report auf die sehr wohl in Lightning unterstützte jQuery Library an.
Eine weitere Seite stammt aus den Anfängen der Lightning-Ära und hat einen Pfad für unterschiedliche Objekte auf der Seite visualisiert. Die Visualforce-Seite kann durch den Salesforce Pfad ersetzt werden.
Die nächste Visualforce-Seite diente dazu, Duplikate zu finden. Auch diese Seite ist mittlerweile überflüssig geworden und kann durch Duplikatsregeln ersetzt werden.
Probelmlos Migrierbar
Einige weitere Visualforce-Seiten sind ebenfalls problemlos migrierbar. Beispielsweise Seiten, die nicht auf einer Seite, sondern als ganze Seite über die Tabs (Registerkarten) in der Navigation aufgerufen werden. Wir können auch (fast) jede Seite als Komponente auf der Seite darstellen: Hierfür nur nicht vergessen, das Häkchen bei "Verfügbar für Lightning Experience, Lightning Communities und die mobile Anwendung" zu setzen.
Auch praktisch: Visualforce E-Mail-Templates sind in Lightning ohne Anpassung verfügbar.
Dann gibt es natürlich noch den "kommt-darauf-an"-Fall für Visualforce Quick Actions (Schnellaktionen) und Button Overwrites. Enthalten diese Visualforce-Seiten JavaScript und/oder Weiterleitungen, ist hier etwas mehr zu tun. Hier bleibt nur eines: Testen und ggf. Anpassen.
Erstes Fazit
Der Report zeigt tatsächlich fast alle Seiten auf, die in Lightning Probleme machen könnten. Nur eine Visualforce-Seite wurde übersehen. Aber dort lag das Problem beim JavaScript-Button, der die Seite aufrief - und der wird bereits beim Lightning Readiness Report angezeigt. Davon abgesehen: Die Migration ist eine gute Gelegenheit, die Org "auszumisten" und tatsächlich können viele alte Lösungen durch Standard-Komponenten und -Funktionalitäten ersetzt werden.
In Teil 2 von "Visualforce und Lightning" betrachten wir die Aspekte, die tatsächlich nur über eine Anpassung der Visualforce-Seite selbst oder sogar durch Ersetzen der Seite gelöst werden können. Dabei liegt der Fokus der Lösungen vor allem auf dem Seitenaufbau und der Navigation in Lightning.