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",

Creating a Rule Set for a Profile Group that Includes Roles: ATG

Creating a Rule Set for a Profile Group that Includes Roles:

You can use global and organizational roles to define membership of a profile group. For example, you can create a profile group that includes anyone assigned the global role “administrator.” You can then use that profile group within a content targeter, effectively allowing you to deliver personalized content according to the role of the person viewing the page.

The following example shows a rule set for a profile group that includes a global role named admin.


<rule op="includesItem">
   <valueof target="roles">
        <rule op="or">
           <rule op="and">
               <rule op="equals">
                   <valueof target="name">
                   <valueof constant="admin">
               </rule>
               <rule op="equals">
                  <valueof target="type">
                  <valueof constant="role">
               </rule>
           </rule>
        </rule>
</rule>

The <value of target="type"> setting determines whether the role is global or organizational, allowing the Personalization module to distinguish between a global role and an organizational role that have the same name.




Note: If you want to use global roles within rule sets, as shown above, all global role names must be unique.



The same restriction does not apply to organizational roles, which need to be unique only within their organization.

The following example shows a rule set for a profile group that includes an organizational (relative) role named buyer. This role belongs to an organization named MyCompany.

<rule op="includesItem">
   <valueof target="roles">
        <rule op="or">
            <rule op="and">
                  <rule op="eq">
                    <valueof target="name">
                    <valueof constant="buyer">
                  </rule>
                  <rule op="eq">
                    <valueof target="relativeTo.name">
                    <valueof constant="MyCompany">
                  </rule>
            </rule>
        </rule>
</rule>

Note also that you can create profile groups that include roles by using the Targeting > Profile Groups window in the ACC. However, the ACC supports the creation of <rule op=or> rules only; in other words, if you create a profile group that includes people assigned to Role A and Role B, everyone assigned either role will be a member of the profile group. If you want to create rules that use other operators, for example, <rule op=and>, write the rule by hand as described in this chapter. See Rule Tag Operations for more information.

Important Terminology's In BCC : ATG

Terminology's In BCC:

Assets:

Assets are persistent, publishable objects that are used by one or more ATG applications. ATG Content Administration supports two kinds of assets:

1.A repository asset is created and edited in the ACC or the ATG Business Control Center and is deployed as a repository item.

2.A file asset is created in the ATG Business Control Center or an external application such as Word or Excel and is deployed as a file to the target server.

If a file asset is created in an external application, you can upload the file into ATG Content Administration. Users can edit the item either through the ATG Business Control Center or by downloading the file, changing it and uploading the file again.


Project:

A project is a persistent entity that encompasses additions, changes and deletions to a set of assets. Each project moves independently through a workflow that typically includes these tasks:

1.Author or revise asset content

2.Review content changes

3.Approve the project for deployment

4.Verify deployment

Project objects are defined by the project item-descriptor in the publishing.xml repository definition file, located in:

<ATGdir>/Publishing/base/config/atg/epub


Project Workflow:

Project Workflows define and control the user tasks that make up a project and modify its state. Project workflows also define actions that are triggered by state changes, such as workspace check-in, email notification, and tagging of versions for deployment


Process:

A process is the parent object of a Project Workflow.

Process objects are defined by the process item-descriptor in the publishing.xml repository definition file.


Versioning:

Content Administration maintains versions of all assets, to ensure that the latest changes are deployed to target sites, and to coordinate multi-user access to the same asset.


Task:

A task is a step in a workflow, such as Author, Review, or Deploy


Deployment:

ATG Content Administration defines a deployment model that incorporates server clusters for development, staging, and production. You can modify the workflow that is provided with ATG Content Administration so its deployment process suits your specific requirements. For example, you can deploy to several servers at the same time; or you can define staged deployments in a staging/production workflow, which lets you review assets on a staging server before deploying them to production and checking them in.

PWS 2.0 Tag Library : ATG BCC

PWS 2.0 Tag Library 

The PWS 2.0 tag library contains a core set of tags that let you access ATG Content Administration-related Nucleus components in JSPs. By default these tags use the pws prefix, such as pws:getAsset, although you can use any prefix you like. All tags in this library support JSP 2.0 technology and are enabled to use the Expression Language (EL).

The tag library source and definition files are included in your ATG installation at the following location:

