Ad
More Related Content
What's hot (20)
Similar to Integration study group 2: Patterns (20)
Ad
More from gemziebeth (8)
Ad
Recently uploaded (20)
Integration study group 2: Patterns
- 1. INTEGRATION PEER-LED STUDY GROUP MEETING 2: APRIL 23, 2018 FACILITATOR: NIKI VANKERK
- 2. AGENDA • Quick round of intros – name/where you are/planned exam date • Remote Process – Request and Reply (Susannah) • Remote Process – Fire and Forget (Edith) • Batch Data Synchronization (Niki) • Remote Call-in (Nadina) • UI Updates based on Data Changes (Niki) • Choose next topics
- 3. INTROS
- 4. REMOTE PROCESS – REQUEST AND REPLY • REQUEST generated from Salesforce to external system • Often kicked-off by user in the UI • Remote system provides real-time REPLY to Salesforce • Synchronous process
- 5. REMOTE PROCESS – REQUEST AND REPLY • Salesforce connects to remote system using SOAP services or HTTP callout (usings a synchronous call) • The response from the remote system is returned to the Apex controller • The controller processes the response and updates data in Salesforce as required
- 6. REMOTE PROCESS – REQUEST AND REPLY • If an error occurs, exceptions or error codes are returned to the caller (i.e. 201 = Success 500 = Failure) • Salesforce should programmatically handle this error so user knows what to do • Changes aren’t committed to Salesforce until the caller (Salesforce) receives a successful response • Salesforce has a timeout of up to 60 seconds for calls from Apex
- 7. REMOTE PROCESS – REQUEST AND REPLY • Since you can’t control that Salesforce only makes the request once (i.e.: a user could repeatedly click on a button) the receiver must be idempotent. • Design for the idempotent receiver by: • Adding a unique message ID to your web service or REST call so the receiver can recognize duplicate requests • Passing a unique record Id as part of your request and perform upsert instead of insert when your request creates records in the remote system
- 8. REMOTE PROCESS – REQUEST AND REPLY • One-way SSL is enabled by default, but two-way SSL is supported • Salesforce does not currently support WS-Security • Where necessary, consider using one-way hashes or digital signatures using the Apex Crypto Class methods to ensure request integrity
- 9. REMOTE PROCESS – REQUEST AND REPLY • The Request and Reply pattern is primarily used for small volume, real-time activities. • Limitations include the small timeout values and the maximum size of the request or response. • Timeliness matters since the request is typically invoked from the UI— don’t keep your users waiting! • Next steps in my learning: parsing JSON responses, tracking state management, handling integration keys
- 10. REMOTE PROCESS – FIRE AND FORGET Initiate a process in a remote system (other than Salesforce) Do not wait for a response Asynchronous calls
- 11. Criteria to define the solution Asynchronous messages Is the integration based on a specific event? Is guaranteed message delivery required? Quality-of-service requirements. Contract, who specifies it? Declarative / apex code
- 12. Options in Salesforce Outbound messages (declarative) Apex callouts (code) SOAP asynchronous SOAP / REST Contract first - Salesforce defines it Open Guaranteed delivery It’s recommended that the remote endpoint implements JMS or MQ / custom retry mechanism, positive ack No complex system integrations Use of middleware or composite service Idempotent, unique id per message Custom implementation required
- 13. Workflow driven outbound-messaging Best Insert / update event Indirect solution for deletes
- 14. Outbound-messaging and callbacks Best Mitigate the impacts of out-of-sequence messaging Idempotency, get up-to-date information Retrieving more data The outbound message provides a unique session id (authentication token)
- 15. Visualforce page and async callout Good User interface-based scenarios Visualforce page and apex callouts
- 16. Triggers and async callout Suboptimal Automation based on record data changes In the triggers the callouts must be asynchronous (@future - restrictions) Using apex proxy call (SOAP) / REST
- 17. Batch Apex and async callout Batch remote process execution Remember the limits: 100 callouts in a transaction (execute)
- 18. Security Callouts One way SSL enabled, two way SSL supported WS-Security not supported in proxy classes Consider using hashes or digital signatures Protect remote system using firewalls Outbound messaging One way SSL enabled, two way SSL supported, Whitelist, firewalls
- 19. BATCH DATA SYNCHRONIZATION • Use for pushing SF data into external system (replication/backup) or refreshing SF data from external system (customer orders from master ERP) • data movement in either direction - usually done with ETL tool/Data Loader etc • Change Data Capture: • SF is master: SOAP API with query() or getUpdated() methods to find data to send • Remote is master: ETL Tool uses Bulk API to upsert data in SF; use data warehouse to aggregate/queue data to be sent • Timing: schedule during low usage to avoid conflicts, synchronous updates to be avoided as lots of traffic and locking potentials
- 20. BATCH DATA SYNCHRONIZATION • Control tables: track last successful sync and errors • Automation queries control table for last successful sync, apply filter to master, update tables when sync is complete • Keep tables in ETL tool to access in case SF access errors • Chain jobs for logical processing, using primary keys between systems for matching • Locking: child records should be grouped by parent • if children are updated, M-D parent is updated and could be locked if subsequent update of children from same parent (also lookups with ‘do not allow deletion’ cause lock to parent) • Error Handling: • read from SF: retry if possible and log errors/send notification • write to SF: saveResult sends back IDs, success/fail and list of errors per failed record, parse and retry if possible.
- 21. BATCH DATA SYNCHRONIZATION • Security: need a platform license to connect, use standard encryption to keep password safe • Bulk API • loads records into temp storage • server pulls batches for processing • saves results against job • progress/status viewable in SF • retries after failure/time out • allows serial/parallel processing
- 22. REMOTE CALL-IN • Used to connect and authenticate remote(external) systems with Salesforce. • Considerations • Type of call Synchronous or Asynchronous • Message size, small or large ? • Message format (Soap/Rest/over HTTP)?
- 23. REMOTE CALL-IN Solutions Communication Type Protocol Calling Mechanism Security Considerations Data Volumes Notes/Comment s/ Special COnsiderations Soap API Synchronous Soap(WSDL) Enterprise WSDL Partner WSDL Data Format- XML Supports SSL & TLS Remote System must log in to get session ID Cache SOAP API and reuse the session ID to maximize performance. Login request - 10KB or less. Create/Update/ Delete Processing -200 records at a time Query Result Size- Maximum 2000 records API requests limits are ona 24 hour period Session Timeouts based on the organization’s session timeout setting 120 limit on SOQL query timeout
- 24. REMOTE CALL-IN Solutions Communication Type Protocol Calling Mechanism Security Considerations Data Volumes Notes/Comme nts/ Special Consideration s Rest API Synchronous Rest Authenticate using OAuth 2.0(Recommen d) or Session ID Data Format- JSON, XML If Session must be used cache the Rest API to maximize performance. Same as SOAP API API requests limits are ona 24 hour period Apex Web Services Synchronous Rest Custom Apex Web Service WSDL Data Format- JSON, XML Same consideration as SOAP API Apex class has to be exposed Code needs to be maintained
- 25. REMOTE CALL-IN Solutions Communication Type Protocol Calling Mechanism Security Considerations Data Volumes Notes/Comment s/ Special COnsiderations Apex Rest Service Synchronous Rest Data Format- JSON, XML, Custom Same consideration as SOAP API Apex class has to be exposed Code needs to be maintained Bulk API Asynchronous Rest Data Format- JSON, XML, CSV Same consideration as Rest API
- 26. REMOTE CALL-IN State Management • Keys are important for tracking • Salesforce • In this scenario, the remote system should store either the Salesforce RecordId or some other unique surrogate key from the record. • Remote system • In this scenario, Salesforce must store a reference to the unique identifier in the remote system. Because the process is synchronous, the key can be provided as part of the same transaction using external ID fields.
- 27. REMOTE CALL-IN Middleware Considerations • Time Constraints • Resource Availability
- 28. REMOTE CALL-IN Complex Integration Scenarios • SOAP API or REST API • Provide for simple transactions on objects. • Integration scenarios, such as aggregation, orchestration, and transformation, can’t be performed in Salesforce. • These scenarios will need to be handled by the remote system or middleware, with middleware as the preferred method. • Apex Web service or Apex REST service • Custom Web services can provide for cross-object functionality, custom logic, and more complex transaction support. • This solution should be used with care, and you should always consider the suitability of middleware for any transformation, orchestration, and error handling logic
- 29. REMOTE CALL-IN Reliable Messaging • SOAP API and REST API are synchronous and don’t provide explicit support for any reliable messaging protocols. • Recommend that the remote system implement a reliable messaging system to ensure that error and timeout scenarios are successfully managed.
- 30. REMOTE CALL-IN Scenario A printing supplies and services company uses Salesforce as a front-end to create and manage accounts and opportunities. Opportunities on existing accounts are updated with printing usage statistics from the on-premises Printer Management System (PMS), which regularly monitors printers on client sites. Upon creation of an opportunity, an outbound message is sent to the PMS to register the new opportunity. The PMS stores the Salesforce ID (Salesforce is the opportunity record master). • The following constraints apply: • The PMS is capable of participating in a contract-first integration, where Salesforce provides the contract and the PMS acts as a client (consumer) of the Salesforce service (defined via the Enterprise or Partner WSDL). • There should be no custom development in Salesforce.
- 31. REMOTE CALL-IN References • Which API Do I Use?
- 32. UI Updates based on Data Changes • Used when you need a real time update from external systems (ie payment made by customer while on the phone, want to see resulting update to outstanding balance) without needing to update page/lose edits on Case • Streaming API to respond to push topics • Visualforce page for display and polling mechanism • Push Topic with query into SF data • Javascript library/CometD implementation to maintain connection over long polling period • Can subscribe to updates in SF or external systems (oauth connection recommended)
- 33. UI Updates based on Data Changes • Pro: • Automates update into open page (pub/sub model) • Events stored for 24 hrs allowing replay (API 37 and later) • Con: not guaranteed to receive notifications/order and none generated from bulk API • Should use HTTPS protocol, follows user profile/sharing • Streaming API document provides sample applications: https://resources.docs.salesforce.com/212/latest/en- us/sfdc/pdf/api_streaming.pdf
- 35. GREAT RESOURCES • Integration Exam Resource Guide • Integration Patterns Guide • Trailmix for Integration Exam here
- 36. 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