If you ever want to go back to basics to see what’s not working with your OData calls, or what’s possible, this post is for you.
Fire up POSTMAN. It’s an online tool (can require a local agent depending on network setup) that allows you to execute a range of commands (and probably lots more) up against OData services. For the sake of D365FO OData services I’ll demonstrate GET and POST operations.
Get out your environment URL, such as
1 |
https://<environment-sub-url>.cloudax.dynamics.com |
To find the Url of an entity, remember the previous post and this command:
1 2 |
PS C:\> Get-D365ODataPublicEntity -EntityName CustomersV3 | Get-D365ODataEntityUrl https://afahrenholz-dev24d2d448f42b83303devaos.cloudax.dynamics.com/data/CustomersV3 |
In POSTMAN, go define a new environment and set up a variable to hold the base url. After that is done, you can create a new request in the collection to get data out of:
1 |
{{baseUrl}}/data/CustomersV3 |
But, before we GET, we need to link the environment to our request, and set up the authentication. Enter, d365fo.integrations. Go to your console with a loaded environment config, type in
1 |
Get-D365ODataToken | Set-Clipboard |
And paste that as the bearer token for your request. Remember to remove the Bearer part.
It’s an easy way to get back to the ground in case you want to skip other tooling and complexity layers. It allows you to see if the base functionality is working as you expect it to.
Remember, you can find the d365fo.integrations module here: https://github.com/d365collaborative/d365fo.integrations
For POSTMAN, go here: https://www.postman.com/
The POST operation will come in different blog post, and applies when we want to call an OData action on one of our D365FO entities. Until then, stay safe and share that knowledge.