Presentation given to internal developers about the technical details of Springboard.

1. deep dive
Wednesday, September 8, 2010
Phillip Cave

2. Agenda
I. High-level technical overview
II. The what and why of Salesforce
III. Drupal modules
IV. Demo

3. High-level overview
I. History – from contrib to Springboard
II. Salesforce components
– Custom objects, triggers, and fields
– Workflow rules and field updates
– Reports
– Page layouts
III. Drupal components
– 15 modules (and counting)
– Very loosely coupled
– Batch processing architecture

4. Salesforce
I. Development platform in the cloud
II. Objects
– Core and custom
III. Apex – object oriented programming
language
IV. Visual Force
V. Well documented API
VI. Upsert? WTF?

6. Fundraiser
I. Only module that doesn’t require SF
II. Smoke and mirrors with webform and
ubercart
– Genetically modified
webform

7. demo

8. Fundraiser
I. Supports one-time and recurring
donations
– Tracks when future donations should be charged
– Processing occurs during cron runs
– One order id to rule them all

9. Salesforce Management API
I. Originally from contrib
II. Wrapper for the Salesforce PHP toolkit
– SOAP based
– Utilizes enterprise WSDL (also a partner WSDL)
III. Controls
– Fieldmaps (mostly)
– Business rules
– Connection settings
– Object mapping

10. Queue API
I. Not very robust at the moment
– Currently has 1 function (sf_queue_insert)
– Determines if the object:
• Is already in the queue
• Is in the retry queue
• Is a permanent failure
• Is on the heap
II. Defines the schema for the entire queue
system

11. Queue API
I. Why queue
– Accountability
• Can get a peek into what is happening at any given time
• Better control over when things get processed
– Robust
• Salesforce maintenance windows
• Ability to take advantage of Batch API
– Reporting
• Batch history
• Queues (current, retry, and permanent failures)
II. Downside
– Upserts cannot take fieldmap rules into consideration

12. Queue Processor
I. Original vision
Import Service
User
Queue Processor
Import Service Start
Node Fieldmap assign
Pre-process
Import Service Global Queue
Send
Donation
Post-process
Import Service
Webform
Fieldmaps
Salesforce Management API Rules

13. Queue Processor
I. Settings
– Processing order: Specifies the order in which Drupal entities are
processed
– Maximum items per cron run: Specifies how many items should
be processed per cron run (default 1,000)
– Batch size: Maximum number of items to include in a batch
(default 200)
– Maximum retry attempt: The number of times an entity will be
retried before being marked as a permanent failure (default 3)
– Email summary: The email addresses that will receive a
summary of batches processed after each cron run

14. Queue Processor
I. Available triggers
– A connection to Salesforce cannot be established
– An object fails to export to Salesforce
– An object is moved to the retry queue
– An object becomes a permanent failure
– A SOAP fault occurs

15. Queue Processor
yes
Lock queue items Get all locked items EOF? Process heap
no
What yes
Fieldmap
no
Assign fieldmap
assigned?
happens yes
when
In heap?
cron
no
runs Add to heap

16. Queue Processor
Heap Batch 1
Type: user
User upsert Batch 3 Action: upsert
Type: node
Donation upsert Action upsert
Node upsert Sweet! 2
Batch
User upsert Type: donation
Action: upsert
Webformupsert
Batch 4
Type: webform
Node update Action: upsert
User update
User update Batch 5
Type: node
Donation upsert
Action: update
User delete Batch 6
Type: user
Donation upsert Action: update
Webformupsert Batch 7
Type: user
Node upsert Action: delete
User update
Node update

17. Queue Processor
I. Hooks
– hook_queue_fieldmap_assignment_alter()
• Allows a module to assign a fieldmap to an item in the queue before it is
placed in the heap
– hook_queue_preprocess_batch_alter()
• Alter the entire batch – object building happens here
– hook_queue_batch_item_alter()
• Alter an individual item in the batch (last ditch effort)
– hook_queue_postprocess_batch()
• Modules can further process the data after the calls to Salesforce
– hook_queue_salesforce_info()
• Allows a module to expose it’s own fieldmap and dedupe schema

18. Queue Processor
I. Reports
– Batch history
– Currently queued items
– Retry queue
– Permanent failures

19. Queue Processor
I. Batch history
– Insight into an individual batch

20. Queue Processor
I. Currently queued items
– Shows items that are currently in the queue
– Will reset after every cron run
– queue_report_item_title()

21. Queue Processor
I. Retry queue
– Where the bad boys go

22. Queue Processor
I. Permanent failures
– Where the really bad boys go

23. SF User
I. Drupal user integration module

24. SF Node
I. Node integration module
– New!

25. SF Node Import
I. Complement to SF Node
II. Define criteria for selecting objects in
Salesforce
III. Can update or create new nodes in
Drupal
IV. Requires defined fieldmap

26. SF Donation
I. Donation integration module

27. SF Webform
I. Webform integration module

28. Webform User
I. Worst module name in history (thanks
Tom)
II. Free beer to whoever comes up with a
better name
III. Adds account and profile fields to
webform
IV. Optionally relates the created object to a
Salesforce account or contact

29. And the others
I. Market Source
– Pure wizardry
II. Capwiz
– More wizardry
III. Webform reorder?
– Brock?

30. Demo
I. Arcade game high-score app
– Salesforce objects
• Contact
• High-score
– Drupal entities
• User
• High-score webform

31. Questions
This is great! How can I get
started?