Postman, has been in use by the web development community for more than a decade now. When it comes to the Microsoft Dynamics community, more specifically, Microsoft Dynamics Finance and Supply Chain consultants, it can be a comparatively new tool. The majority of Microsoft Dynamics professionals (including myself) have a background in Microsoft Dynamics AX. In Dynamics AX, very limited tooling was available apart from the AOT and the only kind of web services supported were SOAP endpoints.

I am personally a great advocate of developers’ productivity and more use of the open-source and community tools in the typical Dynamics development flows. Fortunately, Microsoft Dynamics 365 Finance and Supply Chain provides a richer and more modern infrastructure to support data migration and application integration scenarios than its predecessor, Microsoft Dynamics AX.

Postman, becomes handy while you are testing the custom APIs or just want to check the call to an OData APIs. Since, Microsoft Dynamics 365 Finance and Supply Chain, is now actually an Azure cloud application, this adds some complexity in different kind of pre-reqs in setting up the Postman. The purpose of this blog post is not to discuss the steps required to setup a Postman for Dynamics 365, as this is already well covered by Microsoft. You can read more about it here. Here, I am just going to focus on some of the best practices that are going to make the use of Postman even more effective.

Always create a collection

Always consider creating a new collection. With collections, you can:

• Organize your requests.
• help you make use of the variables, which improve maintenance and increase reusability.

Make effective use of Postman variables

Postman is quite flexible when it comes to the variable definition, and you can define it at various levels, depending upon your needs. Think about defining because:

• It helps with reusability.
• Improves maintenance.

Consider defining the following as environment variables or collection variables in the case of Dynamics:

• Tenant id.
• Application id.
• Authorization end point.
• Authorization token, which you are going to receive from Azure AD.
• Client secret.
• Base API URL of your Dynamics 365 Finance and Supply Chain environment.

Consider checking in the file into your Azure DevOps repository

Export the Postman and periodically check-in to your Azure DevOps TFS repository. Alternatively, you can also consider the share feature within the Postman.

Test your APIs using test scripts in Postman

As a solution architect, I have been required to test the APIs. In most of the times, it all works without a need of a test scripts. Test scripts become handy for me while testing custom APIs, especially when the development is still ongoing. You can find a complete reference on how to write test scripts in Postman here.

Please note that writing a test script requires basic knowledge of JavaScript.

About Impulz Technologies LLC

Impulz Technologies, is a Silver Certified Microsoft Partner company. We specialize in the implementation, consulting and development of Microsoft Dynamics and Microsoft Power Platform. Impulz Technologies also provide staff augmentation services all across the US. For more information please contact us at 630-540-6302 or email us at info@impulztech.com. You can also contact us through our website.

The post Postman Best Practices for Microsoft Dynamics 365 Finance and Supply Chain Management appeared first on Impulz Technologies LLC.

This blog reflects the approach to connect .Net client console application with Microsoft Dataverse. We will first have to create a connection between Dataverse and our console application. The connection process via API which we followed is explained in this blog divided into three sections.

1. Creating a basic console application with the required NuGet packages
2. Creating client application in Azure Active Directory.
3. Linking Azure client application id with the Power Apps.

1. Creating a basic console application with the required NuGet packages

The NuGet packages we use to create 2the connection are Microsoft.Identity.Client and Newtonsoft.Json.Linq

Authentication

The requirement is to authenticate then allow access. We built the connection through a client token generated on providing sensitive information depending on the authentication library used. Since we used ConfidentialClientApplicationBuilder our requirement to generate client token is (client ID, client secret, Redirecturi and Tenantid). How did we get these secret items will be discussed in the later sections. We store the response and later pass it to a built-in method to acquire token. This part covers Authentication.

Client Configuration

We used HTTP Client to send http request which requires base address to hit. This can be found in PowerApps portal > Developer Resources > WebAPI Endpoint.

