ARC-101 Practice Questions

The CIO's primary concern is the scalability and long-term viability of the current point-to-point integration architecture. Direct @future callouts create tight coupling between Salesforce and each target system. As the number of systems grows, this approach leads to a brittle, unmanageable "spaghetti architecture."

Implementing an Enterprise Service Bus (ESB) or a similar middleware layer introduces a hub-and-spoke model. This fundamentally decouples the systems. Salesforce communicates with a single endpoint (the ESB), which then handles the complex tasks of routing, message transformation (mediation), and orchestration to the various target systems. This architectural pattern is designed specifically to enhance scalability, simplify maintenance, and provide centralized governance, directly mitigating the CIO's strategic concerns.

1. Salesforce Architects

"Architect's Guide to Integration Patterns and Practices" (salesforce.com)

Page 6

"Point-to-Point Integration": This section describes the pattern currently in use

noting

"...it can become brittle and difficult to maintain as the number of systems and integrations grow." This validates the CIO's concern.

Page 7

"Hub-and-Spoke": This section describes the solution proposed in option D. It states

"This model provides a more scalable and manageable approach to integration... It reduces the number of connections required and centralizes the management of integrations."

2. Hohpe

G.

& Woolf

B. (2003). Enterprise Integration Patterns: Designing

Building

and Deploying Messaging Solutions. Addison-Wesley.

Chapter 2

"Integration Styles

" Section "Point-to-Point Connection": The book highlights that while simple for two applications

this style results in a "rat's nest" of connections that is expensive to maintain and extend as more applications are added.

Chapter 2

"Integration Styles

" Section "Messaging": This section introduces messaging middleware (the core of an ESB) as the solution to decouple applications

enabling them to communicate asynchronously and reliably without direct knowledge of each other

thus improving scalability.

3. Salesforce Developer Documentation

"Integration Patterns Overview"

The documentation contrasts simple patterns like "Remote Call-In" with more robust patterns like "Publish / Subscribe

" which often use a message bus (middleware). It emphasizes that for decoupling and scaling to multiple subscribers

a pub/sub pattern with a message bus is the superior choice

aligning with the ESB approach.

For securing an outbound HTTPS request from Salesforce, Named Credentials and Two-way SSL are the most direct and appropriate security methods.

A Named Credential is the standard Salesforce feature for managing outbound callouts. It abstracts the endpoint URL and handles the authentication protocol (e.g., Basic Auth, OAuth 2.0), preventing sensitive credentials from being hardcoded in Apex code. Salesforce manages the authentication, simplifying the process and enhancing security.

Two-way SSL (also known as mutual TLS or mTLS) provides transport-level security. In this method, both the client (Salesforce) and the server (the external system) authenticate each other by presenting and validating digital certificates. This ensures that Salesforce is communicating with the legitimate server and the server is receiving requests from the correct Salesforce org.

1. Salesforce Developer Documentation

Apex Developer Guide: "A named credential specifies the URL of a callout endpoint and its required authentication parameters in one definition... Salesforce manages all authentication for Apex callouts that specify a named credential as the callout endpoint." (See section: "Named Credentials as Callout Endpoints").

2. Salesforce Help

Certificate and Key Management: "You can use certificates to authenticate your Salesforce org to an external website... For example

for an outbound message to an external endpoint that requires two-way SSL authentication." This describes the use case for client certificates in mTLS.

3. Salesforce Developer Documentation

Security Guide: "Mutual authentication

also known as two-way transport layer security (TLS) authentication

verifies that both the client and server in a communication are who they claim to be... Salesforce supports mutual authentication for outbound messages and Apex callouts." (See section: "Mutual Authentication").

4. Salesforce Developer Documentation

Connected Apps: "A connected app is a framework that enables an external application to integrate with Salesforce using APIs and standard protocols

such as SAML

OAuth

and OpenID Connect." This highlights its primary role in enabling external apps to connect to Salesforce.

This scenario requires a real-time, scalable, and decoupled integration to send business event data to an external analytics system. Platform Events are the ideal Salesforce feature for this, creating a durable event stream that external subscribers can consume in real-time.

Option C correctly addresses the events initiated by a customer creating a Case (e.g., for an exchange or cancellation). An Apex trigger on the Case object is the standard mechanism to react to record creation and can publish a Platform Event to the event bus.

