An enterprise is building a Copilot Studio agent that allows purchasing managers to query SAP for current purchase order status, vendor details, and open GR/IR (Goods Receipt/Invoice Receipt) items. SAP ECC is hosted on-premises. The organization has already deployed an on-premises data gateway. A developer needs to design the integration approach to expose relevant SAP data to the agent. Which integration architecture is most appropriate for this scenario?

SAP ECC on-premises does not have a native cloud API. However, SAP Gateway, an ABAP middleware layer, exposes SAP business objects such as purchase orders, vendors, and GR/IR items as OData services. These OData endpoints can be consumed by Power Platform custom connectors.

The custom connector approach that calls SAP OData services exposed through SAP Gateway, routes requests through the on-premises data gateway, and configures the connector in Copilot Studio as an agent action with input parameters for purchase order number and vendor ID is correct because it uses the architecturally appropriate components for on-premises SAP integration with Power Platform. SAP Gateway OData services provide a standards-based REST interface over SAP business data. The custom connector defines the API actions that the Copilot Studio agent can call as agent actions. The on-premises data gateway acts as a secure relay, allowing Power Platform services in Azure to reach the on-premises SAP Gateway without requiring inbound internet connectivity to the on-premises network. This is exactly the integration pattern Microsoft and SAP recommend for Power Platform-SAP connectivity.

The approach that installs the SAP BAPI connector directly on the Copilot Studio agent host in Azure and configures BAPI RFC calls to invoke SAP function modules for purchase order and vendor lookups without an intermediary gateway is incorrect. RFC and BAPI calls require a native SAP client library, such as the SAP .NET Connector or SAP NWRFC SDK, and network-level access to the SAP application server. Azure-hosted Copilot Studio agents cannot directly install SAP client libraries or make RFC connections to on-premises SAP application servers without an intermediary. Even if this were technically possible, it would bypass the on-premises data gateway security model and expose the SAP system to direct cloud connectivity risks.

The approach that uses Power BI Embedded to build a purchase order dashboard connected to SAP and then configures the Copilot Studio agent to render Power BI visuals inline in the chat response as the data retrieval mechanism is incorrect for the use case. Power BI is a data visualization tool, not a data query API for agent actions. Rendering Power BI visuals in chat responses is not a supported Copilot Studio integration pattern for retrieving structured SAP data. A purchasing manager asking for a specific PO status needs a text or card response, not an embedded chart that requires user interaction.

The approach that exports SAP purchase order data to an Azure SQL Database on a nightly ETL schedule and then configures the Copilot Studio agent to query Azure SQL for purchase order status, accepting a maximum data freshness of 24 hours, would work for reporting but fails the freshness requirement implied by the scenario. Purchase order status changes throughout the business day as vendors ship goods, GR/IR items are cleared, and invoices are posted. A 24-hour ETL lag means the agent would regularly provide outdated status information for active transactions. This approach is appropriate for historical analytics but not for operational purchase order queries.

Exam tip: For SAP integration questions on AB-620, the on-premises data gateway plus SAP Gateway OData plus custom connector is the canonical architecture. Know that SAP Gateway exposes OData v2 and v4 services, that the on-premises data gateway handles the network traversal for on-premises systems, and that custom connectors defined with OpenAPI specifications can wrap these OData endpoints for Copilot Studio consumption.