The Web API implements the OData (Open Data Protocol). This is an open data protocol to exchange data over the web. The protocol is HTTP based and has been designed with a RESTFUL mindset meaning you use a URI as a base address and HTTP headers to interact from the endpoint of server. The default Web API Whoami is used to fetch the results.

More information about OData can be found on: OData overview – OData | Microsoft Docs

We use HTTP headers in our code they are used for additional communication between the client and the server with an HTTP request or response. We use HTTP Authorization request header to provide credentials that authenticate a user agent with a server, allowing access to a protected resource. We added a connection check which if the connection is successful returns the User ID of user otherwise returns the reason for failure.

2. Creating client application in Azure Active Directory

Before moving on to create a client application, we first need to understand the need for its creations. The answer is simple, to integrate and grant permissions we create a client application in Azure Active Directory (AAD) and later integrate it with our console application. The AAD App is different from the application in Visual Studio. AAD App generates secret keys representing your access level. You can have many applications in an Active Directory. Each application will have a different access level.

Creating client application facilitates authentication and authorization and you can grant access permissions accordingly.

We can control multiple aspects via AAD like Supporting Account Types, Certificates and Permissions. We can configure platforms, which could be android, web, and many more platforms. In short, we can authenticate and authorize easily for a variety of different client types.

Steps to Create an app

To create a client application, we will have to login Microsoft azure portal. Under services search for App Registrations and create a new registration. The registration page will look like the snapshot below:

1. First give a meaningful name to the application.
2. Select which account types to support access. We wanted our app to be accessed in any organizational directory so selected multitenant.
3. The Redirect URI can be added here or later. We added a redirect URI *localhost* and let the Uri decide whatever port is available and connects to.
4. Redirect URI is the location where a user’s client is redirected and sends the security token after authentication.
5. Register

The client application is registered.

Follow the step by step details for registering an app in Azure Active Directory in: Quick start: Register an application with the Microsoft identity platform

Modifications to Integrate with Console App

As we have successfully registered client application in previous section and now, we head to modify some properties in order to integrate our console application with the app just registered.

Integration requires a token and to generate token for client, multiple things are required.

We used ConfidentialClientApplicationBuilder which requires the following parameters to generate a token for authentication (client ID, client secret, Redirecturi and Tenantid).

The client ID shown in the Overview pane is one of the input required by an authentication library used in your application’s code for authentication via token and integration.

For client secret we will head to Manage > Certificates & Secrets and add a client secret. Please note that Client secret values cannot be viewed, except for immediately after creation. Be sure to save the secret value when created before leaving the page since we will be needing this to generate the token.

The Redirect URI that was mentioned in Steps to Create an app while Tenantid can be found after logging into PowerApps portal then Settings > Session Details.

Then switch to Azure portal and head to Manage > Manifest where we can see many properties. Our concern here is allowPublicClient. Set allowPublicClient to true and save.

Lastly in Azure portal, head to Manage > API permissions > Add permission then search for Dynamics CRM and select user_impersonation and add it.

We also granted admin consent for your organization since without admin consent the connection might raise errors.

Now all the necessary modifications have been made for our connection to be built and the client application is successfully created and ready to be integrated in code. But before that the connection still requires one last thing otherwise the connection will be forbidden. This is because we have linked Azure application within our console app but it still isn’t aware of PowerApps so we link Azure client application with PowerApps in the next section.

3. Linking Azure client application id with the Power Apps

To link Azure client application just registered with Power Apps, login to Power Apps > Settings > Admin Centre.

Then head to Environments Section shown on left pane and select the relevant environment and look for Users under Access section.

Then open app users list and add a new app user which requires Business Unit (your organization) and define System Admin role for the app and add your registered client application from Add an app.

In the end, a notification pops confirming that Power Apps is linked with our client application successfully.

The post Microsoft Dataverse Web API using .Net client console application appeared first on Impulz Technologies LLC.