Administration Tools and Topics

ADMINISTRATIVE TOOLS AND TOPICS

SECURITY ISSUES

Remote Admin pages must only be access with an SSL connection plus additional means of validation. Failure to setup remote admin access correctly can greatly compromise the security of your e-store.

see security configuration

DECOMMISSIONING, DELETING, AND ADDING RECORDS MANUALLY

E-commerce system are extremely similar to a standard multiple ledger accounting systems combined with a real-time manufacturing control system and should be approached with a similar type of understanding as you would a accounting system. Many of the rules that apply to accounting systems also apply to e-commerce systems. Some types of manual changes to records are the same as ledger entries and must be used with discretion and great care.

The same as in accounting programs, there are two classes of records in SendSafe. There are records of events and records of objects. In general terms, records of objects are intended to be manually modified while records of events are not intended to be manually modified after the event is completed. Examples:

Items records are records of objects
Order records are records of events
Order lineitem records are records of events
Customer records are records of objects
Eventlog records are records of events

Note: In most cases, each unique database table is analogous to an accounting ledger.

The same as with all multi-ledger accounting systems, records of events and objects should always be decommissioned or voided, and never deleted. In almost all cases, records of events should only be manually individually added to repair an imbalance.

Deletion of any record is destroying part of an audit trail.
When you manually delete or add any record in an e-commerce or accounting system there will be ramifications (good or bad).
There are ramifications when you manually alter any data in an event record in an e-commerce or accounting system because events are records of historical fact and never intended for alteration. There are semantic exceptions, for example in systems set up for delayed charge capture, it is fine to manually alter an order's price or collection of lineitems to meet a customer's changed requirements before the charge is captured (i.e. before the sales event has been completed).
Deleting an item record can result in broken or orphaned orders which are missing lineitems (see how to decommission or void an item).
Deleting a customer record can result in orders for that customer no longer being accessible in an admin page.
Deleting an order record will result in imbalances between different sales ledgers such as internal credit card event records, eventlog records, customer state records, and order state records (OrdersPostProc).
Deleting an order record will result in broken or orphaned order lineitem records.

In all multi-ledger accounting systems, the delete functions are part of a special class of functions called "ledger entries." As in all multi-ledger accounting programs, these types of functions are used only in special cases to repair damaged ledgers, records, or create special balance adjustments. The only way to repair a damaged accounting ledger is to have the ability to delete or add individual records without creating or deleting any other related records. To repair damaged accounting information is the only proper use and reason for the manual delete functions presence in SendSafe.

Once a record is deleted there is no simple way to recover the record or any broken relationships (linkages). You can use the admin page to ADD a duplicate of the record but the linkages will remain severed. Linkages are created using a DB record's primary key (also sometimes called a record locater). This primary key is unique for the life of the DB. When you delete a record, you are deleting this primary key. When you ADD a record it will have a new primary key and therefore no linkage will be restored.

If you delete the parent record of an event such as an order or customer, you will leave other related records in the system as orphans. An orphan record is a ticking time bomb. Since SendSafe will reuse a deleted record keys, the possibility exist that a new record will be created which uses the key of the deleted record. If this happens, many of the orphan records will now be incorrectly related (linked) to the newly created record. As you can imagine, this is not a good thing to have in an accounting system or an e-commerce systems.

For orders (sales events) the use of the void button accomplishes any legitimate goal for deleting a sales record and does not have an impact on ledger balance or audit trail. There is also a clone button on the order page which is often used in conjunction with the void button. If you need to change an order record after the event has been complete (i.e. the charge has been captured), then you should clone the record, void the original, and make all changes to the cloned record.

How to decommission or disable specific records:

WEB BASED ADMINISTRATION

Most storefront configuration and administration is done with on-line admin pages. The starting point for all Admin is the control panel. The control panel lists all other Admin Pages and provides the ability to immediately place on-line order for customers. The filename for control panel is AdminControlPanel.asp... It can be found on your web server at the location http://www.mybiz.com/SendSafeAdm/Admincontrolpanel.asp.

This is a partial list of the SendSafe Admin pages and functions:

Web Admin Page URL Parameters:

Some of the admin pages accept URL parameters that can be used to pre-load records or perform other operations.

**Warning! UID/PID should only be used with an IntraNet connection. Using UID/PID over the Internet can greatly compromise security since URL parameters are not encrypted. The UID/PID parameter processing is disabled by default (to enabled see SendSafe.global.inc.asa configuration ).

Admin Page	LoadRec	LoadIC	UID (USerId)	PID (password)
Admin Control Panel	n/a	n/a	**UID=UserId	**PID=Password
Admin Coupon	LoadRec=Coupon Number	n/a	n/a	n/a
Admin Customer	LoadRec=RecordID	n/a	n/a	n/a
Admin Dealer	LoadRec=DealerID	LoadIC=BusinessCodeID	n/a	n/a
Admin Product Item	LoadRec=ItemCodeID	LoadIC=SKU	n/a	n/a
Admin Order	LoadRec=TransactionID	LoadIC=SendSafeTxNum	n/a	n/a

