Shoreforce*

Lightning Workbench: Salesforce API Access via Lightning Component

Christian Szandor Knapp -

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:

Pros

  • Keine Abhängigkeiten zu externen Bibliotheken
  • Keine Connected App / Named Credential / Remote Site Setting
  • Kein Visualforce
  • Keine Einflußnahme auf SessionId

Cons

  • @future kann 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.

Code

https://github.com/Szandor72/LightningWorkbench