IBM Infocenter URL for CommandContext is Infocenter CommandContext API

When you review the methods you will see lot of deprecated methods which mention use of other context objects to access the information.

For this article we will review the CommandContext.getRemoteAddr() method which will give the IP address of the user accessing the site.

Infocenter mentions:

getRemoteAddr()
Deprecated. The TransportData object should be retrieved from the AuditContext of the request. The remote address is retrieved by calling TransportData.getRemoteAddress()

We need to use the AuditContext, but the first question is how we get instance of AuditContext.

CommandContext.getContext(strContextName) is the method we need to use.

Below sample code explains how to get IP address using the AuditContext

AuditContext auditCtx = (AuditContext) getCommandContext().getContext(AuditContext.NAME);
System.out.println("IP Address "+auditCtx.getTransportData().getRemoteAddress());

Issue:

In the final step of check out flow, when the user clicks the order button he might be displayed with a message like “Order not locked but should be locked”.

Sample Logs:

[2/13/11 1:09:15:500 EST] 0000009f WC_ORDER      > 222ee85c:12e1d76ea52:-7ffb com.ibm.commerce.order.commands.PreProcessOrderCmdImpl.validateShippingAddress Entry

[2/13/11 1:09:15:500 EST] 0000009f WC_ORDER      < 222ee85c:12e1d76ea52:-7ffb com.ibm.commerce.order.commands.PreProcessOrderCmdImpl.validateShippingAddress Exit

[2/13/11 1:09:15:500 EST] 0000009f CommerceSrvr  A com.ibm.commerce.order.commands.PreProcessOrderCmdImpl performExecute CMN1022E: Order 11001 is not locked, but it should be locked.

[2/13/11 1:09:15:609 EST] 0000009f FfdcProvider  W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on C

[2/13/11 1:09:16:078 EST] 0000009f servlet       I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [WC] [/webapp/wcs/stores] [/AjaxActionErrorResponse.jsp[2/13/11 1:09:15:890 EST] 0000009f bod           I   Order 11001 is not locked, but it should be locked.

Cause:

The final step of the order confirmation might be calling the Out-Of-Box OrderProcessCmdImpl. Before proceeding with the processing of the order, the command checks the state of order. In the database, it would check for ORDERS.LOCKED field. If the value of this field is 0, it would indicate that the order was not locked and ready for order confirmation.

This could happen if the call to the OrderPrepareCmdImpl got skipped. During the process of preparing the order, this command also locks(LOCKED=1) before the order can be confirmed using the OrderProcessCmdImpl.

The command invoked when the cart is access unlocks the orders (LOCKED=0). One command would be OrderItemDeleteCmdImpl which unlocks.

Solution:

1. Understand the checkout flow and the possible skipped step which could miss the call to OrderPrepareCmdImpl.
2. Ensure by using a workflow like check to ensure that OrderProcessCmdImpl should not be invoked before OrderPrepareCmdImpl invocation step is executed.