Course Objectives

•
•
•
Module 1
Data Entities
Module 1: Data Entities

• Overview
• Supported Scenarios
Overview
Normalized Tables (Customer Data)
Electronic Address
Customer (LogisticsElectronicAddress)
(CustTable)

Party Location Postal Address

(DirPartyTable) (LogisticsLocation) (LogisticsPostalAddress)

Party-Location
Location roles
relationship
(LogisticsLocationRole)
(DirPartyLocation)

Party-Location Role
relationship
(DirPartyLocationRole)
Entity Model (Customer)

Customer entity

• Account number
• Customer group
• Bank account
• Party Number
• Name
• Primary postal address
• Primary email
• Primary fax
Capabilities of Data Entities

ALM and Demo Integration

Single Concept Single Stack
Data Scenarios
• AxD (Document • Business Logic • Import and • OData services
Services) • Import / export export Data • Synchronous
• DIXF Entities • Integration Packages integration
• Aggregate • Programmability • Microsoft Office
Queries integration
 Single Framework Multi Use

Office Mobile/ third Integration Application lifecycle management

Scenarios

integrations party
enabled

applications File Import/ Recurring Copy Data

export integrations configuration migration

Services (OData) Data Management Platform

Pre/Post Data
Staging Validation Mapping
processing packages

Data Entity
 Categories of Entities

Parameter Reference Master Document Transaction

• Functional or • Simple • Data assets • Worksheet • Transaction

behavioral reference of the data data of the
parameters data business • Converted to business
• Set up • Specific to • Complex transactions • Posted
• Industry an industry reference • Complex transactions
specific or or business data of large structure • Pending
business process quantity • Sales orders, invoices
specific data • Units, • Customers, purchase
• Tables that dimensions, Vendors, orders, open
contain one tax codes Projects balances,
record journals
Supported Scenarios
Supported scenarios

1. Integration scenarios
• Synchronous services (OData)
• Asynchronous integration

2. Business intelligence
• Aggregate data
• Standardized key performance indicators (KPIs)

3. Application Lifecycle Management

• Configuration data provisioning
• Copy configuration between company/ environments
• Configure business processes or modules using LCS
• Data migration from legacy or external system
Module 2
Building a Data Entity
Module 2: Building a Data Entity

• Create a Data Entity

• Computed Columns and Virtual Fields
• Validations and Defaults
Create a Data Entity
Entity Design Principles

A Single
Encapsulation Public Simplicity
Contract
Entity Creation Experience
1. Data Entity wizard 2. From tables

3. Using designer APIs

Class: DataEntityViewProjectFactory
Method: CreateEntityInProject(string, AXTable, VSProjectNode)
 Demo
Business problem
Fleet Management stores customer data in the FMCustomer table and address data in the FMAddressTable table.
To access or update customer information, users must access multiple tables. Instead, we want to create a data
entity that functionally represents customer information, and that can be used to build integration solutions.
Behavioral Properties on Data Entities

Level Group Property name Display name Values Default

Entity Behavior IsReadOnly Is Read Only No, Yes No
Data Source Behavior IsReadOnly Is Read Only No, Yes No
Auto, No,
Field Behavior AllowEditOnCreate Allow edit on create Auto
Yes
Auto, No,
Field Behavior AllowEdit Allow edit Auto
Yes
Auto, No,
Field Behavior Mandatory Mandatory Auto
Yes
 Naming Guidelines
Data entity names

Do Don’t
Prefix the name with normal prefixes in Microsoft
Don’t include underscores in names.
Dynamics AX, because of the lack of namespaces.
Add the postfix “Entity” to the name to prevent
conflicts with tables and classes that have the same Don’t use abbreviations in conceptual names.
prefix.

Give the entity a conceptual name that is aligned with

the name in the en-us UI.

Result: <prefix><ConceptualName>Entity
 Naming Guidelines
Data entity field names

Do Don’t
Give the field name a conceptual name that is aligned
Don’t include prefixes in field names.
with the name in the en-us UI.
Add the postfix “ID,” “Number,” and so on, to the name of
Don’t include country/region-specific postfixes in field
a field that is part of foreign keys to prevent collision with
names.
the navigation properties.
Don’t include underscores in field names.
Don’t use abbreviations in field names.
 Naming Guidelines
Data entity relation role names

Do Don’t

Use the plural form when you name roles that have a
Don’t include prefixes in relation role names.
cardinality that is higher than 1.

Use the singular form when you name roles that have a
Don’t add the postfix “Entity” to relation role names.
cardinality of 0 (zero) or 1.

