Unifying organizational systems is not optional if you want to reduce data errors, streamline operations, and create actionable analytics. Dynamics 365 Finance and Operations customers understand the value of data extraction, importation, and translation to create seamless data flows between in-house and vendor systems. This article will give readers information on how to get started accomplishing the much-needed integrations.
Users are required to perform double key entry as vendor systems are not out-of-the-box integrating with our system of record, Dynamics 365 Finance and Operations. We can perform imports and exports with some vendors, but it seems we always need to massage the data. Also, flat files with PII are having to be encrypted and maintained manually outside the system.
Furthermore, employee additions and updates are not getting to the payroll vendor, end of month invoicing is painful, and mistakes happen due to double entry by hard-working quality conscience individuals. We need to unify and streamline our operations quickly.
There are several options for data exchange with Dynamics 365 Finance and Operations. The most common is the file-based Batch Import/Export feature, which is utilized for timed runs as needed; typically, nightly once business activities have subsided (ETL).
Unfortunately, at this time the Microsoft Common Data Service used by D365 CRM and many other platforms is not available for use with Dynamics 365 Finance and Operations. However, there are several 3rd party OData Clients for Visual Studio that can serve the purpose, but most are heavy and somewhat cumbersome to implement.
As a result, we created several smaller OData C# repositories within Azure Functions for real-time integrations with the various Finance and Operations modules such as Vendor Payments, Invoice Journal, and Employees. These smaller units of work helped create fast decomposed services, which can be deployed separately and often.
Figure 1 – Integrations Architecture and Process Steps
- On post of such D365 entities as Vendor Payment and Invoice business events are relayed to the API Management (APIM) endpoint.
- APIM sets outside the secure and dedicated hardware Application Service Environment (ASE) and Integration Service Environment (ISE) and sends the event to the Logic App.
- The Logic App now starts its orchestration.
- First, it fires the Function App GET method
- This invokes the required OData query to gather the newly entered Dynamics 365 Finance and Operations information (Invoice, employee, payroll, …).
- Next, the Logic App sends the queried information to the Integration Service where it is transformed from OData Json to Common Data Model (CDM). Note: The CDM has the ability to house all organizational data and is ‘common’ amongst inhouse systems.
- CDM then gets stored in CosmosDB for consumption by various services
- Finally, the frontside Logic App publishes to the appropriate service bus topic and subscription.
- The backside Logic App subscribes to the newly posted business event and goes to work
- Step 1, it fires off the Function method to go get the new CDM data
- Step 2, it uses the Integration Service to transform CDM into the appropriate ‘Consumer Data Model’. Note: The CDM could be transformed into XML, Json, HL7, flat file, or whatever the receiving party requires.
- Step 3, the Function method takes the transformed data and pushes it out to the 3rd party receiver, which includes SFTP, REST, Shared Folder, SOAP, and other protocols.
- Azure Active Directory where D365 is registered in order to acquire JWT tokens and securely interface with the Dynamics 365 Finance and Operations data store.
Figure 2 – Example Business Event Wire up
This is not a one solution fits all scenario. Depending on your application stack, dataflow, and D365 F7O usage an entirely different design could emerge. Some of the options we considered include:
- Utilize 3rd party OData Client within Visual Studio
- Secure App Service Web API over serverless functions
- Logic App Dynamics 365 Finance and Operations Connector (ISE prohibited us from using this option)
- Mappings and transforms within the C# code (AutoMapper or equal)
- SQL instead of CosmosDB
Solution security is met with implementation of Azure ASE and ISE environments, data encryption at rest and in transit, APIM encrypted API calls (TLS & JWT), user and app authentication & authorization, and the suite of Azure tools for security, alerting, and logging.
Not depicted are the typical NSGs, RBACs, Firewall and a ‘Zero Trust Security’ posture required by healthcare systems today.
Our selection for IDE was Visual Studio. We needed a robust set of features and capabilities to handle all the different demands required by the various vendors and in-house systems. We used Postman and Microsoft Edge Beta (Developer) for building and testing our OData queries and we used Table Browser Caller in Chrome for viewing Dynamics 365 Finance and Operations entities and tables.
Figure 3 – Example Postman GET Employee call
Asynchronous, message-based, decoupled, and decomposed services are the key to scalable, durable, and successful integrations. Keeping components siloed, so they are testable and deployable without effecting other systems will serve you well.
Make security a no-compromise part of the design from day one. From the first line of code, all the way through to production and you’ll have happy users.
If integrations were easy, we’d all be throwing Machine Learning on a pile of data and creating actionable outcomes to bolster our futures. The truth is working with multiple vendors to create easily maintainable integration endpoints can be difficult.
Let’s keep it as simple as possible and set realistic goals and timelines.
Dynamics 365 Finance and Operations has now been broken up into 4 distinct modules:
- Dynamics 365 Finance
- Dynamics 365 Supply Chain Management
- Dynamics 365 Commerce
- Dynamics 365 Human Resources