To be honest, eBM is not slated for any enhancements. Of course, that can change if "enough" of the customer community request it. Due to its specificity to ProvideX and the ProvideX web engine to create, edit and maintain the HTML templates, most are not familiar with it and have requested a more generic platform for their solutions. As a result, the current trend is to lean toward and recommend Web Services which allows users to create their own web pages using readily available web authoring tools, then hook those pages up directly via the framework Sales Order business object to generate a sales order directly in their MAS 90 / MAS 200 database.
But, I want to quickly add eBM is still being actively supported. It is going to be next to impossible to trouble shoot the error messages you are getting using this forum and I am sorry you have been so frustrated in trying to trouble shoot this yourself. But just as there have been calls for a "more genenic" solution and because eBM is a unique implementation, especially when dealing with the web side of things, not all resellers and support analysts are equal in trying to trouble shoot. I am hopeful you understand.
I guess you have figured out I have dealt quite a bit with eBM and I do think it is still a viable solution given the requirements are not too large and complex. When looking at the error log, these entries really only give you a hint on where to start your investigations. Unfortunately, as your frustrations illustrate, you have found out somethimes it is a tedious process. Please understand, with eBM errors it is a unique guessing game since all you have are the remnants of the results and it is anybody's guess what the user did (or did not do) to get the error.
I did take a quick look at your web site but I didn't go into your eBM web store pages. I noticed you have several entry points. (I don't think this is not your problem.). It appears you are just utilizing the .store applet. This just means returning users are identified by a cookie that has been stored on their machine. If that cookie has expired or been removed by your customer or your customer is accessing your site from a different machine, they will not be recognized until they actually attempt to submit a shopping cart and supply the e-mail address and password they used on a previous shopping cart submission. I don't believe it is a "critical error" that we don't recover from or handle, but it may explain one of your error log entries.
The "Method: %TemplateSvc'InitializeTemplate(), Error: Record 101229036660001" error indicates that a problem occurred when attempting the initial display of a specific page. To know which one you need to know / see if the log entry includes the program, line number, etc. Information when you drill down into it.
The Error: Record 101229036660001 is what the key of the eBM UserID record being used to attempt the page display. It could be a new User ID on their first page being displayed or one that is being passed between pages via the cookie I spoke of previously. This is because we keep track of users as they access the eBM pages by this same cookie I spoke of earlier.
If you go into eBM User Maintenance you can use the key of the eBM UserID record value to display the record. Due to the length and format, I can tell this is a .store eBM UserID. They are assigned in the format YYMMDD + time (formatted HHMMM) + sequence number (just in case 2 new customers access the .store pages at the same time) generated. If the record has a customer number on it, that means it is a returning customer that has previously submitted a shopping cart. If not, it is a "new user looking around."
There is other information on the record that may be helpful if you look at it via DFDM. Then you can tell when the record was created, when the user last logged on, etc. That will tell you how much, if any the user accessed your pages. The greater the gap between created, last modified, last logged on the more the user has accessed your pages.
Since you have indicated it happens about 10 (or more) times daily, I would then try to determine if where the group of entries are similar and dissimilar. This would give me a hint as to prevalence i.e.. Is it only occurring displaying one specific page or all pages.
The other thing I would do is have my support contact check their issues tracking database to see if we've looked at this before. These entries do sound familiar, especially the Error #55: Cannot locate statement label. Just a guess, does this error follow the %TemplateSvc'InitializeTemplate() entry (check the date time stamps on the error log entries). If it does, this maybe an error displaying the error message. At least, I think we had one in that scenario.
I know this really doesn't answer your main concern of "am I losing web customers because of these errors" but without this kind of analysis I really can not give you any comfort one way or the other. I can say we have looked at the error log in testing and on a couple of other customers.
In fact, QA analysts (familiar with eBM) would process their test cases and not notice any issues and we still had error log entries. Was that because they were so familiar they were able recover quickly so they didn't realize an error had occurred that we needed to look into? Or, was the error non-critical and we were able to automatically recover from it? Honestly, I do not know, I am sure both scenarios occur.
From our analysis as you would expect:
-- Some of the entries we were able to determine what caused them and fix them.
-- Some we were never able to reliably recreate.
-- Some were normal entries that should have been recorded.
I am sorry to be so long winded and ramble a bit, but I want you to know, we do care. if you would like me to get into this in more detail with you to look into your specific issues, please e-mail me separately so we can discuss.
GatorGal
