Category Archives: ATG

Stealing my Resume? Try Learning ATG First.

Posted on by
1

Apparently someone decided to copy big chunks of my resume and put her name at the top and then go apply for at least one (maybe more) ATG positions. The resume got her a phone screen, but things quickly came to a halt when it became apparent that she didn’t know ATG at all.

It didn’t take long before someone figured out that her resume was actually my resume.

Imitation is the sincerest form of flattery?

It’s hard to fake your way in to “hard” technical fields where either you know your stuff or you don’t and it’s pretty quickly apparent which side you’re on. But the ATG community is so small that it’s doubly silly to try to pass someone’s resume off as your own.

Anyhow, I thought that whole story was pretty crazy so I had to share.

ATG User Group in Boston!

Posted on by
Reply

Spark::red ATG Hosting is pleased to sponsor an ATG User Group in Boston! We invite everyone who works with ATG software and technologies to join us on January 12th (Wednesday) from 6 PM to 9 PM for an evening of great food, free drinks, networking, and a few enlightening presentations.

Boston is a hub of ATG activity, and we would like to bring the community together for a casual evening of meeting new people and learning a bit at the same time. Both business and technical attendees are welcome and we plan to offer content for all audiences. We plan on making this a regular occurrence, but let’s kick off 2011 with a great ATG User Group event!

Click here: Sparkred ATG User Group – Boston for details and to register for this FREE event! I look forward to seeing you there!

The True Cost of ATG’s Core Based Licensing

Posted on by
6

This is a follow up from a post I made 8 months ago: Why ATG’s Core Based Licensing is Stupid

With the new Westmere hex-core CPU’s out now, the problem has gotten worse.  A mid-high or high end Westmere CPU presents as 12 cores.  So what does this really mean?

I just ran the numbers, and basically a mid-high end single CPU server in 2008 (Xeon 5450) would cost me 4 ATG cores worth of licensing, and would handle X amount of traffic.

A mid-high end single CPU server in 2010 (Westmere 5650) would cost me 12 ATG cores worth of licensing, and will only handle X+35 to 70% traffic (based on published SPECint, SPECint_rate, and SPECfp scores for the CPUs).

So it’s a 300% increase in costs to handle 35 to 70% more traffic.  Or just to provision with modern hardware.  That’s crazy.

ATG CSC Usability

Posted on by
1

note: this is post four in my ATG CSC and why I hate it series:

ATG CSC has a new UI

While the old Commerce Assist UI was pretty bare-bones, pretty simple, and not super “smart” it generally worked. It was pretty easy to figure out how to do what you wanted to do, and get it done. I don’t think I ever had to consult the user docs to figure out how to accomplish some task.

The new ATG CSC has a whole new front end with AJAX driven panels and actions.

While AJAX and more dynamic user interfaces can increase a web application’s ease of use and make you more productive, unfortunately the CSC’s new UI seems to do the opposite.

It’s Slow

The AJAX “loading” dialog shows up after clicks for longer than the old Commerce Assist took to load a whole new page the old fashion way. God help you if you try to use the back button. The whole thing feels sluggish. Nothing awful, like 10 second page loads, but in general everyone who’s used it has mentioned how slow it feels overall.

Also with the UI being built in such a complex manner (as mention in earlier posts) from two web apps, database UI Framework data, dynamic JSP includes, dsp includes, panels, panes, includes, and AJAX, it’s very difficult to actually diagnose the cause of various slowness, much less fix it.

It’s Complicated

The UI is more cluttered and much of it is hard to figure out. You can view a user or order, but that’s different than putting a user or order into context. Depending if you’re viewing or have something in context, the available editing actions are different. The information displayed is different. There’s odd expandable panes, that vanish when collapsed, and show the same information you get on other main panels. If you put an order into context, the screen you get then is different than the screen you get if you click on the order number on the top nav. Sometimes you can’t find your way back to the main screen, and you have to search for the order all over again, just to get the main order screen.

Aside from the navigation and information display issues, actions are more complicated as well. Adding a price adjustment to an order isn’t a two step process any longer. It’s sort of buried, and you have to go through this whole faux checkout flow with ~7 steps just to make an adjustment on the order. If you don’t make it through the whole flow and click Save, it looks like your adjustment is on the order, but when you logout it goes away.

Everything you do is wrapped under this concept of Tickets. Which is great if your CSRs aren’t already using another Ticketing system. If they are, then it’s a giant pain. It interferes with your actions, clutters up the UI, and you end up with a ton of open Tickets in the system, that you don’t want or care about.

It’s Error Prone

In some cases errors and stack traces are displayed to the CSR agent in the UI, but aren’t logged out to the logs, which makes tracking down issues reported by CSRs impossible.

Seemingly harmless errors show up in the CSC logs all the time. Window ids missing, session conf mismatch issues (this was so bad we had to turn it off for the CSC entirely), and many others. And this is an OOTB CSC setup.

Lots of stuff just doesn’t work in seemly random ways. Sometimes we see Order out of date errors (seems like Orders aren’t being handled correctly somewhere in the guts of CSC), sometimes actions just fail and work if you click the submit button again. Sometimes AJAX calls say they fail with 500 errors even if nothing shows up in the logs. All in all it feels un-tested across the board.

Summary

The new CSC seems to be more complex, slower, and more error prone than it’s predecessor. I hope it matures in the next version, as I see a lot of potential in a more helpful “smart” application interface, but currently it just doesn’t feel like an upgrade.

ATG CSC UI Customization

