Retrieving Data with the Dynamics Web API

So after I worked that whole plural entity name thing on getting data from Dynamics, I now had my data coming back to me in a wonderful Json format.  When interacting with data from the Web API you query for information via the rest interface of your URL. (more on MSDN).

As an example, if I wanted to retrieve some information on a custom entity I could do it using this query syntax.

HttpResponseMessage response = await httpClient.GetAsync(dyanmicsTenant + "/api/data/v8.1/enc_medias?$select=dat_name,_dat_customer_value,dat_dataid&$filter=dat_name eq '" + SearchParameter + "'");

Which would return a Json package in the format of

{
"@odata.context":"https://myCrmTenant.crm.dynamics.com/api/data/v8.1/$metadata#datas(dat_dataid,dat_name)","value":[
{
"@odata.etag":"W/\"874140\"","dat_dataid":"fd95bfa1-ddb8-e711-8114-c4346bdcf161","_dat_customer_value":"{00665E23-779E-4C8C-A5D4-36213C41EA27}","dat_name":"0000000006"
}
]
}

A few things…

What is _dat_customer_value?

In my query, I wanted to get the lookup for a customerid, the field itself is called data_customerid, however, when accessing lookups you must prepend “_” to the field and append “_value” to the end of the field.  Once done this will return to you the guid of the record that is your lookup.

What’s the easiest way to get at the data?

You can write a converter to parse your JSON data to an OData object.  I ran into a few problems here but also wanted to understand things a little more so I used a JObject.

var s = await response.Content.ReadAsStringAsync();

JObject results = Newtonsoft.Json.JsonConvert.DeserializeObject<JObject>(s);

With the JObject, I was then able to access the “value” node of the results and access my data in a similar fashion as I would if I was LateBinding entities with the old SDK.  It’s not super pretty, but it’s solid, it works and you can easily see grasp what’s happening here.

if (results["value"].HasValues)
 {
 record.Id = new Guid(results["value"][0]["dat_dataid"].ToString());
 record.Name = results["value"][0]["dat_name"].ToString();
 record.Customer = new Guid(results["value"][0]["_dat_customer_value"].ToString());

 }

So now we can query and retrieve our data in the most simplest of manners.

Getting Started with the Dynamics Web API

The Dynamics Web API is the new “preferred” method for interacting with Dynamics entities from web-based applications.  If you are writing plugins and coded workflow activities, you would still use the pre-existing Dynamics SDK.

Getting familiar with the Web API is a bit of a leap of knowledge as you will dabble in Azure Authentication, JSON and Async implementations (if you’re not familiar with it).

Even though the API has been around since 2016, it’s disheartening to see there not being a singular location for Dynamics developers to bridge their current knowledge of the Dynamics SDK to the Web API.

Lots of trial and error still exists and this isn’t helped by the naming of the API either.

Also note, if you are hoping to get away with the now “vintage” Dynamics SDK, in new ASP.NET Web API Core projects, this API is unsupported due to its requirements for embedded Network Credentials.

The first thing you need to do in making your first connection is to authorize yourself in your tenant’s azure environment before doing anything.  The MSDN walkthrough will take you through this in a straightforward way.

One caveat that I cannot stress enough is the redirect URL of your application.  In the scenario, I am running through it is a basic console application so in this case, I don’t have a redirect URL to go to, but you need one.  And when providing the initial connection from your application, you’ll need to include it for your connection to work.

For my connection, I used the following value.

Capture2

The following is the heart of your initial connection and only requires references to the Microsoft.IdentityModel.Clients.ActiveDirectory and Newtonsoft.Json packages.

Untitled

The tenant id is the URL to your Azure tenant while the dynamicCRMTenant is the url to your own Dynamics tenant.  The key thing to note in your initial request to get “all your accounts” is that you are no longer querying for an entity by their schema name but rather the plural name – “accounts”.

So now, you have the simplest method of establishing your base connection.

Accessing the Dynamics SDK in v9

If you are moving your work from an old Dynamics instance to v9, there are a few SDK to know about before you get started.

First – there is no SDK to download anymore.

Well, there is, but you do it through Nuget (and it’s great).

To install the core SDK framework – use the following Nuget command.

Install-Package Microsoft.CrmSdk.CoreAssemblies -Version 9.0.0.7

This will install all the core assemblies you need (i.e., not things like workflow assemblies).

To get the workflows you would need to execute the following Nuget command;

Install-Package Microsoft.CrmSdk.Workflow -Version 9.0.0.7

Different from the last few versions of Dynamics where you could get away with re-using SDK tools between different versions, with v9, you now need to download the updated set of tools via Powershell and use them from there.

Before downloading the tools, make sure you are in the right directory to where you want them installed (i.e., not system32).

After you have downloaded them, the usage of the tools is relatively the same (I’ve only played around with the PlugIn workflow registration tool).

 

 

 

Don’t use your Methodology as a Band-Aid

I can’t remember a time when software development methodology was not a hot, contentious topic of discussion.

