DynamicsSubs

Background Managing data operations using Data Packages is one of the very common execution strategies for any D365F&O implementation.  A data package for a finance and operations app can consist of one or many data entities. A typical data package consists of  a group of entities for a specific task, process, or function . For example, the data entities that are required for general ledger setup might be part of one data package. Importing data that are required for customer creation (e.g. customer group, payment terms, payment methods, reason codes, customers) could be another data package. It’s a very common requirement to make the data packages be exchanged as a part of integration. We could have an external system that a.        drops files on a shared FTP site b.        drops files on a blob storage c.        sends mailers containing file content d.    ...

This article talks about performing CRUD operations, using trigger based Azure Functions, that can generate tokens and further posts the payload to D365FnO for processing. Broadly, for ease of understanding, I have split up the entire design into  a. Token generation logic: we are going to generate a short lived bearer-token, and pass it on to FnO for further executions.  b. Storing/retrieving Azure App based parameters: this is most tricky part of the solution. Typically, all developers have a habit of storing environment variables at configuration level. But unfortunately, we cannot take the configuration to server, during the deployment. We can see what all the choices could we have here.    c. Posting the payload to D365FnO for furtherance.  Additionally (not shown here), you can include logic to validate the incoming data of various fields' data given, to take necessary action, before committing to D365FnO. So, buckle your seatbelt Dorothy, 'cause Kansas is...