Configuring Selective Cache Invalidation: ATG

You can optimize a site’s performance after a switch deployment by enabling selective cache invalidation on target repositories. A repository that is thus configured invalidates its item caches selectively during deployment, rather than invalidating the contents of those caches entirely.

If enabled:

Only those cached items that change as a result of the deployment are invalidated. All other cached items remain unchanged. Because selective invalidation increases deployment overhead, you might want to configure a threshold for the number of invalidated items. On exceeding that threshold—the sum of all changed items in a deployment—the selective invalidation process is skipped and the deployment invalidates all cached items in the target repositories.

If not enabled:

Item caches of all deployed repositories are invalidated. This can result in slow response time to initial requests, as fresh data is obtained directly from the database.

Constraints

Two general constraints apply to usage of selective cache invalidation:

1. Selective cache invalidation only applies to item descriptors that use simple caching mode.

2. The atg.repository.RepositoryImpl method invalidateCaches() clears all caches from the target 

    repository, even if selective cache invalidation is enabled for that repository.

Configuration Steps

You configure selective cache invalidation on the production server and the asset management server, as follows:

1. On each production site repository, set the GSARepository property  

    selectiveCacheInvalidationEnabled to true. By default, this property is set to false.

Note: You can use the liveconfig configuration layer to enable selective cache invalidation on desired 

repositories. As installed, the liveconfig configuration layer enables selective cache invalidation on certain 

ATG repositories such as productCatalog.

2. On the asset management server, configure the item invalidation threshold by setting the threshold  

    property to a positive integer in this component:

   /atg/epub/sci/ServerSCIThresholdController

   The default setting of -1 allows an unlimited number of item invalidations.

  

Excluding Repositories and Item Descriptors

A production site publishing agent can be configured to exclude specific repositories and item descriptors from selective cache invalidation—in other words, require that item caches be fully invalidated on each deployment. To do so, set the property fullInvalidationRepositoryPaths in this component:


/atg/epub/sci/AgentSCIThresholdController

You set this property as follows:

fullInvalidationRepositoryPaths=\
   repository-path[=item-descriptor[;item-descriptor]...] \
   [,...]

repository-path is the path to a repository.

item-descriptor specifies which item caches in that repository to invalidate on each deployment.

If no item descriptors are supplied, all item caches in the repository are invalidated. The property can specify multiple comma-delimited repositories, and each repository can specify multiple semi-colon-delimited item descriptors.

For example:

fullInvalidationRepositoryPaths=\
   /atg/commerce/catalog/ProductCatalog=category;product

Sample filter class in ATG

Filter Example:

For Creating filter you need to extend with CachedCollectionFilter class,

All our logic should comes under generateFilteredColection() method,

In this class i have tried to adding some skus to collection,

shouldApplyFilter(), generateContextKey(), generateFilteredCollection() these methods are overriden from CachedCollectionFilter class,


/**
http://immuraliraj.blogspot.in
**/

package atg.custom.filter;

import java.util.Collection;
import java.util.Iterator;

import atg.repository.RepositoryItem;
import atg.service.collections.filter.CachedCollectionFilter;
import atg.service.collections.filter.FilterException;

public class CustomFilter extends CachedCollectionFilter {

    @Override
    public Object generateContextKey(Collection arg0, String arg1,
            RepositoryItem arg2) {
        // TODO Auto-generated method stub
        return null;
    }

   
    @Override
    protected Collection generateFilteredCollection(Collection unfilteredCollection, String collectionIdentifierKey,
            RepositoryItem org) throws FilterException {
        // TODO Auto-generated method stub
        logDebug("Inside the GenerateFilteredCollection : immuraliraj.blogspot.com");
        if(unfilteredCollection == null){       
        return null;
        }
        /*Adding some sku for custom filtered collection*/
        Collection customFilteredCollection = generateNewCollectionObject(unfilteredCollection);
        Iterator iterator = unfilteredCollection.iterator();
        while(iterator.hasNext()){
            RepositoryItem sku = (RepositoryItem)iterator.next();
            customFilteredCollection.add(sku);
        }
       
       
        return customFilteredCollection;
    }

