The Salesforce Certified Platform Integration Architect (Plat-Arch-204) (Integration-Architect)

In a standard API-led connectivity model, the First Tier (Experience APIs) is responsible for tailoring data for specific systems of engagement.

The Experience APIs take the core data from the lower tiers and transform it into the specific return formats (e.g., JSON for mobile, XML for legacy web) and security protocols (e.g., OAuth for Salesforce, API Keys for web) required by each consumer. Option B correctly identifies that these transformations and security enforcements should happen at this outer layer. While an API Gateway (Option A) can provide generic security and rate limiting, it is the Experience API layer that provides the functional transformation and specific protocol requirements defined by the business needs of the engagement systems.

For a requirement focused on synchronizing record updates from Salesforce to an external system in an event-driven and asynchronous manner, Change Data Capture (CDC) is the architecturally preferred solution over custom Platform Events.

CDC is designed specifically for data replication and synchronization. It automatically publishes change events for Salesforce records (Create, Update, Delete, and Undelete) to the event bus. Unlike Platform Events, which require manual publishing via Apex triggers or Flows, CDC is a low-code feature that requires only a simple activation for the Contact object in Setup. The external homegrown application can then act as a CometD subscriber , listening to the specialized /data/ContactChangeEvent channel to receive near real-time updates without the need for constant polling. Furthermore, CDC provides ordered, replayable events and an extended 72-hour retention window , ensuring that the homegrown application can recover missed updates using a Replay ID if it momentarily loses connection. This native broadcasting capability ensures data integrity across systems while breaking the tight coupling between Salesforce and the legacy application.

For high-volume data loads using the Bulk API, monitoring should be performed programmatically by the orchestrating client—in this case, the custom Java application. The Bulk API is asynchronous, meaning that when you submit a job, Salesforce acknowledges the request and processes it in the background.

The Java application must actively track the state of its own jobs. Using the `getBatchInfo` (or `getJobInfo` in Bulk API 2.0) method allows the application to retrieve the real-time status of each batch. The application can check for statuses such as `Queued`, `InProgress`, `Completed`, or `Failed`. Once a batch is marked as `Completed`, the application can then call `getBatchResult` to retrieve a list of successes and failures for individual records.

Option B is architecturally unsound because Bulk API operations are designed to bypass most synchronous Apex logic to ensure performance; furthermore, creating custom records for every error in a " nightly batch load " would likely hit other platform limits (like storage or CPU) and defeat the purpose of using the Bulk API. Option C is ineffective for Bulk API monitoring, as debug logs do not capture the background processing of bulk batches and would quickly hit the log size limits.

By recommending Option A, the architect ensures that the Java application maintains full control over the integration lifecycle. The application can log errors locally, implement automated retries for transient failures, and provide the CIO with accurate, high-level reporting on the success rate of the nightly loads without placing unnecessary overhead on the Salesforce platform.

---

When an organization must interact with multiple external services (34 different shipping providers) that change frequently, the primary architectural goal is to decouple Salesforce from the specific endpoints and protocols of those services. 11

The architect should propose us 12 ing middleware to abstract the call . By introducing a middleware layer (such as an ESB or iPaaS), Salesforce makes a single, standardized call to the middleware, passing the country and order details. The middleware then handles the " Process Orchestration " :

Service Routing: Determining which shipping service is valid for the specified country.

Protocol Mediation: Translating the standard Salesforce request into the specific format (REST, SOAP, XML, etc.) required by each individual shipping provider.

Maintenance: When a shipper is added or removed, the change is made in the middleware without requiring any code or metadata updates in Salesforce.

Option A (Picklists) creates a high administrative burden and does not solve the underlying technical complexity of making callouts to dozens of different APIs. Option B (Platform Events) is asynchronous and would introduce unnecessary latency for a sales rep who needs an estimate " on the spot " to complete an order. Middleware abstraction provides a scalable, maintainable, and agile architecture that allows NTO to optimize its shipping operations without disrupting the CRM user experience.

Standard synchronous Apex callouts have a timeout limit, and more importantly, Salesforce limits the number of long-running requests (those lasting longer than 5 seconds) that can execute concurrently. If a payment gateway consistently takes 30 seconds, a few simultaneous users could easily exhaust the org ' s concurrent request limit, causing the entire system to stop responding.

The Continuation pattern (Option C) is designed specifically for this " long-wait " scenario. It allows the Apex request to be suspended while waiting for the external service to respond, freeing up the Salesforce worker thread to handle other users. Once the gateway responds, the suspended process resumes and returns the result to the student ' s browser. This provides the " real-time " experience required for the student to retry immediately without the risk of bringing down the entire community due to thread exhaustion.

When dealing with multiple external service providers (like different regional shippers) that have varying API requirements, the most scalable architectural choice is an Enterprise Service Bus (ESB) or middleware solution. This scenario describes a classic " Orchestration " and " Transformation " use case.

