Epicor Commerce Connect vs alternatives

We’re considering upgrading our customized IBM Websphere E-commerce solution, and are thinking about Epicor Commerce Connect (the full version).

Our outside programmer is a genious with websphere, but we’re looking at migrating to a more modern platform for better integration & ease of use.

What are you guys all using for your ecommerce platform? Do you like it? Limitations/frustrations?

How about Magento from scratch instead of ECC?

Here’s what we have now: https://www.farmtek.com

We’re on-prem, and have Websphere it integrated with Epicor as well as Reachmail, and are using Google Analytics, which is cumbersome.

I’ve heard the ECC (full platform, not the 5 day lite version) is a very time consuming install, but the integration Ranier showed at Insights with the configurator was pretty slick.

Thanks for the feedback!

I think it really depends on the scope of integration you need. ECC is definitely more plug and play than a custom, but you might not need all the functionality ECC provides.
Our integration currently is custom modules on the site that call Epicor directly via the REST api.

We will be soon re-working this to build out a middle layer api to expose epicor Functions to the client (website) so that the site only needs to have simple rest calls to the middle layer api (“create order”) and the middle layer then calls the appropriate function which does all the heavy lifting.
What I found with the current approach is it’s quite difficult for a non-epicor dev to get accustom to the quirks of calling the REST api directly, not to mention the scalability or lack thereof of custom modules.

Functions is the way to go on this no need for a middle layer
API + Function
Function can do all the heavy lifting


1 Like

What are these functions you speak of?

I’m concerned about sessions though and want to make sure the calls are being passed with either a standalone integration session or another way like with the web service license.
Un-sessioned calls have caused issues in the past for me. Plus, I want no epicor related configurations (session establishment, username/password) to be configured on the website if possible. Not sure I’ll get 100 percent of that idea but that’s the why behind the thought at least

Yeha I get it, we did the same thing (we are still using that middle man) but even then we’ll move to functions and keep the middle man managing the requests only (no logic)

the whole logic will live in functions.

1 Like

I especially like the idea of the Functions due to portability, self-describing, and simple interface for the client vs. the gnarly BO calls we currently make from the site.


For sure one of my TODO’s after the upgrade (going to 500 in 2 weeks) is going to be to re-write a bunch of my crap in functions…
Man oh man I wish we were going to 600 instead…


I’m trying to jump us up to 600 in the next few weeks, but my scale is waaaay smaller than most so it’s possible :slight_smile:

I want to do something similar at some point.

  • I get that the middle man / functions protect the data, but did you do anything to limit the number of calls / distribute performance among customers?
  • How did you connect existing customers to website accounts?
  • Credit cards?

We didn’t address any performance specific issues, calls all come into the app (middle man) which uses .net and the requests are handled by .net appropriately each call is made with a SingleTon so a single Session is in use for the whole app and we are using the Web Service License.

For customers we used their Contact Record and UD fields to store Username and Hashed Passwords

Credit-cards we are going to handle via EPX and their PayEasy module (We are already using Epicor Payment Exchange)


Do you refresh your session on a schedule or is it somehow cycled or just established upon app start? I was curious if a singleton was used vs. like a transient or scoped service

BTW here’s a longer explanation of what we did for that middle man and even some code in github (though provided as is no support yada yada yada)

Session is established upon first request and if it dies or times out between requests we re-establish as needed)

1 Like

Hmm, so was it a manual process? For example, if I made a webstore now and one of our customers signed up, how would I know it was really them? Provide some numbers off an invoice maybe?

The way we did that is they had to provide an Email and several pieces of information that only they would have
Invoice Number
Order Number

if that all matched we setup the account and send email internal for approval

1 Like

Sounds good, thanks for sharing all the time.

I think the hardest part of the project might be selling it to management. They are often times against custom solutions as we are a small company and have no IT, and I am pretty much the soul person who could maintain it and whatnot. Still, maybe now that they have explored ECC and found it too expensive and unacceptable I might have more luck .

The way to sell it to provide the argument that this project (done well and in a maintainable fashion) provides a channel to generate orders 24/7 and doesn’t need a person to babysit it. E-commerce is pretty much ubiquitous these days and those without are falling behind. It doesn’t have to do everything but it’s an enhancement to having nothing at all

1 Like

This is where I thought that Azure AD B2C would come in handy. It takes the whole authentication piece out of the picture and I wouldn’t have to manage it. You can use the Graph API to create a property in AZAD to connect your login with the Customer, Supplier, Employee, whatever.

We have a custom integration that uses some staging databases and Service Connect as middle layers. It requires a fair amount of babysitting, and I wish we had something more out-of-the-box like ECC.

The biggest challenge for us is that the web side is programmed/maintained by outside developers, so we barely understand how their side works and they barely understand how our side works. Integrations get real difficult when you have two parties trying to meet in the middle like that.