<ATGdir>/Publishing/taglib/pwsTaglib-2_0.tld

For code samples that use these tags, see:

<ATGdir>/PubPortlet/PubPortlets.ear/portlets.war/html

The PWS Tag Library includes the following tags:

pws:canFireTaskOutcome:
Determines whether a user can perform a workflow task.

pws:categorize
Organizes objects based on categories and properties.

pws:createVersionManagerURI:
Accesses the URI for the VersionManager used by a particular asset.

pws:display:
Modifies a text string by removing HTML formatting, adding text, and/or shortening the string length.

pws:getAsset:
Locates an asset using its URI.

pws:getAssignableUsers:
Assembles a list of the users who are permitted to execute a workflow task.

pws:getCurrentProject:
Accesses the current project ID.

pws:getDependentProjects:
Finds projects that have dependence on each other.

pws:getDeployedProjects:
Locates all projects deployed to a particular target site.

pws:getDeployment:
Accesses a deployment item using a deployment ID

pws:getDeployments:
Creates a list of deployment IDs for a given target site.

pws:getItemSubTypes:
Locates all subtypes for a particular asset type.

pws:getPlaceholderAsset:
Accesses an asset that is filling a placeholder

pws:getProcess:
Accesses a process using a process ID.

pws:getProcesses:
Creates a list of process IDs that have a certain status.

pws:getProject:
Accesses a project using a project ID.

pws:getProjectAssets:
Locates assets in a given project.

pws:getProjects:
Creates a list of project IDs that have a certain status.

pws:getProjectsPendingDeployment:
Creates a list of projects that have are not deployed despite the appearance of being deployment-ready.

pws:getTarget:
Accesses a target site via its ID.

pws:getTargets:
Creates a list of target IDs.

pws:getTasks:
Creates a list of tasks based on the criteria you specify.

pws:getUnsuppliedAssets:
Creates a list of unfilled placeholders for a given process.

pws:getVersionedAssetTypes:
Creates a list of asset types defined to work with the VersionManager.

pws:getWorkflowDefinitions:
Accesses all workflow definition files.

pws:getWorkflowDescriptor:
Finds the workflow descriptor used by a particular process.

View Mapping Tables : ATG BCC

View Mapping Tables

vmap_im : 
Contains information about an item.

vmap_fh :
Contains information about form handlers associated with view mapping.

vmap_mode : 
Contains information about view mapping modes.

vmap_ivm :
Contains information about item views.

vmap_im2ivm_re : 
Contains information about item mappings and associated item view mappings.l

vmap_iv : 
Contains information about an item view.

vmap_pv : 
Contains information about property views.

vmap_ivm2pvm_rel :
Contains information about item view mappings and associated property view mappings.

vmap_pvm : 
Contains information about property view mappers.

vmap_attrval : 
Contains information about an attribute value.

vmap_attrval_rel : 
Contains information about mapping items and associated attribute value items.

vmap_cattrval_rel : 
Contains information about mapping items and associated component attribute value items.

vmap_iv2ivad_rel :
Contains information about item views and associated item view attribute definitions.

vmap_ivattrdef : 
Contains information about item view attribute definitions.

vmap_pv2pvad_rel : 
Contains information about property views and associated property view attribute definitions.

vmap_pvattrdef : 
Contains information about property view attribute definitions.

Setting up Price List Functionality in ATG Consumer Commerce

ATG Consumer Commerce users do not have a price list functionality available by default. To add price list functionality, you should:

1.Add the following code to /atg/userprofiling/userProfile.xml in your localconfig:


<gsa-template>
  <header>
    <name>Commerce Related Profile Changes</name>
    <author>DCS Team</author>
     <version>$Id: userProfile.xml,v 1.1 2012/04/26 </version>
   </header>

  <item-descriptor name="user" default="true"
      sub-type-property="userType">
    <table name="dcs_user" type="auxiliary" id-column-name="user_id">
      <property category-resource="categoryCommerceContract"
         name="priceList"
         item-type="priceList"
         display-name-resource="priceList"
         column-name="price_list"
         repository="/atg/commerce/pricing/priceLists/PriceLists"/>
     </table>
   </item-descriptor>
 </gsa-template>


2.Add a price_list column to dcs_user table.