ADMIN ALERTS

SendSafe can send e-mail alerts to a list of names. These alerts go out to warn the adminitator of important events. There is a single list for the entire SendSafe system. Admin lists are not configurable by storefront. The keyword that defines the e-mail list is CC ADMIN LIST.

CLONE ASP GUI TOOL

This tool clones the ASP GUI code located in the ..\SendSafe\ServerSideCode\asp directory into all the currently configured storefronts. The purpose of this tool is to make it easier to install a storefront upgrade. This tool is used as follows:

Load new java code into ..\SendSafe\ServerSideCode\asp directory
Execute the clone command: Robot Menu Operations--> Clone Storefronts.
Force an upload to the server of the new code by executing Menu Operations--> Force Upload of Web Files
Press the [Start Processing] button.

TEST SMTP EMAIL SEVER

An SMTP Server is an outgoing e-mail server (SMTP stands for Simple Mail Transfer Protocol). This test will determine if you have correctly configured the SMTP mail server in the Primary Setup screen. This test will use the "Business E-Mail Return Address" that you entered into Primary Setup Screen. A test e-Mail will be sent to this address. This test will use all configuration items from the selected storefront except mail server (which can be entered manually for each test in a dialog box).

Open the "Setup Menu" and select the storefront you wish to test.
Open the "Setup Menu" and select "Test for presence of SMTP Server".
An "Http Server Test SMTP Server" Dialog box will open.
In the URL entry field type the URL for the Http Web Server that will be hosting your site i.e. www.johns.com or www.mysite.com.
Press the [TEST] button.
Test results will be displayed in the scrolling windows at the bottom of the Robot.
It is okay to see a few "TIME OUT ERRORS." This simply means that your mail server is running slowly. As long as you see the words "SMTP TEST RESULTS:GOOD" at the end of the test YOU can use this SMTP server to send mail.
Sometimes a test will generate lots of errors and you may want to terminate it before it is done. The only way to prematurely terminate a test is to exit the robot by pressing the [EXIT] button. If you do not exit, all test which are stuck generating errors will continue to run until they harmlessly time out in about 5 minutes.

If the test results indicate you have a running SMTP server on your Http (web) Server THEN you will be able to use SendSafe e-mail e-mail alerts, customer e-receipts, and other e-mail messages. If the last message displayed by the test contains "SMTP TEST RESULTS:GOOD", then you have a properly configured and running SMTP server ready to be used by SendSafe.

If you do not have a working SMTP server then SendSafe will be unable to send e-mail included automated e-mail alerts and customer e-receipts. If the last message displayed by the test contains "SMTP TEST RESULTS:PROBLEM", then you must either get your ISP to setup/configure the SMTP server for you OR disable e-mail acknowledgments.

If you start to see messages in the status window which contain text such as "we do not relay" or "no relay allowed" then the SMTP server has SPAM blocking configured on it. Most ISPs configure their SMTP server to block messages that appear to be part of a "SPAM Relaying Scheme." All SMTP servers can be configured to allow "selective mail relaying." Contact your ISP to find out the correct name of the e-mail server you should be using to send e-mail or to have them adjust the configuration of the SMTP server your are assigned to use.

Note: All results of each SMTP test are saved in an audit file. The name of the audit file will be SMTPTEST.<email server>.audit. (i.e. "SMTPTEST.mydomain.com.07.25.98.audit"). These audit files can be found in the ..\SendSafe\audit directory on the machine where the robot was installed.

Responses like that shown below indicate that "POP before Send" Security has been enabled in the storefront's config file WHILE the e-mail account in the storefront's config file is not validating (either userid or password are not correct):

[06/18/2002: 15:04:37 email.cpp:00809 @7] CMailClient::WaitFor( +OK ) ===> +OK abc@yourbiz.com... Recipient ok
[06/18/2002: 15:04:38 email.cpp:01291 @7] CMailClient::GetLine() ===>-ERR access denied

DATABASE DATA INTEGRITY VALIDATION TOOL

This tool will cycle through the entire Items table in the database. It will test for missing Picture Files and other record defects. The tool will also correct some defects if possible. Alway backup your database before running this tool.

The tool is optimized for databases with 8,000,000 or less items. Larger databases will not be fully run. Testing will stop at 8M unique items. A CPU utilization spike will occur while the test is running. An average computer system will be able to processes 60K records per minute.

For configuration information see:

(1) To run this tool manualy add a DBTest job to the database:

Declare @storename char(40)
set @storename =( select top 1 storecode from orders where storecode is not null)
select @storename
INSERT INTO JobQueue VALUES ('31',@storename,'{Run Once}', 1, 1, 
null, null, null, null,null,null,null )

(2) The tool will generate e-mailed status reports as it runs and once it completes.

(3) The tools report (output) will be found in the audit directory in a file named: DBTESTSUBTHREAD.<Storefront name>.MM.DD.YY.audit.