サンプル問題 1： An integration architect has built a solution using REST API, updating Account, Contact, and other related information. The data volumes have increased, resulting in higher API calls consumed, and some days the limits are exceeded. A decision was made to decrease the number of API calls using bulk updates. The customer prefers to continue using REST API to avoid architecture changes. Which REST API composite resources should the integration architect use to allow up to 200 records in one API call?
A: Batch
B: SObject Tree
C: Composite
正解：B
Explanation: When designing high-volume integrations, the Salesforce Platform Integration Architect must distinguish between standard REST resources and "Composite" resources to optimize API consumption. The Salesforce REST API provides several composite resources to group multiple operations into a single call, thereby reducing the overhead of multiple HTTP requests and helping to stay within daily API limits. According to Salesforce documentation on Composite Resources, the sObject Tree resource (/services/data/vXX.X/composite/tree/) is specifically designed to handle multiple records in a single request. While it is primarily marketed for creating complex hierarchies (parent-child relationships), it has a unique limit that allows for up to 200 records to be processed in a single call. These records can even be unrelated records of the same type. This is a significant advantage over the standard Batch and Composite resources. The Composite resource and the Batch resource both have a much lower limit of 25 subrequests per call. While each subrequest in a Batch call could technically be a collection operation, the question specifically asks for the resource that natively supports the "200 records" threshold preferred for bulk-style updates within the REST framework. By utilizing the sObject Tree resource, the architect can bundle 200 record updates into a single transaction, effectively reducing API consumption by a factor of 200 compared to individual REST calls. This aligns with the requirement to avoid major architectural changes (like switching to the Bulk API 2.0) while solving the immediate problem of exceeding daily governor limits. In the context of the Integration Architect exam, understanding these specific payload limits is crucial for selecting the most efficient "Request-Reply" or "Data Synchronization" pattern.
サンプル問題 2： A business requires automating the check and updating of the phone number type classification (mobile vs. landline) for all incoming calls delivered to its phone sales agents. The following conditions exist: At peak, the call center can receive up to 100,000 calls per day. The phone number type classification is a service provided by an external service API. Business is flexible with timing and frequency to check and update the records (throughout the night or every 6-12 hours is sufficient). A Remote-Call-In pattern and/or Batch Synchronization (Replication via ETL: System -> Salesforce) are determined to work with a middleware hosted on customer premise. In order to implement these patterns and mechanisms, which component should an integration architect recommend?
A: ConnectedApp configured in Salesforce to authenticate the middleware
B: An API Gateway that authenticates requests from Salesforce into the middleware (ETL/ESB)
C: Remote Site Settings configured in Salesforce to authenticate the middleware
正解：A
Explanation: In this scenario, the architecture involves a Remote-Call-In pattern or Batch Synchronization, where an external system (the middleware or ETL tool) initiates communication with Salesforce to update records. For any external system to securely access Salesforce APIs and perform these updates, it must be authenticated and authorized. The Connected App is the foundational framework that allows an external application to integrate with Salesforce using APIs and standard protocols, such as OAuth 2.0 and SAML. By configuring a Connected App, the architect can define which permissions (Scopes) the middleware has, such as the ability to access data via the REST or Bulk API. This is the correct choice because the middleware needs to "log in" to Salesforce to push the phone classification data back into the Account or Contact records. Option B, an API Gateway, is typically used to manage and secure requests going out of an organization to external services, or to provide a facade for on-premise APIs; it does not handle the inbound authentication into Salesforce itself. Option C, Remote Site Settings, is a configuration used solely to permit Salesforce to make outbound calls to a specific external URL (for example, if Salesforce were calling the phone classification service directly via Apex). Given that the business is flexible with timing (allowing for nightly or 12-hour syncs) and handles 100,000 calls, a Batch Synchronization pattern via an ETL tool is highly efficient. The ETL tool will authenticate against the Connected App using a secure OAuth flow (such as the JWT Bearer Flow for server-to-server integration), retrieve the new phone numbers, call the external classification API, and then bulk-update the Salesforce records. This setup ensures a secure, scalable, and manageable integration that respects Salesforce's security architecture while meeting the high-volume data requirements of the call center.
サンプル問題 3： A company captures orders and needs to send them to the Order fulfillment system. The user is not required to have confirmation from the Order fulfillment system. Which system constraint question should be considered when designing an integration to send orders from Salesforce to a fulfillment system?
A: What latency is acceptable for orders to reach the fulfillment system?
B: Can the fulfillment system implement a contract-first Outbound Messaging interface?
C: Which system will validate order shipping addresses?
正解：A
Explanation: When designing an integration where the user does not require immediate confirmation, the architect is moving away from a synchronous "Request-Reply" pattern toward an asynchronous "Fire-and-Forget"16 or "Batch Processing" pattern. In such scenarios, the most critical architectural constraint is defining the latency requirements. Latency dictates the technical choice of the integration tool. If the fulfillment system needs the order within seconds of creation to begin a high-speed picking process, the architect might choose Salesforce Outbound Messaging or an Apex Callout triggered by a Platform Event. If the system only needs to process orders once an hour or overnight, a Batch ETL process is more appropriate. Understanding the acceptable delay (latency) ensures that the solution meets business expectations without over-engineering for real-time performance where it isn't required. While Option B (Outbound Messaging) is a valid technical capability, it is a specific solution rather than a high-level "system constraint question" that drives the initial design phase. Option C (Address Validation) is a functional requirement regarding data integrity, but it does not define the architectural framework of the integration as effectively as latency does. By identifying the latency threshold, the architect can determine if the integration should be near real-time, hourly, or daily, which in turn influences how the system handles error recovery, retries, and transaction volumes.
