Software components
The software architecture of Apsona for Salesforce consists of- A browser component, consisting of the user interface layer and a data transport layer
- A server component, consisting of two simple VisualForce pages and one custom object.
The browser component. The browser component displays the user interface within the salesforce.com window, and manages all the user interactions. When necessary, it interacts with the data transport layer, which in turn uses salesforce.com's Apex API to communicate with the server. The browser component uses pure HTML, JavaScript, CSS (Cascading Style Sheets) and Ajax techniques for its display, and does not rely on any plugins.
Server components. On the server side, Apsona for Salesforce uses the salesforce.com's native VisualForce technology. It comprises:
- A main VisualForce page that displays the Apsona for Salesforce user interface embedded within a salesforce.com tab.
- A secondary VisualForce page for exporting data in CSV format, since the only way to deliver a particular non-HTML content-type (such as CSV) is via a server-side component.
- A single custom object that maintains information specific to Apsona for Salesforce, such as filters, reports, page layouts and user preferences.
Data access
Apsona for Salesforce relies heavily on the metadata API (describeGlobal and describeSObjects) provided by salesforce.com. This API includes information about what fields are accessible to and modifiable by the current user. This means that all of the profile information and access rights configured for the user are automatically inherited when the user accesses data via Apsona for Salesforce. In other words, the data and access rights available to the user via Apsona for Salesforce are exactly the same as those available directly via salesforce.com's native user interface. The user experience, however, is better (in our opinion).Software delivery
Our software is structured to deliver the browser-side components from our servers whenever the browser needs them, i.e., at the very moment when the browser requests the Apsona for Salesforce tab from salesforce.com. This architecture offers several benefits:- We can deliver bug fixes and updates rapidly, since we can deploy fixes on our server and have them take effect immediately for our users.
- We can customize the look, feel and functionality of the software to the needs of specific users and organizations.
- Users need not be concerned about updating their versions of the software - it is done automatically.
Technology platform
The core of our offering is a web application UI platform that constructs a rich Ajax-based user interface entirely based on metadata (i.e., descriptions of the objects such as their names, labels, field names and types). Our platform produces a user interface that addresses the most common data management use cases for web applications, such as the standard CRUD operations, import, export, reporting and analytics facilities. The metadata-driven architecture enables it to fully implement strong data validation at the individual field level (such as dates, phone numbers, email addresses, currencies and pick lists) as well as reference fields across multiple metadata objects. In addition, it exploits the reference field descriptions across the metadata objects to produce desirable features such as smart querying, filtering with arbitrary many terms, reporting with multiple visualizations (lists, charts, pivots, and the like), child tabs, calendar views based on arbitrary dates, and lookup of cross-object references when importing or exporting data. The user interface also offers commonly-sought benefits such as retention of context, high responsiveness, lack of screen refresh, and a pleasing look and feel.A large part of the platform is coded in JavaScript. It can run mostly in the browser, but we have also successfully deployed critical parts of it on the server side via the Rhino JavaScript engine for Java.
Because of its reliance on metadata, the platform can be configured for almost any existing web application. Integrating it into a new application is a matter of creating two components: the metadata description in JSON, and a data service object that can talk to the back end service for the application. In the case of salesforce.com, we are able to offer a similar integration. We rely on the metadata API (describeGlobal and describeSObjects) to dynamically create the metadata description for consumption by the platform. We have created a data service object as a wrapper around the sforce.connection object included in the AJAX API. This architecture enables us to defer to salesforce.com's metadata API for field-level access information (for data validation) and user security information (e.g., that a certain field is read-only or inaccessible for a certain user).