/Tag: ATG

ATG CSC Search Issues

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).

Search Summary

Overall CSC Search is now more complex, harder to upgrade to, more limited, and has some significant production issues. Not a fan.

ATG CSC and why I hate it

I recently worked on upgrading a client from ATG 2006.3 to ATG 9.1. The upgrade included upgrading Commerce Assist 2006.3 to CSC 9.1.

Commerce Assist 2006.3 is the ATG Customer Service application for ATG 2006.3 which allows CSRs to work with user profiles and orders. Commerce Assist 2006.3 is a relatively simple straight forward application. It’s essentially a standalone module. It can run against the existing CORE schema. The UI is simple but generally effective.

In stark contrast the new CSC is dependent on ATG Service and the front end is actually presented within the ATG Service UI. The UI is amazingly complex, which I’ll go into shortly. It also requires a new separate Service schema. It also has it’s own CA instance to deploy UI data… to itself…. It also requires it’s own Search engines.

For what it’s worth, before I met CSC 9.1, CA and Search were my two least favorite ATG products. Now CSC not only takes the cake as my #1 most disliked ATG product, but also requires #2 and #3.

There’s actually enough about the new CSC that I dislike that I’m going to break this out into a few posts:

Installation and Schema

CSC now requires it’s own schema. It also requires a bunch of schema changes to be made to CORE. Unfortunately the database installation scripts aren’t clear about where they should be run. service_production_all.sql throws a ton of errors regardless of where it’s run. The install docs are lacking, and point you to Service docs, Search docs, CA docs, etc… You also can’t really upgrade from Commerce Assist, so you lose all your old CSR related data.

Also see:

Guide for Large Scale ATG Applications

Kelly Goetsch has written a very impressive 64 page guide on the development and deployment of very large scalable ATG e-Commerce applications. There’s a ton of great information (a little bit came from me!) and it’s a worth-while read, even if your application isn’t running on 200 production servers. Unfortunately you have to have an account AND be associated with an active support contract in order to read it.

If you do, check it out:

Obligitory Spark::red ATG Hosting plug: The three founders all worked on AT&T’s massive ATG e-Commerce cluster, so we understand how to scale ATG to hundreds of nodes, and how to squeeze out maximal performance and stability out of clusters of any size.

ATG Newsletter Went Out

Our first Spark::red ATG Newsletter was sent on Tuesday morning! We’re pleased and proud to have delivered the first of many monthly ATG Newsletters.

In this newsletter we talk about the importance of improving your site performance, especially now that Google is using site performance as a search result ranking factor. We talk about Why, and provide several helpful links to help with How. I’d be remiss if I didn’t plug the fantastic ATG Hosting that Spark::red can provide, including extensive performance tuning at every level, web, app and database, using knowledge gained from 12 years of ATG experience.

We also reveal our PCI Compliant ATG Encryption Module which is the first PCI complaint credit card encryption option for the ATG eCommerce Platform. It handles strong encryption, key management, importing plain text and encrypted data, periodic re-keying/re-encryption, and more. It’s the fastest and most affordable path to being able to pass a PCI audit for your ATG eCommerce application. Contact us for more info: [email protected].

You can see the whole newsletter here: Spark::red ATG Newsletter #1, and if you haven’t already, I recommend signing up so you don’t miss the next one: Sign Up for the Sparkred ATG Newsletter!

Sparkred Launches an ATG Mailing List

Over at Spark::red ATG Hosting we’ve decided to launch a monthly newsletter. Once a month we’ll send out an e-mail with some very useful ATG content, technical tips and source code, business tricks and advice on leveraging ATG products to increase sales. We’ll talk about PCI compliance and how to reduce cart abandonment.

We won’t send more than one e-mail a month, we won’t spam you, bug you, bother you, or waste your time. Each mailing will be as packed full of genuinely useful information as possible.

Sign up for the world’s best ATG Technology and Business Newsletter!