MB-500 · Question #371
Drag and Drop Question A company has a Dynamics 365 finance and operations app. The company has the following requirements for data entities: - Must asynchronously import XML files that contain…
The correct answer is Composite data entity; Aggregate data entity. Dynamics 365 F&O Data Entity Types - Explained --- The Two Requirements and Their Correct Matches | Requirement | Correct Entity Type | |---|---| | Asynchronously import XML files with sales order header + line data | Composite data entity | | OData endpoint exposing measures…
Question
Exhibit
Answer Area
Drag items
Correct arrangement
- Composite data entity
- Aggregate data entity
Explanation
Dynamics 365 F&O Data Entity Types - Explained
The Two Requirements and Their Correct Matches
| Requirement | Correct Entity Type |
|---|---|
| Asynchronously import XML files with sales order header + line data | Composite data entity |
| OData endpoint exposing measures and attributes from CustTransView for Power BI | Aggregate data entity |
Placement 1: Composite Data Entity → Async XML Import (Sales Order Header + Lines)
Why composite? Sales orders have a parent-child (header/line) structure. A composite data entity bundles multiple related entities (e.g., SalesOrderHeaderEntity and SalesOrderLineEntity) into a single logical unit so both can be imported together in one operation.
Technical reasons:
- Composite data entities are processed through the Data Management Framework (DMF), which natively supports asynchronous import operations.
- DMF supports XML as an import file format - matching the requirement exactly.
- Composite entities are specifically designed for hierarchical document structures (header + N lines), not flat data. A regular data entity would only handle one level.
Placement 2: Aggregate Data Entity → OData + Measures/Attributes for Power BI
Why aggregate? The requirement explicitly mentions measures and attributes - these are the defining building blocks of aggregate data entities, not transactional ones.
Technical reasons:
- Aggregate data entities are built on top of views or aggregate measurements (CustTransView qualifies), and they expose an OData endpoint consumable by Power BI via DirectQuery.
- They model data in analytical terms: measures (e.g., sum of transaction amounts) and attributes (e.g., customer, date - dimensions for slicing).
- This is the only entity type in D365 F&O that natively surfaces measures and dimension attributes for BI tooling via OData.
Common Mistakes and Misconceptions
-
Using a regular (standard) data entity for the XML import: Regular entities handle flat, single-table data. They cannot represent a sales order with multiple lines in a single import operation - you'd have to import header and lines separately and manage relationships manually.
-
Assuming composite entities support OData: They do not. Composite entities are DMF-only (import/export). They have no OData exposure and cannot serve Power BI.
-
Using a regular entity for the Power BI/OData requirement: Regular entities do expose OData, but they do not support the concept of measures - they return raw rows, not aggregated analytical data. The word "measures" in the requirement is the signal that aggregate data entities are required.
-
Overlooking the word "asynchronously": DMF with composite entities supports async batch processing. OData (used by aggregate entities) is synchronous and request-driven - so this word is also a clue pointing away from aggregate entities for the first requirement.
Topics
Community Discussion
No community discussion yet for this question.