Patterns for Integrating Your Salesforce App with Off-Platform Apps
Integrating Salesforce applications with additional off-platform apps can dramatically extend the capability of powerful business apps. From ERP systems to custom apps, integrating with Salesforce can help streamline essential processes, saving your business valuable time and money. In our latest tech webinar, CodeScience Technical Architect Mark Pond dives into Salesforce integration patterns and the positive impacts they can deliver.
In this technical webinar, you will learn:
- Several common Salesforce integration patterns
- Integration pattern pitfalls
- How to leverage a custom queue to automate background work
- Deliverability and reporting advantages of custom queues
Watch today to learn how automated testing can take your enterprise solutions to the next level.
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Technical Webinar: Patterns for Integrating Your Salesforce App with Off-Platform Apps
1.
2. ● Who is CodeScience?
● Introductions
● Common Integration Patterns
● Integration Considerations & Pitfalls
● Leveraging a Custom Queue
● Recap
Agenda
3. Who is CodeScience?
● Founding partner of the Salesforce Product
Development Organization (PDO) Program
since 2008 - named Master PDO in 2017
● We build Salesforce AppExchange solutions
for our clients.
7. Common Integration Patterns
6 commonly documented Salesforce integration patterns:
● Remote Process Invocation—Request and Reply (Apex callout)
● Remote Process Invocation—Fire and Forget (Platform Events / Outbound Messaging)
● Batch Data Synchronization (Middleware / Change Data Capture)
● Remote Call-In (REST API / SOAP API/custom Apex API)
● UI Update Based on Data Changes (Streaming API)
● Data Virtualization (Salesforce Connect)
Each of these integration patterns has a good/better/best ranking for common integration
scenarios and they also have significant limitations around guaranteed delivery, background
execution, delayed processing, retry & exponential backoff strategies, or usability in logging &
archival solutions.
Let's talk about a reliable pattern that straddles the first three bullets and addresses some
significant shortcomings...
8. Integration Considerations & Pitfalls (1/2)
With all integrations it is important to evaluate and plan for the level of resiliency that your solution requires.
While some applications are unaffected by integration messages which have failed to be delivered, in others it
may be imperative that every message be sent and acknowledged.
● Reporting: do you need to know how many records are awaiting processing?
● Monitoring: do you need the system to notify you when an integration appears to be having
performance problems?
● Guaranteed Delivery: do you need to know that every message reached its destination? Kafka queues
used by CDC and Platform Events do not have guaranteed message delivery. Your message has the
possibility of silently not being published.
● Retry: Do you need the ability to retry an operation, potentially with a progressive backoff increasing
the time between each successive retry?
● Object and Field limitations: which objects and field types do you need to integrate with? Some field
types are not supported by all integration options.
● ...
9. Integration Considerations & Pitfalls (2/2)
With all integrations it is important to evaluate and plan for the level of resiliency that your solution requires.
While some applications are unaffected by integration messages which have failed to be delivered, in others it
may be imperative that every message be sent and acknowledged.
● …
● Chaining of Actions while processing: Do you have a complex orchestration that is best suited to be
on-platform and includes a chained set of steps?
● Prioritization of Execution: Do you need to prioritize integration activities? High priority on-demand
action by a user vs a lower priority job, etc.
● Scheduled Job limits: Are you concerned with the number of scheduled jobs your Salesforce org needs
to operate?
● Message Duration: Are you concerned with the duration of integration messages? CDC: 3 days;
Outbound Messages: 24 hours; Data Replication API: 30 days of actions / record id values;
● Delayed Processing: Do you need delayed processing of records by the integration which cannot be
accommodated by Time Based Workflow Rules?
10. Leveraging a Custom Queue
Building a custom solution, which relies on data stored temporarily in an SObject, enables
quite a few solutions to be designed to address the concerns in the previous list.
It enables guaranteed delivery, retry behavior, prioritization, delayed processing of messages,
custom interfaces, dynamic instantiation of custom 'workers' via queueables, background /
asynchronous operations, and more.
11. Benefits:
● Reliability - Data written to SObject records cannot be purged from a Salesforce queue such as the time
based workflow queue can
● Scalability - SObject records control pending queue depth
● Reportability - Leverage standard platform reporting tools for queue analytics
● Retry-ability - Queue records can be reprocessed based on your own retry logic and errored out as
necessary with error log details
● Notifications - Leverage standard platform tools such as email workflow rules to alert administrators
when issues need to be addressed
● Flexibility - Any data format supported in queue item body, Any data format supported in worker
classes
● Durability - Queueable job chaining allows the org to continue processing records infinitely until the
queue is "empty"
● Security - Encryption of queue item payload at rest is possible in a managed package scenario where the
encryption key can be protected
Leveraging a Custom Queue
12. Example Use Cases
● Error Logging - Write log records asynchronously to Big Objects
● Translation of record data - callout to Google translation to translate the value of a
custom field into another language
● Address Verification - call out to address verification system to confirm and correct
mailing address data
● Record enrichment - call out to SaaS endpoint for business info (in scheduled execution
or on demand by a user)
● SMS delivery - call out to telecom service to deliver SMS messages
● Delayed sending of EMail messages
● Calling a remote API which does not support data in bulk or is fragile or frequently
down, requires slower processing such as one record at a time
13. High Level Design Pattern
Let's look at a high-level design diagram of the application flow.
15. The most significant benefit to the custom object + queue processor in apex solution is that you
control your own delivery of messages to or from remote services and can implement it in any
method you choose. You are able to implement your own guaranteed delivery mechanism.
You are also able to take advantage of the numerous additional platform features as your
solution demands.
For instance, if you needed to guarantee delivery of a platform event, you could write to the
custom queue when a record is modified and then let the queue item worker fire a platform
event on your behalf at a later time. A subscriber could then write back to salesforce when the
message is processed, removing the item from the queue.
This abstraction allows you to introduce custom logic such as retries and sending
administrative notifications when an item reaches an error state or receives no
acknowledgement.
Benefits
16. The most significant limitation in this custom queue implementation is that it cannot currently
handle a cascade delete scenario easily.
Because the cascading actions do not fire triggers, process builders, flows, etc. that makes it
extremely challenging to integrate with this implementation.
The apex in a worker instance could query for recently deleted items with parent records in
the queue item data - but this is still an imperfect solution since records may not be available
in the recycle bin
Limitations
17. Recap
What did we cover:
- Salesforce standard integration solutions
- Custom queue solution
Do your due diligence.
There is no one-size fits all solution to solve all integration needs. This custom queue
implementation pattern has a very large number of possible use cases which it can help solve
but it requires a fair amount of custom code.
It centralizes a lot of functionality on the platform in apex which may not be the best choice
for your business and your developer skills if you have deep expertise in other areas.