Notional architecture: Difference between revisions
| Line 19: | Line 19: | ||
The diagram above depicts how the data layer components relate to each other. They all extend from the API abstract class, which includes methods from the Salesforce.com AJAX toolkit. | The diagram above depicts how the data layer components relate to each other. They all extend from the API abstract class, which includes methods from the Salesforce.com AJAX toolkit. | ||
To facilitate bidirectional use of the Salesforce.com API, the BidirectionalAPI extension of API implements an event notification system and periodic polling | |||
Work in progress... | |||
A general write-back flag is included to tell an API implementer to return as quickly as possible and update its backing store later instead of synchronously. The cache object will use the write-back flag to signal offline mode so that changes are logged for an eventual commit to Salesforce.com. When write-back is off, write-through caching is implemented in the cache. | A general write-back flag is included to tell an API implementer to return as quickly as possible and update its backing store later instead of synchronously. The cache object will use the write-back flag to signal offline mode so that changes are logged for an eventual commit to Salesforce.com. When write-back is off, write-through caching is implemented in the cache. | ||
Updates that are routed through the cache will cause the cache to signal an immediate update to the registered listeners. Before committing that change, however, the objects being updated are queried to see if any have changed in a conflicting way. If that is the case, then an exception is thrown with an appropriate error message so that the user will know that a change conflicted with their action and that the current states of Thunderforce for the conflicting objects are now consistent with Salesforce.com. If the change does not conflict, the record is updated and an immediate background data refresh is triggered to account for changes to formula fields and Apex triggers, etc. Listeners are notified of the data change from the cache. When the changes come back from the server, the changes that were already in the cache are not propagated back to listeners. | Updates that are routed through the cache will cause the cache to signal an immediate update to the registered listeners. Before committing that change, however, the objects being updated are queried to see if any have changed in a conflicting way. If that is the case, then an exception is thrown with an appropriate error message so that the user will know that a change conflicted with their action and that the current states of Thunderforce for the conflicting objects are now consistent with Salesforce.com. If the change does not conflict, the record is updated and an immediate background data refresh is triggered to account for changes to formula fields and Apex triggers, etc. Listeners are notified of the data change from the cache. When the changes come back from the server, the changes that were already in the cache are not propagated back to listeners. | ||
Revision as of 05:16, 17 June 2007
This page includes the details of the notional architecture.
Deployment View
Runtime View
The arrows in this diagram indicate the direction of Salesforce.com data flow, excluding control information.
Module View
Package thunderforce.sforce
The diagram above depicts how the data layer components relate to each other. They all extend from the API abstract class, which includes methods from the Salesforce.com AJAX toolkit.
To facilitate bidirectional use of the Salesforce.com API, the BidirectionalAPI extension of API implements an event notification system and periodic polling
Work in progress...
A general write-back flag is included to tell an API implementer to return as quickly as possible and update its backing store later instead of synchronously. The cache object will use the write-back flag to signal offline mode so that changes are logged for an eventual commit to Salesforce.com. When write-back is off, write-through caching is implemented in the cache.
Updates that are routed through the cache will cause the cache to signal an immediate update to the registered listeners. Before committing that change, however, the objects being updated are queried to see if any have changed in a conflicting way. If that is the case, then an exception is thrown with an appropriate error message so that the user will know that a change conflicted with their action and that the current states of Thunderforce for the conflicting objects are now consistent with Salesforce.com. If the change does not conflict, the record is updated and an immediate background data refresh is triggered to account for changes to formula fields and Apex triggers, etc. Listeners are notified of the data change from the cache. When the changes come back from the server, the changes that were already in the cache are not propagated back to listeners.