You may have encountered an error when trying to run a Cache Refresh from within a Business Management Application such as the Catalog Manager or when trying to run a Commerce Server Staging Project with Refresh Cache enabled on one of the following resources (Catalog, Marketing or Orders).
Some of the errors logged to the event log could include a 404 error. Where is this SiteCacheRefresh.axd file that is being requested when a Cache Refresh is executed. The answer is that there is no such SiteCacheRefresh.axd file because it is actually an HTTP Handler that takes care of the SiteCacheRefresh.axd requests.
You can look to your Web.config file to find the HTTP Handler sections for this "file", but more on that later in this post.
So what about the error? There are a couple of things that one can check.
First look to the Application Event log to pull out the requested URL. It should look something like:
http://<WebServerMachineName>/OrdersWebService/SiteCacheRefresh.axd?CacheToRefresh=CatalogCache
If you are getting a 404 error, there is most likely something out of whack in your IIS Configuration.
Commerce Server 2007 (and possibly earlier versions) use the MachineName of the Web Server to construct this URL by default. It is not configurable out-of-the-box. To solve this problem:
- Try bringing up a command prompt and ping your <WebServerMachineName>.
- Take note of the IP address and go into IIS Manager and see which Application/Web Site is on that IP address.
- Check to be sure that the OrdersWebService application or whatever follows <WebServerMachineName> in your request URL is, in fact, under that IIS Web Site/Application.
- If it is not, you can either:
- Move the commerce application under the one that IIS is directing the request to your machine name to
- Add a virtual directory that points to the same directory as the actual OrdersWebService application points to
- Add a Host Header Entry for the <WebServerMachineName> to the application that has your Commerce Application
The last of these options is probably the cleanest.
Now, for more on the HTTP Handler. Why does all of this configuring in IIS matter? The Web.config of a Commerce Server Application (or one of the Web Service Applications) has the needed HTTP Handler entries to handle the request for SiteCacheRefresh.axd. If the application that your http://<ServerMachineName>...SiteCacheRefresh.axd points to does not have this web.config (specifically the HTTP Handler entries), the request for SiteCacheRefresh.axd will fall on deaf ears and IIS will have no idea what to do other than return a 404 or other related error.
You may already have another Site using the <WebServerMachineName> as a Host Header value, and you may not want to add your Commerce Server Web Service Application(s), Web Application or Commerce Web.config HTTP Handlers to this Site. So, how do you change the <WebServerMachineName>? The answer is in a new Hotfix from Microsoft, KB 91168. I have to double check this KB number and I will update this post once I do so if this one is incorrect. This Hotfix will add a registry setting that Commece Server will read which enables the SiteCacheRefresh URL to be built by IP or by Host Header by setting the registry value to either 1 or 0. If you build the SiteCacheRefresh URL with the IP address instead of the <WebServerMachineName>, you can safely assign the IP that Commerce Server puts in the SiteCacheRefresh.axd URL to your Commerce Server Application (of course you will need another IP for the Site you stole this one from). Requests for SiteCacherefresh.axd will then find the HTTP Handler information in the web.config of your Commerce Application and everything will be right in the world (well at least this particular Commerce Server world). The knowledge base article mentioned above is not published yet; it is still being written but should hit the street at some point. How do I know this? I opened a support case with Microsoft and the Commerce Server Support Team really armed with the almost all of the information that you are finding in this post.
There are a lot other possibilities for the problems you may be encountering with SiteCacheRefresh so do not hesitate to comment on this post with questions you may have about your particlar solution and I will do my best to help out.