Drag and Drop Question A company uses Dynamics 365 Finance. The company requires a new custom service to allow transactional data to be attributed to a customer's order. You need to create the…

Question

Exhibit

Answer Area

Explanation

Custom Service Creation in Dynamics 365 Finance - Ordering Explained

The Core Principle

Building a custom service in D365F follows a bottom-up dependency chain: each step creates something the next step depends on. You cannot reference something that doesn't exist yet.

Step-by-Step Breakdown

1. Create request and response classes

These are X++ data contract classes decorated with DataContractAttribute and DataMemberAttribute. They define the shape of data flowing into and out of the service.

They come first because the service class methods will use them as parameter and return types. Nothing else in the chain can be built until you know what data the service handles.

Common mistake: skipping these and putting raw primitives directly in the service class - this breaks serialization and WSDL generation.

2. Create a service class

This is the X++ class containing the actual business logic methods (e.g., attributing transactional data to a customer order). It is decorated with SysEntryPointAttribute on its methods.

It comes second because it consumes the request/response classes defined in step 1. Without those, you cannot properly define the method signatures.

Common mistake: treating this as step 1. The class shell can exist, but you cannot write correct method signatures without the contracts.

3. Create and assign the service object

In the AOT (Application Object Tree), a Service node is created that points to the service class from step 2. This is the bridge between your X++ class and the service infrastructure.

It comes third because it must reference an existing service class. No class = nothing to point to.

Common mistake: confusing the service object (AOT node) with the service class (X++ code). They are distinct artifacts.

4. Create and assign the service group

A Service Group bundles one or more service objects and publishes them as a deployable endpoint. It is the outermost wrapper that makes the service externally accessible.

It comes last because it aggregates service objects - which must already exist - into a single publishable unit.

Common mistake: creating the service group first as a "container" and trying to add objects later mid-build. The group has nothing meaningful to expose until the objects are complete.

Summary Chain

Data shape (contracts) → Logic (service class) → AOT registration (service object) → Publication (service group)

Each layer depends entirely on the layer beneath it, making this a strict sequential dependency - not a matter of preference.

No community discussion yet for this question.