Thank you for the reply. I had a look at the site and saw the AX connector. It does seem a bit ... cumbersome... to do all that management inbetween with profiles and notifications.
I think I was looking more towards a simpler solution, i.e something without 3rd party software driving the handshaking between EPDM and Dynamics.
In the meantime I've watched a number of videos / read some articles on the subject, and it does seem that you can just leverage the XML functionality without a connector between the two programs. I found some videos on youtube where this is done.
I've gone through the example that SolidWorks provides to export XML, which is quite easy to follow, but I don't have any experience importing it into Dynamics, or what type of questions I need to ask of Dynamics to get this to work. Basically, I was thinking that as long as dynamics can poll a folder and look for xml files... everything should be fine.
So do you know if the connector can be left out of the equation? Or at least... what would justify spending the additional money on the connector rather than just using the standard functionality?
BTW: Not a lot of people seem to be making use of this functionality....
We are at the very beginning of an Ax implementation now.
We came the same concluesion you did about the connectors, they are expensive and seem to offer little additional functionality over XML exports. The only advantage we can find it having the data move in real time.
We haven't gotten to the actual integration part of th project so I can't tell you how to import the XML's into Ax but I'll keep this thread book marked and update it when we do complete the integration.
I think the reason this functionality is not widely used is because SEPDM is targeted at companies which would not have a mid market ERP like Ax.
Thanks for the reply*
We are now entering the stage where we're negotiating the implementation of EPDM with Ax.
At first glance there are no show stoppers.
It would seem that there are no real issues with the implementation side of things, as EPDM exports quite easily to xml. I do have to note, however, that EPDM doesn't add xml schema information to the top of their exported files, which is, apparently, required by Ax when importing xml. Aparently Ax won't import files that don't contain these headers. I still have to investigate this further, because it really sounds a bit weird. XML is supposed to be easy to work with. The whole idea behind it being NOT to have to include headers... but like I said... it will require some investigation
For this implementation, it would seem that there might have to be some customization of the system as well (coding a task addin for EPDM) as the users would like to run SQL queries as tasks during certain transitions in the workflow...we'll have to see where this all ends up
Just a comment on your previous post
I think the reason this functionality is not widely used is because SEPDM is targeted at companies which would not have a mid market ERP like Ax.
EPDM seems to be touching those areas more and more. In the past it might just have been seen as an upgrade to Workgroup, but I must say, my goodness, these last 2 years have seen some good enhancements to the system, which really makes it an extremely valuable competitor in the market. It is also my perception that companies confuse ERP systems with PDM systems, and they tend to want to run the two systems exclusively instead of inclusively... which is perhaps erroneous on the users side, since EPDM really just has so much to offer.
Sorry to be cutting in late on this thread, but I am in the middle of exactly the same situation. Our company just bought (and is still implementing) SolidWorks and EPDM. Also, we are implementing Microsoft Dynamics SL (which I have no experience with). I was under the same assumption that XML from EPDM would be a piece of cake to import into Dynamics, but it sounds like that might not be the case? I'll be interested to hear how you make out with all of this. We are looking into Agni-Link by Elmo solutions as the link between SolidWorks and Dynamics. I've not really seen that either, have you heard of this or know anything about it?
I have not heard of AgniLink, but I'm not an expert either.
Our implementation has not started yet! The client is waiting for their holding company to do all the paperwork. But they have bought all the servers / hardware necessary to run all the software. So we're at a bit of a standstill. It would seem that they're waiting for the Dynamics personnel to finish something before we can continue, or perhaps just for the financial year end.
In the meantime I've investigated tasks inside of EPDM / custom services in Windows.
Until we start the actual implementation I'll have to wait some more.
I'll update as soon as we start!
I also see that your post was last year. What has happened in the meantime? Did you go with AgniLink? If not, what were the reasons? I'd be very interested
Well, it seems both of us are in similar 'boats'! We have implemented Dynamics as of November (on a very limited basis) and we are failing miserably. From what I've heard, most companies take one year or more to do an ERP implementation; we attempted it in 6 months (including the planning stages). I'm just thankful that I'm in charge of the SolidWorks implementation (which is going well) and not the Dynamics implementation! It appears we are very far away from any tie-in with SolidWorks ePDM and Dynamics. We have not yet purchased Agni-Link, so I still don't know much about it. (you can find info about it by searching on SolidWorks website). Currently, I'm working on mining data from the ePDM SQL Server for our BOM's and possibly other variable info for reporting outside of Dynamics. Keep me posted on your progress! I hope it goes smoother for you than it has for us.
I'm in the same boat now as you were a couple of years ago. Any advice? How did your company end up implementing the two?
We are currently only using Dynamics SL as an accounting software and not much else. We have basically gone the route of custom programming everything ourselves. I am not a programmer, so my involvement was limited except for directing what needed to communicate with what throughout our company. If I had it all to do over again, I would hire a full-time programmer who understands databases well or use a third party to create the whole package. SolidWorks ePDM has many capabilities and one can extract much data from it and SolidWorks, you just need to know what you want to do with all that data once you have it.
Thanks for the info! Do you know what middleware you used to connect the two? Did you end up using Agnilink? I'm looking into another piece of software called "Pigeon Hole" too. They seem similar.
I am not a programmer either, so I'm trying to figure out exactly what needs to be done to get this up and running efficiently for my designers, estimators, and detailers to all be able to use the system the way it was intended when purchased.
We aren't using anything except custom programming. Our only linking of ePDM to Dynamics SL is one-way; from ePDM to SL. We export our Bill of Material from ePDM using a workflow task, this creates an .XML file. One of our programmers wrote a script of sorts (or other programming wizardry) that uploads the .XML files into Dynamics SL. In our setup, they do not 'talk' back and forth.
Got it. Thanks again for the info. In our system, the direction would go the other way, from SL to EPDM. Basically, pulling the costs from SL, and populating the file properties in SWX so as components are added to an assembly, our designers can estimate the total cost.
Thanks for the help!
Are there any updates for this? Our company is looking to begin the integration, and any help/advice would be appreciated.
Following are the different approaches you can look when you want to integrate EPDM with any ERP system:
- Point-to-point integration
- Information portals
- Multipurpose model – de-Coupled Integration
Point-to-point integration is based on an application-to-application specific interface built using Application Programming Interface (APIs) and custom code. This integration can enable a “REAL TIME” and “TIGHTLY COUPLED” data exchange between the systems ensuring the updates in either of the systems take place instantaneously based on pre-defined rules and configuration settings.
Such integrations can be acquired from an application vendor or can be custom developed. Point-to-point integrations can provide a very rich and uniquely tailored solution.
An Information Portal in the ERP & EPDM scenario is a framework that can be designed to represent the integration of the data or the information that is available in one or more enterprise systems (ex: any PDM/PLM & any ERP).
In larger enterprises, it is common to see processes being enabled via multiple systems. Different people in various organizations need to access information residing in these systems to make decisions on daily basis. Often, these individuals need to collate such information for downstream purposes. Information Portal can be extremely helpful in extracting information from different enterprise systems and presenting it to the users in a pre-determined format. These reports can be presented in different formats based on individual’s role.
The information portal could be built by making use of the pre-configured reporting tools linked to the enterprise systems or can be a standalone interface built for custom requirement. Ex: Cognos Reporting studio, Crystal Reporting tools or custom ASP.NET web development
A de-COUPLED Integration can be designed with an Enterprise PDM system and with any ERP system (ex: Microsoft Dynamics AX) as long as it supports open-source XML based data exchange.
In this integration model, the XML file format will be used as a medium for the data exchange between the enterprise systems.
This type of integration, when developed for unidirectional data exchange between systems, makes the implementation process easier and within shorter lead times since it utilizes out of the box (OOTB) components in both the source and the destination systems.
In certain bi-directional data exchange type integration models, the usage of the Application Programming Interface (APIs) of both ERP and Enterprise PDM tools along with open-source programming platform may be necessary. This can result in a much more complex implementation than the unidirectional data exchange.
A “de-COUPLED” data exchange between the systems will make sure the updates in one or both the systems take place based on pre-defined schedules, rules and configuration settings.
Such integrations can be acquired from an application vendor or can be custom developed. The de-COUPLED integrations can provide a very rich and uniquely tailored solution.
We can support any of the above mentioned method. Please let me know if you need any more clarificaiton or support for your integration requirement
@ Raguraman... I see you attended the ERP / PDM webcast
I think for us not to stray too far from the original question, let me post it again:
Does anyone have any experience in this field of integration, and what was you experience? In other words the pro's and cons to look out for?
Derek: Thank you for your feedback. It is indeed a big 'hill to climb' when implementing an ERP system and yes... it can take anything from 1 to 1.5 yrs.
I am a programmer myself and very interested in creating a link between the two programs. It will most likely follow the de-coupled approach, but if I find myself in a position to do so (with the extra time to do so..uh...what is "extra" time anyway?? lol / rant) the point to point approach looks very attractive. I don't see us investigating Agni link, as we are in south africa and the exchange rates make this non attractive when coupled with the price of PDM.
I'm in the same situation as yours. I'm in process of integrating EPDM with Netsuite and would like to know what was your experience with integration process?
I am in the process of integrating ePDM with AX. I have done some research and have found very limited info on the subject. Do you know anyone who has done an implementation that I could contact?
VP of Engineering - Unity Manufacturing, Garland, TX
Hi James. Since I've started this post, I have not actually gotten to the point of doing any type of integration / customization / writing more than a couple lines of code. The initial post I made was to gather information on what other people have done with regards to this topic, and it seems that there was a gap in the community on this topic, so I wanted to bring this to light.
That being said, I've done some research on this, and for the sake of other readers - here are my findings: In my travels across the internet and in my pursuit of trying to educate myself, I have come across a number of products that offer this type of integration already, and (I'm not a reseller for these guys !!) I would think that it would be wise not to try the integration oneself, but rather a) leave it for people that have done it before (such as QBuildSoftware / CADMes / Agni-Link / etc.) or b) are willing and able to implement the integration.
Just to be clear: By integration I mean: The automatic or scheduled transferal of information (specifically BOM / component information) between 1 or more systems which would otherwise take enormous amounts of time or manual labour to perform by one or more persons. In my case the systems I'm talking about would be from
- EPDM -> AX or
- SolidWorks -> AX or
- AX -> SolidWorks or
- AX -> EPDM
The reasons I would refer the implementation to a 3rd party is the following:
- 1. It is already a massive undertaking to get AX / EPDM running without any form of integration
a) Part numbers / data cards / BOMs / User training / Reforming your data / having hours of discussions etc.
b) Someone has to keep these systems running
- 2. There are a number of potential pitfalls / critical questions to answer in trying to automate the integration yourself, such as:
a) When do the updates push through from EPDM to AX and vice versa? (e.g. during workflow or on demand)
b) Which system will control the master BOM? (This is not always AX and certainly not always EPDM)
c) Should you be focusing on just pushing the BOM through to AX, or individual part information as well?
d) Are your concerned with the industrialization of your parts, and if so, how does this affect the import / export of information?
e) Which system will generate the serial numbers for components? (Typically this would by EPDM, but I've found that in a multi-system environment where the ERP system is the master, it would be better if AX did this)
f) Who will be implementing the automation side of the software, and does this person have the necessary technical / managerial / interpersonal skills to get this project off the ground and to faithfully mirror that which has been done manually so far? (This is probably the biggest one of them all, since this person will be the one having to come up with / answer all these questions)
g) Can this be tested in a test environment first?
- 3. If you are planning for this yourself, you need to have the following in place:
a) A dedicated person to do the job over a 1-2 year period. This cannot be a side show. This is the main show!
b) Someone who is technically skilled in both software packages (not just the user interface, but also the back end (e.g. SQL tables, XML files, etc)
c) Someone who is tenaciously optimistic that he will succeed in this
While some of these points seem to point to almost unachievable goals, I do believe that it is possible and very achievable, and that the rewards will be great. But know this - if you get someone that is not competent - you risk corrupting your ERP data!
So if you have the knowledge in all 3 areas (EPDM, AX, SW), by all means go ahead.
I consider myself very knowledgeable on the topic of EPDM and SolidWorks and their respective API's, but not on AX / ERP and its infrastructure, therefore I would not attempt this, but rather refer it to a 3rd party, because understanding the business logic of the ERP at this time (ordering / stock management / lead times and how it works in the ERP system tables) in combination with data management and automation has yet to be bestowed upon me, and I'm not willing to take the risk of automating a system, just to see the automation push a lot of unwanted data into both systems.
Edit: I work for a VAR in South Africa (Mecad Systems), and spending a year or so on a project like this is not within our current means. While we can assist with support / integration / consulting, I would essentially be out of the office for the duration of the project. For someone who is onsite, within the company, this is definitely a more feasible option (If you have the above mentioned skills), but if not, then the 3rd party solution is for you.
Edit 2: I have seen companies that use macro's to only push their BOMs to an ERP system, so there is not 2 way integration, only 1 way pushing, which works for them. Maybe this is a good first starting point
Thank you Ricardo. I included Agni-Link in the large-ish post above.