The third in a series of peer-led Integration study groups led by Niki Vankerk, in this video we explore multi-org, security, JSON and backup/restore

1. INTEGRATION PEER-LED STUDY GROUP
MEETING 4: MAY 7, 2018
FACILITATOR: NIKI VANKERK

2. AGENDA
• Quick round of intros – name/where you are/planned exam date
• Cross Org Connections (Niki)
• Security/Oauth Part 2 (Edith)
• JSON Basics (Susannah)
• Connected Apps & Backup/Restore (Nadina)
• Choose next topics

3. INTROS

4. CROSS ORG CONNECTIONS- Niki
• Single vs Multiple Orgs: Making the decision
• Technology choices
• Salesforce 2 Salesforce
• Salesforce Connect with cross org adapter
• Middleware/ETL tool
• Wave/Analytics for reporting
• Custom integration via APEX

5. The decision
• consider how integrated and
standardized the business process
are
• Unification: single org
• Diversification: multiple orgs
• Replication: consider multiple but
share config with managed packages
• Coordination: consider single with
responsive biz unit config/governance
reference: https://developer.salesforce.com/blogs/developer-relations/2014/10/enterprise-architecture-multi-org-strategy.html

6. Other factors
• Single Reporting org: consolidate data here for reports
• Other considerations:
• data privacy issues
• org limits (apex) and org wide sharing complexity
• Complex data processes that vary between business units
• local administration requirements

7. Salesforce to Salesforce
• Free technology, Classic interface only for managing data sync
• Once enabled, can’t be disabled; creates Connections and External sharing
tab/lists
• General flow
• Invite a contact to connect, sends them email template where they can accept
• Publish objects and fields in main org; receiving org subscribes to same
objects/fields
• Individual records are then shared to individual connections, manually or via apex
• Receiving org accepts the records being shared, manually or auto subscribe
• Can be bidirectional or one way push

8. More Details (S2S)
• Data is stored into the receiving org so consider data storage issues
• No chatter, only main standard objects available
(account/contact/case/lead/opp with products, Task) and custom objects
• Need workflow/apex to ‘translate’ picklists or values
• Can be difficult to support parent/child sync
• Organization Sync for downtime
• limit to 2 orgs, have to purchase second org fully
• can redirect users to second org during maintenance window, either R/O or edit
• copy meta data over to second org but adjust to avoid trigger loops

9. Salesforce Connect
• Integrates data stored outside of your SF org, not copying data into org but use
External Objects to access data real time.
• Avoids data from getting stale over time, taking up data storage
• Product add on cost may be prohibitive
• Cross object adapter for multi orgs, consumes API calls
• for frequent access to large amounts of data, ETL is best option
• Suitable for pulling in net new objects from different orgs
• each connection feeds into a separate External Object

10. Salesforce Connect
• Adapter types:
• OData 2.0 or 4.0: use for any 2.0/4.0 producer on the internet, REST based
protocol, has OData callout limits (ie 10K per hour, 1000 row result set)
• Custom APEX connector framework: uses callouts/API
• Cross org adapter: uses Lightning REST API for data access, API limits
• calls for viewing external object record, list views, parent/child with external references,
reports
• X-Org limitations:
• activities, notes, record types, record level sharing not available
• formula/roll ups can’t reference external objects, no rich text
• picklists: make local/non restricted on subscriber org
• currency: match between orgs

11. Comparison
Reference: https://www.slideshare.net/developerforce/blurring-the-boundaries-between-salesforce-orgs

12. 3rd party tools
Pros:
• Built/supported by external company, security review if on AppExchange
• Range of complexity from one object to data transformation/warehouse
capability
• prebuilt connectors like Sharepoint etc
Cons:
• Usually pay per connection, could be costly
Sample vendor with array of options: https://skyvia.com/connectors/salesforce

13. Other Integration Options
• Wave/Analytics: bring various org data in as datasets for single reporting view
• Cost for Wave
• Article with details: https://www.linkedin.com/pulse/reporting-analytics-salesforce-
multi-org-scenario-sumit-jain/
• Custom integration code:
• relies on developers, efficient use of API calls
• maintenance issues
• requires tight control/understanding of multiple org processes

14. SECURITY PART 2 - Edith
Last session:
Inbound integration security
• Client integrations are treated as users
OAuth 2.0

15. Overview
Network authentication
Session security
Data security
Application-level security
Transport layer security
Outbound integration security
http://lms.cfs-
api.com/v1/12/lms.aspx?hash=WUlRa1pjd0RRUDZIbE5XYXFsalBoSXluZDdqT0dkZkNKNmt6blpYOTU4TjBWU1BKWmp0SXpOZzVzSzNMRVZ6dkt0dEhRcFh5Uk
VGU3VSSVFCSFk2dm5FM011NHZDTS9SWjhNVDMva25SelkvZnkxS0t4MGM5TCtTZzdEbFNMSUxZQWVodVViamdjWDNNaWhaUlZxL1d3PT0=

16. Network authentication
Network authentication restricted
by:
• Profile: Login hours and IP
ranges
• Organisation: IP address
restrictions