3.Configure the ItemPricingEngine to use the appropriate precalculator. There are price list-specific versions of each of the precalculators used by the ItemPricingEngine. ItemPriceListCalculator is the precalculator for list pricing. ConfigurableItemPriceListCalculator is the precalculator for configurable item pricing.

The following code example shows how the /atg/commerce/pricing/ItemPricingEngine.properties file should change to use the priceList calculators


preCalculators=\
        calculators/ItemPriceListCalculator,\
        calculators/ConfigurableItemPriceListCalculator


Note: The configurable item calculator is optional. It only needs to be used if your site supports configurable commerce items.

Important Pipeline Chains To Remember :ATG

moveToConfirmation Pipeline Chain

The moveToConfirmation pipeline chain prices the Order and validates it. The moveToConfirmation pipeline chain is executed by the handleMoveToConfirmation() method in the PaymentGroupFormHandler. The pipeline chain’s transaction mode is TX_REQUIRED.

The following list describes each processor in the pipeline chain:

1.PipelineLink Name: executeRepriceOrderChain
This processor causes the repriceOrder pipeline chain to be executed.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ExecuteRepriceOrderChain
PipelineProcessor object: atg.commerce.pricing.processor.ProcExecuteChain
Transitions: return value of 1 will execute executeValidateForCheckoutChain2 next

2.PipelineLink Name: executeValidateForCheckoutChain2
This processor causes the validateForCheckout chain to be executed.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ExecuteValidateForCheckoutChain
PipelineProcessor object: atg.commerce.pricing.processor.ProcExecuteChain
Transitions: None, this is the only link in the chain and will cause the PipelineManager to return to the caller.

moveToPurchaseInfo Pipeline Chain

The moveToPurchaseInfo pipeline chain validates the Order. The moveToPurchaseInfo pipeline chain is executed by the handleMoveToPurchaseInfo() method in the CartModifierFormHandler. The pipeline chain’s transaction mode is TX_REQUIRED.

The moveToPurchaseInfo pipeline chain contains the following processor:

PipelineLink Name: validateOrderForCheckout2
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ValidateOrderForCheckout
PipelineProcessor object: atg.commerce.pricing.processor.ProcExecuteChain
Transitions: None, this is the only link in the chain and will cause the PipelineManager to return to the caller.
Notes: This processor causes the validateForCheckout chain to be executed.

validateShippingInfo Pipeline Chain

The validateShippingInfo pipeline chain validates the ShippingGroups in the Order. The validateShippingInfo pipeline chain is executed by the validateShippingGroupsChainId() method in the ShippingGroupFormHandler. The pipeline chain’s transaction mode is TX_REQUIRED.

The validateShippingInfo pipeline chain contains the following processor:

1.PipelineLink Name: validateShippingGroupsInfo
This processor validates ShippingGroups before checking an Order out. The two main things which are checked for are that all CommerceItems in the Order are assigned to ShippingGroups and that all the required fields in all the ShippingGroups, regardless of type, are not null or empty String.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ValidateShippingGroupsForCheckout
PipelineProcessor object: atg.commerce.pricing.processor.ProcValidateShippingGroupsForCheckout
Transitions: None, this is the only link in the chain and will cause the PipelineManager to return to the caller.

sendScenarioEvent Pipeline Chain

The sendScenarioEvent pipeline chain sends a message to the Dynamo Message System. The sendScenarioEvent pipeline chain is used in various areas of ATG Commerce. The pipeline chain’s transaction mode is TX_REQUIRED.

The sendScenarioEvent pipeline chain contains the following processor:

1.PipelineLink Name: sendScenarioEvent
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/SendScenarioEvent
PipelineProcessor object: atg.commerce.pricing.processor.ProcSendScenarioEvent
Transitions: None, this is the only link in the chain and will cause the PipelineManager to return to the caller.
Notes: This processor sends scenario action events to the scenario server.

validateForCheckout Pipeline Chain : ATG

The validateForCheckout pipeline chain verifies that the Order is ready for checkout. The validateForCheckout pipeline chain is executed by the validateOrder() method in the OrderManager and the processOrder pipeline chain. The validateOrder() method adds the given Order, Locale, and OrderManager to its parameter list, which is supplied to the executing chain. The pipeline chain’s transaction mode is TX_REQUIRED.

The following list describes each processor in the pipeline chain:

