Springboard deepdive


Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Springboard deepdive

  1. 1. deep diveWednesday, September 8, 2010Phillip Cave
  2. 2. AgendaI. High-level technical overviewII. The what and why of SalesforceIII. Drupal modulesIV. Demo
  3. 3. High-level overviewI. History – from contrib to SpringboardII. Salesforce components – Custom objects, triggers, and fields – Workflow rules and field updates – Reports – Page layoutsIII. Drupal components – 15 modules (and counting) – Very loosely coupled – Batch processing architecture
  4. 4. SalesforceI. Development platform in the cloudII. Objects – Core and customIII. Apex – object oriented programming languageIV. Visual ForceV. Well documented APIVI. Upsert? WTF?
  5. 5. FundraiserI. Only module that doesn’t require SFII. Smoke and mirrors with webform and ubercart – Genetically modified webform
  6. 6. demo
  7. 7. FundraiserI. 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
  8. 8. Salesforce Management APII. Originally from contribII. 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
  9. 9. Queue APII. 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 heapII. Defines the schema for the entire queue system
  10. 10. Queue APII. 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
  11. 11. Queue ProcessorI. 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
  12. 12. Queue ProcessorI. 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
  13. 13. Queue ProcessorI. 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
  14. 14. 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
  15. 15. Queue Processor Heap Batch 1 Type: userUser upsert Batch 3 Action: upsert Type: nodeDonation upsert Action upsertNode upsert Sweet! 2 BatchUser upsert Type: donation Action: upsertWebformupsert Batch 4 Type: webformNode update Action: upsertUser updateUser update Batch 5 Type: nodeDonation upsert Action: updateUser delete Batch 6 Type: userDonation upsert Action: updateWebformupsert Batch 7 Type: userNode upsert Action: deleteUser updateNode update
  16. 16. Queue ProcessorI. 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
  17. 17. Queue ProcessorI. Reports – Batch history – Currently queued items – Retry queue – Permanent failures
  18. 18. Queue ProcessorI. Batch history – Insight into an individual batch
  19. 19. Queue ProcessorI. Currently queued items – Shows items that are currently in the queue – Will reset after every cron run – queue_report_item_title()
  20. 20. Queue ProcessorI. Retry queue – Where the bad boys go
  21. 21. Queue ProcessorI. Permanent failures – Where the really bad boys go
  22. 22. SF UserI. Drupal user integration module
  23. 23. SF NodeI. Node integration module – New!
  24. 24. SF Node ImportI. Complement to SF NodeII. Define criteria for selecting objects in SalesforceIII. Can update or create new nodes in DrupalIV. Requires defined fieldmap
  25. 25. SF DonationI. Donation integration module
  26. 26. SF WebformI. Webform integration module
  27. 27. Webform UserI. Worst module name in history (thanks Tom)II. Free beer to whoever comes up with a better nameIII. Adds account and profile fields to webformIV. Optionally relates the created object to a Salesforce account or contact
  28. 28. And the othersI. Market Source – Pure wizardryII. Capwiz – More wizardryIII. Webform reorder? – Brock?
  29. 29. DemoI. Arcade game high-score app – Salesforce objects • Contact • High-score – Drupal entities • User • High-score webform
  30. 30. Questions This is great! How can I get started?