/Tag: ATG

What Oracle/ATG Could Do With Licensing

This is a follow-up to my post earlier this week: ATG Licensing – One Step Forward, Two Steps Back.

I feel like Oracle has really shot themselves in the foot on this. They’ve changed up how many licenses need to be sold as a minimum to small and medium customers, and they’ve done this without adequate training for their sales staff. They’ve dramatically increased the mid-market entry level costs, pricing themselves out of many deals – even with aggressive discounting. They’ve also really failed to take care of their existing customers. There’s a huge number of existing ATG customers out there, who were sold a bundle of licenses which prevents them from upgrading without spending a significant amount out of pocket. Those customers have been paying annual support fees against a broken promise of free upgrades.

The problem will get worse as future generations of processors start shipping with hex- and octo- core base configurations. In short Oracle’s licensing policy does not work with modern CPUs and ATG software pricing and infrastructure architecture.

So what could they do? I have a few solutions:

  1. Allow for software disabling of cores. This is simple. Just add an “ATG Licensing Addendum” to the contracts that allows for this. Problem solved now and in the future.
  2. Use the Oracle Standard Database licensing model based on “Sockets” not “Processors”. This is really a clean solution, has precedent in Oracle’s licensing practices, and scales well in the future.
  3. Automatically allow all MC4 bundle customers to upgrade to 6 “Processors” of Commerce and 6 “Processors” of Search on ATG 10, for free. They were sold a small but deployable bundle of Production and Staging licenses. They’ve been paying their support fees. They deserve to still be able to run a small but deployable setup of Production and Staging.
  4. Automatically upgrade any customers who have been sold ATG 10 with less than 6 “Processors” of Commerce and Search to 6+6. These customers have been sold an impossible to deploy list of licenses. Through ignorance (most likely) their ATG Sales rep sold them a lie. Make it right.

What do you think is most fair?

ATG Licensing – One Step Forward, Two Steps Back

This is my fourth post on the subject of ATG Licensing. You may want to read the previous three posts: Rant About Core-Based Licensing, Why ATG’s Core Based Licensing is Stupid, and the latest The True Cost of ATG’s Core Based Licensing.

Oracle bought ATG at the end of last year. ATG 10 was released in a similar timeframe. ATG 10 introduced some great licensing changes. In ATG 9 and earlier, ATG’s License Manager enforced the license limitations encoded in the license files provided by ATG by checking the number of “CPUs” reported by the OS. Unfortunately this number captured cores + HyperThreaded logical cores, and as I talked about in earlier posts, this number increased in each new generation of chip causing issues with license costs. The typical solution was to disable HyperThreading in the BIOS and/or disable CPU cores within the OS in order to limit the server CPU resources to match the licenses. I’m not sure there was ever written policy around this, but it was common practice and many sales reps and sales engineers explicitly okayed this approach during pre-sales architecture planning.

In ATG 10 the licensing stopped being technically enforced via the License Manager and changed over to be enforced by audits. This means that HyperThreading is no longer a 2x penalty. This is the upside! It also means you can setup servers, or change IPs, without waiting for ATG to issue you new license files all the time. This is also handy.

Now comes the bad news.

I’ve just found out that Oracle’s (new) policy is that disabling cores is not permitted to meet license limits. That means you need valid ATG licenses for every physical core installed in any of your ATG servers. They’ve also dropped the “Staging” licenses which means you now need full price production licenses for your Staging environment hardware as well.

The current generation of Intel server CPUs are Westmere 56XX and they come in quad-core models on the low end, and hex-core models on the high end. The previous generation of CPUs are Nehalem 55XX and they come only in quad-core models. The generation before that were 54XXs and they also came only in quad-core models. The generation before that were 53XX, again quad-core only.

What this means is that the smallest ATG setup is basically two production app servers for failover/redundancy with single quad-core CPUs, and one staging app server, also with a single quad-core CPU. That’s 12 cores of ATG Commerce you need licensing for (or 6 ATG Commerce “processor” licenses – which is how they sell it now: Intel chips have a .5 core multiplier to convert from “processors” to physical cores). You also need ATG Search licenses. Given how most ATG 10 sites are massively reliant on Search for facets and site navigation you really need two production Search servers, again for failover/redundancy, and another Search box in stage. You *can* run Stage Search on the Stage App server, but you still need Search licenses for it. So again, you’re looking at 12 cores/6 “processors” minimum. Plus BCC and CSC Seats, etc…

So right now, anything less than 6 “Processors” of ATG Commerce and 6 “Processors” of ATG Search, isn’t actually deployable into a production + stage setup. Unfortunately some in-flight sales proposal out there right now are smaller than that. If you’re involved in an ATG deal with fewer licenses make sure you carefully go over your architecture and deployment plan with your ATG Sales rep and your hosting team.

Here’s another fun fact: when upgrading from a previous version to ATG 10, your currently licensed cores will get you ATG 10 “Processor” credits based on the same core multiplier. I’m not sure if your staging licenses will help at all, but if they do, they won’t count 100% or even close. What this means is that all of the MANY MANY customers out there who were sold MC4 bundles (4 cores of ATG Commerce + Search + Merch + CSC, etc…) have a truly terrible upgrade path. Those 4 cores of Commerce will get them 2 “Processors” of Commerce. Leaving them 4 “processors” short. Ditto for Search. That’s well over $1,000,000 to upgrade, although you’ll probably get some discounts from your sales rep.

That’s right: after paying hundreds of thousands of dollars a year in Support fees, entitling you to “free upgrades”, you’ll have to pony up somewhere in the six-figures range to upgrade to ATG 10.

Oracle’s Enterprise licensing practices do not apply well to standard small/medium deal ATG licensing levels and certainly not to existing ATG customers.

Spark::red is PCI Level 1 Certified!

image from Purpleslog

I’m happy to announce that Spark::red ATG Hosting has received our PCI DSS 1.2 Level 1 Certification as an eCommerce MSP.  We have been Level 2 certified for a while, but completing our Level 1 certification with TrustWave as our third-party auditor is a huge milestone for us.

PCI DSS is the Payment Card Industry’s Data Security Standard.  It is a set of requirements and guidelines designed to ensure merchants who handle or process credit cards, do so securely.  There are different levels based on transaction volume and Level 1 is the highest level, required for the largest volume merchants.  Level 1 is also the most difficult certification to gain, requiring the strictest security protections, the strongest policies, and a very in depth audit by a certified auditing company, such as TrustWave.  Our certification process has taken many months and the completion of our Level 1 Report of Compliance (RoC) is a testament to our dedication to providing the highest level of secure environments to our clients and safeguarding their systems and information, as well as the information of all our clients’ customers.

At Spark::red we focus strongly on Security and Performance beyond the core ATG hosting services.  We handle more PCI DSS requirements than any other ATG Hosting provider out there.  If you are looking for an ATG Hosting provider to help manage your ATG web application, we can offer PCI Level 1 compliant hosting and handle many of your security needs.

ATG CSC Usability

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.


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.


Translated into Romanian by Irina Vasilescu


ATG CSC UI Customization

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.


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.


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.