Skip to main content

ATG - how to create and deploy a new atg module

ATG products are packaged as a number of separate application modules. Application modules exist in the ATG installation as a set of directories defined by a manifest file.

To create a new module, follow the below steps :
  1. Create a module directory within your ATG installation. 
  2. Create a META-INF directory within the module directory. Note that this directory must be named META-INF. 
  3. Create a manifest file named MANIFEST.MF and include it in the META-INF directory for the module. The manifest contains the meta-data describing the module.
  4. A module located at <ATG2007.1dir>/MyModule is named MyModule and a module located at <ATG2007.1dir>/CustomModules/MyModule is named CustomModules.MyModule.
  5. Within the subdirectory that holds the module, any number of files may reside in any desired order. These files are the module resources (EAR files for J2EE applications, WAR files for web applications, EJB-JAR files for Enterprise JavaBeans, JAR files of Java classes, platform-dependent libraries, HTML documentation, configuration files,...)
Sample MANIFEST.MF content :

Manifest-Version:  1.0
ATG-Config-Path:  config/
ATG-Required:  mycomp.my-commerce   mycomp.my-search-query
ATG-J2EE:  j2ee-apps/my-estore
ATG-EAR-Module:  j2ee-apps/my-estore
ATG-Class-Path:  lib

  • ATG-Required --> A space-delimited set of module names. Here we will define the other modules that need to be included in this module. When the application is started up, the module’s manifest is processed after the manifests of the modules that the module depends on. Note that in most cases, you should set this attribute to include the out of the box module DSS. DSS has ATG required DPS and DPS module has DAS.
  • ATG-Config-Path --> Check the ATG-Config-Path for the property files for this module.
  • ATG-Class-Path --> The ATG platform adds the ATG-Class-Path value to the beginning of the EAR file’s classpath as each module is processed. Paths are relative to the module’s root directory.
Read  more about different manifest.mf attributes @ http://docs.oracle.com/cd/E26180_01/Platform.94/ATGProgGuide/html/s0403applicationmodulemanifestfile01.html


How to create an ATG ear ?


           To create an ATG ear module, your web.xml should contain some basic elements. To use ATG platform functionality, a web application needs to start Nucleus by invoking NucleusServlet. So it should be included in the web.xml to load on start up.

<servlet>
 <servlet-name>NucleusServlet</servlet-name>
 <servlet-class>atg.nucleus.servlet.NucleusServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>

Also the following tag lib alias name should be given to call the dsp tags.

<taglib>
<taglib-uri>/dspTaglib</taglib-uri>
 <taglib-location>/WEB-INF/tld/dspjspTaglib1_0.tld</taglib-location>
</taglib>

             To assemble the ATG application, we can use the "runAssembler.bat" available @ ATG\ATG2007.1\home\bin\runAssembler.bat location. The basic syntax of the command follows this format : runAssembler  earfilename  –m  module-list  .  Each EAR file built by runAssembler includes the following J2EE modules:
  • atg_bootstrap_ejb.jar: This module contains a single session EJB. The EJB’s class loader is used to load the ATG classes needed by the application.
  • atg_bootstrap.war: This module starts up Nucleus and runs the DAF servlet pipeline and the DAS servlet pipeline (for JHTML).
  • The EAR file can optionally include Dynamo Administration, which is packaged as a web application named atg_admin.war and you must specify the DafEar.Admin module when you run the application assembler to include Dynamo Administration.

             You can create two types of EAR files with the ATG application assembler, development and standalone. Both types contain all ATG classes needed for the application. The primary difference is in where the configuration files for Nucleus components are stored. In development mode, the application draws its Nucleus configuration information from the ATG installation folders. In standalone mode, the application stores its configuration in the EAR file itself.

             The main differences between development-mode and standalone-mode EAR files are found in the WEB-INF/ATG-INF directory of the atg_bootstrap.war J2EE module. In this directory, both types of EAR files have a file called dynamo.env, which defines Dynamo environment properties. In a development-mode EAR, the dynamo.env file contains the following entry, which tells the application to get its configuration from the .properties and XML files in the ATG installation :  atg.dynamo.use-install=true. So in development-mode you can make configuration changes without having to rebuild the EAR file.



