I’ve got a web page that is being used to set up some custom part fields in the database. When our engineers are finished with it, the idea is to export everything to a CSV file and then DMT the data into Epicor. Over time, more changes will occur, and another export and DMT will be required every time changes are made.
However, it occurred to me that there is a bit of automation that I would like to do here, namely having to export from CSV and then DMT. What I would like to do is have my back end service (written in node.js) talk directly through Epicor via the REST API to perform the DMT that way. I’m already doing with this other APIs, so being able to DMT this way would save a lot of time. Is this possible?
The web server is running on a Linux box separate from Epicor, so using something like a batch script or invoking DMT from the command line isn’t possible.
DMT is NOT a server-side process and there is no way to use REST. It is client-side app and the best you can do is use Windows based tools line command-line/powershell if trying automation.
Whatever you are trying to achieve you will have to do without DMT since you can’t use Windows.
Just out of interest, if you’re looking at automation using REST then why wouldn’t you go direct to Epicor rather than taking the extra steps of using DMT?
Well, for one thing, the DMT interface is a lot simpler. You just have to check which fields are needed, put the values in a CSV file, and pull it into the DMT to validate and run. Going directly to Epicor would presumably require finding the part of the API relevant to whatever table you are dealing with, which would not be the same for every table, and might not even handle the fields you are interested in updating.
The really simple thing would be to use SQL to just update the database, but I understand that’s not a viable route due to the fact that it bypasses all the business logic.
It sounds an interesting project, I just suspect that by opting for conceptual simplicity you may be opening the door to headaches in practice. The actual workings of the DMT are, I believe, based on the UpdateExt methods of the associated Business Objects, and if you have a working set of fields for the DMT you can usually use the same directly into that method and have it work with fewer moving parts. Still, if CSV and DMT are known quantities, don’t let me derail you.
Your not only bypassing the business logic, by doing so (and if Epicor finds out) I’ve header your losing service support by Epicor… or something like it. Can somebody be more specific here please. I’m not to aware of the terms of agreement.
yes you can not use direct SQL code to add, update, or change any values within Epicor DataBase, you only allow to do that through BPM and Customisation using the relevant/available BO methods within Epicor forms UI
What are the consequences if your doing so in terms of Epicor Services? Does Epicor cease to honor is warranty? If so, what are the specific terms of agreement?
YES
i have dealt with two different Approved Epicor partners, both confirmed this information, however you can ask your AM or Epicor Support to send you the relevant term/paragraph on the agreement.
I’ve heard Epicor employees say they will not leave you in the lurch. The consequences are that the regular support agreement that you’ve already paid for is no longer in force. You are now in the land of professional services and you will pay an hourly rate to get your database back into some stable state - and even then, there is no guarantee.
Thanks @Mark_Wonsil. My goal here was to generate a discussion regarding the statement above. In that case, the obvious thing to do is a really bad idea. Just to make sure every knows about it.
Yes, I have no intention of ever running any direct SQL code that can modify the database, as I have heard this “warranty voiding” thing before. In fact, we don’t even have it set up so that you can run such code under normal circumstances.
But - this does bring up an interesting question. Would it be allowed to run such code in a test environment? The idea being, you back up live, then restore it into Test. Then do this unsafe stuff in Test, run some more tests, and then restore the original backup again, basically undoing anything that might have gotten messed up in the database?
FWIW - The following is an exact copy and paste from an Epicor support person - through EpicCare
If you are using an Epicor version more recent than version 10.1.300, I believe the error message can be resolved by deleting the offending record from the TaxSvcMessages table directly at SQL. As an Epicor employee I cannot officially advocate data record deletions directly at SQL but I mention that possible solution here because I recently worked with another customer who resolved the error in that manner; we were unable to find another way to proceed.
Emphasis mine…
It would have been nice if the support person mentioned that If I were to do any direct SQL manipulation, what the effect would be on our support agreement…
Sometimes I wonder if some of their “fix” programs are doing this anyway. I would imagine that sometimes they have to go around the business logic to fix up records which the business logic has busted for whatever reasons.
I’m sure that they DO updates behind the scenes. But they are taking the responsibility for the action and know what the ramifications are since they also know what their code does. I can’t make the same claim.