1.PipelineLink Name: validateOrderForCheckout 
This processor validates that there is at least one ShippingGroup, one PaymentGroup, and one CommerceItem in the Order before checking out.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ValidateOrderForCheckout 
PipelineProcessor object: atg.commerce.order.processor.ProcValidateOrderForCheckout 
Transitions: return value of 1 will execute verifyOrderAddresses next

2.PipelineLink Name: verifyOrderAddresses 
This processor verifies the given addresses in the HardgoodShippingGroup and CreditCard objects. It does this by calling the verifyAddress() method in the AddressVerificationProcessor, which is configured in the bprocessor. Note: The AddressVerificationProcessor is not a pipeline processor.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/VerifyOrderAddresses 
PipelineProcessor object: atg.commerce.order.processor.ProcVerifyOrderAddresses 
Transitions: return value of 1 will execute validateShippingGroupsForCheckout next

3.PipelineLink Name: validateShippingGroupsForCheckout 
This processor validates ShippingGroups before checking an Order out. It checks that all CommerceItems in the Order are assigned to ShippingGroups and that all the required fields in all the ShippingGroups, regardless of type, are not null or empty String.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ValidateShippingGroupsForCheckout 
PipelineProcessor object: atg.commerce.order.processor.ProcValidateShippingGroupsForCheckout
Transitions: return value of 1 will execute creditCardModCheck next

4.PipelineLink Name: creditCardModCheck 
This processor does a mod check on credit card numbers to see if they are valid. The verifyCreditCard method of the atg.payment.creditcard.CreditCardTools class is called on each credit card number in the Order.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/CreditCardModCheck 
PipelineProcessor object: atg.commerce.order.processor.ProcCreditCardModCheck 
Transitions: return value of 1 will execute validatePaymentGroupsForCheckout next

5.PipelineLink Name: validatePaymentGroupsForCheckout 
This processor validates PaymentGroups before checking an Order out. It checks that all CommerceItems, shipping costs, and tax in the Order are assigned to PaymentGroups. It also checks that all the required fields in all the PaymentGroups, regardless of type, are not null or an empty String.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ValidatePaymentGroupsForCheckout 
PipelineProcessor object: atg.commerce.order.processor.ProcValidatePaymentGroupsForCheckout 
Transitions: return value of 1 will execute validateShippingCostsForCheckout next

6.PipelineLink Name: validateShippingCostsForCheckout 
This processor validates that all shipping costs are accounted for by a PaymentGroup. Shipping costs are accounted for if there is only one PaymentGroup and it has no Relationships, if the ShippingGroup has been assigned to a PaymentGroup, or if an order level Relationship exists in the Order that covers the entire amount of the Order.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ValidateShippingCostsForCheckout 
PipelineProcessor object: atg.commerce.order.processor.ProcValidateShippingCostsForCheckout 
Transitions: return value of 1 will execute validateOrderCostsForCheckout next.

7.PipelineLink Name: validateOrderCostsForCheckout 
This processor validates that all order costs are accounted for by a PaymentGroup. Order costs are accounted for if there is only one PaymentGroup and it has no Relationships or if order level Relationships exist in the Order that cover the entire amount of the Order.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ValidateOrderCostsForCheckout 
PipelineProcessor object: atg.commerce.order.processor.ProcValidateOrderCostsForCheckout 
Transitions: return value of 1 will execute validateHandlingInstructionsForCheckout next

8.PipelineLink Name: validateHandlingInstructionsForCheckout 
This processor validates that the total quantities in the HandlingInstructions do not exceed the amount assigned to the ShippingGroup. It does this by iterating over all the HandlingInstructions in the ShippingGroups and validating that the sum of the quantities in the HandlingInstructions do not exceed that which is assigned to the ShippingGroup. It will also catch errors if HandlingInstructions contain errors such as invalid ShippingGroup and CommerceItem IDs or CommerceItems that are not assigned to the ShippingGroup that contains the HandlingInstruction.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ValidateHandlingInstructionsForCheckout
PipelineProcessor object: atg.commerce.order.processor.ProcValidateHandlingInstructionsForCheckout
Transitions: return value of 1 will execute validateCurrencyCodes next

