|
|
Found this "introductory level" article on WebSphere Developer works. It summarizes several tools that are useful in troubleshooting problems with your WebSphere installations.
Here is a list of the tools summarized in this Developer Works Article:
Admittedly, we rarely hear something like this. The email that I received contained this alarming notice:
A hard coded date is in the product, after which customers are no longer able to add items to their shopping carts. For some store models, this date is 22 June, 2008. All editions and all in-service releases have a hard coded date.
A panic situation might arise when the wcsadmin account is disabled. This happens when a user enters incorrect password more than a certain number of times. The default is 3 times, but it depends on the authentication and account lock policies. Note that the account lockout policies are enforced only if users are authenticated against the WebSphere Commerce database.
DB2 Event Monitor helps with taking a deeper look at the database activity while commerce is in use. It comes very handy in debugging commerce issues - especially when you suspect the problem is related to the database. It also exposes you to some interesting details on what database tables are accessed/used when you load/run commerce pages such as user registration and shopping cart. After all there are over 600 database tables and they all must be used in some form or the other! Be careful in using this in production environments, this is very resource intensive.
IBM released WebSphere Commerce 6.0.0.4 Fix Pack.
On my current project, we are still at 6.0.0.3. We are in no big hurry to install the fix pack in our environment. That is the case with most environments that are in production or in advanced development stage. But if you are just getting started it helps to start the environments at the latest fix pack level. Most people may have already installed fix pack 6.0.0.2 particularly if they are using Feature Pack 2 in their environment.
Commerce installation on Windows platforms requires the use of a local user account. The purpose of a local user account is to define and use the commerce services such as the Configuration Manger and the WC Help Server. If you look at the properties of these services, you will see that it uses the local user for stopping and starting the services. These two services are created at the end of the installation process and it is for this purpose, I believe, Commerce requires a local user. I am not sure about what other purposes the local user is used for. But can you use a domain user instead of a local user?
A recent experience with a commerce install frustated me a little bit, but I should confess I made a wrong calculation. I had to install Commerce 6.0 on a Windows 2003 box. As planned we would use a remote database. The remote database will be connected to using a DB2 client. But there is a catch. DB2 client was not installed prior to starting Commerce installation owing to various corporate policy reasons.
When changes are made to files in your commerce application such as commerce config files or your application config files, you would simply copy these files to WC_InstName.ear folder and get away with it. This was true up until version 5.6.x of WebSphere Commerce, whose backbone is WebSphere App Server 5.0. But things changed with WCS 6.0 and WAS 6.0.
Commerce provides built in web services for updating commerce data by the third party tools using messages sent over a transport protocol. These are typically used for updating product inventory levels, product pricing, order status and certain customer updates. In prior versions of Commerce this was predominantly handled by “Legacy” messaging system wherein the message, typically, comes over an MQ Queue. In all the cases, whether web services or legacy way, the incoming message triggers a command on the commerce server. Calling internal commerce command requires the caller to provide its identity before the command can be executed. Without a valid identification, commerce simply returns a message indicating the user does not have authority to execute the command.
Typical configuration changes implemented on a commerce instance is done via the famous instance xml file. This file is located at
{WCS_HOME}/instances/{INST_NAME}\xml\{INST_NAME}.xml
Going back to 5.6.x version of commerce, any changes to this xml file are immediately picked up by commerce when the server is restarted.This changed with Commerce 6.0 and up.
Recently, I noticed this problem when running a commerce script to enable JCA for web services. This can happen any time a script accesses DB2 system tables and the corresponding schema binding information is lost or compromised. Problems like these are noticeable when you are working with a copy of a database that is restored from a back up. I would not associate this problem to any particular commerce version. This is more like a DB2 issue than a commerce issue.
Occasionally you run into a situation where you have to load some plain csv data into a table in your database. This table is either your own custom table or application specific table. The easiest way to do this is to use the database load commands that are native to the database you are using. The alternative is to use the websphere commerce data load process. In my opinion, if it is a custom table and there and no dependencies on other tables through foreign key constraints, it is best to employ the load commands that are native to the database. You might argue that the reason we should use commerce commands is because if the backend database changes, these load commands have to be revisited. But when was the last time that something like this happened? In fact if the backend database changes, say from db2 to oracle or vice-versa, you have a lot more headaches to deal with than just the load commands!
Read the rest of this entry »
WebSphere Commerce 6.0.0.1 Fix Pack has been out for some time now. For those of you who have not applied this fixpack yet, here is the link to download it. The biggest reason why we applied this fix pack: It is a prerequisite for installing and using using WebSphere Commerce Enhancements Feature Pack - particularly for back-end integration using SOA enhancements. Here is a short list(and a complete list)
of important updates in this fix pack:
It is more than likely that your WebSphere Commerce Server is impacted by the changes to the Daylight Savings Time effective March 11, 2007. An update to your OS for DST changes is not enough in itself. IBM has alluded to the fact that the DST changes will impact the commerce server installation including version 6.0.0.1. Note that you do not have to make any changes to the Commerce Server installation itself, it is the underlying Java Run Time Environment that is impacted and need fixing. This simply means that DB2 8.2.3 and down, WebSphere Application Server 6.0.x and down, WebSphere MQ 6.0 and down are all impacted. I am not sure if there are latest fixpacks for WAS, MQ or DB2 that provided for the fixes to the DST changes.
Search Engine Optimization was introduced with WCS 5.6.0.2. If this post were to be written for WCS 5.6.0.2, it would be significantly different. SEO mapping configuration got better with each fixpack and matured to a out of box functionality with WCS 5.6.1 and now with 6.0.
If SEO is to be implemented in a production environment, it is imperative that every developer enable SEO in their development environment as well. This post will focus primarily on the configuration files used for SEO mapping in WCS toolkit.
The following are the key configuration files used for working with SEO mappings.
After reading my post on Search Engine Optimization, if you are wondering where else you can learn more about commerce specific SEO, here are some additional pointers:
Search Engine Optimization overview for WebSphere Commerce
This webcast on WebSphere Commerce Zone, discusses interesting SEO statistics, good pointers on site map, search ranking and why some commerce sites are not ranked well(yes it hurts to have a redirect to index.jsp and a flashy flash on the home page) and finally a nice list of third party SEO tools.
Driving more traffic to your WebSphere Commerce Site
Nice article on developerWorks. In addition to providing you with the basics on why SEO is needed, this article discusses some good design practices. link:hostname and site:hostname are two gems to take away from this article.
Most search engines have trouble dealing with dynamic pages such as the ones used by WebSphere Commerce. This fact is verified by a review of notes on google webmaster help center. In a section on “Does Google index dynamic pages?”, it is stated that google can index dynamic pages - but these pages can cause problems for the crawler and may be ignored. The same note suggests using static copies of the pages for the crawler. Websphere commerce by default uses dynamic links for all the categories and products. It is impossible for a large commerce site to create a static copy of every product and category in its arsenal.
How does WebSphere Commerce address this issue?
Have you ever wondered how to retrieve a forgotten Merchant Key. Using a simple JSP page, say debug.jsp, add this line to print the merchant key:
Copy debug.jsp to any of the folders or a custom folder under Stores.war. Call debug.jsp from your favorite browser.
If you noticed, the class used is com.ibm.commerce.server.WcsApp. This class has several static methods and properties that can help you retrieve the information about your commerce instance, the server and the web application.