Comments

  1. very good explanation...Thanks ..Thomas

    ReplyDelete
  2. Great information for starters. I appreciate you work for us. Thanks a lot!

    ReplyDelete
  3. Really Good explanation Mr.Thomas. Thanks

    ReplyDelete

Post a Comment

Popular posts from this blog

ATG Search Indexing - overview of different steps in search indexing

Read more about the search indexing behind the scene steps @  http://tips4ufromsony.blogspot.in/2011/12/atg-search-indexing-behind-scene-steps.html ATG Search prepares searchable content by indexing the products specified in the XML definition file (/atg/commerce/search/ProductCatalogOutputConfig). Generally there are two types of indexing 1.  Full Indexing  --> all data taken for indexing 2.  Incremental Indexing --> only changed data will be taken for indexing When full indexing is triggered, following happens:    1. The out of box component BulkLoader will call IndexedItemsGroup.getGroupMembers() to load the products to the XHTL document. It prevents uncategorized products from getting indexed. The definition file format begins with a top-level item as a product and includes the properties of parent category and childskus. For each product, the set of Variant Producers configured in ProductCatalogOutputConfig is execute...

ATG Search - search engine tuning settings

In this blog, I am going to list the best tuning settings for ATG Search engine. The AESoapConfig.xml, AESoapWaspConfig.xml  and AEConfig.xml are the xmls referred below and you can find it @  <ATG_DIR>\<Searchx.x>\SearchEngine\<operating_system>\bin\ folder. (1)  Make sure that the AESoapConfig.xml's rwTimeout is less than or equal to routing's readTimeoutMs. You could find the routing's readTimeoutMs @ atg\search\routing\SearchEngineService component.               rwTimeout is the  length of time in seconds to wait before a read or write operation times out on an active connection. The number can be decreased to improve performance. However, a value that is too low could cause slow connections to be prematurely closed. (2)  Adjust the number of engine threads to match the number of CPUs available to the engine. Note that the minimal value for maxThreads and maxSpar...

ATG - basic concepts of ATG

This blog is for the ATG beginners to get some basic overview about ATG. I just given the ATG concepts as a list of numbered points for the ease of understanding. 1. At the framework level, ATG is a               java based application platform for hosting web-based applications, as well as RMI accessible business components,               with an ORM layer,               a component container,               an MVC framework,               and a set of tag libraries for JSP. 2. Art Technology Group(ATG)'s Dynamo Application Server (DAS) is a Java EE compliant application server. DAS is no longer actively developed as ATG recommends using other Java EE applications servers for its products such as BEA WebLogic, JBoss or IBM WebSphere. 3. Prior to ATG 2007, JHTML was used instead of JSP for view purpose. J...

ATG Search architectural flow : Search and Index

I would like to explain the high level ATG Search implementation architecture ( for an online store) through the above diagram. In this diagram 1.x denotes the search functionality and 2.x denotes the indexing functionality. I have given JBoss as the application server. Physical Boxes and Application Servers in the diagram ( as recommended by ATG )  : Estore ( Commerce ) Box --> The box with the estore/site ear (with the site JSPs and Java codes). Search Engine Box --> The box with the search engine application running. Indexing Engine Box --> The box with the indexing engine application running. CA (Content Administration) Box --> The box with the ATG CA ear ( where we could take CA -BCC - Search Administration and configure the search projects) . Search Indexer Box --> The box with the ATG Search Index ear ( to fetch the index data from repository). Note that the engine performing indexing will need access ...

How the ATG Order flow manages a transaction

See more about ATG  Tx management @ http://tips4ufromsony.blogspot.com/2012/05/atg-how-to-use-transaction-manager.html Most of the ATG Commerce form handlers extend atg.commerce.order.purchase.PurchaseProcessFormHandler. The transaction management pattern in order flow is implemented through this form handler’s beforeSet, afterSet, and handler methods. The transaction will be started @ beforeSet method and is ended @ afterSet method. In general, the design pattern for updating an order is as follows: Acquire lock-manager write lock on profile id from the /atg/commerce/order/LocalLockManager Begin Transaction Synchronize on the Order object. Modify Order Call ((OrderImpl) pOrder).updateVersion(); --> atg.commerce.order.InvalidVersionException is thrown based on this Call OrderManager.updateOrder() Release Order synchronization End Transaction Release lock-manager write lock on profile id from the /atg/commerce/order/LocalLockManager     ...