ACC Product Duplication Issues For Small Image and Large Image

I have two products with diferent models:
 BlackBerry A
 BlackBerry B

From BlackBerry A, I have duplicated the product BlackBerry B,Now
i need to change the image for  this  product,as this is of different model,the problem occurred when I
modified “Small image” and “Large image”of
BlackBerry B,these modifications are also reflected in BlackBerry A.
But I am able to  modify “Thumbnail image,Description” and few
other property values on BlackBerry B without any issues.


Please verify the Media item id is same in your duplicated item,
“Small image” and “Large image” ID in “Images & Media”
sections are the same.So in order to insert any modification,we
should re-insert “Small image”and “Large image” for each
duplicated product.

Customize OOTB CMS to make Asset Deployments Faster

Once the CMS project is created,deploy the project to staging and production. This is a one time activity(adding the assets to the project and deploying) and it will take some had taken a full day to finish this activity for us.

Secondly,once the bad data is removed we can start modify/create/delete
data through BCC and go for deployment.We can configure the CA side CMS to be  incremental.It will trigger once you changed a project from 'author' state to
'Ready for staging approval'.

For implementing this way you can customize the editCommerceAssets workflow to inject the custom action.You can add a logic in a way to switch b/w 'CA side incremental CMS' or 'ATG OOTB CMS'

See Also

Catalog Maintenance Service Pre Requisites

There are mainly two activities to achieve this goal

Firstly you need to remove all the bad data from your custom catalog. For this you can create a custom class,add a service method and make use of the manage Commerce assets workflow.

These are the prerequisites

Each category shall belong to one catalog,unassigned categories to catalog 
will not be allowed,there should not be any open project in pending verification state of Staging/Production target.There should not be any Active Projects in BCC,the status of all the projects should be complete.All the orphan categories should be deleted.

The service method will now create a project(CMS Project),This is 
to link all the below properties correctly.

Please find the properties here ->



Also see How to customise out of the box CMS 

Catalog Maintenance Service Performance tips

We know that the ATG OOTB CMS runs on both agent-side as well as target-side after every deployment.Say if the user modified description of a product,the whole service is executed twice.It will consume a lot of time if your catalog has a lot of customization.



This will improve the performance.

This will trigger once you change the project from author state
to ready for staging approval

This will executes against a workspace(project)or in our case it will act only on that specific repository item(eg:change Product description).

Find the Pre Requisites

Cache Invalidation Sample Code Smart way to Invalidate Cache

Create a new Class 'MyRepository' extending ATG’s GSARepository.

Create an Instance variable to decide whether do we need to invalidate the Cache or Not ? Initialize it with true.

private boolean mInvalidateCaches = true;

Override invalidateCaches() method of ‘GSARepository’, inside this method call the super class method  super.invalidateCaches(),only
if ‘invalidateCaches’ Variable is set to true,and this is 

variable is set from the Versioned Repository component.

Configure Repositories, which are taking part in Versioning
with invalidateCaches=false. This will prevent ATG to invalidate Cache automatically when assets of that repositories are getting deployed.

