Dean Thrasher - Behind the Paywall - SUGCON
•Download as PPTX, PDF•
1 like•331 views
A working example of how to leverage Salesforce CRM and Sitecore to create a functioning paywall for members-only website content. I outline the key features of the system, describe lessons learned, and share a few horror stories.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Dean Thrasher - Behind the Paywall - SUGCON
Similar to Dean Thrasher - Behind the Paywall - SUGCON (20)
Recently uploaded
Recently uploaded (20)
Dean Thrasher - Behind the Paywall - SUGCON
- 1. Organized by the Community, for the Community. BEYOND CRM INTEGRATION: SALESFORCE AS CONTENT GATEKEEPER ON SITECORE 7+ DeanThrasher
- 2. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 2 #BEHINDTHEPAYWALL
- 3. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 3 INTRODUCTION
- 4. Organized by the Community, for the Community. ABOUT DEANTHRASHER Email: Dean_Thrasher@epam.com Twitter: @dthrasher Linked in: https://www.linkedin.com/in/ deanthrasher
- 5. Organized by the Community, for the Community. ABOUT DEANTHRASHER • Working with Sitecore for 5 years – Using Sitecore versions 5, 6, 7 and 8 • .NET web development for 15 years – ASP, ASP.NET WebForms, ASP.NET MVC • Background in RM, DM, DAM,WCM, ECM • Began working with Salesforce 18 months ago SUGCON NORTH AMERICA 2015 5
- 6. Organized by the Community, for the Community. ABOUTTHE COMPANY SUGCON NORTH AMERICA 2015 6
- 7. Organized by the Community, for the Community. SITECORE PRACTICE HIGHLIGHTS 90+ Delivered Projects 150+ Experienced Professionals 14x Accolades Recognized • Digital Strategists • Solution Architects • Sitecore Developers • Visual Designers • QA Engineers • Business Analysts • Usability Experts • Support Specialists • Project Managers 8+ Years of Successful Delivery 50+ Customers 4x 4x
- 8. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 8 BACKGROUND
- 9. Organized by the Community, for the Community. THE CLIENT StratasAdvisors http://stratasadvisors.com SUGCON NORTH AMERICA 2015 9
- 10. Organized by the Community, for the Community. INTERACTIVE DATA TOOLS Presenting dynamic, interactive data SUGCON NORTH AMERICA 2015 10
- 11. Organized by the Community, for the Community. INTERACTIVE MAPS Presenting geospatial data SUGCON NORTH AMERICA 2015 11
- 12. Organized by the Community, for the Community. THE SOLUTION SUGCON NORTH AMERICA 2015 12
- 13. Organized by the Community, for the Community. THE BUILDING BLOCKS: SITECORE • Manages public and members-only content • Handles user authentication and authorization • Allows users to update and reset passwords • Allows users to manage profile information and newsletter subscriptions SUGCON NORTH AMERICA 2015 13
- 14. Organized by the Community, for the Community. THE BUILDING BLOCKS: SALESFORCE • Receives leads from the site • Manages accounts and contacts • Defines available product subscriptions • Determines which accounts and contacts have which products, and whether those subscriptions are still active SUGCON NORTH AMERICA 2015 14
- 15. Organized by the Community, for the Community. THE PUBLIC SITE SUGCON NORTH AMERICA 2015 15
- 16. Organized by the Community, for the Community. THE MEMBER DASHBOARD SUGCON NORTH AMERICA 2015 16
- 17. Organized by the Community, for the Community. THE ACCOUNT PROFILE SUGCON NORTH AMERICA 2015 17
- 18. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 18 REQUIREMENTS
- 19. Organized by the Community, for the Community. PRODUCTS AND SUBSCRIPTIONS • More than 165 distinct products offered • Products are often bundled together • Site content can be targeted to multiple products • Subscriptions are offered to corporate accounts • Subscriptions expire after a period of time SUGCON NORTH AMERICA 2015 19
- 20. Organized by the Community, for the Community. SITE USERS • Anonymous users, or visitors • Site members – Prospects (no active subscriptions, see preview content) – Subscribers (have an active subscription) SUGCON NORTH AMERICA 2015 20
- 21. Organized by the Community, for the Community. ACCOUNTS, CONTACTS AND LEADS • Accounts have contacts • Accounts have subscriptions • A contact inherits its subscriptions from the account to which it belongs • Contacts may be granted access to log in to the site • Leads are generated from the website • Leads may be converted into contacts later on • Leads are not allowed to log in to the site SUGCON NORTH AMERICA 2015 21
- 22. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 22 HOW WE DID IT
- 23. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 23 SALESFORCE
- 24. Organized by the Community, for the Community. WHICH SALESFORCE EDITON? • Salesforce has different pricing tiers, offering different features and limits. • You will need at least the Enterprise edition to be able to use the web service APIs • Make sure you know the number of Salesforce users you have available in your instance • Make sure you know how many and what kinds of Salesforce Sandboxes are available to you SUGCON NORTH AMERICA 2015 24
- 25. Organized by the Community, for the Community. WHICH SALESFORCE API? • Salesforce has 10 differentAPIs! • Force.com: REST API vs. SOAP API • If SOAP, whichWSDL? • Force.com Enterprise WSDL SUGCON NORTH AMERICA 2015 25
- 26. Organized by the Community, for the Community. SALESFORCE DATA MODEL: SALES OBJECTS SUGCON NORTH AMERICA 2015 26
- 27. Organized by the Community, for the Community. SALESFORCE DATA MODEL: PRODUCT OBJECTS SUGCON NORTH AMERICA 2015 27
- 28. Organized by the Community, for the Community. CUSTOM SALESFORCE FIELDS • Contact – Contact type – Website access – Sitecore username – Sitecore password • Asset – Subscription start date – Subscription end date SUGCON NORTH AMERICA 2015 28
- 29. Organized by the Community, for the Community. SALESFORCE SANDBOX • Don’t develop or test against a production instance! • The type of sandbox determines: – The amount of data you can have – How often you can refresh – What objects get populated SUGCON NORTH AMERICA 2015 29
- 30. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 30 HORROR STORY #1: KNOWYOUR LIMITS
- 31. Organized by the Community, for the Community. SALESFORCE API LIMITS • You can make a set number of API requests within a 24-hour period. • This limit depends on Salesforce edition and the number of licensed users. • The API limits are different for sandboxes and production instances. • The API limits apply to all integrations and applications that communicate with an instance. • Beware of usage spikes! SUGCON NORTH AMERICA 2015 31
- 32. Organized by the Community, for the Community. WEB SERVICE STYLE GUIDE • Prefer “chunky” over “chatty” web services • Request data in batches • Cache the information you receive • Check request usage against API limits and determine when you’ve had enough • Design your application to survive an API blackout or other service interruption SUGCON NORTH AMERICA 2015 32
- 33. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 33 SITECORE
- 34. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 34 CACHING
- 35. Organized by the Community, for the Community. CACHING USER DATA • Logins and page views should be fast, so we want to avoid calling Salesforce web services when we can • Salesforce determines who can log in and what they can see, but Sitecore enforces this policy • Sitecore can then act as an SSO or claims-based authentication mechanism for other web properties SUGCON NORTH AMERICA 2015 35
- 36. Organized by the Community, for the Community. USER PROFILE CUSTOMIZATION SUGCON NORTH AMERICA 2015 36
- 37. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 37 HORROR STORY #2: ESCAPING THE SANDBOX
- 38. Organized by the Community, for the Community. KEEPYOUR SANDBOXTIDY • Your non-production Sitecore instances will need to communicate with a Salesforce Sandbox • The Sandbox should have a reasonable approximation of production data • Don’t put real customer email addresses in the Sandbox! • Have checks on both the Sitecore and Salesforce side to prevent tests from triggering email, alerts, notifications, and workflow SUGCON NORTH AMERICA 2015 38
- 39. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 39 SECURITY
- 40. Organized by the Community, for the Community. HYBRID SECURITY MODEL 1. Sitecore enforces login for members- only sections of the site 2. Custom code determines who is a subscriber SUGCON NORTH AMERICA 2015 40
- 41. Organized by the Community, for the Community. ENFORCING SITECORE LOGIN SUGCON NORTH AMERICA 2015 41
- 42. Organized by the Community, for the Community. PRODUCT CODETAGS SUGCON NORTH AMERICA 2015 42
- 43. Organized by the Community, for the Community. PRODUCT CODES APPLIEDTO PAGES SUGCON NORTH AMERICA 2015 43
- 44. Organized by the Community, for the Community. PRODUCT CODES AS USER ROLES SUGCON NORTH AMERICA 2015 44
- 45. Organized by the Community, for the Community. AM I SUBSCRIBED? SUGCON NORTH AMERICA 2015 45
- 46. Organized by the Community, for the Community. SECURITY CHECKS: MEMBER DASHBOARD SUGCON NORTH AMERICA 2015 46
- 47. Organized by the Community, for the Community. SECURITY CHECKS: SEARCH RESULTS SUGCON NORTH AMERICA 2015 47
- 48. Organized by the Community, for the Community. SECURITY CHECKS:TABLE OF CONTENTS SUGCON NORTH AMERICA 2015 48
- 49. Organized by the Community, for the Community. SECURITY CHECKS: ARTICLE CONTENT AND SIDEBAR WIDGETS SUGCON NORTH AMERICA 2015 49
- 50. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 50 SYNCRONIZATION
- 51. Organized by the Community, for the Community. KEEPING SUBSCRIPTIONS IN SYNC The site needs regular updates from Salesforce to keep user subscriptions current. So: • Update member data as a background task • Determine the synchronization schedule, and disable tasks if necessary • Perform partial and full sync operations SUGCON NORTH AMERICA 2015 51
- 52. Organized by the Community, for the Community. TASK SCHEDULER SUGCON NORTH AMERICA 2015 52
- 53. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 53 LOGGING
- 54. Organized by the Community, for the Community. LOGGING AND ERROR HANDLING SUGCON NORTH AMERICA 2015 54
- 55. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 55 HORROR STORY #3: SELF-DENIAL OF SERVICE ATTACK
- 56. Organized by the Community, for the Community. TRIGGERS AND OUTBOUND MESSAGES • Using triggers and outbound messages, you can create a “push” architecture instead of a “pull” • Salesforce API limits do not apply to outbound messages • Outbound messages can only send certain fields from certain objects • Salesforce can batch messages – and choose when to send them • Salesforce expects your message endpoint to acknowledge receipt SUGCON NORTH AMERICA 2015 56
- 57. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 57 WRAP UP & QUESTIONS
- 58. Organized by the Community, for the Community.SUGCON NORTH AMERICA 2015 SM 58SUGCON NORTH AMERICA 2015 THANKYOUTO OUR SPONSORS!
Editor's Notes
- Abstract: While CRM integrations with Sitecore are commonplace, using Sitecore to control access to members-only content goes beyond typical lead generation activities. Dean Thrasher, Sitecore Solutions Architect at EPAM, explains how Salesforce integration can utilize contact records and products to control access to specific content hosted in Sitecore. The presentation will highlight best practices and pitfalls occurred during a client build including performance, resilience, caching, error handling and logging, plus chatty vs. chunk web services and push vs. pull communication models. This is a technical talk, but we won’t be looking at much code. Expect to see data flows, interaction diagrams, and lots of integration patterns.
- Can’t remember the long title? Neither can I. Let’s use “Behind the Paywall” as our social media hashtag, shall we? Feel free to tweet, growl, hoot, moo, or whatever about this presentation on the social media platform of your choice.
- Here’s how to get in touch with me.
- Have I really been at this 15 years? Dang, I’m old!
- NavigationArts is now an EPAM Company. EPAM is a leading global provider of product development and software engineering solutions. We are combining our strengths in strategy, user experience, and content management with EPAM’s expertise in software engineering to deliver more valuable digital experiences for our clients.
- 4 MVP titles! While only 4% of Sitecore partners have reached 1+ MVP at all 5 Sitecore sites of the year in different verticals Sitecore certified solution partners – one of only 7 partners with 4+ certifications: CEP = Content Engagement Platform ECM = E-mail Campaign Manager CRM E-commerce Platinum partners – among only 4% of partners (out of 650+!!!) who hold this status! There are 150+ Sitecore trained specialists including architects, developers, QAs, BAs, designers, content managers, support specialists etc. 80 developers among them. We also have some AIIM ECM, AIIM ERM and IIBA-certified specialists (including those with CBAP certificate).
- Stratas Advisors, a research and consulting firm in the energy sector, wanted to: 1) Unify several different brands into a single site 2) Innovate and take advantage of the interactivity of the web 3) Move to a more frequent publishing schedule 4) Broaden its offerings 5) Deepen its relationship with existing customers 6) Implement a comprehensive subscription system
- There is a companion ASP.NET MVC site that allows site members to interact with data sets curated by Stratas Advisors. The Sitecore website provides authentication and authorization services to this site, so that users log in only once, and only get access to the data sets to which they have subscribed.
- There is a companion GIS site that allows site members to interact with map data curated by Stratas Advisors. The Sitecore website provides authentication and authorization services to this site, so that users log in only once, and only get access to the data sets to which they have subscribed.
- This is the high-level conceptual diagram we put together to address the customer needs. For the purpose of this talk, we’ll be looking at the two systems on the right-hand side of this diagram, Sitecore and Salesforce.
- We were building a site using Sitecore 7.2, but the approach presented here will work in the Sitecore 8 series as well.
- Salesforce is constantly updating. They roll out a new version roughly every quarter, with new versions of their API to go with it. More about which editions of Salesforce to use, and which Salesforce APIs, later in the presentation.
- The site is divided into three broad areas. There’s the public side of the site, which contains marketing materials, information about the company, job listings, press releases, and so on.
- Then there’s the member’s area of the site, which has some content you can only see after logging in and other content that’s only available to paying customers. This area houses the vast majority of content on the site.
- Finally there’s the user account management area. This allows a site member to maintain profile information, change his or her password, sign up for email notifications, and view active subscriptions. Our focus will be on these last two areas: member content and profile information. These are the places that rely on Salesforce integration.
- Stratas Advisors has a lot of different product subscriptions available. They cover the energy sector, broadly defined, and want to be able to offer targeted subscriptions. These products aren’t mutually exclusive. The same article might be offered under several different product subscriptions. Most subscriptions expire on an annual basis, but some are quarterly.
- The website has three kinds of users. Note that a member may be a subscriber to one product, but only see a preview of another. Most authenticated site users are a combination of prospect and subscriber, as far as Sitecore is concerned.
- Some definitions from the business side. After lots of discussion with our client, we largely adopted Salesforce terminology to keep things simple.
- Before you begin, you’ll need to gather some basic information about the Salesforce instance you’ll be using.
- Salesforce has a lot of different APIs. For our purposes, we could have used either the Force.com REST API or the SOAP API. The SOAP API has been around longer, has better documentation, and samples in C#. If you choose the SOAP API, you have a further choice to make: which WSDL to use? You’ll need the Enterprise WSDL, because it’s the one with your custom objects and fields. (The awesome graphic comes from Nordic APIs. http://nordicapis.com/)
- Once we know how we’re going to communicate, we need to figure out which objects we’ll need. For the purposes of setting up our subscription security, we need the objects outline in orange from the Sales model. (The objects outlined in blue are used for capturing leads from the website and enrolling site visitors and members in email campaigns.)
- …And we’ll also need this product object over here. The Product object has the very important product code field, which we’ll use everywhere in Sitecore.
- To these out-of-the-box objects, we added the following custom fields. The Sitecore username and password are not strictly necessary; they help facilitate customer service operations.
- You’ll want at least one Sandbox to use for developing and testing your integration. Depending on the type of Sandbox, you might not be able to load it with a complete copy of your production instance, and may have to abide by a refresh schedule. Sometimes it can take a week for Salesforce to provision a Sandbox, so plan ahead.
- Things were working great in the Salesforce Sandbox. We could read contact and subscription information and grant access to site content. But after we moved to the production instance, we suddenly started seeing all sorts of strange behavior. The integration worked intermittently, or sometimes not at all. The site would recover after a time, and then cut out again. What’s going on? API Limits. In the Sandbox, we had a huge limit of 5 million requests per day, and we didn’t even get close to that. But in production, we discovered that the API limit was much smaller: just 15 thousand requests per day. Once we hit the API limit, all further web service requests get refused by Salesforce, until enough time passes to bring us below the limits again. We needed to get a lot more efficient with our API requests.
- Key takeaways with regard to API usage. Remember: Production instances often have lower API limits than do Sandboxes. Production instances may have other applications communicating with them. Production instances have different usage patterns than Sandboxes. Things that work great in your Sandbox might fail in Production – and it could take other applications down with it!
- For Salesforce, here’s what I recommend: Grab big batches of data on an infrequent basis. Cache the information you receive. Be prepared to skip requests if you start to approach the limit. Your integration must be designed to survive an API blackout. Remember that it might not be your application that’s causing the problem. Or it might be a bad interaction between applications. Or your Salesforce instance might be down for maintenance.
- Think about all the different places we’ll be using Salesforce data on this subscription site. For the member’s name on the “welcome” message in the header For the member’s profile page, which displays CRM data For permissions to pages For access to search results For showing items related to purchased subscriptions in the sidebar Performance would be terrible if we reached out to Salesforce in real time. We need to grab this information in advance and store it locally in Sitecore.
- We needed to store essential member information in Sitecore. The Stratas Advisors site needed to function even if we couldn’t communicate with Salesforce. We did this by creating a custom user profile in Sitecore and adding the fields we wanted to cache from Salesforce. Customer and account information were stored here, and product codes were translated into Sitecore security roles. More on roles in a few minutes…
- One of the challenges of using a Sandbox is that it isn’t an exact copy of the production instance. Even if most of the data is the same, all the objects will have different Salesforce object Ids. A Sitecore instance that connects to a new or refreshed instance of a Sandbox will interact with a whole new set of contact and account IDs. This can cause duplicate contacts, if you’re not careful. We avoided this problem by also checking the contact’s email address… which meant that our Sandbox had an accurate copy of real customer names and real email addresses. One day, one of our Sitecore development or QA servers fetched the latest Contacts from the Sandbox, triggering emails informing customers of their new passwords… to the wrong Sitecore servers! Side note: email addresses are not unique by default in either Sitecore or Salesforce. So we had to do a significant amount of clever configuration work to fail in this spectacular fashion.
- Sandboxes are great for testing purposes, but remember not to import sensitive customer data into it. Also remember to disable workflows, emails, and other things you might not want to have leave your Sandbox.
- We developed a hybrid security model for Stratas Advisors. Although we rely on Sitecore to enforce login for secure, members-only pages on the site, we do not use Sitecore security to determine who has access to which pages within the member areas. Sitecore security is all-or-nothing, but we wanted non-subscribers to see these pages in search results. We wanted non-subscribers to follow links to pages and be shown “teaser” content to get them to purchase new subscriptions. We wrote custom code to determine who was a subscriber to the page and who wasn’t. This had the added benefit of simplifying the Sitecore security model for content authors. They just needed to apply the correct product code tags to member pages.
- We consolidated the secure, members-only pages in two places: the user account management area, and the member content area. For these two branches of the Sitecore content tree, we broke inheritance for the Everyone roles – global, sitecore, and stratas – and we denied read access to the stratas Anonymous user. Unauthenticated site visitors arriving at pages in these sections will be redirected to the login page.
- The next step is to represent the Salesforce product codes in Sitecore. We created a series of product code items that could be applied to pages as tags.
- Content authors select which product codes apply to the page. A member will have access to the page if he or she is subscribed to at least one of the selected product codes.
- For each of the Salesforce product codes, we also create a security role within the stratas domain. These roles are assigned to stratas domain users, and represent the user’s active subscriptions.
- To check whether a user is subscribed to a page, we compare the page’s product codes to the user’s roles. If we have at least one match, the user is allowed to view the full content. We wrote custom code to enforce this rule. Our custom security code needed to be clear, concise, and applied consistently throughout the site. We had a single utility method we used to determine if a user was allowed access to the page based on the product codes applied to the item. Note that we needed to handle the cases where a user was a Sitecore administrator or a member of the Sitecore domain. Content authors must be able to see and edit member content in page editor and preview modes.
- This security function gets invoked everywhere, from the featured articles shown on the member dashboard…
- …To the results returned from the member search, implemented using Solr…
- …To the table of contents on member pages, and article lists throughout the site…
- …To the article content itself, where we often show a short teaser and then a call to action to subscribe… …And to the widgets and promos shown in the sidebar. In other words, just about everywhere in the members area. We can’t afford to get this wrong, because getting it wrong means granting access to people that haven’t paid, or denying access to people who have.
- We need to keep members’ information as up-to-date as possible. But it needs to happen as a background task, so the user experience remains fast. We can’t afford to ask Salesforce each time the user wants to do something on the site. We also need to control when and how these sync operations are performed. And ideally, we need some sort of record as to when tasks run and what information was updated. More on logging later…
- We use three scheduled jobs to pull Salesforce information into Sitecore on a scheduled basis. Sync Salesforce Product Codes. We get the list of active product codes from Salesforce and use it to create Sitecore roles. We’d also eventually like it to create product code tags for us as well. Sync All Salesforce Contacts. Sync Modified Salesforce Contacts Pro tip: Improve the user interface for task scheduler o make it easier for Sitecore administrators to use. Use the Sitecore Shell Wax marketplace module to make scheduling tasks easy. This also gives you the handy “Execute Now!” command. Use Adam Conn’s custom field: http://www.sitecore.net/learn/blogs/technical-blogs/getting-to-know-sitecore/posts/2013/11/custom-field-for-task-schedule.aspx
- We need to monitor what’s going on with these sync jobs, as well as audit other operations that interact with Salesforce. We configured log4net to create a separate Salesforce log to make it easy to view Salesforce activity and troubleshoot problems.
- We realized we could work around the API limit problem by relying on Outbound Messages in Salesforce. By setting triggers on key objects, we could send messages to Sitecore when important data changed. In addition to avoiding the API limit problem, it also had the benefit of allowing us to update Sitecore in near real time. The snag was that outbound messages can only contain certain fields from certain objects, which meant we needed to reach back to enrich the information we received. This worked great for single updates, but Salesforce can decide to send a batch of Outbound Messages – in groups of 100 – all at once. (This might happen after a bulk update of Contact information, for example.) Our message listener endpoint on the Sitecore server would receive a block of messages and start processing them in a loop, sometimes asking Salesforce for additional information. It only sent the acknowledgement back to Salesforce once message processing was complete. Salesforce, having decided that Sitecore was taking too long, sent follow up messages, which Sitecore processed and again sent a late reply… continuing the cycle for a 24-hour period until Salesforce gave up in disgust. In the meantime, by asking repeatedly for additional information, Sitecore crushed our client’s API limit, locking everyone out of the system for an additional 24 hours, until the broadcast storm abated and the request counter dropped back under the limit. Doh!
- We could have built our integration on a “push” model from Salesforce using Outbound Messages. The challenge was in the restrictions on what the outbound messages could contain – we found ourselves having to reach back often for additional data. We would also have had to guard against potential loops, such as when users updated account profile information on the website.
- Any questions?