Option D correctly addresses the events initiated by a service representative clicking a specific UI element. The most direct way to capture this user interaction is via the custom Apex controller backing the UI element (e.g., a Lightning Web Component), which can then publish the corresponding Platform Event.

1. Platform Events Developer Guide: "Use platform events to connect business processes in Salesforce and external apps through the exchange of real-time event data...Publish event messages from Salesforce apps using declarative tools or programmatically with Apex or APIs. Subscribe to platform events in Salesforce using Apex triggers or in an external app..." This supports using Platform Events for real-time integration with external systems.

2. Apex Developer Guide

"Triggers" section: "Triggers enable you to perform custom actions before or after events to records in Salesforce

such as insertions

updates

or deletions." This confirms a trigger is the correct tool to react to the creation of a Case (Option C).

3. Apex Developer Guide

"Publish Platform Events" section: "To publish event messages

you call the EventBus.publish method... You can call this method in Apex code that you expose as a custom action in a Lightning component

for example." This directly supports using an Apex controller to publish an event from a UI action (Option D).

4. Salesforce Well-Architected - Event-Driven Architectures: This framework advocates for event-driven patterns for asynchronous processing and system integration. It states

"Decoupling systems using events allows them to evolve independently... This pattern is ideal for broadcasting state changes to many interested systems." This validates the architectural choice of Platform Events over point-to-point callouts or outbound messages.

The core requirement is to establish a secure, firewalled integration between cloud applications and on-premise resources. An API Gateway (A) serves as a dedicated, secure entry point for all incoming requests, allowing for centralized policy enforcement, security screening, and traffic management. To comply with the guideline that all traffic must pass through a secure firewall, the standard architectural pattern is to place this public-facing gateway component within a Demilitarized Zone (DMZ) or perimeter network (B). This isolates the integration layer from the internal trusted network, ensuring all traffic is inspected by firewalls before reaching sensitive on-premise systems.

1. MuleSoft Documentation

"Deployment Models": MuleSoft's Anypoint Platform

a leading integration solution

explicitly describes a hybrid deployment model where the control plane is in the cloud

but the runtime plane (which executes integrations and can host an API Gateway) is deployed on-premises within the customer's network. This on-premise runtime is typically placed in a DMZ to securely mediate access to backend resources. This supports the concepts in both (A) and (B).

Reference: MuleSoft Documentation

About Anypoint Platform > Deployment Models.

2. Richards

M. (2020). Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media.

Reference: Chapter 17

"Architectural Patterns

" discusses the API Gateway pattern as a single entry point for a system. Chapter 21

"Deployment Patterns

" implicitly supports placing such edge services in secured network zones like a DMZ for controlled access to internal systems. The combination of these principles validates options A and B.

3. Microsoft Azure Documentation

"Demilitarized zone (DMZ)": This official vendor documentation describes the core concept of a DMZ as a perimeter network that provides a layer of security between the internet (or cloud) and an enterprise's internal network. It explicitly states that components like API gateways are typically deployed in the DMZ.

Reference: Microsoft Azure

Cloud Adoption Framework > Ready > Azure landing zones > Network topology and connectivity > "Implement a secure hybrid network". This section details using a DMZ to protect on-premises resources from cloud-based workloads.

The core requirement is to update a field that the user cannot edit due to Field Level Security (FLS). Standard API calls, such as the standard REST API (Option C) or SOAP API (Option A), execute in the context of the authenticated user and respect all their permissions, including FLS. Therefore, any attempt to update the read-only geolocation field using these standard APIs would fail.

The correct solution is to create a custom Apex REST service (Option D). By default, Apex code runs in system mode, which bypasses object and field-level security. This allows the Apex method to update the field programmatically, even though the user does not have the direct permission to do so, thus satisfying the requirement.

1. Salesforce Developer Documentation

Apex Developer Guide

"Enforcing Object and Field Permissions": "By default

Apex code runs in system context... Apex code has access to all objects and fields—object permissions

field-level security

sharing rules aren’t applied for the current user." This directly supports why an Apex-based solution (Option D) is necessary to bypass the FLS restriction.

2. Salesforce Developer Documentation

Apex Developer Guide

"Exposing Apex Classes as REST Web Services": This document describes the mechanism for creating custom REST endpoints using Apex (@RestResource annotation)

which is the technical implementation for Option D.

3. Salesforce REST API Developer Guide

"Introduction > Security Considerations": "Access to resources is controlled by the user’s profile and permission sets." This confirms that standard REST API calls (Option C) are bound by user permissions

