Posts

Showing posts from January, 2012

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. Solution: 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 time.it 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 http://atgtipsandtweaks.blogspot.in/2012/01/atg-catalog-maintenance-service.html

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 -> Product,product.ancestorCategories, product.parentCategoriesForCatalog, product.computedCatalogs,Category,Category.ancestorCategories, Category.parentCatalog,Category.computedCatalogs sku,sku.computedCatalogs Also see  How to customis

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. Solution CA Side CMS 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(){   if(isInvalidateCaches()){         super.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 eve

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. Work around -> ATG Manul Cache Invalidation

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 versions. you 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. Brief 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

VersionManagerService Component versionedRepositories property

/ a tg/epub/Version/VersionManagerService this is the component where you can list all your Versioned Repositories.  It has a property defined for this ' versionedRepositories '. eg: versionedRepositories+=\ 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. eg: 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 /atg/commerce/catalog/ProductCatalog_staging/ 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/                                 ExecuteValidateForCheckoutChain"/>             <transition returnvalue="1" link="ApproveOrder"/>          </pipelinelink>        <pipelinelink name="ApproveOrder"  transaction="TX_MANDATORY">             <processor             jndi="/atg/commerce/order/processor/ApproveOrder"/>             <transition returnvalue="1" link="approverEmailIds"/>        </pipelinelink> Adding the processor Approve Order to the Pipeline Registry. </pipeline-registry-configu

Basic things in Customizing Pipeline

Pipeline definition files define pipeline chains. 1.You can create a processor by implementing the interface    atg.service.pipeline.PipelineProcessor,    implement the runprocess() method,returning a status code(int). eg:   public class ProcApproveOrder implements PipelineProcessor {           public int runProcess(Object pParam, PipelineResult                                                      pResult)                      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 (    AprroveOrder.properties)    eg:    $class=x.x.x.x..ProcApproveOrder    $scope=global 3. Modify the --- pipeline.xml file.    Also see the ATG PipelineRegistry