MB-500 · Question #373
Drag and Drop Question You are working on a project that uses out-of-the-box OData endpoints and custom web services. HTTP calls must be used to retrieve data and perform operations with minimal…
The correct answer is OData; Custom service; OData. Dynamics 365 F&O Integration Endpoints - Explanation This question tests knowledge of Microsoft Dynamics 365 Finance & Operations integration patterns. The key constraint is: automated, no user interaction, HTTP-based, minimal development effort. --- Why Excel Add-in is Never…
Question
Exhibit
Answer Area
Drag items
Correct arrangement
- OData
- Custom service
- OData
Explanation
Dynamics 365 F&O Integration Endpoints - Explanation
This question tests knowledge of Microsoft Dynamics 365 Finance & Operations integration patterns. The key constraint is: automated, no user interaction, HTTP-based, minimal development effort.
Why Excel Add-in is Never the Answer Here
Eliminate it immediately. Excel add-in requires a human to open Excel, refresh data, and publish changes. The question explicitly forbids user interaction. It's a productivity tool, not an integration endpoint.
Placement-by-Placement Breakdown
1. Obtain a list of customers from a customer group → OData
OData exposes standard D365 data entities (like CustCustomerV3Entity) as REST endpoints out of the box. A customer list query is a simple GET with a $filter parameter - pure read, no business logic. This is exactly what OData is designed for: low-effort, standard CRUD on existing entities. No custom code needed.
2. Post a sales order invoice → Custom service
"Posting" in ERP means finalizing a business document - triggering validations, ledger entries, tax calculations, and workflow. This is not a CRUD operation. OData cannot invoke complex business actions like posting. Custom services expose specific business logic methods (via REST or SOAP) that can be called programmatically and automated without user interaction. This requires more development effort than OData, but it's the only viable option here.
3. Obtain a vendor balance → OData
Like requirement #1, vendor balance is available through a standard data entity. It's a read operation - a GET request against an existing entity. OData handles this out of the box with minimal development effort.
Common Mistakes
| Mistake | Why It's Wrong |
|---|---|
| Using Custom service for customer/vendor reads | Overkill - OData already exposes these entities; custom services add unnecessary development work |
| Using OData to post an invoice | OData supports POST for creating records, but posting (finalizing) an invoice requires business logic methods only accessible via Custom service |
| Picking Excel add-in for any automated task | Requires manual user steps - disqualified by the question's constraints |
Rule of thumb: OData = read data or simple writes on standard entities. Custom service = trigger complex business operations.
Topics
Community Discussion
No community discussion yet for this question.