If you are in Dynamics 365 Finance and Operations development and if you have a scenario of Synchronous integration, most probably you must have used oData service and along with that POSTMAN app in order to validate your scenarios.
A short intro.. Postman is free tool available for download which can be used as a test client for API development. It is available as a native app (need to download) and also as a Chrome extension.
Just to give you a context around, API, different types of API and D365FO, different integration approaches in D365FO and oData service (format=JSON) - I have tried to illustrate the relation in the below picture.
Disclaimer: Obviously, the above illustration doesn't contain all the relevant information, but might only help in setting some context.
Now in this blog post I would like to share about the ease of working with POSTMAN when working with D365FO oData endpoints. So information regarding integration as such will have to be obtained from various sources which are already available online.
Let's begin with a screenshot of POSTMAN native app.
For the best use of Postman, it is important to understand the highlighted topics in the above screenshot:
Collections - as the name suggests holds the collection of requests. These requests can be organized in folder structure as shown above. And could contain GET/POST or others as you wish.
Having a collection defined would help you run those requests on demand for any number of times and for different environments
Environments (top-right corner) - here you can define environment specific variables, so that you be efficient in running your Collections/requests. And also makes it easier to have environment (DEV, Test, UAT..) specific ClientIDs and secrets.
Below is the screenshot of variables I have defined for my environment, just as a reference.
Requests - In the above example screenshot you can see I have used a variable in my request.
GET : {{resource}}/data/Documents
By doing so, I am making use of the environment variables defined and still run the oData endpoint without making any changes across other enviornments.
For my example here, {{resource}} would convert to https://mydevbox.cloudax.dynamics.com. So when I push the Send button.. the actual request would be,
https://mydevbox.cloudax.dynamics.com/data/Documents -- which is a normal oData endpoint to get the data from Dynamics.
Pre-request Scripts - Now in Postman there several nice features, one of them - the most useful for me is Pre-request scripts. You can define them at Request level, folder level (or) on the collection level. The script placed in here would run before the request is sent out.
So one of the best use of this is to tip: automatically generate the bearer token, instead of manually entering the username and password to authenticate towards the source system. Lot of blogs available online in order to educate and even provide samples.
Output - And finally when we hit the send button on the request and if everything is correctly configured. A json output would be presented in the output body message window. You would be able to see the "response code", "time taken" and "size of the output file" in the window. See below for reference.
Hopefully this helps. Please comment below if you have any questions/suggestions, will try to respond asap. Cheers.
A short intro.. Postman is free tool available for download which can be used as a test client for API development. It is available as a native app (need to download) and also as a Chrome extension.
Just to give you a context around, API, different types of API and D365FO, different integration approaches in D365FO and oData service (format=JSON) - I have tried to illustrate the relation in the below picture.
Disclaimer: Obviously, the above illustration doesn't contain all the relevant information, but might only help in setting some context.
Now in this blog post I would like to share about the ease of working with POSTMAN when working with D365FO oData endpoints. So information regarding integration as such will have to be obtained from various sources which are already available online.
Let's begin with a screenshot of POSTMAN native app.
For the best use of Postman, it is important to understand the highlighted topics in the above screenshot:
Collections - as the name suggests holds the collection of requests. These requests can be organized in folder structure as shown above. And could contain GET/POST or others as you wish.
Having a collection defined would help you run those requests on demand for any number of times and for different environments
Environments (top-right corner) - here you can define environment specific variables, so that you be efficient in running your Collections/requests. And also makes it easier to have environment (DEV, Test, UAT..) specific ClientIDs and secrets.
Below is the screenshot of variables I have defined for my environment, just as a reference.
Requests - In the above example screenshot you can see I have used a variable in my request.
GET : {{resource}}/data/Documents
By doing so, I am making use of the environment variables defined and still run the oData endpoint without making any changes across other enviornments.
For my example here, {{resource}} would convert to https://mydevbox.cloudax.dynamics.com. So when I push the Send button.. the actual request would be,
https://mydevbox.cloudax.dynamics.com/data/Documents -- which is a normal oData endpoint to get the data from Dynamics.
Pre-request Scripts - Now in Postman there several nice features, one of them - the most useful for me is Pre-request scripts. You can define them at Request level, folder level (or) on the collection level. The script placed in here would run before the request is sent out.
So one of the best use of this is to tip: automatically generate the bearer token, instead of manually entering the username and password to authenticate towards the source system. Lot of blogs available online in order to educate and even provide samples.
Output - And finally when we hit the send button on the request and if everything is correctly configured. A json output would be presented in the output body message window. You would be able to see the "response code", "time taken" and "size of the output file" in the window. See below for reference.
Hopefully this helps. Please comment below if you have any questions/suggestions, will try to respond asap. Cheers.
No comments:
Post a Comment