Dynamics 365 - Odata integration (Code snippet)
Dynamics365
integration - Odata:
Guys
below code snippet can help you when you play with Odata integration with D365:
public static void customers(Resources context)
{
DateTime
dateTime = new DateTime(2017, 01, 01);
//Filter the
query
var customers = context.Customers.AsEnumerable().Where(x
=> x.CreatedDateTime >= dateTime);
foreach (var
customer in customers)
{
Console.WriteLine("
Customer Account # - {0}, Name - {1}", customer.CustomerAccount,
customer.Name);
}
}
|
Inserting
the record in D365 table (Just a simple example, FYR):
DataServiceCollection<CustomerGroup>
customerGroupCollection = new
DataServiceCollection<CustomerGroup>(context);
customerGroupCollection.Add(customerGroup);
customerGroup.CustomerGroupId = "1000";
customerGroup.Description = "test";
customerGroup.PaymentTermId = "Net30";
context.SaveChanges(SaveChangesOptions.PostOnlySetProperties);
|
Updating
the record can be done using similar code shown below (Just a simple example,
FYR):
context.UpdateObject(SaveChangesOptions.PostOnlySetProperties
| SaveChangesOptions.BatchWithSingleChangeset);
|
Valuable post useful for everyone.Keep on sharing.
ReplyDeleteMS Dynamics AX Online Training
Thanks for sharing this informative article on Dynamics 365 - Odata integration. With important practical Code screenshot. If you have any requirement to Hire MS Dynamics CRM consultant to accelerate your company's success by evaluating new solutions and customizing existing ones with Microsoft Dynamics. Please contact us.
ReplyDeleteReally helpful snippet for anyone getting started with OData integration in Dynamics 365. The filtering example is especially valuable because so many early implementations overlook performance considerations when querying large customer sets. Simple choices like pulling only the records created after a specific date can drastically reduce payload and improve responsiveness.
ReplyDeleteYour insert and update examples also highlight something teams often forget: D365’s OData layer behaves predictably when collections and contexts are handled cleanly. Explicitly setting the properties before SaveChanges avoids confusion when debugging and keeps the integration logic maintainable.
For teams building more structured integration layers, this kind of clarity becomes essential. It is the same mindset that drives good QA practice. Tools such as Tuskr test management software encourage engineers to think in terms of clean processes, traceability, and repeatable behavior. Integration code benefits from that same discipline.