| Tweet |
Building my own Learning System - Part 3
Introduction
In Part 1 of this blog series I covered the problem I was trying to solve (on-boarding/accrediting internal and external users with the same content, but without opening up all my content to everyone) and the data model to support this. Part 2 covered the user interface and a faker to allow me to check that my idea had legs without building the whole thing - if I’m going to fail, I like to get it over with as quickly as possible. This wasn’t the case though, so I then proceeded to build out the backend.
There are any number of ways to implement the backend, both on Salesforce and elsewhere. As I’ve created an Apex interface that the front end works against, any mechanism can be supported simply by creating a new implementation of the interface that knows how to talk tot the remote endpoint. For the purposed of my sample implementation I went with e REST endpoint surfaced via a Force.com site, as this means I don’t have to worry about authentication, can focus on the business problem and can easily use hurl.it to test. As to whether this is appropriate for a real training endpoint is a topic for discussion - it depends on how sensitive the information is and whether there is any issue with someone getting hold of it. I decide for each endpoint based on these and other factors.
REST API
Again in the interests of simplicity, I went with a REST API that exposes a single POST method that acts as a dispatcher. The body of the request contains the underlying “method” that should be invoked, and any parameters required for that method. While this might not please the purists, as I don’t have an endpoint per object, I didn’t want to have to create a new Apex class to implement each method that I added, especially for a sample implementation.
The API implements much the same interface as my faker, but with additional parameters to identify the candidate taking the training. As I’m not using authentication, I identify users by their email address. Note that this is about identification rather than authentication or authorisation, as anyone can choose any email address.
Client
The client makes use of a new implementation of the same API as the faker, that simply sends a request to the remote REST API. As I want to support multiple endpoints, these are configured via a custom metadata type in the client org. This means that a user has a number of training histories and badge totals, one per endpoint,
In my sample REST API, the training step details are retrieved from rich text area fields on sObjects. Any images that have been added via the rich text editor will be returned with a relative URL which will obviously point to nothing in the client org. To fix this, the custom metadata for an endpoint has a checkbox to indicate if images should be rewritten. If this is checked then the endpoint hostname is prepended to the image links, which works a treat.
As nothing is now stored in the client org, a user can install the training metadata components in any Salesforce org and, as long as they reuse the same email address that they’ve previously taken training with and configure the endpoints appropriately, they can pick up where they left off. This was a key feature for me as I really didn’t want to have to install the training paths along with the client software, as it makes things must more resistant to change.
That’s it for part 3 - in part 4 I’ll go through the installation and configuration and, all things being equal, share the code too.
No comments:
Post a Comment