9.PipelineLink Name: validateCurrencyCodes 
Verifies that all the PriceInfo objects in the Order have been priced using the same currency code. The currency code in the OrderPriceInfo object is the one that must be matched. The code checks the TaxPriceInfo object’s currency code in the Order and all the ShippingPriceInfo and ItemPriceInfo currency codes in all the ShippingGroups and CommerceItems, respectively.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ValidateCurrencyCodes 
PipelineProcessor object: atg.commerce.order.processor.ProcValidateCurrencyCodes 
Transitions: Return value of 1 executes checkForDiscontinuedProducts next.

10.PipelineLink Name: checkForDiscontinuedProducts 
Ensures that the order does not contain any products that are no longer available
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/CheckForDiscontinuedProducts 
PipelineProcessor object: atg.commerce.order.processor.ProcCheckForDiscontinuedProducts 
Transitions: None, this is the last link in the chain and will cause the PipelineManager to return to the caller.

processOrder Pipeline Chain : ATG

The processOrder pipeline chain submits the given Order for checkout. The processOrder pipeline chain is executed by the processOrder() method in the OrderManager. The processOrder() method adds the given Order, Profile, Request, Locale, and OrderManager to its parameter list, which is supplied to the executing chain. The pipeline chain’s transaction mode is TX_REQUIRED.

The following list describes each processor in the pipeline chain:

1.PipelineLink Name: executeValidateForCheckoutChain 
This processor causes the validateForCheckout chain to be executed. If the execution of this chain causes any errors, then execution will be returned to the caller.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ExecuteValidateForCheckoutChain 
PipelineProcessor object: atg.commerce.order.processor.ProcExecuteChain 
Transitions: In ATG Consumer Commerce, return value of 1 executes checkForExpiredPromotions next. In ATG Business Commerce, return value of 1 executes executeApproveOrderChain next.

2.PipelineLink Name: executeValidateForCheckoutChain 
This processor causes the validateForCheckout chain to be executed. If the execution of this chain causes any errors, then execution will be returned to the caller.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/ExecuteValidateForCheckoutChain 
PipelineProcessor object: atg.commerce.order.processor.ProcExecuteChain 
Transitions: In ATG Consumer Commerce, return value of 1 executes checkForExpiredPromotions next. In ATG Business Commerce, return value of 1 executes executeApproveOrderChain next.

3.(ATG Business Commerce only)
PipelineLink Name: stopChainIfOrderRequiresApproval 
This processor checks whether the order has been determined to require approval. Specifically, it checks whether the state of the order is PENDING_APPROVAL. If it isn’t, the order moves to the next processor in processOrder. If it is, execution of the processOrder chain stops.
Transactional mode: TX_MANDATORY
Nucleus component: 
/atg/commerce/approval/processor/StopChainIfOrderRequiresApproval 
PipelineProcessor object: 
atg.commerce.order.processor.ProcCheckOrderState 
Transitions: Return value of 1 executes executeValidatePostApprovalChain next. Return value of 2 executes executeValidateNoApprovalChain.

4.(ATG Business Commerce only)
Pipeline Link Name: executeValidatePostApprovalChain 
If the order requires approval and has been approved, this processor revalidates order information in case the approver changed anything.
Transactional mode: TX_MANDATORY
Nucleus component: 
atg/commerce/order/processor/ExecuteValidatePostApprovalChain 
PipelineProcessor object: 
atg.commerce.order.processor.ProcExecuteChain 
Transitions: Return value of 1 executes checkForExpiredPromotions next.

5.(ATG Business Commerce only)
Pipeline Link Name: executeValidateNoApprovalChain 
If the order does not require approval, finish validation.
Transactional mode: TX_MANDATORY
Nucleus component: 
atg/commerce/order/processor/ExecuteValidateNoApprovalChain 
PipelineProcessor object: 
atg.commerce.order.processor.ProcExecuteChain 
Transitions: Return value of 1 executes checkForExpiredPromotions.

6.PipelineLink Name: checkForExpiredPromotions 
This processor walks through all the promotions that are being applied to the Order and verifies that none of them have expired.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/CheckForExpiredPromotions 
PipelineProcessor object: atg.commerce.order.processor.ProcCheckForExpiredPromotions 
Transitions: return value of 1 will execute removeEmptyShippingGroups next

