Our business model involves sitting on a measurable amount of finished goods.
I was brought on to start pulling that information and packaging it into something clients can interact with to get the status of their orders, mainly amount of finished good waiting for pickup.
Is there already a packaged interface for them to query and get results back? Do I need to build something that integrates with the REST API?
Something that integrates needs to be built or bought.
Customer Connect , Part Trap are a couple that are off the shelf.
Have you used CC before? It seems like a turnkey solution with extensive compatibility with epicor, I just don’t know rough cost figures. The company is trying to put our toes in the water for customer portals so I’m road mapping it out.
Epicor Commerce Connect (ECC) is a prebuilt platform that allows you to show your customers (Authorized users) your saleable parts. The interface is already built, and allows the customers to place their own orders, see status, etc. We have customers that have a large quantity of orders placed with 80% of their line items handled directly by their customers via ECC. see Epicor Commerce | Epicor U.S. for more info
I’m doing a presentation on building a portal like this using REST at Insights. If you’re there feel free to stop in for that too.
My presentation on this is 7/14 at 10:25am. After working through some authentication challenges, I finished this thing in about 30 days alongside other work. It’s pretty rapid once you get rolling. This is the tech doc that outlines the features of the portal.
Is wci’s site wordpress and if so did you need to load up a commerce plug in? I can see it going both ways where something like woocommerce is needed and also where it isn’t needed and all of those features are just made with the rest api
Our www.wcibags.com is wordpress and we use woocommerce just to display parts. That app.wcibags.com in the documentation is a custom angular application.
We had a similar requirement for material ready on floor for customers to be able to look at. Using Rest with BAQs we were able to build something very rough in house with no web development experience and some input from this group. Feel free to reach out if you have any questions.
Node is the backend with some java for the frontend.
I’m new to episuers but I couldn’t find an direct messaging option. This is EXACTLY where we want to start with our ecommerce transition.
@jdewitt6029 also made a portal using REST and BAQs I think he posted about it on here before.
I think I’ve got a plan moving forward.
- Build BAQs for the respective information we want to populate customer accounts
- Ultimate User wp plug-in to register Accounts
- Connect Users to their respective odata feeds via REST and postman (At this point I feel like I’m speaking a foreign language and kind of guessing)
The BAQs can take parameters so if you set up their customer accounts on your interface with their epicor custID as a property then you only have to build one baq that is filtered by CustID = @yourCustIDparameterthatisassociatedwiththeiruseraccount and pass that parameter in the REST call to get their respective info.
You have to find a way to key authenticate the user against epicor though and limit them to just their user info. If they used the developer console they could change the param fire off a new request and get another customers info. This will require a middle service. You don’t want to bake your Epicor credentials into any app either you should protect the actual epicor login, use a service account, use access scope, and v1 REST disabled or it’s incredibly easy to hack around.
I knew there was a lot to worry about with vulnerabilities, but now I have somewhere to start. I think this is the actual starting place. I have a developmental framework of what needs to be done. But from a customer standpoint this is the most critical component.
Biggest impact is disable v1 for external access. You can’t disable it entirely as some Epicor components still use and require v1, but block that URI using a cloudflare or some higher layer gateway in network.
Also, when you say access acount you mean a specific epicor account that has its access scope severely limited as another layer of security?
I’m thinking something like access scope limited to the BAQ’s I built for the customer portal.
I was considering using calls on direct BO’s and filtering with odata syntax, but maybe building BAQ’s and limiting access scopes to those specifically is easier regarding secuirty,
Correct so create an actual epicor user something like PortalSvcUser or whatever and apply an access scope as you described directly to the user. Apply that access scope to the API key you use for any REST calls as well, and at least you are on the path to damage control
Security is like Shrek it has layers… or maybe an onion? or maybe both but you get the point
Thank you for the clarification! I did not know that they could use the developer console they could change the param fire off a new request