“We need to be Agile, because that will make us go faster”

“Scrum will save us from everything we are doing wrong”

“Waterfall is the devil’s child”

“Design Patterns are the only way to go”

“Design Patterns don’t work for me”

The problem with every architecture style and delivery methodology (new and old) is the same as it was yesterday, last year, five years ago and most likely in the 80s.

We refuse to look at what the problem is that we are trying to solve and instead are content with slapping a band-aid on it and calling it “fixed, because we now have #INSERT FAVOURITE METHODOLOGY HERE#”.

If you are not will to identify what is wrong with your delivery of software in the first place, you will never be able to apply the correct methodology that applies to you.

And when I say “identify what is wrong with your delivery of software”, saying “we’re always late” is a cop-out to the true problem.

My company BetaRover Inc, specializes in working with organizations getting over these humps and breaking through the Invisible Barriers that are holding them back.

Check us out, we’re always happy to chat.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Dynamics Workflow Registration Mismatch

Recently I was deploying an update to a workflow when I received the following message.

workflowfail

Upon further investigation, the cause of the problem were the dll references I was using for deploying this particular code to this particular environment.

I had updated my Dynamics SDK to use the latest set of dlls (8.2.0.566) while the environment I had already deployed to was on (7.1.0001.3108).  A few updated file references later and I was back in business – coding, registering, deploying and testing my code.

Don’t Sweat the Customizations

Dynamics365 (and it’s previous incarnations) is designed and built to be customized and integrated into your pre-existing Line of Business applications and/or seamlessly integrate into your new ones.

That’s the goal of the platform (in my humble opinion).

To this extent, the only times you should be afraid of performing customizations on the core or extended system are;

  • You don’t understand the requirements and are changing things willy, nilly all over the place.
  • You have gone beyond writing your own code and are now changing underlying code which may or may not be supported in future upgrades.
  • You are recreating functionality that already exists in the system in your own variant.
  • You are taking something called an account and making it look like a “cat” but then having to create another thing called an “account” because you messed up the initial account.

Those are times when customizations in Dynamics can get you into a world of hurt.

Now, think about your work as a C# developer, Java, Web, VB.NET, Python, PHP, whatever and read those 4 items again.

Notice anything?

…..

That’s right, those 4 tenets apply to any software development language or platform not ONLY Dynamics365.

I think the “problem” (if you want to call it a problem with Dynamics) is that Customization and Solution Architecture is a very easy to get up and running with (good) but you can miss a lot if you don’t know what you are doing (bad).  At the end of the day, don’t be afraid to customize and leverage core attributes, do be afraid when you are not leveraging functionality in the system and having to create your own.

It’s not good for you or your customers.

 

Why do I need the Unified Service Desk?

I’ve been (and will continue to do) some blogging on the Dynamics Unified Service Desk (USD) but I’ve failed to answer the first, probably most important question you might be asking yourself right now.

Why do I need the Unified Service Desk?

Before I proceed, answer these questions (no rush, I’ll wait).

  • Do I run a Contact Centre? Y/N
  • Do I have a phone system? Y/N
  • Do I already have Dynamics installed?  Y/N
  • Have I invested some serious $$$ in our company’s own proprietary Line of Business Applications? Y/N
  • Do I have agents that work remotely? Y/N

Do I run a Contact Centre?

Great, the USD is designed, from the ground up, to be your agent’s only app they will ever need to do their job.  No more wasted context switching between applications, no more trying to find the right app that applies to the right situation – it’s all there for them to use and consume when they need it.

Do I have a phone system?

Great, with the USD you can use (or purchase from a partner) the CTI – Computer Telephony Integration – SDK that enables you to work magic with incoming phone calls to your agent’s – i.e., ScreenPops.  With this SDK, you can enable the USD to listen onto telephony events that can open up Dynamics, search through it and determine next course of action without the agent having ever picked up the phone.

Do I already have Dynamics installed?

If yes, fantastic, the USD is free, the SDKs are free and all of those wonderful Dynamics customizations and forms you have in place are freely available in the USD.  You don’t need to create any new screens (unless you want to) or develop any new workflows (unless you want to) – you can leverage everything you have to be up and running today.

Have I invested some serious $$$ in our company’s own proprietary Line of Business Applications?

Great, the USD can host many Windows and Web-based applications as hosted controls.  If you want to get really fancy, you can enable Single Sign-On protocols to automatically sign in your agents to these other systems without forcing them to remember multiple credentials.

Do I have agents that work remotely?

Yes?  Great, they can download the USD to their desktop from wherever they are, login and begin working as if they were in the office.  It’s as simple as running an install.

I zipped through these questions pretty fast and so should you.  At the end of the day, the USD can help you deploy and deliver a unified Contact Centre experience to your customers and agents while reducing costs, leveraging your existing Dynamics 365 investments and not having to throw out years of investment in your existing Line of Business applications.

Best of all, the USD does not care if you are on-premise or in the cloud, it loves them all.