17. Authentication flow

18. Session security
Org-wide level

19. Data security
Types:
• Object-level security
• Field-level security (remember
encrypted fields)
• Record-level security
• View all, modify all
• Sharing rules
• Manual sharing
• Role hierarchy

20. Application-level security
Restrict access to client apps, such as Data Loader or the Salesforce app
• “API client whitelisting feature”
• Restrict access to all connected apps until admin explicitly approve each app
• “Use any client API permission”: User can access any app

21. Transport layer security
TLS protocol
• Provides secure transport over HTTP or HTPS
• Network segments are encrypted end-to-end
• Uses SSL certificates
• Allows detection of message tampering

22. Outbound integration security
Two-way TLS
• 2 certificates, client and server
• Certificate authority signs the certificates
Outbound port restrictions
Remote site settings
• Register before callouts are made

23. JSON Basics - Susannah
• JSON (JavaScript Object Notation) is a lightweight text-based format used to
transport data between a web application and a server
• Supports UTF-8 and ISO8601 for data interchange
• Uses string-value pairs for representing data
• Used by the REST API, Chatter REST API, Streaming API and Bulk API

24. JSON String-Value/Name-Value Pairs
• JSON uses an unordered
collection of string-value pairs to
represent data.
• The string is the field name the
value should be associated with
• The value can be any string,
boolean, number, object or array
• Each name is followed by a
colon
• Each pair is separated by a
comma

25. JSON is Built on Two Structures: Object and Array

26. Example:
JSON Response to a REST Api
Query

27. JSON Support
You can work with JSON in a variety of languages (Java, C#, etc). Luckily, Apex
provides a set of classes that expose methods for JSON serialization and
deserialization. For complete documentation visit the developer docs.

28. Example: Using the method
JSON.deserializeStrict()
Method:
JSON.deserializeStrict(jsonString,a
pexType)
This method deserializes a JSON
string into an Apex object of the
specified type.
In this example, the JSON string is
deserialized into the Apex object
“Car”, represented by the Car class

29. CONNECTED APPS & BACKUP/RESTORE -
Nadina

30. CONNECTED APPS
• A connected app integrates an application with Salesforce using APIs.
Connected apps are designed to be run independently of the user interface.
Connected apps use standard SAML and OAuth protocols to authenticate,
provide single sign-on, and provide tokens for use with Salesforce APIs. In
addition to standard OAuth capabilities, connected apps allow Salesforce
admins to set various security policies and have explicit control over who can
use the corresponding apps.

31. CONNECTED APPS
• Here’s a general list of information that you provide when
you create a connected app:
• Name, description, logo, and contact information
• URL where Salesforce can locate the app for
authorization or identification
• Authorization protocol: OAuth, SAML, or bothIP
ranges from where users can log in to
• connected app (optional)
• Information about mobile policies that the connected
app can enforce (optional)

32. BACKUP
➔ Data backup and restore is often considered a
security topic.
➔ Why would you backup Salesforce data
(including metadata)?
◆ Recover from data corruption (unintended user error or malicious
activity)
◆ Prepare for a data migration rollback
◆ Archive data to reduce volumes
◆ Replicate data to a data warehouse/BI
◆ Take snapshots of development versions**
**Yes, don’t rely on this alone. Version Control Software should be your source
of truth (Github, Bitbucket,SVN etc)

33. BACKUP
Additional Caveats
● Bulk API still does not support Base64 fields.
● The below is the list of the objects that are not supported by Bulk
API. The below objects has different metadata compared to the
data objects that are supported.
○ CaseStatus
○ ContractStatus
○ KnowledgeArticle
○ KnowledgeArticleVersion
○ KnowledgeArticleVersionHistory
○ KnowledgeArticleViewStat
○ KnowledgeArticleVoteStat
○ LeadStatus
○ List item
○ OpportunityStage
○ PartnerRole
○ RecentlyViewed
○ SolutionStatus
○ TaskPriority
○ UserRecordAccess

34. RESTORE
● Depending on your restore use case, you’ll use one of the following types of restore processes:
○ Single restore
○ Logical partial restore

35. RESTORE

36. Resources
• Connected Apps Practice: Salesforce Mobile SDK Basics
• BEST PRACTICES: Data Backup & Recovery Best Practices
• Salesforce Backup and Restore Essentials Part 1: Backup Overview, API Options and Performance(UPDATED
February 2017)
• Salesforce Backup and Restore Essentials Part 2: Restore Strategies and Processes(UPDATED February 2017)
• Choosing Integration Approach

37. BRAINSTORM
TOPICS

38. MORE RESOURCES
• Integration Exam Resource Guide
• Integration Patterns Guide
• Trailmix for Integration Exam here

39. THANK YOU FOR COMING!
• Join our Trailblazer Community group – don’t forget to fill out your personal profile!
• Post your exam successes into the group
• If you tweet, use #LadiesBeArchitects
• Get Involved –
• Run a study group for us
• Speak at one of our Inspire meet-ups
• Blog / talk about us