But only 1 that works properly in all cases (including the ones you’ve not dreamt up yet)
The trick is finding it without testing every option first, I’m still working on this part and I suspect most others here are too 
1 Like
It can definitely be a frustrating experience for sure. I just try to remember to be grateful that I have the ability to customize and interact with Epicor at this level at all.
If you come at it with more of a mindset that you are hacking someone else’s product to do what you want (like modding a video game) and not like a professional well documented API (such as the .NET Framework) it can help set your expectations of what the experience will be like.
4 Likes
@hkeric.wci I am certainly not going to get into any personal barb trading. I can’t see why you are taking this so personally.
What we are looking for (and have contract $$ to pay for) is authoritative information about what JobEntry does. That is, someone who is actually knows what the BO does and what the equivalent ODATA or if not there, custom methods to:
- Create basic job header
- Add Make to stock (demand link)
- Add Operations
As for why REST?
- Well you have Microsoft walking away from WCF
- You have EPICOR doing all their new front end (Kinect) with REST
- You have the Bart (Software architect at Epicor) tell us REST is a better choice
And if you have 40+ years of experience all over the software industry, then you know when it is time to stop wishing for return to the past:
- CORBA ORB (gee seemed like a great idea at the time)
- SOAP WSDL
- or WCF (which if you read the writing on the wall is headed the same way).
- and our customers (us government) loves ODATA (look at odata.gov)
Maybe the future is GraphQL (would like to know what Epicor thinks).
But really, in this case, some folks business needs allow them to work with REST, GraphQL and that is great, and others will be using WPF and WCF and thick clients. As one pundit here said there are lots of ways to do this.
But what is not desired is someone who wants to spend hundreds of hours of precious consult $$ to explore and experiment to read the entrails of EPICOR traces. For a person who knows how JobEntry works, this is a 10 minute question. That is what is needed.
So maybe I can provide a little clarity on what we intended to solve with REST from the tools development perspective. When we built out REST v1 the mission was to make our existing APIs easier to get at using a REST interface, but not to try and solve the much larger surface of - how do we make super easy APIs for each business object.
So what REST is for us is a RESTful-ish veneer over the existing APIs which makes it significantly faster to get started with integrations, makes simple things like querying out BO data simpler to get at, and in a limited way makes API integrations against the OData a bit more resilient to underlying ERP changes since you can send and pull partial data you need. But it’s not all candy and roses - from a tooling perspective we can’t automatically solve making complex APIs which we have thousands of into simple to use APIs. To do that someone has to carefully redesign each one. So under the rest veneer all of the same data validation, sequencing, etc that’s baked into that very large set of services is still in play in the same way and we intentionally provided the direct mapping POST methods. So we provide generated swagger & odata $metadata that describes the services, but generally speaking our complex business object services have logic too complex to express in that fashion. Fields aren’t just required they’re required when x, but not y. Records can be saved only after certain other actions have taken place so there’s multi-api-call-sequencing that matters. That’s what ui trace is good for - understanding the sequence & details in which the ERP Client uses the existing BO services.
So all that said you should use rest for the reasons you enumerate - it’s the same api you’re hitting when in WCF there so that’s not really any easier you have to figure out the same complex sequence of events for the same complex business objects in the same way. WRT mapping to OData it is not always 100% possible to do so and sometimes you will need to use the custom methods (aka the direct business object api). Update in odata in particular as everyone has noted maps to UpdateExt. These are generated methods that attempt to simplify updates to a BO and sequence events - how well these services encompass the full scope of behaviors in the direct API varies and may not always be appropriate so sometimes you do need to call one of the custom methods.
Here’s my 2c on GraphQL - We think the GraphQL is niceand it’s built with a lot of the same problems as OData in mind namely that it helps build a lighter payload, be more resilient to underlying changes in the API, and has good query semantics. We might add it eventually as an option, but for the moment we think OData is solving the same set of problems for us and we have more important harder things to solve in the API that would get you all more value such as api keys with imbued security (maybe), standard oauth2, improved metadata and swagger, better help, import/export services for bulk operations, custom facade services to let you craft your own updateExt type of simple services atop the complex apis, etc.
11 Likes
For what my opinion is worth… i doubt much - As noted, REST has provided a much quicker and painless way to interface the system. Since it’s introduction in 10.1.500, I’ve seen nothing but positive strides in it’s overall usefulness in the system. I take solace in knowing that it (as is much of E10) is a growing beast that is sure to get better with time and input from users such as ourselves. Just the fact that the @Bart_Elia, @bconner, @Olga. @Rich (and the several many other official experts) are gracing our community is proof of Epicor’s commitment to getting our real world experiences and turning them into better vNexts.
After all my fawning over REST, it’s all too true what @bconner says. The REST exposes the BL but there is inherent complexity in that logic. It’s a tall hurdle most of us here have had to jump (and trip over as @hkeric.wci notes). That’s why our community here is so epic - you have people who have had the same hard knocks, willing to share experiences and give advice. Outside of the free advice that you can get from the forums, there are also two other more direct approaches - 1) I think Epicor offers an SDK course that might give a much deeper dive into the architecture and best practices of the system ( I could stand to learn those myself) 2) Hire a development consultant to not just do the work, but to teach you how to do it. (Shameless plug)
3 Likes
Dr. Just to clear the air, you are more than welcome here. In other words what I meant to say was slow down a bit, revisit the fundamentals of Epicor Under The Hood and you will struggle less. You are rebuilding Job Entry to make it easier for your users, but it will be a long road unless you give yourself 14-60 days to get the fundamentals down. As soon as you asked about GetList, GetDataSetForTree and Tracing 101, it was clear that you needed to slow down a bit. Confidence can be a double edge sword.
You do realize every upgrade you will have to do rigorous testing, Job Entry isn’t ABC Code Entry. 1 Mistake and MRP Crashes, 1 Mistake and Scheduling Fails, 1 Mistake and everyone in the company will come to you and say “Yechezkal! YOUR SYSTEM DOES NOT WORK!” As if you wrote the whole ERP Application, suddently Epicor becomes “Your System”.
We try not to spoon-feed as a community, often times we do - but we’d rather guide towards the answers and teach someone to fish. Sometimes those answers may sound like a “fu” to a person, but the intend always is, you will thank me later. Just ask @Hari_Dutt who just wants a simple BPM 
since February.
We want you to keep posting, but give yourself some time to read the Architecture Guide, ICE Tools Guide and understand Epicors N-Tier Application Setup, how it utilizes Entity Framework and how it has “Entity Framework Triggers” (not db triggers). BELIEVE Me you will stumble upon a simple method that will keep you there stuck for a month all because there is internal Trigger Code overwriting you. You will start dreaming about a villain called “Row has been modified by another user” chasing you and trying to eat you.
I understood your intent as you want to learn the Framework and Epicor, and become the best one can be, so I guided you towards that – slow down, hit the books and practice, practice, practice.
We also try to guide folks towards the right solution, for example you want to make the Job Entry easier because your Mfg Folks struggle with it? To me that is not a reason you should customize, it just means a failed Training Program. We have a VERY Complicate Job Entry - a single Job can have 1000 operations and 50,000 materials, 80 Sub-Assemblies, 100 Child Jobs, building Vehicles 1 mistake and guess what happens? RECALL, Government Fines, Millions of Dollars Lost and as a Publicly Traded Company we are under Investigation and our Stock Drops. But somehow our English and Non-English speaking Computer illeterate people navigate it just fine. Perhaps Re-Train and hire someone who specializes in Training who speaks to the people, who can mix emotions with logic and resonate. Plus Job Entry should always be accessed by Engineers and Subject Matter Experts and if they are struggling, do you have the right people for the role?
I Customized the Packout HandHeld Screen for 3 months, a tiny little itsy screen spitting out labels, how hard can it be? Every upgrade I find myself debugging as Epicor adds more PCID stuff to it, breaking my stuff. I remember @Chris_Conn staying awake for days to Freight and Unfreight a Shipment, how hard can it be – we got the trace… I guess its much harder in practice. @josecgomez was struggling with Updating a Job due to an Epicor Bug he had to use UpdateExt, everything seemed simple, this was after he already had reached his 6+yrs of Epicor Under The Hood Experience.
Try understanding Epicors “Phantom, Non-Stock, Purchased, Manufactured, View As Assembly, Pull As Assembly” flags, simple checkboxes that make or break your mfg process. Before we even began to Customize that portion, we ran 60 tests to understand the cause and effect. Not a single Epicor Guide or Epicor Specialist could help us, it was hands-on and practice, practice, practice. I doubt even Epicor knows about it as much as we do now, definitely all the consultants we had were a joke and the only contribution they gave within a 8hr/2 day period was… “Did you know, if you right click the tree, you can resequence?”… “No Sh*t, where were you the other 7hrs to contribute something, while we pay for all your travel expenses” lol Paid 5K for a Resequence Tip.
Many other Screens are like Job Entry, are you going to rebuild them all? Perhaps your company has chosen the wrong ERP System to begin with, or its a proper staffing issue. We upgraded to Epicor from IBM AS/400 (Terminal) so you can imagine the challenges we faced going from DOS to UI… “why doesnt the enter key, tab anymore?” - “Because use the TAB Key to Tab”. Also IBM AS400 is FAST!!! I mean FAST!!! MRP Full Regen 45min… Epicor 8hrs.
We just upgraded from 10.1 to 10.2 and immediately a request came in to customize Logged Invoice Entry, because Epicor now makes you search Purchase Points and not just Suppliers… But on the UI You can Filter by Supplier, the team immediately said “WE NEED A QUICK SEARCH!!!” The response was “No you dont, you need to train them how to filter it, because you will see this exact same issue on 50 other screens, are we going to customize them all?”… Sometimes Better Training, Training and Re-Training is the solution. EKM (Epicor Knowledge Mentor) can assist with making EUPs and Videos.
You have ambition I give you that, but always ask yourself am I solving the cause or symptom. Example: With the CORS Issue you were happy to have resolved the symptom, but not addressing the cause of potentially corrupt Instance, before you know it - you will hot-patch 30 other things. Hope all works out! Good Luck and Welcome to the Forums.
2 Likes
One thing to mention, we had a group that did poorly, they have been trained several times. Then a few weeks ago they were re-trained, they are doing a killer job now… Turns out the problem wasn’t the people, it was the Trainer who spoke in a monotone voice and did not resonate, who knew the logic VERY WELL, when you speak in logic and process terms hes the master, guy memorized the whole Epicor Book. He can tell you more about something than Epicor Guide can.
But we gave them another Trainer who knew less but they understood him clearly! They even gave testimonials after the training, how this time they understood it all because the trainer explained to them the “WHY” with proper real-life examples, turned it into a challenge, made it fun, handed out golden stars… He Sold them on the WHY and the HOW became easy. This Trainer worked 15yrs on the Shopfloor so he spoke their language and was humble. Every 1hr he gave the class a 5min smoking break, and they were like OMG This Guy is THE BEST! Small things Matter.
Cause: Trainer
Symptom: People are struggling understanding XYZ Process, They must be not getting it. We must hire new people, these ones suck…
The same Trainer can train them a 100x, they still won’t get it. The New Trainer 1 attempt and they are now SME’s training other users and funny thing is they are now Cheerleaders and Supporters of the ERP Implementation. Win! Some people learn visually, some hands-on, some like lectures, you have to mix it all up.
" I hear and I forget/I see and I remember/I do and I understand "
Now someone has to tell Bob Smith that he sucks at human interaction despite doing the ERP Implementation 8yrs. Not going to be me.
Sometimes its difficult to look in the mirror, but perhaps the problem is the ERP Team, Managers, Supervisors or even Executives not providing the proper tools and time and not the Users.
Sometimes it is the Users, do an Audit perhaps you will find a few users “bypassing” Epicor and handling stuff via Excel, at one of our sites we had a Visio Map in the Conference Room taped on the wall Labeled “How to Bypass Epicor”. Why? Because the Plant Manager was the Cause, causing Users to follow merely orders.
Cause: Plant Manager
Symptom: Users, Supervisors, Managers were bypassing Epicor and using Excel, we should fire them immediately, for not following their training and because they havent been doing it, they already forgot what they got trained on - might as well get freshly open-minded resources who will accept the change.
2 Likes
Wow, take a couple of days off from e10Help for 400 go live and bam.
First, Stephen I am not sure how I stated incorrectly that the trace is all your need but rather it’s more like the best we have and usually does the job for folks reverse engineering the core processes in ERP. For that, my apologies for being incomplete.
The real struggle most have with ERP understanding is we (including myself) parachuting into the middle of a 100 Million+ line code base of 1700+ services and 200 odd modules with roots in the early 90s and feel overwhelmed by the tons and tons of functionality of the system with massive customization possibilities (Too many more than too few most would state).
Insert the adage of the how to eat an elephant - one bite at a time and you have my basic response. Anyone new to anything will go thru the aggressive push, the horror or overwhelmed anger, the imposter syndrome, the lights starting to go off and finally recognition and a bit of self confidence at the comprehension.
The services in general try to tackle the simple things simply. Unfortunately as many have found out internally as well as externally, certain processes have gained popularity and the flow in the system is not as easy as any internal or external would prefer. The easy reaction is to toss baby and bath water out and break every existing customer and partner and integration. That is something we will not do.
What we will do is build new services to simplify certain recognized flows. We are looking at new patterns that I hope to be able to have us show off over the next cycles but #SafeHarbor as always. REST is an obvious go forward and REST patterns are slightly different than the existing core methods especially to restafarians such as myself. Options are being reviewed that take legacy, existing an future needs into account.
As the majority of our new customers are cloud based and the new Kinetic UX is trickling out to market, that area is becoming more and more important to us and all will benefit from a cleaned up API surface. Stay tuned but in the meanwhile, plenty of good anecdotes up here.
6 Likes
@Bart_Elia, @bconner Thank you so MUCH for your informative comments. (and @hkeric.wci , your comments about serviceConnect also are very timely, we will look more carefully at the pros/cons).
I had no idea I was opening such a hot topic. It seemed a simple technical issue, needing some information. More likely, I should have realized that humor rarely works except in person. I think some people misread this as anger. It is the opposite, Rather:
I agree with @Bart_Elia that we are really excited about what the REST interface enables. And I think our team will soon be able to show how this really improves the Epicor ecosystem, and we are looking forward to contributing.
As for the value of looking at traces. Yes, that is a technique. But probably one that should be the last resort, rather than the first.
The value and beauty of was has been done here is that by having all the information in the DB, it is a place for mining meta-information about all sorts of causal links about dependencies.
Let me sketch out an idea, that will need fleshing out, and would need some work, but it might get folks thinking about what is possible). [I will be out of the country for 2 weeks, so I cannot follow up on this]
For example, there are lots of chains of DB state changes triggered by BPMs , etc. One thought I have one could have a graph database (e.g. the free Neo4j) with attributes related to data and action chains. This would operate in parallel with the MS SQL relational DB.
One can then construct and interactive query interface to:
- look for cyclical paths
- look for race conditions
- discover conflicts in update between transactions, processes, etc.
- find spanning node paths to discover all touched BOs, or tables,
- explore timing and latency for hidden execution paths
No, not a week project, but the meta-data about these causal chains already are in the DB,
If you want, we have sponsors (or epicor might have customers) that would be interested in an R&D project to exploit reinforcement learning, gradient analysis and hill climbing to do process optimization (think of discovering business rules that actually are working as bottlenecks to efficient tool and personal use).
In any case, opening the ERP system to a wide ecosystem of toolware, is a great business value for EPICOR,
(as for WCF, well I have been a Microsoft tech for many many years. Do folks here still remember DirectAnimation, DirectShow, JET, ODBC, OLEDB, and lots of other casualties. REST also has it’s issues, but I applaud the move, mostly because it allows better leverage of a large ecosystem).
2 Likes
Traces are always my first step if I’m automating or side-stepping/replacing an Epicor process. I try to understand what Epicor planned the software to do, and then I decide what our business wants and how much of that I need to tweak. Traces have saved thousands of hours of digging through disassembled code, and I’ve done my fair share of that as well.
I’ve also never seen this much customization ability, this much access to code, this much access to the developers and designers who built this product, on any other platform. Epicor is worlds beyond everyone in this category, and the developers have a great willingness to help.
I’m pretty sure OLEDB and ODBC are still around, and the others are still around, but under a different name (e.g. Extensible Storage Engine - Wikipedia). That’s what we do as humans…learn and grow, which requires change. Part of that change is making things simpler, faster, or smarter. Yesterday is was SOA, today it’s Cloud Computing, tomorrow it will be Exploding Space Modulators (once we make it to Mars). Same idea, simpler means, faster to the destination.
If there is something that helps your business, Epicor allows you to use that if you have the knowledge and determination to use that. Almost all technology can be attached onto the product and used alongside, so if you want to use GraphQL, Epicor isn’t preventing it. What I’ve found is there is usually someone in the community who is in the same boat and are investigating these technologies as well. The flexibility of this system incredible and you will often see encouragement to utilize that flexibility for your own processes.
I second (or third, or fourth) Haso. Read the docs, blow up a server or two (test of course). The more you do it, the easier it is to understand what is noise and what is music, especially when it comes to the traces.
2 Likes
I thought I would fill you in on our progress. Before I left for a 10 day overseas trip, I hired a Epicor consultant. In 3.5 days he had a working Job Creation, using CURL he could
- Create Job header
- create Demand link (stock)
- assign human resources
- Add operations
- Engineer, release and schedule.
All by ODATA methods (and I added the only custom method GetNextJobNumber).
The guy was:
- Excited by this project
- Had no REST experience
- Not a programmer
- But had a great attitude
- NO whining about needed to spend 60+ days learning fundamentals
- DID not use Trace
- NO comments about C#, WPF, BLTester, (i.e. he is a non-programmer)
- Did not make stupid comments like: navigate via .NET Reflector, dotPeek, dnSpy. and spending 80+ hours a week tinkering.
All he did was come with a exciting, positive attitude. And in the two day that I have been back I have slapped on a React/Redux Forms driven interface with a very powerful material-ui table/pivotchart toolware (not Kendo, which I know but one I think is even better).
@bconner, you have a great system. Strongly encourage you to follow up on what you are said above about having better documentation for the REST API. If you get that, you will get a much larger talent pool building and expanding your product via REST.
We are excited about showing and sharing this at the next EPIC or other forums. Here is my 2-cents on the value proposition for what you guys have done:
- Truly RAD development times
- Modern clean and custom interface
- Rapid iteration for co-design of workflows with customers (we can rebuild the UX experience in hours).
- Full spectrum access at the BO level to Epicor
- Non-opinionated UX experience (WPF was forcing some really poor choices)
- Access to powerful web based Visual Analytics tools (D3, DevExtreme Tables, Pivot, Charts, etc.)
I could go on.
1 Like
Well shit, sounds like he needs a better paying job.
2 Likes
If people can do this with a blindfold and have no corruption then there is no excuse for anyone.
Especially not for those who have 7yrs of Epicor Experience or more. I should ask for money back from Codabears, Pronto Progress, cre8tive, Epicor CSG, SixS Partners for having decades of experience - Gold and Platinum Partners hmmm., probably a shit-ton of pre-made snippets, yet still taking their time and even sometimes when it takes 15 days, its buggy as hell. If anyone is reading it from any Consulting Companies, step-up your game. New Kids on the block.
Yes that means you too @Chris_Conn - spending a week Freighting and Unfreighting a Shipment, with your employer having access to the SDK with all the glory of Development Comments, SCR Numbers, Full Schema in Plain Text, Client and Server-Side Code
What if Epicor University and what is thought at Insights is, simply… wrong. That Epicor even advocating BL Tester, Tracing and other things is just a conspiracy to fill your mind with… garbage? To occupy our minds so we dont investigate Operation Paperclip… Food for thought.
When Epicor sends its “Certified” Consultants with 20yrs of experience, they cant even touch your guy, because most of the SMEs that Epicor sent, struggled, desperately, provided misinformation and had to call in for additional help… Sometimes they even give-up and call it a bug and fly back home, send us a bill and expect us to pay in full… Someone tag Epicor’s Head of Consultancy, to learn from the master.
2 Likes
I appreciate the comments on the technology approach being more reasonable to understand and on board than alternatives we have provided in the past. There is a lot of value in being able to treat the system as a black box and not having to know all the details during your initial understanding and approach to the system.
Looking at some of this thread though I think you can see some alarms being raised about learning the details as a valuable step in adopting the product. Sooner or later, something will be wrong and having that increased level of understanding will help future you 
4 Likes
@Yechezkal_Gutfreund This is absolutely the story we want to tell on what REST can do for you.
We might like to have this person out to insights next year to tell it!
Now as you dig into deeper into other BOs the above conversation still applies you might end up tracing or just trial and error figuring out what’s required in what circumstance on different BO services, but (depending on the service quite a lot of CRUD activities are as easy as described).
on the documentation - we continue to have this discussion wrt how to expose more information and make it easier to reason about. There are some obvious low hanging fruit items we’ll do like exposing more $metadata we have at hand, but the real hard part is complex contextual business rules and multi-service call flows where the exact rules really only exist in code. We have some ideas about how to generate something useful from the information we do have (telemetry, inspect-able code) - docs or even friendlier api facades. In a similar direction to a comment you made above wrt process inspection machine learning. One of those weekend research projects I’ve been meaning to try for some time now.
I think you are on the right track with these comments. A lot will have to do with how much automated reflection and introspection you can do at the source level, how much will have to be done by automated tracing, ML, and other techniques.,
Ideally, good interfaces provide nearly opaque abstractions that cover the internals. Look at the MS .NET docs for hastable: https://docs.microsoft.com/en-us/dotnet/api/system.collections.hashtable?view=netframework-4.8,
Lots of examples, remarks, see also, caveats, etc.
Yes, in my time I have done 100K+ lines of assembly code (I worked at DEC and was part of RSTS/e OS development), I have done CUDA, FPGA, etc. but we don’t want to expose those lower level machinery when we can create a BO layer over the DB. This is application work, not programming naked iron.
I do appreciate the challenges of your problem. If one was nasty, one would say: “what a ridiculous spider web of causal semantic links of data-flows across BO domains”. But, that is so unfair. You are modeling the real world, and that his the nature of real world systems. They are deeply inter-related and linked.
You might consider a GraphDB for some type for this meta-data, so that you can do 1st person projections and queries from a particular node of activity and trim the nature of the causation network.
I think the $$ spent on producing documentation will make good business sense. It will widen the user base (less dependence on pricey consultants), increase market reach (and hopefully add to the # of seats sold, and increase deep integration into business processes (customer loyalty) by allowing easier specialization to unique business needs.
So it took this guy 3.5 days to do what should have taken 10 minutes?
In his defense, he wasnt a developer, didnt know REST, and was very spunky.
Well that was an entertaining and informative thread to read during my morning coffee.
6 Likes
@Banderson EXCELLENT, you are making my point for me.
For a person inside of EPICOR with the inside knowledge of JobEntry, this would have been a 10 minute question. Or if the documentation was up to the level of the Microsoft .NET framework docs, it would have also have been that way.
But instead we had to hire a consultant who had to spend 3.5 days by iterative detective work to get the solution.
I did not mention this, but I also filed a tech support request with Epicare, and got back this reply:
I'm with the Tech Support side and not on the Application Support side, so I do not know the exact payload that is required for every API/BO call. This is not knowledge that we are expected to have (and I do not). If I knew I'd be more than happy to share that with you. All I can do is offer advice.
Creating a Job is a complex operation.
Having said that, I spent time trying to create a Job via the REST API in my Demo DB. This is the minimum payload that worked for me in creating a Job.
So it seems that Tech support also does not have the documentation, and has to waste time/money doing random walk detective work.
So, you help make the value proposition for Epicor to improve the REST API doc even more clear:
- You save time & money for your own tech support team
- You will radically save time and effort for your customers (3.5 days / 10 minutes) = (168x speedup)
- You can increase market share (I don’t think SAP, or Oracle) has anything near this end-user friendly system.
- We can retire consultants who approach devops with a 1970s mentality, and allow more customers to do their own customizations
- Is anyone from Epicor Management listening? Yes, you have to put out some $ initially, but I think @Banderson is making the case this makes financial sense