    @Override
    public boolean shouldApplyFilter(Collection arg0, String arg1,
            RepositoryItem arg2) {
        // TODO Auto-generated method stub
        return false;
    }

}

CustomFilter.properties

$class=atg.custom.filter.CustomFilter
$scope=request
cacheEnabled=false


Note: after creating the CustomFilter component, this component will be enable in scenario's so that we can you use this class for creating some sku promotions

Configuring Sitemap Generation In ATG

Configuring Sitemap Generation

To set up the sitemap generation process, you must create and configure:

    One SitemapGeneratorService component

    One or more StaticSitemapGenerator components

    One or more DynamicSitemapGenerator components

    One SitemapIndexGenerator component

    One SitemapWriterService component on each page-serving ATG instance

Configuring the SitemapGeneratorService

The atg.sitemap.SitemapGeneratorService class manages the process of generating sitemaps and sitemap indexes. The ATG platform includes a component of this class, /atg/sitemap/SitemapGeneratorService. To configure a SitemapGeneratorService component, set the following properties:

sitemapGenerators
    An array of components of classes that implement the atg.sitemap.SitemapGenerator interface. Typically this is a mix of components of class atg.sitemap.StaticSitemapGenerator and components of class atg.sitemap.DynamicSitemapGenerator.

sitemapIndexGenerator
    A component of class atg.sitemap.SitemapIndexGenerator.

sitemapRepository
    The repository that stores the sitemaps and the sitemap index. This should be set to /atg/sitemap/repository/SitemapRepository.

sitemapPropertiesManager
    A component that maps properties in the SitemapRepository to the names used in Java code. This should be set to /atg/sitemap/repository/SitemapPropertiesManager.

sitemapTools
    A component with utility methods for looking up and modifying items in the SitemapRepository. This should be set to /atg/sitemap/repository/SitemapTools.

maxUrlsPerSitemap
    The maximum number of URLs to be stored in a single sitemap file. If this property is not set explicitly, it defaults to 50000, the maximum allowed by sitemap.org.

maxSitemapSize
    Maximum size of a single sitemap file, in bytes. If this property is not set explicitly, it defaults to 10485760 (10 Mb), the maximum allowed by sitemap.org.

urlPrefix
    String to prepend to the URL entries produced by the generator components. This property is not actually used by the SitemapGeneratorService itself, but you can set it here and then set the corresponding property of the generator components by linking to this value.

webApp
    The Nucleus pathname for the component of class atg.service.webappregistry.WebApp that represents the web application that the sitemap is generated for. This property is not actually used by the SitemapGeneratorService itself, but you can set it here and then set the corresponding property of the generator components by linking to this value.

warDir
    The operating-system pathname of the deployed WAR file that the sitemap is generated for. This property is not actually used by the SitemapGeneratorService itself, but you can set it here and then set the corresponding property of the generator and writer components by linking to this value.

In addition to these sitemap-related properties, SitemapGeneratorService also has several properties it inherits from atg.service.scheduler.SingletonSchedulableService. See Invoking Sitemap Generation and Writing for more information.


A properties file for a SitemapGeneratorService component might look like this:


$class=atg.sitemap.SitemapGeneratorService
$scope=global

schedule=calendar * * . . 1 .
scheduler=/atg/dynamo/service/Scheduler
clientLockManager=/atg/dynamo/service/ClientLockManager
lockName=SitemapGeneratorService

sitemapGenerators=\
     /atg/sitemap/ProductSitemapGenerator,\
     /atg/sitemap/CategorySitemapGenerator,\
     /atg/sitemap/StaticSitemapGenerator
sitemapIndexGenerator=/atg/sitemap/SitemapIndexGenerator

sitemapRepository=/atg/sitemap/repository/SitemapRepository
sitemapPropertiesManager=/atg/sitemap/repository/SitemapPropertiesManager
sitemapTools=/atg/sitemap/repository/SitemapTools

maxUrlsPerSitemap=10000
maxSitemapSize=5000000

Configuring the StaticSitemapGenerator

The atg.sitemap.StaticSitemapGenerator class generates sitemaps for static pages. This class has a staticPages property that you use to specify a list of static pages to be included in the sitemap. For example:

staticPages=/index.jsp,\
            /support/contact.jsp,\
            /company/news.jsp,\
            /company/aboutUs.jsp

 

The entries in the list can use wildcards in the following ways:

    A single asterisk (*) matches a filename of any length in the specified directory, but does not include files in subdirectories. For example, /company/*.jsp matches any JSP file in the /company/ directory, but not in the /company/about/ subdirectory..

    Two asterisks (**) match subdirectories to any depth. For example, /company/**/*.jsp matches any JSP file in the /company/ directory or any subdirectory of it.

    A question mark (?) matches any single character in a filename. For example, /company/news?.jsp matches news1.jsp, news2.jsp, etc., in the /company/ directory.

The StaticSitemapGenerator class has changeFrequency and priority properties for setting the default values of the <changefreq> and <priority> tags for each URL in the static pages sitemap. You can override these values for an individual page or group of pages by explicitly setting the values in the entry for the page or pages, as in this example:

staticPages=/index.jsp,\
            /support/contact.jsp:monthly:0.8,\
            /company/*.jsp:weekly

To configure a StaticSitemapGenerator component, set the following properties:

changeFrequency
    The default value to use for the <changefreq> tag for each URL. This value can be overridden for specific pages in the staticPages property (see above).

priority
    The default value to use for the <priority> tag for each URL. This value can be overridden for specific pages in the staticPages property (see above).

staticPages
    A list of static pages to be included in the sitemap (see above).

sitemapFilePrefix
    A String used to form the names of the dynamic sitemap files. If a single file is generated, .xml is appended to this String to form the filename (e.g., if sitemapFilePrefix=dynamicSitemap, the resulting filename is dynamicSitemap.xml). If multiple files are generated (because the maximum number of URLs or maximum file size is exceeded), 2.xml, 3.xml, and so on are appended to the second and subsequent files (e.g., dynamicSitemap2.xml, dynamicSitemap3.xml, etc.). Note that the value of sitemapFilePrefix must be unique for each sitemap generator component, to prevent overwriting of files.

urlPrefix
    String to prepend to the filenames found using staticPages to form the URL entries included in the sitemap. This should include the protocol, domain, and port (if needed). If the webApp property is null, urlPrefix should also include the context root; for example:

    http://www.example.com/mywebapp/

webApp
    The Nucleus pathname for the component of class atg.service.webappregistry.WebApp that represents the web application that the sitemap is generated for; for example:

    /atg/registry/webappregistry/MyWebApp

    The StaticSitemapGenerator examines the web application to find the context root to append to urlPrefix. If you include the context root in urlPrefix, leave webApp null.

warDir
    The operating-system pathname of the deployed WAR file that the sitemap is generated for; for example:

    C:\jboss-eap-4.2\jboss-as\server\atg\deploy\ATG.ear\mywebapp.war

    The StaticSitemapGenerator looks in this directory for files that match the patterns specified in the staticPages property.

Configuring the DynamicSitemapGenerator

The atg.sitemap.DynamicSitemapGenerator class generates sitemaps for dynamic pages. This class uses a URL template to translate dynamic URLs to static URLs for inclusion in the sitemaps. For example, suppose the URL for a product detail page looks like this:

http://mywebsite.com/mywebapp/productDetail.jsp?productId=id

DynamicSitemapGenerator iterates through all of the product repository items in the ProductCatalog repository and for each item generates a static URL, such as:

http://mywebsite.com/mywebapp/jump/product/12345/Oxford+Shirt/

To configure a DynamicSitemapGenerator component, set the following properties:

changeFrequency
    The value to use for the <changefreq> tag for each URL.

priority
    The value to use for the <priority> tag for each URL.

sourceRepository
    The repository whose items are used to construct the dynamic sitemap URLs. For example, for a Commerce site, this is typically /atg/commerce/catalog/ProductCatalog.

itemDescriptorName
    The name of the type of item to retrieve from the source repository to use for constructing URLs. For example, for a product detail page on a Commerce site, this would typically be product. Note that an individual DynamicSitemapGenerator component can use only a single item type, so if you want your sitemap to include pages based on different item types (e.g., product pages and category pages), you need to configure a separate DynamicSitemapGenerator for each item type.

transactionManager
    The transaction manager to use. Typically /atg/dynamo/transaction/TransactionManager.

template
    A URL template component that translates URLs for inclusion in sitemaps. Typically this is a component of class atg.repository.seo.IndirectUrlTemplate, which translates dynamic URLs to their static equivalents. See URL Templates for more information.
 

sitemapFilePrefix    A String used to form the names of the dynamic sitemap files. If a single file is generated, .xml is appended to this String to form the filename (e.g., if sitemapFilePrefix=dynamicSitemap, the resulting filename is dynamicSitemap.xml). If multiple files are generated (because the maximum number of URLs or maximum file size is exceeded), 2.xml, 3.xml, and so on are appended to the second and subsequent files (e.g., dynamicSitemap2.xml, dynamicSitemap3.xml, etc.). Note that the value of sitemapFilePrefix must be unique for each sitemap generator component, to prevent overwriting of files.

urlPrefix
    String to prepend to the URLs created by the URL template. This should include the protocol, domain, and port (if needed). If the webApp property is null, urlPrefix should also include the context root; for example:

    http://www.example.com/mywebapp/

webApp
    The Nucleus pathname for the component of class atg.service.webappregistry.WebApp that represents the web application that the sitemap is generated for; for example:

    /atg/registry/webappregistry/MyWebApp

    The DynamicSitemapGenerator examines the web application to find the context root to append to urlPrefix. If you include the context root in urlPrefix, leave webApp null.

Configuring the SitemapIndexGenerator

The atg.sitemap.SitemapIndexGenerator class generates sitemap indexes. This class creates a sitemap index containing a list of all of the sitemap files generated by the corresponding SitemapGenerator components.

To configure a SitemapIndexGenerator component, set the following properties:

siteIndexFilename
    The name of the generated sitemap index file; for example, sitemap.xml.

urlPrefix
    String to prepend to the sitemap filenames to form the URL entries included in the sitemap index. This should include the protocol, domain, and port (if needed). If the webApp property is null, urlPrefix should also include the context root; for example:

    http://www.example.com/mywebapp/

webApp
    The Nucleus pathname for the component of class atg.service.webappregistry.WebApp that represents the web application that the sitemap is generated for; for example:

    /atg/registry/webappregistry/MyWebApp

    The SitemapIndexGenerator examines the web application to find the context root to append to urlPrefix. If you include the context root in urlPrefix, leave webApp null.

Basic Fulfillment Process : ATG

Basic Fulfillment Process:

Online shopping can be broken down into two major phases, the purchase process and the fulfillment process. The purchase process is everything that is done before checking out, while the fulfillment process begins after the checkout.

The transition from the purchase process to the fulfillment process occurs when the SubmitOrder message is sent out after a successful checkout. The successful delivery of this message signals the transfer of control and the beginning of the fulfillment process.

The SubmitOrder message is a JMS ObjectMessage that contains the serialized order object. The order is serialized so that fulfillment can be serviced by an entirely independent system.

Building the fulfillment system on top of JMS provides the flexibility of a distributed fulfillment system. For example, a site could contain products from various vendors that can be purchased through the same account. A large site might sell bikes from one vendor and books from another publisher. These orders would require different fulfillers because they would not be fulfilled from the same warehouse. The Purchase Process allows for multiple shipping groups and multiple payment methods. The Fulfillment Process then determines which shipping groups will be fulfilled by which fulfiller and forwards the requests to the relevant fulfillers.

The following list describes the control flow during the Order Fulfillment process.

    1.OrderFulfiller receives a SubmitOrder message containing a serialized copy of the order. The owner of the order object is the component that receives this message. By default, the OrderFulfiller receives this message.

    2.The OrderFulfiller passes control of the different components to the configured fulfillers using FulfillOrderFragments. In this example there is only one fulfiller, the HardgoodFulfiller.

      Note: The various fragments contain the shipping groups associated with the items in the fragment. All the shipping groups listed in the fragment are now controlled by the component receiving this message. In this example, the HardgoodFulfiller now controls the shipping groups.

    3.While the HardgoodFulfiller controls the shipping groups, all modifications to the shipping groups take place through the HardgoodFulfiller. It is important that no other component modifies these shipping groups while the HardgoodFulfiller controls the shipping groups. The HardgoodFulfiller could be running on a back-end system in a different environment. If other components need to make changes to the shipping groups, the ModifyOrder requests are forwarded to the HardgoodFulfiller. The HardgoodFulfiller is responsible for making the requested changes to the shipping groups while they are under its control.

      Note: All modifications are performed by fulfillers by calling pipeline chains. For more information, see the Processor Chains and the Pipeline Manager chapter.

    4.When the shipping groups are shipped, a ModifyOrderNotification message is sent. When this message is sent, the HardgoodFulfiller gives up control of the shipping groups within the order. Control is transferred back to the OrderFulfiller automatically if no one else has control until the complete fulfillment of the order. This follows the assumption in the pattern that the OrderFulfiller retains control until the order is complete.

    5.The OrderFulfiller receives the ModifyOrderNotification message. If the business rules allow payment to settle on first shipment, then the payment groups are charged with the cost of the items, shipment and taxes. Business rules can also specify that payment be settled upon the shipment of the last shipping group.

    6.After the order is settled, the OrderFulfiller changes its state to NO_PENDING_ACTION and no longer controls the order.

    

   
Note: The OrderFulfiller is the only class that has control over the payment groups and the only class that can modify the highest-level Order object.

The fulfillment system is designed to be a flexible implementation that is easily extensible. This flexibility allows for the different ways businesses handle their fulfillment. If the ATG Commerce order fulfillment system is not appropriate for a site, it is easy to remove the ATG Commerce order fulfillment framework. Remove the ATG Commerce order fulfillment framework by not running a fulfillment server and having another component listen for the SubmitOrder message. The SubmitOrder should contain all the information necessary for the vendor to start the fulfillment process.

Sample Scheduling a Task : ATG

Scheduling a Task

In order to schedule a task, a component needs a pointer to the Scheduler, which is usually set as a component property. The component schedules a new task by calling addScheduledJob on the Scheduler. The Scheduler executes the job as scheduled.

When the Scheduler executes a job, it calls performScheduledTask on the object that performs the task, which must implement atg.service.scheduler.Schedulable. Typically, the component that schedules the task is also the Schedulable component that executes it, but this is not strictly required.

CustomScheduler.java

package atg.custom.schedule;



import atg.nucleus.GenericService;
import atg.nucleus.ServiceException;
import atg.service.scheduler.Schedulable;
import atg.service.scheduler.Schedule;
import atg.service.scheduler.ScheduledJob;
import atg.service.scheduler.Scheduler;

public class CustomScheduler extends GenericService implements Schedulable {

    private Scheduler scheduler;
    private Schedule schedule;
    int jobId;
   
    public Schedule getSchedule() {
        return schedule;
    }


    public void setSchedule(Schedule schedule) {
        this.schedule = schedule;
    }


    public Scheduler getScheduler() {
        return scheduler;
    }


    public void setScheduler(Scheduler scheduler) {
        this.scheduler = scheduler;
    }


    @Override
    public void performScheduledTask(Scheduler arg0, ScheduledJob arg1) {
        // TODO Auto-generated method stub
        logDebug("Muraliraj says Hello");
    }

    @Override
    public void doStartService() throws ServiceException {
        // TODO Auto-generated method stub
        ScheduledJob scheduledJob = new ScheduledJob("Hello","Prints Hello",getAbsoluteName(),getSchedule(),this,ScheduledJob.SCHEDULER_THREAD);
        jobId = getScheduler().addScheduledJob(scheduledJob);
        //super.doStartService();
    }
   
    @Override
    public void doStopService() throws ServiceException {
        // TODO Auto-generated method stub
    getScheduler().removeScheduledJob(jobId);
    }
   
       
   
}


Note : If a job runs in the same thread as other services, no other scheduled services can run until the job finishes. If the job is long and expensive, it should run in a separate thread. If the job is short, it should run in the same thread

CustomScheduler.properties

$class=atg.custom.schedule.CustomScheduler
$scope=global
scheduler=/atg/dynamo/service/Scheduler
schedule=every 1 minutes

Note: Start the server and check the server log now, every 1 minutes you can see the message "Muraliraj says Hello",