public void invalidateCaches(){ 

Because we have Overridden invalidateCaches() method in MyRepository class, it will invalidate Cache only if invalidateCaches=true, ATG will not be invalidating the Cache automatically after every Deployment.

Now if you want to see the deployed changes on target, we have to manually invoke invalidateCaches() method using Admin UI, which can be done during off peak hours, so that site performance will not be compromised.

Modify your Versioned Repositories like below.

eg: /atg/commerce/catalog/


Merchandising Cache Invalidation Performance Improvement tips

How to Invalidate Cache in the off Peak Hours

Generally in BCC prior to ATG 10, if we deploy a new asset,the entire cache is getting invalidated.This entire cache invalidation process consumes a lot of time.
This happens even though our change is minimal for Eg:modifying description of a Product or Sku.

Moreover this puts an additional overhead on Database Servers if all the instances running in clusters tries to refresh the cache by pulling the fresh data from the Database. The site performance can impact badly if we are doing such deployments on the
normal business hours.

Manual Cache Invalidation while Deploying Assets

Disable the Automatic Cache Invalidation and make the Cache Invalidation Process Manual

As you know currently after every deployment the cache is getting invalidated automatically,so the first step towards this is to disable the  automatic cache invalidation after every deployment.

By doing some customization you can achieve this,so that you can progress your work of deploying assets during regular business hours and not to Invalidate cache each time  the Deployment happens.

But to see the deployed changes on the target site we have to manually perform Cache Invalidation, which can be done during off peak hours, so that site performance is not compromised.

Also see Cache Invalidation Sample Code

Selective/Smart Cache Invalidation

Enable Selective/Smart Cache Invalidation

In ATG 10 we have a feature newly added to handle the automatic cache invalidation.This feature tracks which assets are deployed and invalidate cache only for those assets.
There will be a patch provided by ATG to implement this feature in previous may need to contact ATG for further details.
Please verify how to configure selective cache invalidation on the below link.

Selective cache invalidation will works only on item descriptors with cache mode is set as simple cache.

Even if Selective cache invalidation is enabled,the method invalidateCaches() clears all caches from the target repository.


On each Production Repository pointing to atg.adapter.gsa.GSARepository,there is a property 'selectiveCacheInvalidationEnabled' which needs to set to true,default is false.To achieve this,you need to add an entry to the Repository component in your Application,if not layer the Repository component in your module config path or inside localconfig or liveconfig layer.


1. This will drastically improves site performance as it will not
   invalidate the repository caches for the assets which is not
   being touched or changed.
2. Deployments will be much more faster
3. This results in better performance for companies, fast loading of
   pages,and a reduction of load on the database due to reloading
   the cache

VersionManagerService Component versionedRepositories property


this is the component where you can list all your Versioned Repositories. It has a property defined for this


CustomProductCatalog=/atg/commerce/catalog/ProductCatalog \

You can find the Repository name from the property 'repositoryName'.This property will be present in all versioned repository components.While adding you need to specify the full nucleus path of that component.


Go to ProductCatalog Component and look for the
repositoryName and path.

This property 'repositoryName' will not be present in UnVersioned Repositories.

CA Deployment Debugging Components tips

Assuming you are a NoVice,setting up your Target sites and Agent  for Deployment will not be an easy task,you might be encountering different issues during this process,it would  really going to help,if you turn on debugging during deployment.

This can be done by setting the property loggingDebug= true
in the following components.

/atg/epub/DeploymentServer on CA Server
/atg/epub/DeploymentAgent on Target site(Staging or 
Production,depends upon your configuration).
/atg/deployment/DeploymentManager(Enable loggingthreadDebug too)
/atg/commerce/catalog/ProductCatalog_production or

Also check the switching configurations.

You can now look into your Weblogic Console or the log files
to Debug errors.

Customizing the Pipeline definition files - XML Modifications

Adding the ApproveOrder pipelinelink to the existing pipeine chain.

<pipelinechain name="executeValidateForCheckoutChain ">     
     <pipelinelink name="ExecuteValidateForCheckoutChain"
               transaction="TX_MANDATORY" xml-combine="replace">
          <processor jndi="/atg/commerce/order/processor/

            <transition returnvalue="1" link="ApproveOrder"/>   

<pipelinelink name="ApproveOrder" transaction="TX_MANDATORY">

            <transition returnvalue="1" link="approverEmailIds"/>

Adding the processor Approve Order to the Pipeline Registry.

  <processor-registry xml-combine="append-without-matching">

      <display-name>give a name ....</display-name>
      <description>give a description</description>


See the Java and Property files changes for a Component

Basic things in Customizing Pipeline

Pipeline definition files define pipeline chains.

1.You can create a processor by implementing the interface
   implement the runprocess() method,returning a status code(int).

  public class ProcApproveOrder implements PipelineProcessor {
          public int runProcess(Object pParam, PipelineResult
                     throws Exception {
              return CONTINUE_CHAIN_EXECUTION;
   After adding the required functionality,return the status
   code,anything other than the return value  0,will tell the
   PipeLineManager to execute the next processor in the chain.

2. Create a nucleus component for your Processor (

3. Modify the ---pipeline.xml file.

   Also see the ATG PipelineRegistry
Related Posts Plugin for WordPress, Blogger...