Welcome to JRI's Help page for StoreFront, Dayton Access, Servers, Redback

This web page is designed to be the central point for help topics, links, etc. for issues related to the on-line aspects of Dayton Superior. Chose a link on the right to get detailed information about a specific topic.

ePortal Part Test     top

Use SOP9182 to determine if a part will appear in Dayton Access / StoreFront, and if not, why not.

UniData Paths     top

    You can not LOGTO the EPORTAL accounts via the SB LOGTO process. Instead, you must go to TCL and type LOGTO desiredpath or
from Unix, cd desiredpath followed by udt:
  • Live: /av1/igi/avante94/floprogs/EPORTAL
  • Pilot: /av1/igi/avante94/floprogs/EPORTAL_PILOT
  • Test: /av1/igi/avante94/floprogs/EPORTAL_DEV
            Note: this currently points to the PILOT94.DATA account

    If you need to point to an Avante account, use the following paths:
  • Live: /av1/igi/avante94/flodata/live/LIVE.DATA
  • BP:   /av1/igi/avante94/floprogs/live/LIVE.IIBASE8/BP8.0
  • Pilot: /av1/igi/avante94/flodata/train/PILOT94.DATA
  • BP:   /av1/igi/avante94/floprogs/train/TRN.IIBASE8/BP8.0
  • Test: /av1/igi/avante94/flodata/dev/TEST94.DATA
  • BP:   /av1/igi/avante94/floprogs/dev/DEV.IIBASE8/BP8.0

    In addition, there are some globally used accounts:
  • iConnect: /av1/igi/avante94/floprogs/global/ICONNECT
  • Redback /usr/igi/redback/server/redback

Web Paths     top

    Below is a list of various places that must have the path for the account:
  • ECP_ADMIN ADMIN /av1/igi/avante94/flodata/train/PILOT94.DATA
  • global.asa Application("Account") = "EPORTAL_DEV"1
  • global.asa Application("ERPAccount") = "PILOT94.DATA"1
1 Defined in the Unix rgwresp.ini file.

