Cacheable Command ! a really cool performance addition

If you are using Dynacache for you commerce site. This functionality is one of the coolest features that could be incorporated to improve caching results drastically.
It has 2 parts:
1. Writing the actual cache able command extending CacheableCommandImpl
2. Making the entry in cachespec.xml

In the command implementation, mandatory methods to be implemented
public void setOutputProperties(TargetableCommand fromCommand)
public void performExecute() throws Exception
public boolean isReadyToCallExecute() {

Good candidates for this kind of caching would be any complex computational logic such as Geo lookup, ATP messages or any complex logic that requires lot of computation and if the underlying data changes dynamically, will need to also build the cache invalidation with it.

STAGEPROP ! Mystery behind the starting number !

I have worked on stageprop over the years on several issues but this is an interesting one that I had to wake up really early morning to help resolve.
Lots of clients have millions of records to STAGEPROP so some clients use a batch commits to avoid memory problems from loading the whole set. The usage of STGPKEY is very important to remember, if there is a STAGEPROP issue where the STAGELOG processed flag is manually changed states from unprocessed to processed and back. It is very important to understand that the starting number in STAGEPROP comes from the query below.

select stgpkey from staglog where stgrfnbr=0;

Show after discount prices in Product page\Category pages

If you have 6.0.0.9 or higher versions of commerce. You can use the bean below to retrieve price after discounts.

PromotionalPriceDataBean

Before this bean, it was very performance intensive and complex to retrieve price after discount prices.

It is important to understand that it works by creating a temp order and out of the box, it only works by sending 1 catentry at a time, for multiple items, this bean needs to be extended.

The price is calculated as if an order is placed that includes only the current catalog entry with quantity of one. I haven't used this in a live site hence I am curious about the performance of this bean.

Debugging, memory problem at the appserver

In the past when we saw there were memory issues that brought down the entire site. We have used a few methods but this was the most effective and helped us figure out the issue. Heap dumps are pretty good but they take a long time and tools have size/JDK/OS limitations to load them.

Application servers > server1 > Process Definition > Java Virtual Machine

Set this parameter in the Generic JVM arguments
-XX:+PrintClassHistogram

The histogram gave a pretty good idea of the objects in memory that helped us trace the issue.

Pillars of SEO !

1. To have short URLs with productnames, categorynames and having keywords in these links.
2. Canonical URL links in the HTML header.
This is for the search engines to look at this tag and to digest the page in question should be treated as though it were a copy of the URL and that all of the link & content metrics the engines apply should technically flow back to that URL.
e.g.

<link rel="canonical" href="http://hostname/product/en/abc350" />
<link rel="canonical" href="http://hostname/category/en/s_furniturechair" />

3. Generating Google site map periodically.
4. XML site map and keeping at the root of the shop.
5. Link building and using Fat Navigation\Fat Footer With using key words in links.

Common Errors that could bring down a site?

1. If you have a couple of traces on Websphere or Commerce in production environment that is good enough to bring down the eCommerce site.
2. TrashCan user disabled. This could really spike up the CPU utilization and could also cause DB locks.
3. Dynacache servlet caching disabled, the CPU on the application and DB server would spike up that could potentially bring down the server.
4. Cart with number of items greater than 50 added to an individual cart with active promotions against those items and if the quantity is increased to a big number.
5. Not correctly setting this parameter could bring down the server.
Application servers -> web container transport chains ->WCInboundDefault->TCP Inbound Channel (TCP_2) -> Maximum open connections. (Specifies the maximum number of connections that are available for a server to use.)

APAR Installation| How to do it efficiently and reduce downtime

Generally lot of clients bring down all servers as a part of the APAR\Code installation.

There is an alternate approach that would help a lot with down time.

As most of our APAR’s could be only commerce code changes this would work perfectly, if there are DB changes this approach may or may not work and the APAR might need analysis to see the nature of the DB changes.

Steps:

1. Bring down the primary node. (Each cluster has only 1 primary node and the rest are federated nodes.)
2. The site is technically still up and should be able to handle the requests.
3. Install APAR using the DM on the primary node. (All the APARs are technically always installed only primary node.)
4. Verify for successfully installation of the APAR.
5. At this point bring down other nodes.
6. Synchronize nodes and restart.

It takes about 15 minutes to do the step 5 and Step 6 and that should be the down time.

Also the same approach is used for code deployment and apparently this helps them to confirm for the code deployment and if there are issues with any code deployment, the site can still be up while the issue is worked upon.

More Information on the topology look up in info center:

IBM has APARs, Fix Packs and Feature packs for Commerce and Fix Packs and iFixes for Application Server.

Topology Background high level: IBM 6.0 Deployment: Cell\Nodes\Node Agent\DM (Network Deployment Manager)