Friday, July 15, 2011

Everest Advanced Edition 5.0 API versus eStorefront

My client that uses Everest Advanced Edition business software built a web front end for online orders using the eStorefront provided by Everest.  I wasn't involved in that part, but as I understand it, Everest generates all the pages in the eStorefront for you based on some parameters you can set within Everest.  There is some possibility of customization after the eStorefront pages are generated, but there are a couple problems with that:

A) If you upgrade Everest, then apparently the existing eStorefront ends up not working.  That means you have to regenerate all the eStorefront pages, so all your customizations get wiped out
B) The code generated for the eStorefront is really quite ugly and is in classic ASP.  There is no separation of the interface from the logic so with all that ugly code mixed in there, customization is not easy

So the client asked me to build a new store front using the Everest 5.0 API and ASP.Net.  I've built a project with the Everest API already, so I know most of its abilities.  I noticed pretty quickly that the eStorefront pages could do some things that didn't seem possible with the API.  So I looked a little more closely at the code in the eStorefront pages.

As it turns out, the auto-generated eStorefront uses a completely different set of objects and calls than the 5.0 API.  I don't know if the eStorefront is using an old version of the API or if its an undocumented API reserved just for their eStorefront.  There is plenty of documentation about the new 5.0 API, but I could find nothing about these eStorefront objects.  It doesn't help that on the Everest support site, neither their Customer Forums or the Knowledge Base are functional, both produce errors (at least for our support account).  I saw one reference to the "shopping cart" objects in the list of COM objects installed with Everest, so I think that's what they might be called.  I considered trying to re-use some of that code to get some of those more powerful features.  But even if I could find documentation on those other objects and decided to use them, I'm not sure it would be a good idea to use them anyway since they seem to have problems when Everest is upgraded.

So far I already know of a couple small consequences of using the new API instead of the eStorefront objects:

1) In the API, you can not update a customer's billing address once they have been invoiced. Once a customer is invoiced for anything, then you can only update some things in their profile, like phone number and credit cards, but some things like billing address become locked.  This is consistent with the interface of the Everest desktop application.  But there is a way around it in Everest, and there seems to be a way around it with the eStorefront objects too.

2)  The eStorefront claims that it can email you your password if you forget it.  I say "claims" because this feature wasn't working in our eStorefront.  Regardless, the API does not allow this because there is no way to retrieve a person's password for the sake of emailing it to them.  Again, this is consistent with using the Everest application, as you can't see a person's password in their profile.  The API allows a check to see if a provided password is valid, so that's how a login can be checked.  If users forget their password, they can answer their secret question correctly so that they can reset their password to something else.  The secret question and secret answer are retrievable from the customer profile using the API.

Overall, it seems like the API can handle all the important features provided to a normal user in the application for setting up a new customer and handling orders.  So it should have everything we need for the new web interface.  It will be very nice having a custom built web interface that we can customize how we want and not have to worry about it breaking when Everest is upgraded.