Preferred ATG Module structure for any applications

Basically an ATG application is built using many layered modules whose configurations are combined by the ATG Nucleus at runtime forming a superset of all the configurations in the underlying modules. The sequence or order in which the configuration layers are combined is important and provides a facilitates to control the configuration from a generic or base application; through applications, environments, and server groups; to individual server instances.

Module structure:

Config-Module

|

|-------1.Base

|          |

|          |----atg(Default)

|          |

|          |----App specific config

|

|-------2.Applications

|          |

|          |----Store

|          |----CSC

|          |----Publish

|          

|-------3.Environments

|          |

|          |---Dev

|          |---SIT

|          |---UAT

|          |---Prod

|  

|-------4.Server Groups

|             |

|             |----Store Server

|             |----CSC Server 

|             |----Auxiliary Server

|      

|-------5.Server Instances  

|             |

|             |--Prod

|                 |----App server -1

|                     |----Primary Lock Server

|                     |----Secondary lock server

|                     |----GSS

|                     |----PES

Benefits of this approach are:

Base layer( No: 1 in above diagram) should contain configurations which are consistent regardless of module and will be used to configure the default values across applications and also to override the default ATG module configurations. 

Examples of this include:

·         Repository xml definition files such as orderrepository.xml file which is used by all the ATG modules

·         The resource bundles which are shared between the respective modules.

Application layer(No:2 in above diagram) should contain the default application configuration and will contain configurations which are specific to application ATG modules regardless of the environment, server group, or server instance. This layer will typically contain the bulk of the configurations and extend upon the application base layer(No 1) configurations. 

Examples of the types of configurations in this layer include:

·         The default values for all the application specific components.

      Environment Layer(No:3) contains configurations which are consistent for a particular environment examples of these types of configurations include:

·         DB configurations.

·         Other environment configs such as email configs.Environment specific credentials.

The Server layer(No :4) provides  most specific control of particular application servers. Examples of this layer:

1.      The CSC application is run on both the internal agent facing servers, but also the auxiliary instances of ATG. Both of these servers run the same application but with different configurations.

      The customer facing store and lock manager instances both run the store module. Both of these groups of servers will be run on the same application module but in different configurations.

The Instance layer (No: 5) provides the most specific control of particular server instance and allows configuration to be specified for individual instances of ATG servers. They are logically grouped by environment and hostname, and used the qualified ATG instance name. Examples of this:

·         ServerLockManager configurations which require specific hostnames/ports for each lock manager.

·         Global Scenario Server and Process Editor Server configurations.

      These configurations are deployed to the ATG data folder of each instance and not part of EAR.