Die Werkstatt steht still
Vor ziemlich genau zwei Jahren habe ich meine ersten Schritte in Richtung Lightning Workbench gemacht. Von der Idee her die Workbench - aber eben in meiner Org in der Lightning Experience und nicht extern authentifiziert. Meine Version ist nie über ein Minitool für Admins hinausgewachsen.
Kein Zugriff auf APIs aus Lightning
2014 gab es noch Zugriff, das war ein Bug
Die größte Hürde: Workbench bietet Zugriff auf die Salesforce APIs, was in Lightning nicht möglich ist. Die sogenannte SessionId eines Nutzers in Lightning unterscheidet sich von der eines Nutzers in Classic, insofern sie keinen direkten Zugriff auf die Salesforce APIs via Callout erlaubt - anders als Visualforce. Das war nicht ganz von Anfang so, Peter Knolle hat 2014 noch einen Ansatz veröffentlicht, dann wurde es schnell still - denn es war schlichtweg ein Versehen, daß das überhaupt ging und wurde schnell gepatcht. Hintergrund sind Sicherheitsaspekte - eine letzte Verteidigungslinie, vermute ich.
2018/19 ist die Situation unverändert
Das Thema API Zugriff aus einer Component heraus war deswegen aber noch nicht vom Tisch. Gerade weil in Aura Components - anders als in Lightning Web Components - kein Zugriff auf die UserInfo API möglich ist, waren manche Usecases versperrt: RecordType spezifische Picklist-Werte zum Beispiel als StandaAlone, ohne lightning:recordForm drumherum.
Im letzten Jahr hat sich dann Douglas C. Ayers der Frage gewidmet und auch erklärt, wie man Peter Knolles Ansatz retten könne - mittels Named Credential, Connected App und bei genauer Betrachtung noch viel mehr.
Um sich diesen Aufwand vom Hals zu halten, hat Doug einen Weg über Visualforce und window.postMessage() gewählt. Wie er selbst erklärt, ist der Ansatz kniffelig und voraussetzungsvoll, da er verschiedene Javascript Bibilotheken nutzt, um den ganzen Sicherheitsthemen rund um postMessage() zu begegnen.
Proof of Concept: @future + Platform Event + lightning:empAPI
Letztens ist mir eine Idee gekommen, die funktioniert hat:
No Remote Site Setting. No Visualforce. No messing with sessionId.
— Ch. Szandor Knapp (@ch_sz_knapp) April 5, 2019
Experimental PoC for Accessing APIs from lightning components pic.twitter.com/CaKz8PRDYy
Pros
- Keine Abhängigkeiten zu externen Bibliotheken
- Keine
Connected App/Named Credential/Remote Site Setting - Kein
Visualforce - Keine Einflußnahme auf
SessionId
Cons
@futurekann bis zu 24h brauchen, damit ist kein Einsatz in Production zu empfehlen.- Um die Antwort des API Calls im Event unterzubekommen, sind viele LongText Felder entstanden. Vielleicht sind noch mehr nötig.