Enable Javascript

Please enable Javascript to view website properly

Toll Free 1800 889 7020

Looking for an Expert Development Team? Take two weeks Trial! Try Now

Step by step integration using Azure API Integration with D365 FO

azure api integration

We already have discussed an Azure API integration on a previous blog. This blog will guide you to Azure API with policy parsing capabilities. But before that: to give you a recap:

Azure API: a recap

Azure APIs is a stub of reliable connecters to any external world that can let you connect your application to talk to any 3rd party appliance. Azure API in itself is a huge sea of possibilities:

The most appreciative features of Azure API are:

The API operation circuitry

API operation circuitry

Creating an Azure API

Create a new Azure API

Browsing down to Azure portal → API management → you can reach out to the API management corner of the portal→ create new:

Click create to continue. It takes around 15 minutes to deploy and make the API up and running.

Create a service operation

You can now create An API operation from a host of available options:

For our example purpose, let us create a Blank API

Click ‘Create’ to validate/finish.

Settings

You can validate various information provided in the previous step

Security:

You can optionally set up an oAuth2.0 security. Selecting this option, the system will ask the oAuth 2.0 server(you can set this in the oAuth2.0 tab of the Azure API)

Policies

Policies are a collection of statements that let you control the demeanor of the API through configuration: either run time or design time. To see/edit the policies, you need to click on the box named: base from either inbound/outbound/backend processing.

Examples:

We have a requirement to pursue an incoming JSON payload that contains an ‘URL’ node. Consider an example like this:

{ “Message”: { “Id”: “HSHDCBMK1898989686881CDY”, “entityId”: “5FJYK173391CF45”, “eventtype”: “Item_Created”, “url”: “https://int.mynetwork.com/item/v1/FFWEE167757711KJHF33”, “createdby”: “md347” } }

For that, you can declare a variable called msg URL and then store the value of the parsed message in it. Browse down at the inbound section of the URL:

< set - variable name=“msgURL” value=”@ { stringjson=(string) context.Variables[context.Request.Body.As < JObject> ()]; JObjectrss = JObject.Parse(json); String rssMsg = (string) rss.SelectToken(“Message”); stringurl = (string) jsonObj[“url”]; returnurl; }” />

Visiting another URL: suppose we need to visit another URL as a part of the process. Several websites do that, eg: to obtain a token, cascaded calls → one API calling another API. And you need to pass on a payload as a body when making the request. The following example gives you an idea whereby you can set a variable URL on a call( for example the URL obtained from the above example):

<send-request mode=”new” response-variable-name=”itemGETAPI” ignore-error=”true”> <set-url> @{ return ((string)context.Variables[“msgURL”]); } </set-url> <set-method>GET</set-method> </send-request>

Alternately you can specify an authentication thumbprint as:

<authentication-certificate-thumbprint = “****THUMBPRINT_VALUE***” /> this value you can obtain by uploading a CERT file in the azure API → CA certificates section. These kinds of activity is more applicable for visiting APIs that do not allow open/direct calls.

POST calls: you can also make a post-call to another API and analyze a response:

<send-request mode=”new” response-variable-name=”TestPostAPI” ignore-error=”true”> <set-url> @{ return“https://apimanagement/azure-api.net/create/items”; } </set-url> <set-method>POST</set-method> <set-header name=”content-type” exists-action=”override”> <value>application-json</value> </set-header> <set-body> @{ JObjectitemBody = ((IResponse)context.Variables[“itemGETAPI”]).Body.As <JObject>(); } </set-body> </send-request>

Analysing the response:

<return-response> <set-status code=”@(((IResponse)context.Response).StatusCode)” reason=”@(((IResponse)context.Response).StatusReason)” /> <set-header name=”content-type” exists-action=”override”> <value>application-json</value> </set-header> <set-body> @{ JObjectcallResult = ((IResponse)context.Variables[“TestPostAPI”].Body.As <JObject>(); Return callResult.ToString(); } </set-body> </return-response>

Difference between Send-Request and send-oneway-request:

A Send-request is an asynchronous call to an end URL, letting you receive a response and analyze it for further use. A one-way request is more like an asynchronous call with no return response.

Conclusion:

Azure API is a vast ocean of opportunities letting you connect to any dynamics 365 for finance and operations third-party services. Please consider the following points while using Azure API.

Software Development Team
Need Software Development Team?
captcha
🙌

Thank you!
We will contact soon.

Oops! Something went wrong.

Recent Blogs

Categories

NSS Note
Some of our clients
team