Practice the Layer Approach

Learning Objectives

After completing this unit, you’ll be able to:

• Identify the three layers you use to evaluate integration patterns.
  
• Describe the two types of timing and why they’re important.
  

The Layer Approach

Depending on your integration initiative, you’ll follow different approaches to evaluate patterns. In this module, you learn how to use the layer approach to evaluate patterns for an application integration initiative. Application integration initiatives are common integrations for the Salesforce Lightning Platform. 

Explore the Four Dimensions

In the layer approach, you use the following four dimensions to evaluate integration patterns and solutions. Each dimension represents criteria that helps you understand which solution best solves your integration problem. Review each dimension and compare the results against your integration requirements. 

Layers: The different types of tasks in a system

Volume: The amount of data synched and the transformation activity between systems

Timing: Communication timing is either asynchronous or synchronous, where data flows between systems in real time (or as soon as possible) or is batched up for later delivery 

Direction: The source direction, which can be from Salesforce to another system, from another system to Salesforce, or bidirectional

Explore the Different Layers

The layer approach divides the application architecture concepts into logical categories. Each layer represents a division of tasks in the system. The most common way to divide the tasks is into the following three layers.

• User interface layer
  
• Business process layer
  
• Data layer
  

This division of tasks helps you group together similar patterns and solutions. Even though these layers are separate, they still communicate with each other.

User Interface Layer

The UI layer focuses on user interactions with the system. In this layer, you identify the components to integrate third-party web applications into Salesforce. You combine the UI from multiple systems such as displaying Salesforce UI in a third-party application. The UI layer interacts with the business process layer. 

• Salesforce canvas
  
• Mashups or Lightning out
  

Business Process Layer

The business process layer interacts with the data and builds on the UI layer. The business logic includes data interaction, validation, and processing data transactions. These transactions are real-time calls from the UI or data capture events to the database that stores the data. 

Here are some example integration solutions associated with this layer. 

• Mulesoft Anypoint Platform
  
• Platform events bus (including Streaming API)
  
• Flows
  
• Outbound messaging
  

Data Layer

The data layer is the connection with the UI layer and the business process layer. It maps and identifies the primary data source and connections to other segments of the system. Data transformations, migration, and replications often occur in this layer. The connectors and services aligned to this layer focus on data accuracies and integrity as the data permeates through the solution.  

Here are some example integration solutions associated with this layer. 

• Heroku Connect
  
• Salesforce Connect
  
• Apex
  
• REST and SOAP API
  
• Composite API
  
• Bulk API
  

Now that you’ve learned more about each layer, this table shows you the layer for each Salesforce Lightning Platform integration pattern. 

Volume

Volume focuses on the amount of the data and the size of the message communicated. Every Salesforce org has hard governor limits and allocations imposed. Some allocations, such as API calls, are extendable by purchasing additional licenses. The hard set governor limits, such as the number of records updated through a DML statement, cannot be extended. The best practice is to use only necessary technologies, connectors, and services so that the solution doesn’t needlessly consume available resources.

For example, some Salesforce Lightning Platform patterns have solutions that are ideal for small volumes of data. The ideal integration pattern these solutions align to is Remote Process Invocation—Request and Reply. In this pattern, the system sends a small (or single) transaction and requires reply. This pattern is great for small transactions. However, there are governor limits and license allocations to consider.

There are other patterns that work better for bulk data processing such as Batch Data Replication. Heroku Connect is available in this pattern option. This option works best for grabbing large amounts of data at once without exceeding limits. Knowing the volume is important when considering the resource limits available for the design.

Timing

The timing and frequency of communication are important when evaluating integration solutions. Consider whether you need the system to send the communication in near–real time or to process it later in a batch. The solution you implement determines the timing of the communication. 

There are two types of integration modes: asynchronous and synchronous. 

Synchronouscommunication means a client sends a request to the server and waits for the response before issuing another request. For example, the Remote Process Invocation—Request and Reply integration pattern is a synchronous communication. An application sends a message and waits for a reply before proceeding.  

Asynchronouscommunication means the system doesn’t wait for a reply before proceeding. The application sends a message and the system returns a reply as soon as the resources are available. The system that sent the original message has the ability to continue sending messages without waiting for a reply. Processing the return message is controlled separately.

Direction

The direction clarifies the interaction between two systems. This dimension identifies the primary source system and the target system. It's about how the systems interact and connect, and not about the direction that data flows. 

For example, imagine that an integration solution originates from Salesforce due to an event and call out to an external system. The external system is set up to respond with important data. The direction is captured as Salesforce → System because Salesforce is the primary system and the external system is the target system.

Identify the direction to determine which pattern is ideal for the design. 

• Salesforce → System (or possibly into another Salesforce org)
  
• System → Salesforce
  

This table shows the direction for each Salesforce Lightning Platform pattern. Review the Integration Patterns and Practices - Design Pattern Catalog documentation to learn more about the direction of interactions.

Security Requirements

Security is an important consideration when designing an integration solution. Your design should include aspects such as user identity, data masking, and PII storage as part of your integration strategy. The General Data Protection Regulation (GDPR) is a regulation in EU law on data protection and privacy in Europe. Most US-based companies have adopted this law as a best practice for their business.

Integration patterns that follow the direction Salesforce → System benefit the most from incorporating Shield Platform Encryption into their design. Shield Platform Encryption uses a combination of a unique tenant secret you maintain, and a master secret that's maintained by Salesforce. Together they create a unique data encryption key. Review the Salesforce Shield Platform Encryption Implementation Guide to learn how to incorporate it into your design.

Error-Handling and Recovery

There are a variety of errors that occur in an integration. Errors include system thresholds (such as governor limits and API allocations), business process errors (when a request violates business rules), and user authorization and authentication problems. It’s important to include an error handling and recovery strategy as part of the overall solution. 

Error-Handling

When an error occurs (exceptions or error codes are returned to the caller), the caller manages error handling. For example, when an error message displayed on the end user’s page or logged to a table requires further action.

Recovery

Changes aren’t committed to Salesforce until the caller receives a successful response. For example, the order status isn’t updated in the database until a response that indicates success is received. If necessary, the caller can retry the operation.

Coupling

Communication across multiple systems introduces the risk of latency and unreliability when out of sync. Each solution relies on different dependencies across systems. These dependencies include technology requirements (such as services used), data type requirements (date, number, text communicated), or interaction style (asynchronous versus synchronous and timing) to name a few. 

Components in a loosely coupled solution have the ability to be switched out should a requirement or dependency change. For example, messaging is a loosely coupled solution when utilized in an asynchronous communication. Tightly coupled solutions don’t have much flexibility to be altered without redesigning the integration strategy. When deciding between solution options, choose the loosely coupled option to reduce the risk of dependencies breaking.

In the next unit, you practice evaluating a Salesforce Lightning Platform integration pattern using all the tools you’ve learned so far in this module.

Resources:

• Mulesoft: Error Handling from an Integration Patterns Perspective
  
• Mulesoft: Synchronous vs. Asynchronous Communication in Applications Integration
  
• Salesforce: Integration Patterns Overview
  
• Salesforce: Shield Learning Map
  
• Enterprise Integration Patterns: Messaging Patterns Overview