Key Concepts
Use a site path as the method to associate commerce sites to model sites
Enable application logic for the different types of site path
Store site path data in the application database
Include selection criteria based on site path in the database queries
Create a site path service to reduce the knowledge of site-path structure within commerce applications
The concepts of model sites and authorization domains enable the sharing of data among sites. As described in the previous chapter, data assets that are placed in a model site can be made available to many commerce sites. By associating a commerce site with a model site, we make shared data available in the commerce site.
In a multisite commerce platform, you have many commerce sites, each associated with a number of model sites. The software applications of the platform must be aware of the site associations, to present both the site-specific and the shared data to customers and to administrators.
In this chapter, we further explore these site associations and discuss how they can be efficiently implemented in a commerce platform.
Because the associations between a site and the model sites are the key to data sharing among sites, they deserve to have a special name. We will call these site associations a site path. The analogy is based on the command PATH in the UNIX® shell, where the PATH environment variable specifies the directories in which the operating system searches for scripts and executables. Similarly, within the shared commerce platform, the site path indicates the list of sites where the commerce platform’s business logic should look for data assets.
For a commerce site to make use of shared data that is made available by model sites, a site path must be specified for the commerce site. The site path consists of a list of associations between a commerce site and the corresponding model site. Each association must be qualified to indicate what sort of data assets can be found in the indicated site. Thus, you can have a site path association for product data, up-sells and cross-sells, inventory, marketing data, presentation data, and so on.
The business logic of the commerce platform must be programmed to look up the site path for the commerce site and to treat the data in the specified model sites as if it were available to the commerce site. We call this the site path enablement of the commerce platform.
Each commerce application that allows the sharing of data between sites must be enabled for the site path for the shared data assets.
For example, let’s say the platform is put together from the following applications:
• Commerce application—Responsible for catalog presentation and associated marketing campaigns
• Order capture application—Responsible for management of the shopping carts, submission of orders, and presenting order status
• Payment application—Responsible for capturing and storing payment information and processing payment authorizations
Let’s also say that the company has requirements to share catalog, presentation, and marketing information among sites. In this case, the business logic of the commerce application must be enabled to look at the site path for these data types. For example, when looking up the presentation template information, the commerce application needs to look through the appropriate files, both for the commerce site and the presentation model site.
Similarly, every time that the application needs to look up the catalog or marketing information, it must find the appropriate products or marketing content both in the commerce site and in the associated catalog and presentation model sites.
The order capture application also needs to be enabled for the presentation site path. Generally, the checkout flow, and the appearance of orders and shopping carts, can differ between sites: For example, checkout flow would be different between B2B and B2C sites. Hence, the order capture application must access the presentation template in the appropriate model sites.
On the other hand, the payment application might not need to be enabled for the site path, neither for the catalog nor for the presentation. This would be true provided that the payment application does not need to be aware of the site where the order was placed. If the payment application does not present the product or marketing information and the presentation template for this application is identical for all sites, the business logic can be left completely ignorant of the site path.
One simple way to specify the site path is to express it as a table. We illustrate the specification based on the example in Figure 16.1.
In this diagram, there is one catalog model site, two presentation model sites, and eight commerce sites. Each site, including the model sites and commerce sites, is assigned a label that is a unique identifier of that site. Table 16.1 shows the specification of the site paths for this environment.
This spreadsheet shows the site paths for all the commerce sites created in the platform. Each commerce site is represented by a column in the table. Each row corresponds to the site path for a particular data asset type.
This method of site path specification indicates the model site for each type of data asset that needs to be shared. This spreadsheet format makes it easy for IT personnel to see at a glance all the associations that have been created between sites.
As we see, the site path associations do tend to create a fair amount of data when many commerce sites are involved. In reality, however, a commerce site needs only a few associations because usually many types of data are stored in a single model site.
You can optimize the specification of the site path. Table 16.2 contains the same site path information based on the example of Figure 16.1, but now it is simplified.
This time there are only two types of the site path, corresponding to the two types of model sites that the commerce platform has. For each commerce site, the table simply indicates the model sites that it needs.
The site path specifications in Table 16.2 are updated every time a new commerce site is created. In this spreadsheet, a new column is added to the spreadsheet, which is actually a small amount of data because there are only two rows to worry about!
For this simplified specification to make sense, you need to also define the types of shared data assets that each model site can contain. Table 16.3 contains this definition of the model site types.
The content of Table 16.3 is created by IT personnel when the commerce platform is initially created. There is a single definition that applies to the entire platform, and it generally does not need to be changed throughout the lifetime of the platform.
In the previous chapter, we suggested that in some cases a commerce site can to be associated with multiple model sites. The idea was to allow different portions of shared data to be managed by independent teams of administrators, while aggregating all the shared data for use in a single commerce site. An example of this was given in Figure 15.13 of Chapter 15, “Sharing Data.”
Now let’s see how the site path would be specified in this case. First, we elaborate on the example by creating additional commerce sites for different regions. In Figure 16.2, we have a more complex arrangement in which many commerce sites need to be created, each of which presents a combined catalog of the two divisions of the company.
To illustrate, we also created two presentation model sites, one for North America and one for Europe. In this environment, each commerce site is associated with one presentation model site and two catalog model sites. Hence, the catalog site path has two elements, whereas the presentation site path has a single element. Table 16.4 shows the specification of the site paths for this arrangement.
Note
The sections that follow are intended for the technically minded reader who likes SQL. If you are interested in how sites and site paths could be modeled in a relational database and want to see examples of how an application can be enabled for site path, then please read on. However, if database tables, SQL queries, and data caches are not of interest to you, then do not hesitate to skip this section entirely and go on to the next chapter.
The first problem to enable a component for a site path is to instrument all database queries to include data in the site path in the search request. This means that whenever product or category information is looked up, the query must include not only the site that is accessed by the customer or the administrator, but the query must also include all the model sites included in the site path.
To illustrate this, we start with an arrangement of the sites shown in Figure 16.3.
In this example, all sites share the same catalog that is maintained in the catalog model site. This shared catalog has two categories: Writing Instruments and Paper. In addition to the shared categories and products, the Canadian site has another product in the Writing Instruments category, namely a Laser Pen, which is available only in Canada. Similarly, there is a Green Graph Paper Pad that is available only in the UK.
Now consider a database table design for a commerce platform that contains such data as the sites, the catalog products and categories, and the necessary site path associations. One possible such design for a relational database is shown in Tables 16.5 through 16.9. These tables show both the required columns and sample data based on the example in Figure 16.3.
Obviously, this example is simplified: It assumes that there is only a single master catalog that the company has within the commerce platform, and it does not show how a category would contain other child categories. Even for the tables shown, there is a lot of other data that would be required in real life, such as detailed language-specific descriptions, additional product attributes, product and category images, and so on, and presumably it would be stored in additional tables or columns. However, in spite of the simplifications, this example should be sufficient to illustrate a data design enabled for data sharing among sites.
In the sample data design, we show the columns of the following database tables: SITE, SITEPATH, PRODUCT, CATEGORY, and PRODCAT. The SITE table contains the definitions of the sites that have been created on the platform; that is, each row in this table corresponds to either a commerce site or a model site. The SITEPATH table contains the site paths of all the commerce sites; in other words, it contains the associations between commerce and model sites. The PRODUCT and CATEGORY tables contain the definitions of the products and categories in the company’s catalog. Finally, the PRODCAT table associates the products with the categories; in other words, it indicates which products are contained in each category. Tables 16.5 through 16.9 describe these database tables respectively.
From the data design point of view, the enablement of the site path is achieved by the SITEPATH table, which contains the relationship of commerce sites to their model sites. In addition, each business object, such as a product or a category, is associated with the site that owns it, whether it is a model site or a commerce site.
We notice that from the data object point of view, both commerce sites and model sites are treated identically. Business objects, such as products and categories, are not aware of the type of site they are created in, but simply have a reference to their owning site, whatever it might be. As we described previously, this makes the administration of the business data assets much simpler because the same tools can be used to manage shared assets in model sites and site-specific assets in commerce sites.
In our example, most products are defined in site 1, which is the catalog model site, and are available to all sites. However, product 1000 is defined in site 11, which is the Canadian site, and this product is available only in Canada. Product 1001 is in site 12, and is only available in the UK.
One characteristic of this design is that the associations between products and categories in the “PRODCAT” table are not qualified by the site_id. This qualification is unnecessary, because inherently if the product applies only to one site, so does its association to the parent category. For example, because Product 1001 exists only within site 12, its association to category 1 is valid only within that site. The data selection criteria within the business logic can look only at those product-category associations that are relevant to their site. It is not necessary to have an extra site_id column in the PRODCAT table.
Let’s imagine that the application needs to retrieve all products in a given category. If we were to ignore the issue of the site path and model sites, the SQL statement would simply need to join the PRODUCT and PRODCAT tables, as follows:
SELECT name, description FROM PRODUCT, PRODCAT WHERE
PRODCAT.category_id=:CATEGORYID AND
PRODUCT.id=PRODCAT.product_id
(The :CATEGORYID variable here would hold the id of the category searched. For “Writing Instruments” it is 1, and for “Paper” it is 2.)
However, in a multisite platform, we do not want to retrieve all products that were ever created in the category. Instead, we want to retrieve all products that are available in that category in the site that is accessed by the customer or by the administrator. Let’s assume that the platform makes the current site id available through the :SITEID variable. The following enhanced SQL statement would retrieve all products in the specified category, which are available in the current site:
SELECT name, description FROM PRODUCT, PRODCAT WHERE
PRODCAT.category_id=:CATEGORYID AND
PRODUCT.id=PRODCAT.product_id AND (PRODUCT.site_id=:SITEID OR
PRODUCT.site_id IN (SELECT modelsite_id FROM SITEPATH WHERE
commercesite_id=:SITEID AND pathtype="catalog"))
This statement adds the additional constraints that the products looked for must be defined either in the current site, or in any of the catalog model sites associated with the current site. The subselect statement is used to retrieve all the model sites because a commerce site might be associated with multiple model sites.
With this additional constraint, the set of products retrieved would depend on the current site used. For Canada, the search of “Writing Instruments” would retrieve three products: Pen, Paper, and Laser Pen. For UK, the Laser Pen does not exist, so only the Pen and the Pencil would be retrieved.
While this query is generic and satisfies the requirements of many situations, we must recognize that it is quite inefficient. First, the use of a subselect statement is generally not a good idea because it increases the processing time associated with this statement and can increase the load on the database. In addition, in many database engine implementations, the IN clause is quite inefficient and should generally be avoided.
The result of using this inefficient query would be that the performance of catalog browsing can be significantly slower when the site path is in use, compared with a single standalone site. Such a side effect of employing a site path would be quite unpleasant because the performance of a commerce site is a significant factor in its acceptance by the business. Ideally, we want the performance of a multisite commerce platform to be no worse than the performance in a single-site environment.
To optimize this query, it is best for the application to look up and cache the site path during initial startup. Let’s say the id of the catalog model site is stored in the :CATALOGMODELSITEID variable. In this case, the SQL statement to retrieve products in a given category for the current site would be simplified:
SELECT name, description FROM PRODUCT, PRODCAT WHERE
PRODCAT.category_id=:CATEGORYID AND
PRODUCT.id=PRODCAT.product_id AND (PRODUCT.site_id=:SITEID OR
PRODUCT.site_id=:CATALOGMODELSITEID)
When we now compare the overhead of the site path enabled query with the original single-site query, we see that the difference is relatively minor. There is no additional overhead of a table join or any inefficient clauses. Rather, there are two additional Boolean criteria, which are specified on a column in the PRODUCT table. If the site_id column is indexed, the performance of the query will not be significantly affected by the introduction of the site path concept into the selection criteria.
In the examples of database queries, retrieval of product information requires the knowledge of two types of data: catalog data and site path data. In other words, with this query, the catalog component knows about the structure of site path and contains business logic that depends on the site relationships. This awareness of the site path with commerce components such as the catalog is generally not a good idea. Fundamentally, business logic should have as few dependencies as possible between components.
One important reason to avoid such logical dependencies is the need to enhance site path capability. For example, so far we have described a linear site path; in other words, an arrangement where each site is associated with one model site. However, what if the commerce platform needs to be enhanced so that the site path might now be arranged in a tree? A possible such arrangement is shown in Figure 16.4.
In this example, the company has a global worldwide catalog of products made available to all sites. However, there are some products that are targeted only to Asian countries, and other products are only targeted to European countries. It would be convenient to permit organizing catalog model sites in a tree so that each level in the tree can provide additional products specific to only a subset of the sites. This way, there is no need for all European sites to have to filter out Asian products, and similarly each Asian site does not need to exclude Europe-specific products.
Instead, a European catalog model site would reference the global model site and add Europe-specific products. Similarly, an Asian catalog model site would reference the global catalog model site and add products for the Asian market. Every European site’s catalog site path would point at the European model site, and Asian sites would use their appropriate catalog model site. Because the two regional model sites also reference the global model site, the country sites get both the global catalog of products and their region’s additions.
Let’s imagine that initially the commerce platform did not support such trees of model sites, but rather only the immediate parent model sites are looked at by the catalog component. Then the company decides to enhance the platform and to introduce the concept of model site trees.
If the catalog queries incorporate the knowledge of site path and model site relationships, this enhancement would be difficult to do. Every catalog query would need to be examined and modified so that product in both the parent and the grandparent model sites are made available to the commerce site.
The considerations apply to other commerce components. Marketing, Inventory, Pricing, or any other components that were enabled for site path, would need to be enhanced so that they make available the shared data in the new model sites.
Such global modifications would be expensive because this effort effectively requires attention to all aspects of the business logic. With so many modifications necessary, it is also possible to introduce numerous new defects, destabilizing the entire platform.
Therefore, it is much better to avoid combining queries into commerce data assets with queries into the site path. Instead, it is preferable to treat the site path as a service that can be queried by all components. The business logic of each component would consist of the following steps:
- Retrieve the list of the model sites from the site path service.
- Include the list of the model sites in the search query.
The commerce data queries always include a list of sites to be searched. However, each component should not contain the logic to determine this site list but instead should retrieve it from the site path service.
In this way, the concept of site path and all its complexities are largely isolated from the commerce application components. The minimal enablement for each component is to include the invocation of site path service and to qualify all queries with the list of model sites. The underlying complexity of the site path is hidden by the service.
Another advantage to have this service is that you can create a single cache of the site path data. As we described, it is much faster to retrieve the list of model sites from memory cache, rather than always having to go to the database. A memory cache of site path associations for all sites within the platform can greatly accelerate the application queries to look up products or other data within the model sites used by a given commerce site. The central site path service would be responsible for building such a cache and for optimizing the performance of site path queries. This way, all components can benefit from the best and most-efficient site path implementation.
The association between a site and the model sites that it uses is expressed as a site path. The site path can be specified as a list of model sites for each type of data asset. Alternatively, you can create definitions of model site types, and in this case, the site path can be simplified to be a list of model sites of each type.
The applications used by the commerce platform must be enabled for the site path. However, if an application inherently is not aware of the site but behaves identically for all sites, it can be left ignorant of the site path.
The applications that are enabled for the site path must structure their database queries so that the selection criteria take the site path into account. To achieve this, you can design the database tables so that each data asset is associated with the site that owns it.
Using caching techniques, you can optimize the queries so that the performance of multisite platform is not significantly affected by the need to look at the site path.
Depending on the implementation of the commerce platform, the structure of the site path can be of varying complexity. Some platforms might allow only a single model site for each commerce site, whereas others might allow arranging model sites into multilevel trees.
The business logic of each component of the commerce platform should include as little knowledge as possible of the site path. Instead, the commerce business logic should invoke a central site path service. This service should be used to retrieve the relevant model sites and to include the returned list in all search queries.