Springboard deepdive

Preview:

DESCRIPTION

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

Citation preview

deep dive

Wednesday, September 8, 2010Phillip Cave

I. High-level technical overview

II. The what and why of Salesforce

III. Drupal modules

IV. Demo

Agenda

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

High-level overview

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?

Salesforce

I. Only module that doesn’t require SF

II. Smoke and mirrors with webform and ubercart

– Genetically modified webform

Fundraiser

demo

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

Fundraiser

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

Salesforce Management 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

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

Queue API

I. Original vision

Queue Processor

User

Node

Donation

Webform

Salesforce Management APIFieldmaps

Rules

Queue Processor

Global Queue

Start

Fieldmap assign

Pre-process

Send

Post-process

Import Service

Import Service

Import Service

Import Service

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

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

Queue Processor

Queue Processor

EOF?

Assign fieldmapFieldmap assigned?

In heap?

Lock queue items Get all locked items Process heap

Add to heap

yes

no

yes

no

yes

noWhat happenswhencronruns

Userupsert

Webform upsert

Nodeupdate

Userupdate

Userupdate

Donation upsert

Userdelete

Donation upsert

Webform upsert

Nodeupsert

Userupdate

Nodeupdate

Userupsert

Donation upsert

Nodeupsert

Batch 1Type: userAction: upsert

Batch 2Type: donationAction: upsert

Batch 3Type: nodeAction upsert

Batch 4Type: webformAction: upsert

Batch 5Type: nodeAction: update

Batch 6Type: userAction: update

Batch 7Type: userAction: delete

Queue ProcessorHeap

Sweet!

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

Queue Processor

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

Queue Processor

I. Batch history– Insight into an individual batch

Queue Processor

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

Queue Processor

I. Retry queue– Where the bad boys go

Queue Processor

I. Permanent failures– Where the really bad boys go

Queue Processor

I. Drupal user integration module

SF User

I. Node integration module– New!

SF Node

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

SF Node Import

I. Donation integration module

SF Donation

I. Webform integration module

SF Webform

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

Webform User

I. Market Source– Pure wizardry

II. Capwiz– More wizardry

III. Webform reorder?– Brock?

And the others

I. Arcade game high-score app– Salesforce objects

• Contact• High-score

– Drupal entities• User• High-score webform

Demo

This is great! How can I get started?

Questions