Microsoft Dynamics ERP – Systems Integrations

Dynamics ERP – Systems Integrations

Welcome to systems integration with Microsoft Dynamics. For any system integration, the basics include the message types or the package that contains the information. It’s going to be moving back and forth. This might be an XML message. You might use an API library to communicate directly. It could be something as simple as a flat file. The integration between the systems can be scheduled, either run in real time like an e-commerce platform or to run periodically like a retail point of sale closing out the end of the day. Integrations can be described as either being single direction or bidirectional. In any case, the source system will generate an output file, deliver that file to the integration tool. The integration tool then reads that tool and delivers it into the destination system for processing, again, either in a single direction or in a bidirectional path like a CRM system.

The challenge with doing a demo or a video for integration systems is the integration tool set itself is a black box, and you really can’t see inside that black box very well. To try to illustrate those principles, I want to use an older integration tool that has a lot of visual components that allows us to understand how th

ese components work together. By opening an existing integration, in this case GL transaction, I see the same components here that we were talking about previously. My source of information, in this case I have two files, a header file and a detail file. I have a destination going straight to my general journal. Because I have two source files, I’ll need to define the query relationship between those. I can use the tool to preview my sources, see the data that’s coming in, verify that everything looks fine, it’s lined up the way I need it to be. I have two source files, and I’ll define the relationship between them. That’s simply any data element that the two files have in common, in this case a doc number. It might be an invoice number, it might be a customer ID, et cetera.

Then finally, I need to describe where inside the system I want this information to be delivered. Once that’s been defined, I can go through and see how do I want to map data field to data field? For those data fields, what type of information do I want to use? How will this be structured? In some cases, it may be information that’s coming from the source record. I may take the source information and convert its sign, so it becomes a negative source field. I might use a system wide default. I could also use constants or other values to get inserted by code. Those basics, the source of information, the relationship between those sources, if there are multiple sources in one integration, the destination, where to park the information once it’s been processed, and then that field to field mapping allow us to produce the final integration. Once that’s been mapped and the data source has been loaded, we’re now ready to run that integration through.

Again, to review the basics of any system integration, there are different message types that can be exchanged. The scheduling needs to be discussed and determined in real time or in a periodic fashion. What will be the directions will follow a single path or a bidirectional path.

Thanks for watching the video, TMC is here to help. For specific information, feel free to contact us.