JavaScript Required

We're sorry, but we doesn't work properly without JavaScript enabled.

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

Step by step integration using Azure APIintegration with D365FO

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

Azure API: a recap

Azure APIs are 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 setup a oAuth2.0 security. Selecting this option, the system will ask the oAuth 2.0 server(you can set this in oAuth2.0 tab of the Azure API)

Policies

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

Examples:

We have a requirement to purse 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 msgURL 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 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 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. This kind of activities are 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 analyse 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 a synchronous call to an end URL, letting you receive a response and analysing it for further use. An 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

 

Some of our clients

team