Has anyone achieved this? I’m not looking for details, just feasibility. My first thought was to create a screen that allows the user to select/specify an XML file and then click a process button of some kind that builds records in Epicor based on data from the XML. I’m not interested in automation, just the ability to create records in Epicor from a flat file without sc. My main concern is the ability for the screen to read and cycle through the XML records. Any and all input is greatly appreciated. It’s fun to kick around these ideas.
Sure thing done this a billion times. Just need to understand the XML schema and parse it , then loop through the records and create the Epicor data… no big trick there.
However 99.9999% of Epicor customers own SC runtime, so why re-invent the wheel if you don’t have to 
2 Likes
Agreed, thank you for the feedback!
There is native support in PowerShell do these things…
Pass parameters into WebServices app, download the XML/JSON file, open a SQL connection, loop through the records and put into a table all with a few lines of code. Emails and log files can be generated as well.
I do this with Daily Exchange Rates and Expense Reports (both web-based) which have no need to go through the Epicor Business Object layer. Its all automated. but I am sure you could create a little windows form with a button for them to pick the file they want as well.
1 Like
Personally, I recommend working within the Framework. Even for exchange rates. One could accidentally add two records for the same date with different rates but the Business Object would protect one from that. It still can be automated just in a different method.
I heed @Bart_Elia’s warning: https://epiusers.help/t/how-to-update-epicor-table-externally/41897/4
Mark W.
1 Like
Yes, I will have to go through the business layer for this . So Tom’s idea, while creative and I’ll definitely remember it, doesn’t work in this case (it also sounds like it can be dangerous in a lot of cases )
@tomdomurat I love the use of PowerShell. If you said you do all of that but use Invoke-RestMethod instead of SQL connection I would give you a gold star 
e.g. - We cache the holy heck out of everything in E10. If you ever see the pause at the beginning of an app server standup and the pause in first time access to a service you know what I mean. When you go directly at the db, the app server(s) have no clue that data changed. All the caching framework in E10 taps in the data directives and listens for changes. When it notes a change we either brute force tear down the whole cache and refresh or do an incremental refresh as per the needs of the cache. We even have cross app server notification of cache invalidation for farms (added in 10.1).
Going to the db bypasses all of that.
You may be in an area today that does not have a cache so you don’t see an issue today. But as soon as a service adds a new cache to speed things up, we just broke your integration. I may be overreacting and this could be YAGNI but do take it under consideration to future proof your integrations a bit
4 Likes
Bart.
It has been running like this in 10.1.400 for at least 2 years now w/o a glitch, but I am literally upgrading to the 10.2.200.15 release this week. I will check into the Invoke-RestMethod. Thank you for mentioning that!
Also, this customer’s client users are going to be doubling in size shortly so I will be looking for performance improvements where ever I can get them. I am glad I decided to come here today. 
3 Likes