When working with the Infor CRM SData REST API from a .NET application or website, there are a few different choices for libraries you can use to make the SData code easier. The original library was called the SDataCSharpClientLib, which I have written about previously. However, the SDataCSharpClientLib was replaced with the newer DotNetSDataClient library. I figured it was time to write a few articles using the DotNetSDataClient since, if you’re just starting your app, that is what you’ll want to use. The older SDataCSharpClientLib is still valid, however, any new work is going into the newer DotNetSDataClient since it has a lot of newer features that the other doesn’t have.

How to get the DotNetSDataClient Library

The easiest way to get the DotNetSDataClient Library is via the NuGet packaging system built into Visual Studio. Just search for DotNetSDataClient and you’ll easily find it. Alternatively, you can download it from the source at it’s home on Github.

How to use the DotNetSDataClient Library

There are several ways you can use the DotNetSDataClient library. I’m going to cover my preferred method of using POCO objects. In a nutshell, the DotNetSDataClient library works in the same way that Sublogix does. It does all the work of retrieving and sending data to the SData API and then serializes to and from POCO objects. A POCO object, as-in a “Plain Old CLR Object”, is a simple class that will represent the data that comes from SData. It’s a simple entity objects with properties that match the properties coming from the SData entity. Basically, when you read data from SData it comes back in the form of JSON or Atom/XML. You’ll make a simple class to represent this data and the DotNetSDataClient will serialize the JSON data into your .NET object. For example, if you’re reading contacts, you’ll create a simple contact class, with matching properties to what is in the SData feed, and the DotNetSDataClient will serialize the JSON into your class. Then you have a nice, strongly-typed .NET object(s) to work with.

Let’s take a look at an example POCO class for an Account (this doesn’t include everything for an account, just the ones I want for this example):

using System;
using Saleslogix.SData.Client;

namespace MyApp.Entities
{
    [SDataPath("accounts")]
    public class Account
    {
        [SDataProtocolProperty(SDataProtocolProperty.Key)]
        public string Id { get; set; }

        public string AccountName { get; set; }
        public string Type { get; set; }
        public string Status { get; set; }
        public string MainPhone { get; set; }
        public string WebAddress { get; set; }
    }
}

That’s a pretty simple class that I will use for account data returned from my SData calls. I use the same property names here as what is in my entity and the DotNetSDataClient will map the same property names from the SData entity to the property in the class. Notice the [SDataPath(“accounts”)] attribute on the class, which tells the DotNetSDataClient the SData path the data in this class is for (you can see what an entity’s SData path is by opening the entity in Application Architect and you’ll find it’s path on the SData tab). Also, the [SDataProtocolProperty(SDataProtocolProperty.Key)] on the Id property. This tells the DotNetSDataClient to map the $key property (the primary ID value from the entity) from SData to this property in the class.

Now, to use this Account class we created, we can make a call using the DotNetSDataClient to retrieve an account or accounts, and tell it to use this class for the results.

To get a single Account given it’s ID

// create client and provide SData address & credentials
var client = new SDataClient("http://localhost:3333/sdata/slx/dynamic/-/")
{
	UserName = "admin",
	Password = ""
};

// get single account using it's ID
var account = client.Get<Account>("AGHEA0002669");

In that code, all the magic happens in the one line var account = client.Get<Account>(“IDVALUE”). In that line, we tell the DotNetSDataClient to use our Account class and fill it with the account with the matching ID value. It looks at the SDataPath attribute in the Account class to know what SData path to use and requests the account with that ID value. It takes the result and deserializes it into an instance of our Account class, matching up the property names from the SData result with the property names in our class, and returns that to us.

To get a list of accounts given criteria

// create client and provide SData address & credentials
var client = new SDataClient("http://localhost:3333/sdata/slx/dynamic/-/")
{
	UserName = "admin",
	Password = ""
};

// get list of accounts where account name starts with 'Ab'
var accounts = client.Execute<List<Account>>(new SDataParameters
{
	Method = HttpMethod.Get,
	Path = "accounts",
	OrderBy = "AccountName",
	Where = "AccountName like 'Ab%'"
});

Well, that’s the basics. Next time we’ll be looking at how to do the same as the above using Linq queries (which is a far better and easier route and even includes built in paging) as well as several other topics using the DotNetSDataClient library.