Completing the Order | MySQL and JSP Web Applications: Data-Driven Programming Using Tomcat and MySQL

I l @ ve RuBoard

With the beans in place to record orders and authorize credit cards, you can write the JSP to run the credit card and complete the order (see Listing 13.9).

Listing 13.9 authorizePurchase.jsp

 <%@ include file="/jsp/cust/AutoLogin.jsp" %> <%@ page import="com.bfg.product.Product" %> <%@ page import="com.bfg.product.Order" %> <%@ page import="java.util.Iterator" %> <%@ page import="com.bfg.cart.CartItem" %> <jsp:useBean id="orderaddr" class="com.bfg.customer.Address" scope="session"/> <jsp:useBean id="ordercredit" class="com.bfg.customer.CreditCard" scope="session"/> <jsp:useBean id="cart" class="com.bfg.cart.Cart" scope="session"/> <jsp:useBean id="customer" class="com.bfg.customer.Customer" scope="session"/> <% if (!cart.authorizeCharge(ordercredit)) {     response.sendRedirect("authorizationFailed.jsp");     return; } Order order = new Order(customer, orderaddr, ordercredit, cart); order.recordOrder(); order.emailReceipt(customer.getEmail()); cart.clear(); pageContext.setAttribute("orderaddr", null, PageContext.SESSION_SCOPE); pageContext.setAttribute("ordercredit", null, PageContext.SESSION_SCOPE); %> <HEAD> <TITLE>Order Receipt</TITLE> </HEAD> <BODY> <%@ include file="/jsp/includes/bfgheader.jsp" %> <CENTER><H1>Order Receipt</H1></CENTER> Thank you for your order, your credit card has been charged <%= order.getOrderTotalString() %>.  Your order number is <%= order.getOrderNumber() %>.  Please write down this order number in case you need to refer to the order at a future date. You will also be receiving a copy of your receipt via e-Mail. <%@ include file="/jsp/includes/bfgfooter.jsp" %>

After the normal heading items, the page runs the authorization call to see if a successful result is returned. If not, it redirects to a "We Had a Problem with Your Order" page (which is so much more polite than "You're a deadbeat, get lost").

Assuming that your customer has money in the bank, a new order object is created from all of its component elements and is recorded. Then you can have the page send the nice customer a receipt via e-mail.

Finally, you need to have the page clear out the cart contents and make sure that the order information isn't left in the session, where it might possibly end up bleeding through somewhere that it shouldn't.

This last step might seem overcautious, but I've seen real-life examples of platform failures that caused one person's order information to leak into another session. It's just good common sense to purge the cart as soon as it is no longer needed.

If you go to the site and give final confirmation to an order now, you'll see the screen shown in Figure 13.1.

Figure 13.1. The order receipt page.

graphics/13fig01.jpg

Confirmation will also result in the following e-mail being sent:

 Return-Path: <turner@blackbear.com> Received: from JAMES (james [192.168.1.10])      by linux.blackbear.com (8.11.6/8.11.6) with ESMTP id fAJ4n0H19225      for <turner@blackbear.com>; Sun, 18 Nov 2001 23:49:01 -0500 Date: Sun, 18 Nov 2001 23:49:01 -0500 Message-ID: <4544380.1006145340846.JavaMail.james@JAMES> From: turner@blackbear.com To: turner@blackbear.com Subject: Receipt for order 8 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Status: Thank you for shopping at Books for Geeks. Here is the receipt for your order 8 placed on 2001-11-18 CODE        TITLE                           QUANT  PRICE  TOTAL ================================================================ 672320959   Java 2 Micro Edition (J2ME) Ap   4     .99 9.96 PALMCASE    Genuine Nagahyde PDA Carrying    1     .00 $ 0.00 672321173   Oracle and Java Development      5     .99 9.95

FAILING TO HANDLE FAILURE

In almost all cases, all you really need to do as far as exception handling goes in JSP is make sure that you redirect to a friendly failure page rather than spitting Java backtraces all over the page.

You just wrote some code that is the exception to that rule, and you didn't really write it correctly. Consider the following scenario. authorizeCharge is called on the cart, and it succeeds. At this point, the customer's card has successfully been charged for the transaction. Now, the next thing the code does is call the recordOrder method. What happens if that method throws an exception before the order is recorded in the database (for any number of reasons, including bugs in the code, a database crash, a power failure, and so on)?

That's right ”the customer has been charged for an order, but this hasn't been recorded in the database. This is going to lead to a very unhappy customer.

In a perfect world, the code should record the order first with a rollback segment set and then should try to authorize the charge. If it fails, it should roll back the order. But if you want the method to record information such as the credit card authorization number in the order record, this is difficult to do in this order.

Alternatively, you can put a catch around the order record and void the credit card transaction if the recording fails.

Of course, this won't save you from a situation in which the power goes out or the hardware fails before the credit can be issued. In a worst-case scenario, a good gateway provider will have an independent interface that you can use to look at all the charges that have been processed in a given period and match them up against what you have in the database.

I l @ ve RuBoard