A key aspect of multisite support is the sharing of resources such as shopping carts and gift lists. From a coding point of view, however, the issue is not so much sharing as restricting sharing. By default, all resources are shared across sites. You code your application in a way that limits the sharing of resources.

Another way to think of this is as making resources site-aware. A site-aware resource tracks the site it is being used on, and behaves differently depending on the site.

For example, suppose you have three sites, A, B, and C. By default, all three sites share a shopping cart. To make the shopping cart site-aware, you create a shareable type component and associate it with the shopping cart. (Actually, this has already been done for you, but you can ignore that for the sake of this example.) Now the default behavior is for none of the sites to share a cart; each site has a separate instance of the cart.

Now that you have made the shopping cart site-aware, you can enable restricted cart sharing by creating sharing groups. For example, suppose you create a sharing group consisting of sites A and B and the shopping cart. Sites A and B now share one instance of the shopping cart, while site C has a separate cart instance.

Note that not all resources can be site-aware. For example, user profiles are not site-aware. User profiles (and therefore logins) are always shared across all sites in the application.

ATG provide a number of mechanisms for making resources site-aware, which are discussed below.

Site-Specific Session-Scoped Components (Shareable Types)

As discussed above, shareable types designate resources that are shared within site groups. If the shared resource is a Nucleus component, the application may need multiple instances of the same component in a single session. In the example above, the application needs two instances of the shopping cart in each session, one shared by site A and B, and the other used only by site C. That way, a site customer moving from site A to site B will see the same shopping cart in both places, but when moving to site C, the customer will see a different cart.

To simplify site development, switching between instances of shared Nucleus components is designed to happen automatically. Underlying system services are responsible for tracking the current site and using the correct instance of the shopping cart. In your own code, you refer to the cart as if it were a single entity.

Site-Specific Property Value Overrides

Another mechanism for making components site-aware enables you to override property values on a per site basis. For example, suppose you have multiple Commerce sites that each charge a different fixed price for shipping. To manage this, you could use a single atg.commerce.pricing.FixedPriceShippingCalculator component to determine the shipping cost, and override the component’s amount property (which sets the shipping cost) for each site.

Site-specific overrides are handled through the atg.service.subclasser.SiteSourcedPropertyGetterSubClasser class. The ATG platform includes a component of this class, /atg/multisite/SiteSourcedPropertyGetterSubClasser. SiteSourcedPropertyGetterSubClasser overrides the value of a specific component property (such as FixedPriceShippingCalculator.amount) by setting it to the value of a property of the siteConfiguration repository item. This allows the component property to take on a different value for each site.

To override the value of the amount property of your FixedPriceShippingCalculator component:

Site-Specific Personalization

Targeters, user segments, and content groups all support site-specific rules. For example, suppose you have a user segment that by default includes all customers whose age is between 30 and 40 years old. You could add a site-specific override rule specifying that on site A the segment includes all customers whose age is between 30 and 50. As the result of this override, a customer who is 43 years old would be included in this segment when browsing site A, but not when browsing any other site.

In addition to site-specific rules, targeters and content groups also make it possible to show on one site content that is associated with other sites. For example, when customers browse products on site A, a targeter might display a set of related products from site B.

Scenario conditions and actions are also site-aware. For example, an action that fills a slot with items from a targeter can specify a site, causing the targeter to execute a site-specific rule.

Site-Specific Repository Data (Site Membership)

The ATG platform also includes a mechanism for making repository items site-aware. This is done by using a context membership property to designate which sites the item applies to. This mechanism is used in the catalog repository. The catalog, category, product, and SKU item types all have a siteIds property that holds an array of the site IDs of the sites that the item is part of. So, for example, if a product is included on site A and C, but not site B, the value of this property would be the site IDs of sites A and C.

Context membership is used by internal querying mechanisms of the repository, enabling it to issue queries such as “return all products that are included in site A.” Note that other repositories may have siteIds properties to track which sites an item is associated with, but these are not context membership properties unless explicitly configured as such in the repository definition.