Posted on by
3

note: this is post three in my ATG CSC and why I hate it series:

UI Modification

Mostly customers using ATG CSC will want to make at least minor UI customizations. This could include providing information to CSRs about alternate payment types (PayPal, BillMeLater, Gift Cards), displaying customer loyalty program status, or more involved changes to support non-standard actions or flows.

Commerce Assist UI

When modifying the UI of the old Commerce Assist product, you basically ended up loading the DCS-CSR WAR into your own project (SVN/Eclipse), editing it’s JSPs directly, and deploying it out at the ATG install as part of your build process. While a little hacky, it was a very straight forward and simple process. Most of the JSPs were simple and used a small number of basic included files to support common fragments. Looking at a page in the Commerce Assist tool, and then tracking down which JSP you’d need to modify to change the page was very easy. The whole UI was driving using a single WAR filled with straightforward JSP files. With an Eclipse builder setup to call an ANT task that copies out the JSPs, you can actually see your UI changes in the Commerce Assist application in real time; no building, no bouncing. Simple.

ATG CSC UI

The new CSC tool’s UI is a much more complicated beast. The user interface is built dynamically using a mis-mash of JSPs and JSP fragments coming from two completely different WARs. The overall Service interface mostly comes from the agent.war, which is part of the Service module, where as commerce specific elements (such as order presentation and manipulation, catalog browsing, etc…) are pulled from the CSC’s DCS-CSR.war. There are many more JSP fragments and includes used, and the organization of the file is much more complex and confusing than the old Commerce Assist.

UI Framework Repository Data

The way the interface is built, how tabs and panels are presented, is managed via repository items in the database. These UI Framework items are the reason that you have to run a CA instance within CSC. This CA instance is used to deploy out the data used to build the UI. Until you setup CA and run a Full Deployment, you can’t even hit the CSC at all, since none of this data is available. Perhaps there is a good reason that these UI data elements need to be versioned and deployed from a workflow, independent of code/JSP development that makes sense in ATG Service, but within the context of CSC I doesn’t make any sense to me.

UI Components

Presumably in order to make UI customization easier, the JSPs (both from agent.war and DCS-CSR.war) include many fragments, and many of these fragments aren’t loaded via simple includes, but instead have includes referencing properties on Nucleus components. There are a number of undocumented components which each point to a JSP URI and a context root. For instance, a JSP representing a panel within the UI might include three sub-fragments by referencing three different ATG components, and doing each include based on properties of that component.

The premise is that instead of having to load the ATG WAR(s) into your project, and modify JSP files within the WARs, you can create a new custom WAR (myapp-csc.war), create new JSPs in that WAR for whatever overrides you need to make, and using the config layer override the URL and context root on the appropriate UI component. Then the parent JSP will include your custom JSP fragment from your WAR instead of the default JSP fragment.

This sounds great! Unfortunately it all breaks down about 5 minutes after you start actually looking at the JSPs.

The first issue is that many of the fragments you’d like to modify use a JSP (not DSP) include of a top.jspf file. You can’t just copy and paste the original JSP to your new JSP and modify it in place, because that include will fail and break most of the original functionality of the fragment. Because it’s a JSP include you can’t point it back at the original WAR context root. You have to copy the top.jspf into your war. However, agent.war and DCS-CSR.war have two different top.jspf files (in the same relative path), for instance one loads in the dsp taglib with a prefix of “dsp” while the other uses a prefix of “dspel” as well as many other differences. So assuming you want to override JSPs from both WARs, which is pretty likely, you have to copy in both, rename them, and reference the correct one for each of your custom JSPs. As far as I could tell, none of this was documented. Then you go ahead and setup your config layer overrides, build, and deploy.

The second issue is that there’s a great deal of logic and markup that is NOT in JSP fragments loaded in this way. As soon as you hit this scenario (which you will), you’re back to loading in the ATG WARs into your project, modifying the JSPs directly, and building out your customized versions of the WARs to the ATG install for assembly into the EAR. Only now you’re doing it on two WARs, not one.

As soon as you hit the second issue, you have to question the logic of using the configuration system at all, since it just adds more complexity, and you’re probably better off just working with the ATG WARs you have in your project.

Extensive markup and logic is hidden in tags

Then you’ll find some section of the UI that you need to change, only you can’t find the JSP that’s creating the markup. This is because there are JSP tags which include hundreds of lines of HTML output and JSP logic (DCS-CSR.war/WEb-INF/tags/displayOrderSummary.tag is a great example of this). So now you’re modifying tags as well as JSPs.

AJAX and DOJO

Another element that increases the complexity is that much of the interface is now AJAX driven, so pages are built and rebuilt via Javascript and AJAX calls, not just straight forward JSP. Figuring out how to make modifications to an AJAX driven UI is complex enough when its your own application and code, it’s MUCH harder when it’s two (two WARs) black boxes of DOJO magic with no documentation.

To summarize

In order to make relatively minor modifications to the CSC’s UI, you have to deal with:

  1. UI Framework Data in the DB and deployed via CA
  2. A custom WAR with JSP overrides and config files to override UI component properties
  3. JSPs in DCS-CSR.war, which you’ve had to add to your project and edit directly
  4. JSPs in agent.war, which you’ve had to add to your project and edit directly
  5. Tags in both wars
  6. Undocumented DOJO AJAX logic

It’s a real pain. I’m sure many of the changes were well intentioned, but in my experience when the rubber meets the road the new UI system makes customization and debugging much more difficult.