External application consume data through Odata end point

(0) Share

Report

Posted on by CU10121822-0

998

Hi team,

With continuing the thread…

https://community.dynamics.com/forums/thread/details/?threadid=d63a56c8-c0a3-f111-b8de-6045bda97caf

I beleive to consume data from d65fo through Odata , middleware is not necessary, I mean it's not mandatory.

Without middleware -

We can share the Odata endpoint with external systems along with Azure app ID, secret key, tanent id to get the authentication (token) to access of d3650. So, that they will consume it.

Am I correct?

Pls advise, thanks

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (7)

Answers (3)

Sort by

Verified answer

CU-1234529-002 337 on at

Like (1)

Report
Copy link

Link copied!

Hi, yes you are correct, middleware is not mandatory for OData. You can directly share the OData endpoint along with the Azure App registration details (App ID, Secret, Tenant ID) with the external system, and they can authenticate and consume D365FO data directly without any middleware in between.
Middleware like Logic Apps is only needed when you require additional orchestration, transformation, or routing between systems. For straightforward data consumption, direct OData access is perfectly fine. Thanks,

Was this reply helpful? Yes No
CU10121822-0 998 on at

Like (0)

Report
Copy link

Link copied!

Hi, thanks for your response.

As mentioned “Middleware like Logic Apps is only needed when you require additional orchestration, transformation, or routing between systems.”

Here you mean to say during consume Odata endpoint by external systems, if any additional logic needs to be executed, then only we need middleware. Is it?

If yes, pls give me an example

Pls advise, thanks

Was this reply helpful? Yes No
André Arnaud de Cal... 307,019 Super User 2026 Season 2 on at

Like (0)

Report
Copy link

Link copied!

Hi,
If you just need data from one entity and the external application can perform business logic for transformation, then middleware can be skipped.
Next to orchestration and combining data into a single message that is understandable by the external application, middleware can be used as a trigger in case of scheduled integrations.
Also in case additional data needs to be retrieved from another application in the tenant where Dynamics 365 is running, it will be beneficial to use middleware.
Also for security purposes middleware can be considered. E.g. if the external application is from your vendor. Giving direct Dynamics 365 access to an external party comes with a risk.

Was this reply helpful? Yes No
Verified answer

CU-1234529-002 337 on at

Like (1)

Report
Copy link

Link copied!

Hi, yes exactly, middleware is only needed when additional logic is required beyond just reading/writing data. Here are a few examples:
Transformation D365FO returns item price in USD, but the external system needs it in EUR. Middleware handles the currency conversion in between.
Routing data from D365FO needs to be sent to multiple external systems simultaneously. Middleware routes it accordingly.
Scheduling/Orchestration external system can't call OData directly on a schedule, so Logic Apps triggers the call at a set time and passes the data along.
Format conversion D365FO OData returns JSON, but the external system only accepts XML. Middleware transforms the format.
Without these kinds of requirements, direct OData consumption is enough.
If need any manipulation in the recovered data middleware is need
Thanks,

1 people found this reply helpful.

Was this reply helpful? Yes No
CU10121822-0 998 on at

Like (0)

Report
Copy link

Link copied!

Hi, thanks for your response and validate my answer
Finally one thing…

Is the “Odata action method” is the only way (if required) to do it additionally logic to add in Odata while consuming. As mentioned above.

Pls advise, thanks

Was this reply helpful? Yes No
Verified answer

CU-1234529-002 337 on at

Like (1)

Report
Copy link

Link copied!

Hi, OData action methods are one way to add custom logic on the D365FO side, but not the only way. Here are the options:
OData Action method — custom logic added directly on the D365FO entity side, triggered by the external system calling that action.
Middleware (Logic Apps/Azure Functions) — additional logic handled outside D365FO, between the external system and D365FO.
Custom Service (SOAP/REST)if OData doesn't fit, you can expose a custom service with your own logic in D365FO.
So it depends on where you want the logic to sit inside D365FO or in the integration layer. Thanks,

1 people found this reply helpful.

Was this reply helpful? Yes No
Martin Dráb 240,646 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

You've marked the previous reply as verified, but it's wrong. It completely forgot the main way: adding code to data entities. That's much more common than creating OData actions. Also, data entities call certain table methods (insert(), validations etc.), therefore logic there influence behavior of data entities, and therefore OData services, as well.

Was this reply helpful? Yes No