making them unsuitable for this scenario.

The scenario requires a "Fire and Forget" integration from Salesforce to a legacy system's SOAP API. Salesforce's Outbound Message is a declarative, native feature designed specifically for this purpose. It sends a SOAP notification to a designated endpoint asynchronously without waiting for a response, perfectly matching the fire-and-forget pattern.

For the return communication from the legacy system to Salesforce, the requirement is for a "strongly typed format." The Enterprise WSDL is strongly typed, meaning it is bound to the specific configuration of the Salesforce org, including its custom objects and fields. This provides a strict contract for the external system, fulfilling the requirement.

1. Salesforce Architects Documentation

Integration Patterns and Practices: The "Fire-and-Forget" pattern description notes that declarative features like workflow-driven outbound messages are a primary implementation method from Salesforce. This supports using Outbound Message for the first leg of the integration. (See "Remote Process Invocation—Fire and Forget" pattern).

2. Salesforce SOAP API Developer Guide

"Introduction to WSDL": This guide explicitly differentiates the two WSDL types. It states

"The Enterprise WSDL is strongly typed... It is tied to a specific configuration of Salesforce." This directly supports the use of Enterprise WSDL for the "strongly typed format" requirement.

3. Salesforce SOAP API Developer Guide

"Introduction to WSDL": The guide contrasts the Enterprise WSDL with the Partner WSDL

stating

"The Partner WSDL is loosely typed... It is used for applications that work with data from multiple Salesforce organizations." This confirms why Partner WSDL is incorrect for this scenario.

4. Salesforce Help

"Set Up Outbound Messages": This documentation describes Outbound Messages as a type of action that "sends a secure

configurable API message (in XML format) to a designated listener." This confirms its role as a SOAP-based

fire-and-forget mechanism.

The scenario involves a long-running callout (up to 90 seconds) initiated from a Lightning UI that must pass through a gateway with a short timeout (9 seconds). This requires an asynchronous integration pattern.

1. (A) The ESB (MuleSoft) must immediately acknowledge the request and return a correlation or requestID. This decouples Salesforce from the long-running backend process, satisfying the 9-second gateway timeout. Mule then manages the state of the long-running transaction.

2. (C) On the Salesforce side, a Continuation is the ideal mechanism to make a long-running callout from a Lightning component. It frees up the Apex thread, preventing it from being blocked and hitting governor limits, which is crucial with 3,000 concurrent users.

3. (E) To retrieve the result, a client-side polling mechanism is the most viable option. After receiving the requestID, a "Check Update" button allows the user to poll for the result. The alternative, using Platform Events (Option D), is not feasible as the 3,000 concurrent users would exceed the platform's limit of 2,000 concurrent CometD subscribers.

B: A synchronous callout will always fail. The 9-second API Gateway timeout is much shorter than the potential 90-second response time from the external system.

D: This solution is not scalable to 3,000 concurrent users. The empApi component uses the CometD protocol, which is subject to a limit of 2,000 concurrent client subscribers per org.

1. Continuation Framework: Salesforce Apex Developer Guide

"Continuation Class". This official documentation explains how Continuations are used to make long-running requests from a UI without blocking threads

which is the exact use case for initiating the call. (See section: "Making Long-Running Callouts with the Continuation Class").

2. Streaming API Limits (CometD): Salesforce Platform Events Developer Guide

"Streaming API Limits". This document explicitly states the "Maximum number of concurrent clients (subscribers) across all channels" is 2

000 for Enterprise Edition and above. This limit makes option D unfeasible for the 3

000 concurrent users specified.

3. Asynchronous Integration Patterns: MuleSoft Documentation

"Asynchronous flows". This documentation describes patterns where a flow can process a message asynchronously

often returning an immediate acknowledgment while processing continues in the background

which aligns with the recommendation in option A.

4. Asynchronous Request-Reply Pattern: Gregor Hohpe & Bobby Woolf

Enterprise Integration Patterns: Designing

Building

and Deploying Messaging Solutions. Addison-Wesley

2003. Chapter 10

"Messaging Systems

" discusses the Asynchronous Request-Reply pattern

where a requester sends a message and expects a reply later. The use of a requestID (correlation identifier) and a polling mechanism are core components of this pattern

validating options A and E as a combined strategy. (See section: "Asynchronous Request-Reply").

