As you may have read in the Commerce Server 2007 Catalog Manager Documentation, there are some elements of the Catalog that cannot be overridden in Virtual Catalogs. One of these elements that has reared it's ugly head due to a specific requirement is product relationships.
In the database, Viurtual Catalogs are actually nothing more than a view. And with the way that these are set up, product relationships as well as other catalog elements such as category assignements cannot be overridden in a VIrtual Catalog.
Depending on the specifics of your solution, there are a few ways to get around this limitation:
- Do not use Virtual Catalogs - Make all of you product catalogs Base Catalogs.
*This will not be viable in many if not most situations because if you are using Virtual Catalogs, chances are that you need the convenience of being able to refresh them from the base. This workaround would not enable you to use this feature.
- Create a copy of the product - In the base catalog, create a copy of the product that is to be excluded from the relationship in the base. Set all of the categorizations and relationships that you do want it to have in the Virtual Catalog. Then, delete the exclude the product from the Virtual Catalog and inherit/set an inclusion rule for the new one.
*The problem with this option is that you have to change the ProductId of the copied product because the ProductId has to be unique. Changing the productId presents isues if you are passing this Product Id on to any other third party systems, such as a fullfillment center, unless extra logic is added to strip off a standard appendage to the ProductID when you are making a copy for this purpoise.
- **Use the description field or name of the relationship - In the relationship name or description field, you can store a magic value like 'exclude' or 'inactive', that can, in turn, be checked at runtime to see if the relationship is truly valid for this Virtual Catalog. The only drawback to this option is that you will be using a magic value which breaks most best practice development standards but has no *real* side effects here.
*In my opinion, this option is the least evil of all of the options.