Ontwikkelen zonder locale servers of software

We kennen Salesforce.com vooral van hun CRM-product, opgebouwd rond het Apex platform dat in oktober van vorig jaar het licht zag. Dit laat toe dat je er allerlei maatwerk aan toevoegt, om bijvoorbeeld connecties te maken met lokale databases, om de samenwerking tussen medewerkers anders te organiseren en te stroomlijnen, om een eigen gebruiksinterface met speciale formulieren en andere interacties te ontwerpen, of zelfs een Web Services API voor programmatorische toegang en integratie ter beschikking te stellen..

Recent maakt Salesforce.com nogal wat rumoer rond de in de steigers staande Apex Code, een manier om code te schrijven die exclusief uitgevoerd wordt op hun servers. Daardoor ontstaat de mogelijkheid om een nieuwe klasse applicaties en functies te ontwerpen die volledig op aanvraag ontplooid kunnen worden. Denken we maar aan complexe vormen van inventariscontrole of de afhandeling van bestellingen. In tegenstelling tot andere programmeertalen als C++, Java of .NET is Apex Code veel beperkter in draagwijdte. De ‘klassiekers’ laten zowat alle soorten ontwikkelingen toe, van videospelletjes tot commerciële toepassingen. Dat is niet het geval bij deze technologie, die enkel tot haar recht komt binnen de grotere context van het Apex platform.

Een belangrijk voordeel is dat de ontwikkelaar zich kan concentreren op het realiseren van het gewenste proces in samenspraak met de gepaste data, zonder zich bezig te houden met de ‘loodgieterij’ die het gebruik van de achterliggende infrastructuur met zich mee brengt. Vergelijk het met een taal als Java. Die maakt gebruik van zoveel mogelijk systeemresources als de onderliggende hardware kan ondersteunen. Apex Code, daarentegen, gebruikt enkel zoveel resources als toegelaten is. Dat wordt bereikt door een bijkomende abstractielaag die de uitvoering van een bepaalde, in Apex Code geschreven component, onder controle houdt. En die controle mag je in de meest ruime zin van het woord interpreteren: het totaal aantal uitgestuurde queries, de hoeveelheid opgevraagde data, het aantal uitgevoerde gegevensbewerkingen en transacties, het aantal controlestructuren (lussen, iteraties en dergelijke) enzovoort. Alles wordt permanent in de gaten gehouden en desnoods aan banden gelegd.

De code zélf focust in de eerste plaats op het uitdrukken van zakelijke logica en het manipuleren van gegevens. De gebruikersinterface en de interactie daarmee verdwijnen naar de achtergrond. Conceptueel leunt de code dus dichter aan bij de stored procedures talen van traditionele databaseomgevingen als PL/SQL of Transact-SQL. Maar in tegenstelling tot die laatste, die vaak een zware en moeilijk te gebruiken erfenis van neerwaartse compatibiliteit meetorsen, gebruikt Apex Code eerder een Java-achtige syntax, en is het een streng getypeerde taal. De code moet gecompileerd worden door de ontwikkelaar vooraleer ze kan worden uitgevoerd, en tijdens die compilatieslag moeten variabelen geassocieerd worden met specifi eke objecttypes.

CODE SCHRIJVEN
Apex Code schrijven kan in drie omgevingen: in een simpele tekstverwerker (stijl Notepad), in de webinterface van het Apex platform (als een trigger achter een standaard, een maatwerkobject, of als een package), of door gebruik te maken van de Apex Toolkit for Eclipse, een plugin voor het gelijknamige openbron ontwikkelingsplatform. De plugin biedt kleurcodering, een outline zicht, geïntegreerde unittesten en een automatische compilatie, plus het tonen van de nodige foutberichten bij het bewaren.

Codering via het platform sluit nauwer aan bij de essentie van deze taal, die we in de eerste plaats gebruikt zien worden om het standaardgedrag van de Salesforce.com omgeving aan te passen of uit te breiden: de werking van bestaande knoppen veranderen, er nieuwe aan toevoegen, de controle van een link of van een gegevenslijst beïnvloeden of overnemen enzovoort. Denken we maar aan een applicatie die bij het toevoegen van een commerciële lead aan de CRM-database eerst gaat controleren of er al iemand met een zelfde of gelijkende naam in de database zit, en desgevallend een procedure opstart om de datakwaliteit te verbeteren. Elke methode die in een package gedefi nieerd is, kan optioneel ter beschikking worden gesteld als een web service, en op die manier opgeroepen via de Web Service API of rechtstreeks door de AJAX toolkit. En omdat de code op de Salesforce. com servers draait, hoeft men geen rekening te houden met schaalbaarheid, compatibiliteit of onderhoud.

Dat de CRM-producent gelooft in zijn Apex platform blijkt uit de talrijke initiatieven die de voorbije maanden op de rails gezet werden, te beginnen met het Developer Preview Program. Hopelijk ontwikkelt zich dit tot méér dan een meetpunt voor het marktpotentieel, waaruit dan louter de initiële prijsstelling moet volgen. Bovendien bindt een bedrijf dat zijn ontwikkelingen inbedt in de Salesforce.com omgeving zich uiteraard met handen en voeten aan deze leverancier vast. En wat houdt die tegen om na een tijdje en/of bij uitvoerig gebruik van een succesvolle ontwikkeling de prijs de hoogte in te jagen? Wij behouden in ieder geval de nodige scepsis…