Core Basic Programs     top

    Core basic programs that are run from the web site are stored in:
  • ECPLIB
  • SFLIB
  • CFGLIB
  • DFL-PROGS (look at VOC & Unix - it's odd)
All programs must be cataloged locally.

Custom Basic Programs     top

    Custom (altered core) programs must stay in their original file (either ECPLIB or SFLIB. This is because in addition to being in the ePortal account, they are also run from the Avante account. Putting alterred code in another source file (like BP) will lead to problems with cata loged VOC pointers.
    New program should be put in the BP file. However, unlike the pre-existing programs from Epicor, these program will not have cataloged VOC pointers in Avante. Be sure to manually build these as well (in all 3 accounts).
    Also be sure to set the Unix permissions to both the source and object.

Promoting Programs to PILOT or LIVE     top

    There is a simple utility to promote basic programs (but only basic programs) forward called PUSH.SOURCE. This utility will promote cataloged program from TEST to PILOT or from PILOT to LIVE.
    To use this utility, build a SAVEDLISTS of the programs you wish to promote. It is advised that just prior to promotion, that you verify that the SAVEDLIST is correct. A good, simple test is to get your SAVEDLIST, they type
        LIST filename UNIX.DATE UNIX.TIME1
and verify that the programs to promote have date/time stamps as expected.
    Once the SAVEDLIST is built and confirmed, simply type PUSH.SOURCE. The program will display the current account and the destination account, then prompt for the SAVEDLIST. The program will then verify that all the entries in the SAVEDLIST have local cataloged VOC pointers. If even one of the items in the SAVEDLIST fails, the entire process will stop. If all the entries in the SAVEDLIST look good, it will then ask you to press [RTN] to initiate the push of the source code. The utility will then:
  • copy each piece of source code from the source file (BP, ECPLIB, SFLIB, etc) to the destination account/file
  • compile each program
  • catalog each program
  • set the Unix permissions as needed (required if it is a new program)
  • send the user an E-mail of the results
    Note that it is a good idea to then log to the destination account and verify your results just to be sure. To make this easier, pull up the E-mail of the push results, right-click in the body of the E-mail, and choose "View Source". Buried in the message in a hidden comment is a list of the programs that were copied. This is raw text. Highlight these program in the comment and copy them to your clipboard (ctl-C). Log to the destination account and drop to TCL. Edit a SAVEDLIST by typing EL SAVEDLIST name. If the SAVEDLISTS already existed, delete all existing info. Type I (insert) and paste (ctl-V) the pushed program names into the SAVEDLIST and save it. Verify that the programs have the expected date/time stamps and that the cataloged VOC items exist.
    To verify the date/time stamps, simply type GL savedlist name, then type LIST filename UNIX.DATE UNIX.TIME1
    To verify the catalog VOC pointers, simply type GL savedlist name, then type LISTCAT2
    Note that there is no archiving or "un-promoting" available at this time, so be sure you have the right programs.
-----
1UNIX.DATE and UNIX.TIME are dicts in the three program files (BP, ECPLIB and SFLIB) that get the Unix info.
2LISTCAT lists all VOCs that have a "C" in field 1.

StoreFront Bugs     top

    StoreFront has a number of bugs in it that are not obvious. If everything works as expected, things are great. However, if things do NOT work as expected, the software may or may not correctly exit out of the programs. It may or may not even inform you there is a problem.
    To determine the problem areas and notify the developers of these serious problems (missing files, missing control recs, etc.), use the Debugging Basic Programs logic. If all goes well, no E-mails are sent, but if a fatal error is detected, using these enhancements should make it fairly easy to find and fix.

Debugging Basic Programs     top

    Since DaytonAccess is all seen via web pages, we can not use the normal debugging practices of displaying stuff on the screen. Instead, the best way to do this is to add custom code to track this info.
    To track a program's compete flow, find the initial basic program that is run from the web page via the callMethod command and all subsequently called programs.
Step 1:
After the initial includes of the program(s), add the following:
Initial Program Called from Web Page All Subsequently Called Programs
$INCLUDE BP DAYSUP.COMMON
TRACKING.PATH = @FM
TRACKING.PATH = "xxx.asp"1
$INCLUDE BP INITIATE.DBUG.EMAIL
 		$INCLUDE BP DAYSUP.COMMON
$INCLUDE BP INITIATE.DBUG.EMAIL
1Note: commenting out the 2nd TRACKING.PATH statement will cleanly turn off all debugging E-mail throughout all the subroutines.
This is part of the "magic" that makes this programming technique so powerful.

Step 2:
Go to the bottom of the program(s), and add the following 2 subroutines:
*****************
BUILD.PGM.PATH: *
*****************
    TRACKING.PATH = ORIG.TRACKING.PATH
    OUTPUT.MODE = 1
    HTML.INDENT = 0
    CHILD.INDENT = 5
    CALL MV.TO.BR(TRACKING.PATH, HTML.PATH, OUTPUT.MODE, HTML.INDENT, CHILD.INDENT, "", "", "")
    EMAIL.BODY<-1> = "<u><b>Program Path</b></u><br>"
    EMAIL.BODY<-1> = HTML.PATH
    EMAIL.BODY<-1> = "<br><br>"
    NO.INDENTS = DCOUNT(HTML.PATH, @VM) -2
    RETURN

**************
DEBUG.EMAIL: *
**************
    CONVERT @FM TO @VM IN EMAIL.BODY
    EMAIL.CTL = 5
    EMAIL.CTL<2> = SPACE(NO.INDENTS):"E-mail Title"
    EMAIL.CTL<6> = EMAIL.BODY
    CALL SYSS9002.1(EMAIL.CTL, "", CALLING.PGM)
    RETURN

Step 3:
Add your debugging E-mail messages as needed. The following is the basic code that is needed:
    IF USE.EMAIL THEN
        $INCLUDE BP EMAIL.TOP
        GOSUB BUILD.PGM.PATH
        EMAIL.BODY<-1> = "Your debugging E-mail message"
        EMAIL.BODY<-1> = "Your debugging E-mail message"
        EMAIL.BODY<-1> = "Your debugging E-mail message"
        $INCLUDE BP EMAIL.BOTTOM
        GOSUB DEBUG.EMAIL
    END
    Granted, there could be a lot of IF statements in a program that never do anything if the E-mails are disabled1, but the ability to turn this back on at a later date has been shown to be worth its weight in gold. Follow this standard in your ePortal code and you will not go wrong.

META Files     top

  • For ePortal (but not StoreFront), data is passed back and forth via METADATA.
  • There are several key objects that are used, and they are defined in the ECP_META_DEFS file.
  • Each record in the ECP_META_DEFS file corasponds to a file name (called a sub-file for this web page), which generally (but not always) is the same name as the record name.
  • Data is not actually stored in these sub-files. Instead, the Dict file is used to link object properties, which in turn are linked via the accociation (field 7) of the Dict.
  • These Dicts should be updated via the web site from Admin -> meta data -> choose the appropriate file from the dropdown.
  • Base Dicts (from Epicor) are always at the end of the file, while user Dicts are inserted before the first Base dict (don't ask why - just accept it).
  • The ECP_META_DEFS record stores all the Dict info enterred via the web site as multi-values, and includes an offset to know where the Base dicts begin.
  • In addition to the normal Dict definition info, the ECP_META_DEFS record also stores a "B" for each base Dict (thus distinguishing them from user defined Dicts)
  • Always use an Association when building a Dict - this will save you headaches later when blending UniData data into a Redback object - ECPSETOBPROPS is hard-coded to look for a default of PAGE_ASSOC this value. However, other associations can be used to populate the object. Associated dicts are linked with Redback Designer under the "Field" column. If a property is defined in Redback Designer as a type "Field" or "mvField", then it must be a true field name in the linked data file.
  • ECPGETMETADATA is a generic program that reads the custom data extraction program from the ECP_META_DEFS record, in field 9, then calls this subroutine.
  • ECPSETOBJPROPS is a generic program that reads the ECP_META_DEFS record and blends the UniData info into METADATA.
  • Field 9 stores the name of the program used to extract the UniData info and load into METADATA. This will be unique for each META file.
  • If you ever need a new object:
    • Manually build the new file with the name of "META_name (ex. CREATE.FILE META_RENTAL 5 1)
    • Manually build a new ECP_META_DEFS record (ex. ECP_META_DEFS META_RENTAL)
    • Manually populate your ECP_META_DEFs record with an initial dummy record. Be sure to set it as a Base dict (even though it is not) by making field 8 equal "B" or else the web page will blow up. Pull this new dict up from Admin -> meta data -> META_RENTAL and change the conversion code to force it to go through the filing logic.
    • Create a new program to extract the data from UniData and populate METADATA. This program must have a name of "ECPX" : FILE : "AV" where FILE is hard-coded in ECPUPDATEDEFS.
    • Add the file name to administration/ad_metaselect.asp (Admin -> meta data)
    • Add the file name to ECPUPDATEDEFS (which is run when you submit Admin -> site setup).
    • Note that when you submit Admin -> site setup, it rebuilds the names of ALL the extract programs in field 9 of the ECP_META_DEFS records. If you have not build it as it expects, it will clear this value out, and your extract will not work for that file!
  • Add new user fields via the web site as needed (ex. RENTAL_NO). Note that you should always use the value of "PAGE_ASSOC" Associate. When you file your new field/Dict, it will:
    • update the ECP_META_DEFS record
    • update the true Dict file (ex. META_RENTAL RENTAL_NO)
    • update the true Dict file's Association Dict "PAGE_ASSOC" - this is vital as this is how it know how to link the fields/METADATA/Redback object. You will also want to use the Redback Editor to update your object to match your new Dicts.

Exporting to Excel     top

    Sometimes, we will want to export specific data from the database into Excel. To do this, there are several parts need to make this all happen smoothly.
    We need:
  • Step 1: a button to initiate the export,
  • Step 2: a webpage to initialte the request against the database, then export the results,
  • Step 3: a basic program to collect the desired data,
  • Step 4: a CSS for common format
Step 1:
Create a button on the web page similar to the example below. In this case, we only want the button to appear for Site and Account Admins. Note that this
  • directly invokes a JavaScript call,
  • location is a variable (from i_links.asp),
  • we are passing userid as an aurgument,
  • we always pass guid as an aurgument,
  • class="buttonface" will create a common button
<% if (admin_flg="1") or (admin_flg="2") then %>
<input type="button" value="Export All Users" name="Export All Users" onclick="javascript:parent.location='<%=ad_export_usersURL%>?userid=<%=userid%>&guid=<%=GUID%>'" class="buttonface">
<% end if %>

Step 2:
Create/modify an ASP web page that is initiated from the button in step 1. This web page should set the variable pageTitle, contain all the normal ASP code that tests for timeout, etc. It then needs to set a new object, assign the needed properties of the object, and call the needed method/subroutine (see step 3).
Assuming the subroutine worked and data was returned, the ASP page now needs to output the data into Excel.
Use the following ASP code as a template to direct the ASP page to output into Excel. This should be placed just prior to the HTML code (i.e. the <html> tag)
'Change HTML header to specify Excel's MIME content type
Response.Buffer = TRUE
Response.ContentType = "application/vnd.ms-excel"
Response.AddHeader "content-disposition", "attachment; filename=All_Users.xls"

site_root = Application("site_root")
cssFile = site_root & "/std/" & "export.css"
In the <title> section of the web page, be sure to add the following line of code:
<link rel="stylesheet" type="text/css" href="<%=cssFile%>">
This is then followed by a simple HTML page that basically just builds a table. When the page finishes, you automatically be will be prompted if you wish to open or save the file.
To make the Excel file as clean as possible so the user has to do minimal clean up, the following standards should be used:
  • assign the header row to class="highlight"
  • once you have tested the output, you should know the general size of each column - set each column width to in the header to be the needed size
  • assign each data row to class="normal"
  • build whatever formulas the user is likely to need


Step 3:
Create a basic program that reads in the object properties for any criteria, processes whatever data is required, scrubs the data, then loads the data back into the appropriate object properties.
Note: if you wish to return multiple pieces of info into a single cell, seperate them with the break tag:
        <br>
The CSS (step 4) has code to keep these neatly displayed within a single cell.

Step 4:
As stated in step 2, you should include a special CSS that was built specifically for exporting data.
This CSS defines how the table should be displayed - this will then be translated into Excel.

iConnect     top

    Agents (ECL_AGENTs) store a checksum and will fail to load if modified outside of the iConnect tool (like the editor). To fix the checksum, go to the appropriate Avante account and type:
      ECL.RUNAGENT 99999
where 99999 is the agent number. This will show the current checksum and what the new checksum should be. Use the editor and replace line 25 with the new checksum value.

iConnect     top

To have an ASP web page write to disk (usually for debugging), add something like this:
dim fs,f
set fs=Server.CreateObject("Scripting.FileSystemObject")
set f=fs.CreateTextFile("c:\IBM\Temp\YourNameHere.txt",true)
f.write("Application('sf_exists'): ")
f.write Application("sf_exists")
f.close
set f=nothing
set fs=nothing
This will write to a single line. To get a new line, add the following where needed:
f.write vbCrLf

Electronic Price List     top

There are 2 ways to export the Electronic Price List:
  • 1) A manual export by an admin for a single customer
    • customer/in_select.asp (Web page)
      • ECP:oPriceList (Redback object)
        • PriceListExport (Redback object method)
          • ECPPRICELISTEXPORT.DRIVER (Executes: PHANTOM ECPPRICELISTEXPORT GUID:xxx MODE:xxx EXPORT.RANGE:xxx)
            • ECPPRICELISTEXPORT (Extract arguments & Calls PRICELIST.EXPORT)
              • PRICELIST.EXPORT(CUSTMST.KEY, EXPORT.FORMAT, UNUSED, SOURCE, BUILD.LOG.KEY, GUID, ERR)1 (Does all the real work)
  • 2) A mass export by a site admin for all customer
    • administration/ad_userselect.asp (Web page - actually an include)
      • ECP:oPriceList (Redback object)
        • PriceListExportAll (Redback object method)
          • ECPPRICELISTEXPORTALL.DRIVER (Executes: PHANTOM ECPPRICELISTEXPORTALL GUID:xxx)
            • ECPPRICELISTEXPORTALL (Calls PRICELIST.EXPORT.SHARED)
              • PRICELIST.EXPORT.SHARED (Loops through customers and calls PRICELIST.EXPORT)
                • PRICELIST.EXPORT(CUSTMST.KEY, EXPORT.FORMAT, UNUSED, SOURCE, BUILD.LOG.KEY, GUID, ERR)1 (Does all the real work)
1 PRICELIST.EXPORT is the program that does all the real work for a single account. It is use by both the manual and mass export!

SOP9182 (PARTS MISSING FROM WEB)     top

To determine why a part is not appearing in Dayton Access or StoreFront, run process SOP9182. After entering a part number, it will show most restrictions. There is an optional 2nd prompt for the customer #, which can have additional restrictions (like Private Label).

Dayton Access is Down!     top

OH SHIT! Dayton Access is down! What do we do?
  1. This is rare - Dayton Acces is stable!
  2. There are so many things that could be considered "down". Here are the likely conditions and solutions.
Symptom Condition What to Try
Nothing shows up or 404 error Web site is down
IIS server is down (or at least that web site is) 		Connect to the mbeportal server
start/bounce the IIS server or web site
A cryptic error from the web sever Web server/site is up but had a fatal error Check the logs (see next table)
"Hunky guy" Web site is up but disabled
Maybe correct, maybe not
This was a manual action - why? 		Go to web server and check global.asa file
Look for "webStatus"
There are several levels of access

Other places to test are the IIS (web server) logs and the Reback logs.

IIS Logs (Windows Web Server) Redback Logs (UNIX Redback Server)
Connect to the mbeportal server, drill down to c:\inetput\logs\LogFiles\W3SVC2.
Open the most recent log file in a text editor, scroll to the bottom and look for any clues.
Note that the logs only get updated 1/minute so you may need to wait to see very recent activity.
Errors here will tend to simply identify a line in a web page that called a Redback mehod and that is what really failed, but it is a start. To see what code a mehod used:
  • Open the web page in an editor
  • Find the line that failed
  • Figure out the module & object
  • Launch U2 Web Designer
  • Connect to the desired account
  • Open the module
  • Open the object
  • Click on the Methods associated with that object
  • Determine the program that is called by the method - likely found in
    • ECPLIB,
    • SFLIB or
    • APLIB
 From UNIX (or prefereably a mapped drive), go to: /usr/igi/redback/server/redback/rgw/log
For most issues look at:
out_EPORTAL_####_1 (or something like that)
For the actual filing of a StoreFront order (and maybe one or two other pages) look at:
out_LIVE.DATA_####_1 (or something like that)
Your milage my vary.