Don’t add country/region-specific postfixes to relation

Consider adding the role of the relationship as a prefix.
role names.

Don’t include underscores in relation role names.

 Naming Guidelines
Data entity relation names
Do
•Give the relation name the same name as the related role name, in singular form.

OData EntityType names

Do
•Give the EntityType a conceptual name.
The name should be the same as the conceptual name of the data entity, but without the prefix and without the
“Entity” postfix.
•Name the EntityType in singular form.

OData EntitySet (Entity Collection) names

Do
•Name the EntitySet in plural form.
Computed Columns and
Virtual Fields Overview
Overview
 Computed Columns
•
•

•
•
 Virtual Fields
•
•
•

•
 Properties of Un-Mapped Fields
Default
Category Name Type Behavior
value

•Yes – The field is synchronized as a SQL view computed column.

Requires an X++ method to compute the SQL definition string
Data IsComputedField NoYes Yes for the column.
•No – The field is a true virtual field, where inbound and
outbound values are fully controlled through custom code.

ComputedFieldMet A static DataEntity method in X++ to build the SQL expression

Data String
hod that will generate the field definition.
 Unmapped Fields Comparison
Virtual field Computed column
•Is Computed = Yes
Metadata properties Is computed = No •Computed Field Method = static
method

•X++ (override postLoad) •SQL computed column

Read
•Row by row •Set-based read possible

X++ X++
Write
(override mapEntityToDataSource) (override mapEntityToDataSource)

•Unbound to the schema, keeps the

public contract the same, but the Faster reads, large export can occur
Advantages
implementation can change directly from the view
•Call X++ methods
Validations and Defaults
 Validations : Entity-Based Validation Behavior
Validation Target Caller

•Data types
•Is called automatically from OData
•Mandatory relationships (both tables and
•Is called by the form engine when a field is
extended data types [EDTs])
DataEntity.ValidateField modified
•Any custom validation
•Isn’t called automatically if an insert/update
•Doesn’t call validateField for underlying
is fired from X++ code
mapped table fields

•Mandatory columns •Is called automatically from OData

•Relationships (both tables and EDTs) •Is called by the form engine when a record
DataEntity.ValidateWrite •Any custom validation is saved.
•Doesn’t call table-level validateWrite for •Isn’t called automatically if an insert/update
underlying tables is fired from X++ code

•Is called automatically from OData.

•DeleteActions
•Is called by the form engine when a record
•Any custom validation
DataEntity.ValidateDelete is deleted
•Doesn’t call table-level validateDelete for
•Isn’t called automatically if a delete is fired
underlying tables
from X++ code
Validations : Table-Based Validation Behavior

mapEntityToDataSource
Validations : Table-Based Validation Behavior
Validations : Table-Based Validation Behavior
Validations : Table-Based Validation Behavior
Validations : Table-Based Validation Behavior
Validations : Table-Based Validation Behavior
Validations : Table-Based Validation Behavior
Validations : Table-Based Validation Behavior
Defaults : Initializations

initializeDataSource
(Happens with company
context)
Defaults: Initializations
Defaults: DefaultRow
Module 3
Using Data Entities
Module 3: Using Data Entities
• Access Data Using X++
• Access Data Using OData
Access Data Using X++
Access Data Using X++
•
•
•
•
Demo
public static void main(Args _args)
{
FMLabCustomerEntity customer;
str license = "License";
Random r = new Random();
int rand = r.nextInt();
license = license + int2str(rand);

//Create a new record in FM lab customer entity

customer.clear();
customer.FirstName = "Bob";
customer.LastName = "Smith";
customer.DriversLicense = license;
customer.insert();

info(strfmt("Tried to insert customer '%1 %2' with license %3",

customer.FirstName, customer.LastName, customer.DriversLicense));

ttsbegin;
//Display newly created record
select forupdate customer where customer.DriversLicense==license;
info(strfmt("Found newly created customer '%1 %2' with license %3",
customer.FirstName, customer.LastName, customer.DriversLicense));
customer.FirstName = "John";
customer.update();
ttscommit;

select forupdate customer where customer.DriversLicense==license;

info(strfmt("Found modified customer '%1 %2' with license %3",
customer.FirstName, customer.LastName, customer.DriversLicense));

//Now delete the record from the entity

customer.delete();

select customer where customer.DriversLicense==license ;

info(strfmt("Deleted customer does not exist: license- %1", customer.DriversLicense));

}
Access Data Using
OData
Access Data Using OData
•
•
•
•