In Salesforce, when Platform Events are published from within an Apex transaction using the EventBus.publish() method, the events are not sent immediately. Instead, they are queued. The actual publication to the event bus occurs only after the entire Apex transaction has been successfully committed to the database. This transactional behavior is a critical feature that ensures data consistency, as it prevents events from being published if the originating transaction fails and is rolled back. The events are discarded along with the other rolled-back changes.

1. Salesforce Platform Events Developer Guide

"Publish Events with Apex": "To publish an event message

you call the EventBus.publish() method... The event is published after the transaction is committed. If the transaction fails

the event isn't published."

2. Salesforce Apex Developer Guide

"EventBus Class": The documentation for the publish method states: "The publishing of events is transactional. The events are published only after the transaction completes successfully. If the transaction is rolled back

the events aren't published."

3. Salesforce Platform Events Basics Trailhead Module

"Publish and Subscribe to Platform Events": "When you publish a platform event with Apex

the EventBus.publish() method call is queued. The event is actually published when the transaction is successfully committed."

The most precise and recommended solution is the Salesforce B2C Commerce to Service Cloud Connector. This is a pre-built, managed solution specifically designed to integrate these two platforms. It synchronizes customer and order data from B2C Commerce directly into Service Cloud, providing service agents with a 360-degree view of the customer, including their order history, without requiring extensive custom development. This connector is the most direct and efficient way to meet the specified requirement.

1. Salesforce Help

B2C Commerce to Service Cloud Connector: "The B2C Commerce to Service Cloud Connector provides a link between a B2C Commerce Cloud instance and a Service Cloud instance. The connector provides your service agents with a 360-degree view of your customers by synchronizing customer and order data between the two clouds." (Salesforce Help

B2C Commerce to Service Cloud Connector

Overview section).

2. Salesforce Help

Set Up the B2C Service and Commerce Connector: "The B2C Service and Commerce Connector lets you seamlessly connect your Commerce Cloud and Service Cloud orgs to provide a single view of your customer to your service agents." (Salesforce Help

Set Up the B2C Service and Commerce Connector

Introduction).

3. Salesforce Developers

Open Commerce API Documentation: This documentation describes the B2C Commerce REST APIs (OCAPI) which would be used for a custom integration

highlighting the development effort required

which is abstracted away by the connector. (Salesforce Developers

Open Commerce API

Version 23.10

Introduction).

4. MuleSoft Anypoint Platform Documentation: "Anypoint Platform is a complete solution for API-led connectivity that helps companies build application networks of apps

data

and devices through both on-premises and cloud environments." This shows its scope as a broad platform

contrasting with the specific nature of the connector. (MuleSoft Docs

Anypoint Platform

"What is Anypoint Platform?").

For a large enterprise with business-critical processes and multiple back-office systems, a middleware platform (such as an Enterprise Service Bus or an Integration Platform as a Service) is the standard architectural solution. Middleware is specifically designed to manage complex integrations by providing a centralized hub for orchestration, transformation, and routing. Crucially, these platforms offer robust, out-of-the-box capabilities for reliability (e.g., guaranteed delivery, retry logic), centralized monitoring, logging, and real-time alerting. This directly addresses the customer's requirements for a reliable, manageable, and observable integration landscape in a regulated environment.

1. Salesforce Architects

"Architect's Guide to Integration Patterns and Practices": In the section "Remote Process Invocation—Request and Reply

" the guide explicitly recommends middleware for complex landscapes: "In a more complex landscape

with multiple systems to be integrated

it’s common to use an enterprise service bus (ESB) to implement this pattern... The ESB can also provide other cross-cutting concerns

such as monitoring

error handling

and service-level agreement (SLA) management." This directly supports the use of middleware for monitoring and reliability.

2. Salesforce Architects

"Architect's Guide to Building Forms": In the "Data Integration" section

the guide discusses using middleware for orchestrating calls to multiple back-end systems

stating

"Use middleware to orchestrate calls to multiple back-end systems. This approach is more scalable and manageable than creating complex point-to-point integrations." This reinforces the scalability and manageability benefits of middleware over other approaches.

3. Hohpe

G.

& Woolf

B. (2003). Enterprise Integration Patterns: Designing

Building

and Deploying Messaging Solutions. Addison-Wesley. (A foundational academic text for integration architecture). Chapter 3

"Messaging Systems

" and Chapter 6

"Message Routing

" detail how middleware provides reliability through mechanisms like Message Channels and centralizes control

which is essential for monitoring and management in complex enterprise scenarios.