Power Platform connections to D365 and AAD Tokens

by in Dynamics 365 F&O, Integration, Power Apps
Wolftek - D365FO Integration

In this short post we wanted to offer some clarifications and options for managing the connections to D365 from the Power Platform applications. The same D365 connector is leveraged in all applications that are part of the Power suite. Just a note for the techies who like the inner workings of things, as far as the connection details, including authentication credential and tokens, the Power Platform connectors store the details behind the scenes in a APIM (Azure’s API Management).

When dealing with connecting to D365 the typical use is to leverage the standard connector and configure it to leverage a generic service account. In terms of authentication this means that the Power Platform application will authenticate to AAD to get the access token, with every call to D365. Easy, convenient – takes your worries away from having to refresh the AAD tokens, which are by default set to expire within 60 minutes.

Alternatively, if you choose to connect to D365, or for that matter to any other API, which leverages AAD Authentication, using OData or RESTful Http service calls, you have to decide what makes sense in terms of access token refreshes. In most cases, again, an authentication made with every service call should be sufficient. However, if you need to be more expressive with your flow – perhaps for performance reasons – you may want to cache the access token for reuse. One straightforward way to handle it is to store the access token in a local variable the first time the call to the API is made, and then reuse it on subsequent calls. The assumption here being that the application runs for a reasonably short time, shorter than the expiration of the token.

Another, more intricate approach, which solves the issue of reusing the access token across multiple executions of the same application is to store the access token externally – for example in an Azure KeyVault. This approach also requires that you implement logic to refresh the token when it expires. For inspiration see the following blog post.

Power Apps – Code Reuse

by in Dynamics 365 F&O, Power Apps

Yes, we know. No self-respecting D365 developer can stand the idea of writing the same line of code twice. Code reusability is at the core of the object-oriented development and certainly is in our book. As it stands, Power Apps aren’t lending easily to code reuse at the moment. Therefore, a creative approach is called for. One way code reuse can be achieved is by implementing the logic on a ‘click’ of a button (OnSelect event) and then ‘clicking’ the button programmatically throughout the application. Note, that this approach is limited to the same-page context; and while it is possible to extend it to other pages in your application, the user experience may be compromised (page flickering etc.).

Here is a flavor of how it is done:

  • Create ‘invisible’ buttons to mimic functions – we like to prefix these with ‘function*’ to indicate their purpose.
  • Implement logic on the OnSelect event
  • In the below example, one ‘function’ calls two other functions. RefreshCollections() invokes the getSales() and the getCustomers() logic:

  • This ‘function’ could then be leveraged from different events on the page. For example, on page load and on a periodic data refresh timer tick:

Power Apps – The Three Flavors of D365 Connections

by in Dynamics 365 F&O, Power Apps
Tags: , ,

There are many different ways to connect Power Apps to D365 F&O. We’ll discuss the following three common approaches in this post:

  • Standard D365 F&O Connector
  • Custom Connector
  • Power Automate

We threw together a simple App to demonstrate these options:

 

Standard D365 F&O Connector

The use case here is simple. If you’re able to leverage the Standard F&O Connector, go for it! For simple update scenarios the connector does the job fairly well. Use the standard Patch function to insert or update the data.

Here is a simple example of creating or updating Customer Groups with a standard connector:

Custom Connector

The tool of choice for anything more complex and custom. This feature gives you the full flexibility that comes with custom services in D365.

Really briefly, we threw together a custom RESTful service in D365 and wrapped it in a Custom Connector:

Call the custom connector on button click:


Power Automate

The very nice fallback to the above methods is Power Automate. The use case here are scenarios that call for iteration of collections, multiple staggered actions, etc.