7.PipelineLink Name: removeEmptyShippingGroups 
This processor checks to see if there are any empty ShippingGroups in the Order. It removes any empty groups it finds. An empty ShippingGroup contains no Relationships. If the Order contains only one ShippingGroup then it will not be removed if it is empty.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/RemoveEmptyShippingGroups 
PipelineProcessor object: atg.commerce.order.processor.ProcRemoveEmptyShippingGroups 
Transitions: return value of 1 will execute removeEmptyPaymentGroups next

8.PipelineLink Name: removeEmptyPaymentGroups 
This processor checks to see if there are any empty PaymentGroups in the Order. If so then it will remove them. An empty PaymentGroup contains no Relationships. If the Order contains only one PaymentGroup then it will not be removed if it is empty.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/RemoveEmptyPaymentGroups 
PipelineProcessor object: atg.commerce.order.processor.ProcRemoveEmptyPaymentGroups 
Transitions: return value of 1 will execute createImplicitRelationships next

9.PipelineLink Name: createImplicitRelationships 
This processor adds Relationships to the Order if there is only one ShippingGroup or one PaymentGroup. If either one of these or both have no Relationships, then relationships will automatically be created. For the ShippingGroup, Relationships will be created between it and each CommerceItem. For the PaymentGroup, a Relationship will be created between itself and the Order with type OrderAmountRemaining.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/CreateImplicitRelationships 
PipelineProcessor object: atg.commerce.order.processor.ProcCreateImplicitRelationships 
Transitions: return value of 1 will execute setPaymentGroupAmount next

10.PipelineLink Name: setPaymentGroupAmount 
This processor sets the amount property of each PaymentGroup in the Order based on the Relationships in each PaymentGroup. This amount is the amount that will ultimately be debited by the PaymentManager.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/SetPaymentGroupAmount 
PipelineProcessor object: atg.commerce.order.processor.ProcSetPaymentGroupAmount 
Transitions: return value of 1 will execute moveUsedPromotions next

11.PipelineLink Name: moveUsedPromotions 
This processor updates the promotion use information in the Profile repository for the user.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/MoveUsedPromotions 
PipelineProcessor object: atg.commerce.order.processor.ProcMoveUsedPromotions 
Transitions: return value of 1 will execute authorizePayment next

12.PipelineLink Name: authorizePayment 
This processor authorizes all the payment information in the PaymentGroups. It essentially calls the authorize() method in the PaymentManager for each PaymentGroup.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/AuthorizePayment 
PipelineProcessor object: atg.commerce.order.processor.ProcAuthorizePayment 
Transitions: return value of 1 will execute updateGiftRepository next

13.PipelineLink Name: updateGiftRepository 
This processor updates the gift list repository information for the user.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/UpdateGiftRepository 
PipelineProcessor object: atg.commerce.order.processor.ProcUpdateGiftRepository 
Transitions: return value of 1 will execute sendGiftPurchasedMessage next

14.PipelineLink Name: sendGiftPurchasedMessage 
This processor sends a gift purchased message to the messaging system.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/SendGiftPurchasedMessage 
PipelineProcessor object: atg.commerce.order.processor.ProcSendGiftPurchasedMessage 
Transitions: return value of 1 will execute addOrderToRepository next

15.PipelineLink Name: addOrderToRepository 
This processor saves the Order to the Order Repository and if the user is not a registered user, adds the Order to the repository and then saves it.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/AddOrderToRepository 
PipelineProcessor object: atg.commerce.order.processor.ProcAddOrderToRepository 
Transitions: return value of 1 will execute sendPromotionUsedMessage next

16.PipelineLink Name: sendPromotionUsedMessage 
This processor sends a message to the Scenario Server for each promotion that was used in the Order signifying that the given promotion was used by the user.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/SendPromotionUsedMessage 
PipelineProcessor object: atg.commerce.order.processor.ProcSendPromotionUsedMessage 
Transitions: return value of 1 will execute sendFulfillmentMessage next

17.PipelineLink Name: sendFulfillmentMessage 
This processor sends a message to the fulfillment engine signifying that it should begin processing the Order.
Transactional mode: TX_MANDATORY
Nucleus component: /atg/commerce/order/processor/SendFulfillmentMessage 
PipelineProcessor object: atg.commerce.order.processor.ProcSendFulfillmentMessage 
Transitions: None, this is the last link in the chain and will cause the PipelineManager to return to the caller.

