9 hordes bij het ontwikkelen van Salesforce Sites

Iedere Salesforce ontwikkelaar die op een goede dag begint aan het ontwikkelen van een site, zal tegen een aantal beperkingen aanlopen die hij wellicht niet had verwacht. In deze blog neem ik je mee langs een aantal van die hordes.
Met een site ontsluit je Salesforce voor gebruikers zonder licentie. Zo kun je geld besparen door gebruikers die slechts beperkte toegang tot jouw Salesforce organisatie nodig hebben, geen licentie te geven, maar een site.

Horde 1: De gastgebruiker van site is geen gewone gebruiker

Het belangrijkste om te begrijpen als je een site gaat bouwen, is dat je te maken hebt met een site-specifieke gebruiker, een gastgebruiker van site. Deze gastgebruiker van site komt niet voor in je lijst met normale gebruikers, heeft geen gebruikersnaam en wachtwoord, en je kunt de gastgebruiker dus ook niet gebruiken om in te loggen op Salesforce. Op het moment dat je jouw site bezoekt, zal alle interactie met Salesforce gebeuren op naam van de gastgebruiker van site. Pas je een record aan, dan zal de gastgebruiker van site zichtbaar zijn als degene die het record als laatst heeft aangepast. De gastgebruiker van site is niet te herleiden naar een natuurlijk persoon.

Horde 2: Het profiel van de gastgebruiker vraagt extra aandacht

Het ligt dan ook voor de hand om de gastgebruiker van site zo weinig mogelijk rechten te geven. De gastgebruiker van site heeft daarom zijn eigen, unieke, niet aan andere gebruikers toewijsbare profiel. Je vindt het profiel niet bij de profielen voor de normale Salesforce gebruikers, maar via de knop “Instellingen voor openbare toegang” in de Sitedetails. Geef in dat profiel niet meer dan de hoogst noodzakelijke rechten.

Horde 3: Een gastgebruiker van site kan geen standaardobjecten bewerken of verwijderen

Je kunt de gastgebruiker van site alle soorten rechten geven op custom objecten. Dat geldt niet voor standaard objecten. Accounts kun je wel lezen en maken via site, maar niet bewerken. In onderstaand screenshot zie je een deel van de standaardobjecten met hun mogelijkheden voor de gastgebruiker.

Horde 4: Soms zijn ingewikkelde constructies onvermijdelijk

Wil je bijvoorbeeld dat jouw klanten kunnen inloggen en hun eigen account kunnen bewerken? Dan is het eerste waar je aan zou moeten denken om je klant een (community) licentie te geven. Wil je dit niet, dan is een apart object met een lookup naar account wellicht een optie. Voldoet ook deze oplossing niet, dan zijn er twee manieren om vanuit site een account te bewerken of verwijderen:

1. Schrijf de updates die je klant op zijn account moet doen, weg in een apart object en laat een Batch class dit object uitlezen en verwerken. Een batch class wordt uitgevoerd in de context van een echte Salesforce user en die wel accounts kan bewerken.
2. Gebruik een e-mailhandler. Verstuur vanaf de site een e-mail, waar je de wijzigingen op account in de body zet. De e-mailhandler verwerkt deze e-mail als een bepaalde Salesforce gebruiker en kan dus ook het account updaten.

Horde 5: E-mailen vanaf een site moet met een bijzonder e-mailadres

Over e-mailen gesproken: als je e-mailt vanuit een site, krijgt de ontvanger een e-mail van “sitenaam gastgebruiker van site”. Dat kan natuurlijk een stuk netter. De enige manier hiervoor is het aanmaken van een “E-mailadres voor de gehele organisatie”. Zo’n e-mailadres kan worden gebruikt door een selectie van profielen. Omdat de gastgebruiker van site profiel geen standaard profiel is, is deze niet beschikbaar voor deze keuze. Je moet het e-mailadres beschikbaar maken voor “Alle profielen”, zodat ook jouw gastgebruiker van site dit e-mailadres kan gebruiken.

Horde 6: Sitepagina’s testen kan niet goed op de standaardmanier

Als Salesforce ontwikkelaar gebruik ik Illuminated Cloud. Hiermee kan ik bij het bewerken van een pagina op een icoontje van een webbrowser klikken om de pagina in die browser te openen. Ik word dan bijvoorbeeld naar https://docg-dev-ed–docg.eu10.visual.force.com/apex/HelloWorld geleid. Op dat moment ben ik ingelogd als Salesforce gebruiker, met mijn eigen rechten op objecten, velden en pagina’s (als jij nu op die link klikt, wordt je gevraagd in te loggen). Bij het ontwikkelen van sites wil je altijd testen in de context van de site: https://growteq-developer-edition.eu10.force.com/blog . Je ziet in deze url de domeinnaam terug die is ingesteld onder “Mijn domein”. Via deze url benader je de pagina als gastgebruiker van site, met zijn eigen specifieke rechten en beperkingen: precies wat je wilt als je goed wilt testen.

Horde 7: Foutopsporingslogboeken activeren vraagt extra werk

Als tester kom je dan bij de volgende kleine uitdaging: waar haal je je debug logs vandaan? Onder “Foutopsporingslogboeken” creëer je een nieuwe traceringsvlag voor “Blog Gastgebruiker van site” (mijn site heb ik ‘blog’ genoemd). In de sectie Foutopsporingslogboeken vind je de logboeken terug. Een traceringsvlag is beperkt geldig en moet dagelijks vernieuwd worden als je de logboeken wilt blijven bekijken.

Horde 8: Visualforce debuggen kan moeizaam zijn

Als er iets fout gaat in je controller, vind je in de logboeken de exceptions terug. Soms kun je helemaal niets met zo’n logboek: er staat dan alleen in dat er een authenticatiefout is opgetreden. Meestal moet je de oplossing dan in de visualforcepagina zoeken. Als je in apex een collectie niet hebt geïnitialiseerd krijg je een nette nullpointer exception. Maar als je in visualforce met een apex:repeat een null-waarde wilt gaan uitlezen, krijg je een scherm te zien met de mededeling dat je moet inloggen. Het logboek vertelt je hetzelfde. Mijn aanpak is om dan hele blokken visualforce te verwijderen tot ik de plek heb geïsoleerd waar de foutmelding door veroorzaakt wordt.

Horde 9: Url-parameters kunnen verdwijnen

Ik wil nog één punt aanstippen: het gebruik van parameters in de url. Een bedrijf stuurde e-mails uit naar klanten met een link waarop zij konden klikken om een Salesforce site openen. De url bevatte twee parameters, die beide belangrijk waren om de pagina überhaupt te kunnen zien. De eerste was het accountId, de tweede een accesstoken die beperkt geldig was. In de pagina maakte ik gebruik van actionFunctions in combinatie met een reRender. Om het herladen van de pagina te voorkomen sloot de apex-functie af met return null;. Op dat moment verdween de tweede parameter uit de url. Nu was de viewstate nog intact en leverde dat niet direct problemen op, maar je kunt je voorstellen dat de gebruiker raar opkeek toen hij de url kopieerde en in een ander tabblad plakte en de melding kreeg dat de url niet geldig was. Ik het opgelost door het bij één parameter te houden en daarin de accountId en accesstoken gescheiden door een ‘-’ op te nemen.

Tot slot

Er valt nog veel meer te schrijven over het ontwikkelen van pagina’s, componenten en site en wat je daarbij allemaal aan hordes kunt tegenkomen. Hopelijk heb je met deze blog een goed beeld gekregen van de top 9 hordes.