An ESB excels at:

1. Routing/Mediation: The ESB can receive a single, standardized request from Salesforce ( " Get Shipping Rates " ) and use business logic to determine which regional carrier ' s API should be called.

2. Transformation: Each carrier likely has a distinct XML or JSON schema. The ESB can transform the common data model sent by Salesforce into the specific format required by the chosen shipper.

3. Protocol Bridging: If one shipper uses SOAP and another uses REST, the ESB handles these technical differences, allowing Salesforce to interact with a single, simplified interface.

Option A (Apex REST) would require the Salesforce team to maintain custom code for every new shipping provider added, leading to high technical debt and maintenance challenges. Option C is incorrect because an ESB is a back-end infrastructure component, not a user interface tool.

By utilizing an ESB, Northern Trail Outfitters decouples Salesforce from the complexities of the shipping providers ' APIs. This " Hub and Spoke " model means that adding a new regional shipper in the future only requires configuration within the ESB, rather than a full code deployment in Salesforce. This provides the agility and architectural separation necessary for a global retail operation.

When migrating from a legacy environment to a multi-tenant cloud platform like Salesforce, Data volume and processing volume represent the most critical technical constraints. Legacy systems often operate without the strict governor limits found in Salesforce, meaning they may push large datasets or high-frequency updates that could easily overwhelm standard Salesforce APIs.

An integration architect must evaluate these volumes to determine the appropriate integration pattern:

Pattern Selection: If the daily volume involves millions of records, the architect must recommend the Bulk API rather than standard REST or SOAP APIs to avoid hitting daily API limits.

Synchronous vs. Asynchronous: High processing volumes often necessitate asynchronous patterns (such as Fire-and-Forget or Batch) to prevent user-interface lag and " Concurrent Request Limit " errors.

Data Virtualization: If the legacy data volume is massive but only needs to be viewed occasionally, the architect might consider Salesforce Connect to avoid consuming expensive internal data storage.

While reporting (Option A) and multi-currency (Option C) are important functional requirements, they do not fundamentally dictate the technical " plumbing " or scalability of the integration architecture. By prioritizing the analysis of volume and processing needs, the architect ensures the new modernization effort is stable, performant, and capable of scaling as the business grows within the bounds of the Salesforce platform.

To secure outbound HTTP requests from Salesforce, architects must implement defense-in-depth measures at both the authentication and transport layers.

Named Credentials are the primary architectural recommendation for managing callout endpoints and authentication in a secure, declarative manner. They abstract the endpoint URL and authentication parameters (such as usernames, passwords, or OAuth tokens) away from Apex code. This prevents sensitive credentials from being hardcoded or exposed in metadata, significantly reducing the risk of accidental disclosure. By using Named Credentials, Salesforce handles the heavy lifting of authentication headers automatically, ensuring that the integration is both secure and maintainable.

Two-way SSL (Mutual Authentication) provides an additional layer of security at the transport layer. While standard SSL ensures that Salesforce trusts the external server, Two-way SSL requires the external server to also verify the identity of the Salesforce client. The architect first generates a certificate in Salesforce, which is then presented to the external system during the TLS handshake. This " mutual trust " ensures that the external service only accepts requests from an authorized Salesforce instance, protecting against man-in-the-middle attacks and unauthorized access attempts.

While an Authorization Provider (Option C) is essential for OAuth-based flows, it is typically used within the configuration of a Named Credential rather than as a standalone security method for a generic HTTP request. By combining Named Credentials with Two-way SSL, the architect ensures that the integration is secured at both the session/authentication level and the network/transport level, adhering to enterprise security best practices for cloud-to-on-premise or cloud-to-cloud communication.

In a Synchronous Request-Reply pattern, the user ' s experience is directly tied to the performance of the external service. For a mission-critical " Available-to-Promise " (ATP) service during checkout, the most vital scalability consideration is the typical and worst-case historical response times of the target system.

Salesforce imposes strict Governor Limits on synchronous callouts to protect platform health. Specifically, if an ATP callout takes longer than 120 seconds, the transaction will time out. More importantly, Salesforce limits the number of long-running requests (those lasting longer than 5 seconds). If multiple users are checking out simultaneously and the external inventory system begins to respond slowly (worst-case), those requests can quickly occupy all available slots in the concurrent request queue, leading to " Concurrent Request Limit Exceeded " errors for all users in the org.

By analyzing historical response times, the architect can determine if the service is reliable enough for a synchronous callout. If the worst-case response time frequently exceeds 5 seconds, the architect should consider a more resilient pattern, such as the Continuation pattern or an asynchronous approach, to prevent blocking the UI thread and hitting platform limits. Options A and C are irrelevant to synchronous checkout performance; query cursors relate to database state, and batch jobs are asynchronous background processes that do not impact real-time user checkout latency.