Specifying Components as Properties : ATG

The preceding examples demonstrated how Nucleus can create and initialize components from properties files. While this is itself a powerful function, the true power of Nucleus is its ability to allow components to point to each other through configuration files.

The easiest way to get components to point to each other is through properties. For example, say that a Weather component is defined in Nucleus, and the Person component needs a pointer to that Weather.

The Weather class might look like this:

public class Weather {
String currentWeather;

  public Weather () {
    System.out.println ("constructing Weather");
  }
  public String getCurrentWeather () {
    return currentWeather;
  }
  public void setCurrentWeather (String currentWeather) {
    System.out.println ("setting currentWeather to " + currentWeather);
    this.currentWeather = currentWeather;
  }
}

For this example, we need an instance of Weather in Nucleus, called /services/Weather. This means that you should compile the Weather Java class and create a Weather class component with a Weather.properties file in the same directory as Person.properties. Note that, as with any Nucleus component, you can create /services/Weather either with the ATG Control Center’s Generic Component Wizard, or by writing a properties file like this:

$class=Weather
currentWeather=sunny

Now modify the Person component to contain a property that points to the Weather:

public class Person {
  String name;
  int age;
  Weather weather;

  public Person () {
    System.out.println ("constructing Person");
  }
  public String getName () { return name; }
  public void setName (String name) {
    System.out.println ("setting name to " + name);
    this.name = name;
  }
  public int getAge () { return age; }
  public void setAge (int age) {
    System.out.println ("setting age to " + age);
    this.age = age;
  }
  public Weather getWeather () { return weather; }
  public void setWeather (Weather weather) {
    System.out.println ("setting weather to " + weather.getCurrentWeather ());
    this.weather = weather;
  }
}

Finally, the Person component must be modified so that it has a weather property that points to the weather component:

$class=Person
name=Stephen
age=20
weather=Weather

If you have included the Person component as an initial service (as described in the Starting a Nucleus Component section in this chapter), then, when you start your application, the Person component will be created and initialized. Its name and age properties will be set from the values found in the properties file. But to set the weather property, Nucleus must resolve the name Weather. In doing so, Nucleus ends up creating the Weather component and initializing that component before assigning it to the Person property. The output should look something like this:

constructing Person
setting age to 20
constructing Weather
setting currentWeather to sunny
setting weather to sunny
setting name to Stephen

The first two lines of the output show that Nucleus has created the /services/Person component and has set the age property. Then Nucleus attempts to set the weather property. In doing so, it searches for the component named Weather. This is a relative name, and so it is resolved relative to the current context /services, resulting in /services/Weather.

Nucleus searches its existing components and, finding that there is no /services/Weather, it attempts to create one from the configuration file found in services/Weather.properties. This causes Nucleus to construct an instance of the Weather class and initialize its currentWeather property, thereby resulting in the third and fourth lines of output.

Now that a /services/Weather component has been created and initialized, Nucleus can go on to initialize the rest of the Person component, by setting its weather and name properties. This results in the last two lines of output.

Nucleus does not put a “nesting limit” on the number of components that may refer to each other through properties. For example, component 1 may refer to component 2, may refer to component 3, etc. Nucleus also allows circular references. For example, component 1 may have a property that points to component 2, which may have a property that points back to component 1. In fact, component 1 may have a property that points back to itself. Nucleus handles these circular cases without spiraling into infinite loops.

Application errors can sometimes occur, however, if you reference a property of a component before that component is completely configured. To diagnose this type of error, set the loggingInfo property of the / Nucleus service to true, and the ATG platform will print information messages for this situation.

Arrays of components can also be specified in the same way that other array values are specified: as a comma-separated list. For example, the Person component may have a property called cityWeathers that contains an array of Weather components:

public Weather [] getCityWeathers ();
public void setCityWeathers (Weather [] cityWeathers);

This property might be initialized in the configuration file like this:

cityWeathers=\
        /services/weather/cities/atlanta,\
        /services/weather/cities/boston,\
        /services/weather/cities/tampa,\
        /services/weather/cities/phoenix

Nucleus handles this by finding each of the components in the list, arranging the found components into a 4-element array, then assigning that array to the cityWeathers property of the Person component.