note: this is post two in my ATG CSC and why I hate it series:
For some unknown reason ATG has replaced the standard Repository based search used for looking up profiles and orders with ATG Search engine based indexing and lookups. First off, I’ve never had any issues with the old Repository based search. It always seemed fast and worked fine. So I’m not sure why the change was warranted.
Search Issue 1: Supported Environments and Configuration
ATG Search is a 3rd party product ATG acquired so it’s not very “ATG-esque”. It’s also based on native binaries, which means it doesn’t run on Mac OS X, which myself and many others use for development. Configuring and tuning it is a real pain, and in my experience with hosting ATG Search using sites, the binary Search engines will occasionally die or have port conflicts, or otherwise foul up the works. The ATG Search used within CSC to index and provide searching on Profiles and Orders is sort of a sub-Search system. It’s not exactly full blown ATG Search, but it uses the same binaries, configs, and needs you to run Search patches, etc… In fixing a problem, which as far as I can tell didn’t exist, the new ATG CSC 9.1 has dramatically increased it’s install and runtime complexity by requiring ATG Search binary engines to be running.
Search Issue 2: Bulk Indexing Means Downtime
Another issue is if you are upgrading an existing environment, you have to run Bulk indexing on all of your existing Profiles and Orders in your CORE schema during the cut-over. What this means is that after you cut over to the new 9.1 site, using CSC 9.1 your CSR agents will be UNABLE TO HELP CUSTOMERS until the bulk indexing is completed. I’ve seen bulk indexing take ~6 hours per million items. Running profile and order bulk indexing at the same time does work, but also slows down the process a bit. So if you have 2 million orders and 2 million profiles, expect 12-18 hours of CSC downtime while the bulk indexing completes.
Search Issue 3: Incremental Indexing Falls Behind Production Activity
Newly created or updated Order and Profiles make their way into the CSC’s Search indexes by way of incremental indexing jobs, which run every 5 seconds. In testing, this works great. However in production it seems like it’s very easy to have the incoming item index events exceed the incremental indexing rate of processing. By which I mean the incremental indexing queue (SRCH_UPDATE_QUEUE) grows and grows, and your CSC Profile and Order indexes fall further and further behind your live data. Since most CSR calls are about orders placed in the last 24 hours, this becomes a serious problem very quickly as the CSR reps are unable to lookup orders or profiles created in the last X hours, where X continues to grow each day.
Part of this is due to badly planned default configurations, but part of it also seems intrinsic to the product. I am testing some post-patch 2 Search hotfixes, and we’ll see if they help or not. Another complaint I have is that no one told us about the hotfixes until after we’d gone live, and have this issue as a critical problem in our production environment. So if you are going live to CSC 9.1, make sure that ATG gives you any and all hotfixes they may have for CSC and Search BEFORE you go live.
Search Issue 4: Searching is More Limited
Because you can now only search on indexed properties your search options are more limited. For instance you can’t search for all orders in a date range (i.e. orders placed in the last 1 hour or 1 day).
Overall CSC Search is now more complex, harder to upgrade to, more limited, and has some significant production issues. Not a fan.
Leave a Reply