引言
一个营销企业有多个销售策略，每个策略的目标都是不同类的客户。需要为每类客户（有时每位客户）定制不同样式的站点。这引发了一个问题就是必须管理不断增长的一套业务数据资产。要求尽可能重用不同站点中的大部分数据资产来减小数据管理的问题。本文引入了资产存储及存储路径的概念，使得可以共享不同站点中的数据。通过在 IBM® WebSphere® Commerce 中创建扩展的站点，您可以提供必要的基础架构，从而在扩大站点管理的可伸缩性时构建定制的站点。
扩展站点的概述
在复杂的业务环境中，企业需要应用多种策略来为客户创建可用的产品。确保业务成功的重要策略是企业必须在市场上呈现多种“面貌”，每种面貌都被客户看作独特的站点。一些实例包括为特殊的地区定制站点、基于品牌需求呈现特殊的站点，或者为大客户设立定制的站点。每个站点对于访问它的客户看上去都必须是独特的，此外每个站点都需要实现该站点特有的业务规则。例如，不同地区可能有特有的法律和税务规则。
然而，要想获得操作上的成功，整套站点的管理的可伸缩性变得非常关键。虽然必须维护每个站点的特有方面（如表示法、营销活动及种类变更），设备的公共方面被分解成单一共享的数据，这是非常重要的。从我们的经验来看，企业管理的 75% 到 90% 的配置数据对于所有以营销为目的创建并维护的定制站点都是通用的。
本文描述了 WebSphere Commerce 如何使用扩展站点的功能来提出站点可伸缩性的问题。应用这种功能，企业创建并管理一套被所有站点共享的通用配置数据资产。对于企业需要向市场呈现的每种“面貌”，您创建可扩展的站点，它包含为特定市场的站点定位出的所有必要的定制信息。
我们首先描述多站点的一些公共业务场景，然后概述使资产能够在站点之间共享的技术。
扩展的站点业务模型及场景
本文重在描述 Consumer Direct 和 B2B Direct 业务模型。在 Consumer Direct 业务模型中，企业向公众出售商品及服务。在此业务模型的变化中，客户可能是受限制的。例如，使用流行的 Employee Purchase Plans，客户是公司的职员。使用 B2B Direct 业务模型，企业向产品的终端用户或产品的二次营销者（某些情况下）出售其它业务。
所有企业都有他们特有的营销策略，每个销售组织都建立他们自己的特有的与客户交互的解决方案。然而，销售的企业需要创建多个站点，在这些业务模型中存在一些公共场景。这样的场景包含适用于不同地区、不同品牌、不同市场的特有站点，以及适用于大客户的特有站点。
不同地区的站点
通常，销售企业需要在多个地区出现。在跨国的销售企业中，由国界、州或省的管辖范围或营销及销售区域来确定地区。
考虑出现在许多国家的跨国营销企业。通常，每个国家在各地区有它自己的规则和特色。例如，虽然整个企业提供单独的一套产品或服务，但是任何一个地区可以确定在该地区内可用的子产品。可用的产品的这种差异可能由于法律约束或者营销决策。其它存在地区之间差异的实例是税务规则，国家与国家之间的差异非常大，并且依赖本地的运输提供者来运载这些规则。
营销活动可能以特定地区为目标，仅在选定地区使用特有的广告或提供促销。可能有一些营销信息需要在企业级发布；换句话说，需要启动所有地区共享的全球的活动。
甚至对于共享的资产，在某些方面仍需有差异。例如，产品描述可以被所有销售特定产品的地区所共享。然而，每个地区可能以不同语言来呈现这些描述。例如，在美国，客户可以选择以英语或西班牙语查看站点，而在加拿大许多站点以英语和法语出现。跨国的销售者需要设置站点以便在每个地区都有适当的语言选择。
对于特殊地区的站点设置必须以国家相应的货币提出定价。这包括管理多种货币的价格，或购买流程中动态的货币转换。
不同品牌的站点
具备品牌的站点通常以该品牌特有的方式呈现产品。虽然对于每种品牌有时产品有很大的差异，许多产品以多个品牌出售。然而，站点必须定制适合于每个品牌需求的表示，例如站点的外观和感觉、大体流程及产品显示页面。
另一个特有的品牌技术是由站点发布销售信息。虽然有时一些企业信息可能被所有品牌显示，通常每个品牌有它自己特有的销售策略。例如，目录销售和交叉销售、促销及广告几乎是每个品牌特有的。
不同市场部门的站点
通常，销售企业例示以特定市场部门为对象的站点。最典型的差别是 B2B 和 B2C 客户由不同的站点提交。此外，在 B2B 公司中，可以创建特有站点，这些站点适用于诸如教育、旅行、运输、工业等部门。所有这些站点都基于同一套目录数据，但是每个站点都需要过滤出适用于它的目录部分。如同使用品牌一样，营销活动及消息通常是站点所特有的，但是给定的营销信息对于一些市场部门、公司或整个企业可能是通用的。
在 B2B 领域中，每个站点都为多个客户服务。这对于中小型企业（SME）尤为重要，其中销售者可能在同一部门中有大批客户。每个客户有他自己的定制，例如运输和账单操作，以及影响定价或产品权限的合约安排。在很多情况下，提前设置通用的典型合约来提出大多数典型客户的需求。在这样的安排下，允许客户预先定义期限及条件，一些可能出现的例外情况也在预先定义的合约中提出。此外，客户可以商议价格，或有权利定做仅适用于他个人的产品。
不同的业务客户可以在站点流程中请求截然不同的操作。例如，一些客户可能请求定购批准，而其它客户没有此请求。对于如何处理购买序列号存在差异，并且有时客户可能希望当他们的员工访问该站点时能够在站点上看到他们公司的标识。
适用于大客户的站点
非常大的客户通常有特殊的购买需求。他们的需求从具有特别设计的定价及产品权利到持有特有的市场消息、对于站点的外观和表示法进行特定的修改，甚至变更业务逻辑。例如，大客户可能需要不同的检验流程，来向他们的公司提供特有的信息。注册流程可能不同。例如，一些公司希望批准每个在站点注册的员工，而其它公司可能更需要自服务的流程，每个员工必须知道公司代码或密码才能注册。
定购通告是不同企业表达不同需求的另一方面。一些企业可能希望将每个定购的通告都发送给指定的合约，而其它公司需要将通告发送给员工来下订单。需要对于大企业客户的需求定制访问控制。一些企业允许所有员工都能下订单，而指定的管理员可以在他们的部门中查看所有订单。有时，企业客户可能允许员工浏览目录，但仅采购职员有权下订单。访问控制可能存在许多差异，但每次都定制它们以控制企业买主的需求。
大客户的另一常见需求是与他们的采购系统的交互，以便购买订单能够自动地输入进商业环境中。已注册授权的员工可以追踪 B2B 订单的状况。
存在企业客户可能需要的一些定制。然而，这些实例说明了全部的站点定制需求。这样的企业站点必须共存于同一基础架构中，尽可能多地共享数据和业务逻辑，以便全部操作的管理对于销售组织不会变得非常昂贵。
回页首
实现扩展的站点
此部分描述了 WebSphere Commerce 用于在单一基础架构上实现大量的定制站点的技术和业务建模元素。
存储
一个管理商业事务所需的基本元素是值交换事务发生的设备。该设备必须为这些事务制定上下文，依照管理业务规则及管理所有交互的策略。在 WebSphere Commerce 中我们使用“存储”来为值交换设备建模，它是管理的商业事务进行交互的空间。在单一存储中，可以使用诸如营销活动及促销、个性化或 B2B 合约之类的技术来为不同客户定制业务规则。然而，有一些例外，整个业务流程对于所有适用同一存储的客户是类似的。
允许对于不同地区、市场部门或客户的业务数据、业务规则及表示逻辑之间存在差异，需要创建多个存储，定制每个存储以适合于相应的市场需求。扩展站点调用这种定制的存储，而共享站点间的公共配置及数据资产。
基本的存储建模
确定如何在 WebSphere Commerce 中设置多站点的业务的第一步是确定存储代表什么。WebSphere Commerce 装置可能仅包含单一存储，如果它对于业务建模来说足够了。通常，WebSphere Commerce 装置创建成百甚至上千的存储，这些存储支持多数业务上下文及营销事务。
通常，为连续客户设置存储是合理的，他的全部需求类似于表示逻辑、在他们看到的目录中有一些公共特征，并且在以他们为目标的营销活动中具有公共特征。
另一方面，如果客户，或一批客户，与其他人不同，按照适用于他们的业务逻辑，或者在表示的某些重要方面，或者根据特有的业务数据的设置，诸如产品目录、定价或存货，那些通常是指示器，需要为这些客户设置单独的存储。
高级的存储建模
对于大量站点装置的成功管理的关键在于销售者管理独立资产的能力，这些资产在包含全部操作的站点之间共享。不是复制所有必要资产的定义，每个站点仅选取他们感兴趣的资产。例如，每个站点需要过滤产品种类，以便终端用户仅能看见相关的部分。此外，每个站点需要添加市场指定的产品。类似地，每个站点需要确定在站点上呈现哪个全球化的活动，以及设置对于指定站点提出的业务客户的特有活动。
WebSphere Commerce 使用该机制来共享存储路径调用的数据资产。图 1 说明了这种概念。
图 1. 目录共享
在本实例中，为业务客户及消费者创建独立的扩展站点。这些站点从同一目录中销售产品。在 WebSphere Commerce 中的存储代表每个站点。
为了共享目录，而创建资产存储。资产存储是存储的一种类型，它不能被客户访问，但是它持有业务数据。在这种情况下，Catalog Asset Store 持有目录数据。两个扩展的站点不包含任何目录数据，但是它们设置它们的存储路径来指向目录资产存储。WebSphere Commerce 中的业务逻辑使用该存储路径来检索目录数据，使它看起来好像在客户存储中，虽然它是从资产存储中继承来的。在其他方面，诸如表示外观和营销活动，B2B 和 B2C 存储彼此是完全不同的。
使用这种机制，销售者在资产存储中持有独立的目录图片，然而从站点表示和流程的角度看，客户可能看到完全不同的站点。
WebSphere Commerce 有两种不同的存储：
- 资产存储——这种存储是配置及数据资产的容器。客户不能登录以进入这种存储中，然而资产存储中包含的配置数据可以通过使用 WebSphere Commerce 加速器（同其它存储使用的相同）来管理。
- 客户外观存储——客户外观存储具备客户能够访问的存储外观。这种存储定义了选择资产存储（包括必要的配置数据）的存储路径。在这种环境下创建的每个客户外观存储都被扩展的站点调用。
通过存储路径共享的其它资源
目录仅是使用存储路径的存储之间共享的多种资源之一。其它类型的商业配置数据可以通过使用该机制来共享。
图 2. 表示及目录存储路径
在图 2 中，销售者为教育部门中的客户创建了两个存储，为政府部门的客户创建了两个存储。所有存储都共享同一目录数据。然而，不同部门中的存储可能需要不同的表示。对检验流程、存储外观，甚至特殊的目录信息的显示都有不同的需求。为了满足这些需求，销售者创建了“表示资产存储”，它包含诸如对于站点中的每个视图应调用哪个 JSP（JavaServer 页面）之类的信息。
使用图 2 中的机制，销售者管理所有存储的单一目录。销售者需要尽可能多地创建业务所需的表示资产，在这种情况下，每个部门对应一套表示资产。然而，每个客户外观存储都以指定的用户为对象。例如，他可能有自己的个人营销活动及运输和支付机制。
到此为止，我们已经了解了不同存储之间是如何使用存储路径来共享目录数据及表示的。事实上，许多其它资产也是使用该机制来共享的。例如，上销及交叉销售、营销活动、基础合约和业务策略可以通过相应资源的存储路径来共享。
存储路径的灵活性在于在它自己的资产存储中创建每个资源。这样，资源可以被混合并匹配业务的需求。例如，通常销售者创建并管理两种资产存储：独立的目录资产存储及多个表示的资产存储。目录资产存储定义了可被所有客户存储共享的公共目录；而每个表示资产存储包含表示信息、全球的营销活动及公共业务策略。所有客户外观存储的目录存储路径选择了通用目录资产存储。此外，每个客户外观存储的存储路径选择适合于相应地区及市场的表示资产存储。使用这种机制，少量的资产存储可以涵盖具有成百上千个扩展站点的多站点装置的需求。
扩展的资产共享
存储路径的功能不仅在于共享数据资产的能力，而且在于共享这种数据选择的能力。回顾图 2，我们说 K-12 客户存储需要仅销售目录中产品的一部分，而其它产品或种类不适用于该部门。每个客户存储可能需要使用目录的不同过滤器，使得在销售中仅出现由存储所服务的客户部门相关的产品。而且，目录资产存储可以定义所有产品的价格列表，每个客户外观存储可以设置自己对于那些价格的调整，有时甚至完全更改价格。为了提出该请求，WebSphere Commerce 创建目录过滤器，它提供了调整每个存储中出现的目录的机制。
图 3. 管理在目录资产存储中定义的目录
图 3 展示了功能工具的管理目录，如同定义在目录资产存储中的一样。该目录包括四个顶级种类。图 4 展示了不同存储如何提出目录的不同部分。
图 4. 两个不同客户存储的目录过滤器
图 4 展示了为两个存储而设计的两个目录过滤器的实例。第一个存储排除所有木制产品。第二个存储排除所有钻孔及相关产品。
图 4 说明了您如何将管理目录作为独立单元，而每个存储都设置了目录的一部分，用于该存储中的销售。此外，每个存储可以通过指定定价的上标记或下标记来调整产品的价格，或指定实际的价格。而上面的实例展示了相对小且简易的目录、WebSphere Commerce 的基础架构及已经被证实能用于具有成百上千个项目的目录的工具。
目录存储路径使得销售者不仅能够定义共享目录的子集及相应的价格调整，而且能创建该存储所服务的客户部门的特定数据。例如，以一个大客户为目标的存储可以包含以该客户指定的价格创建的产品。因为这些产品被放置在客户存储中，所以它们对其它任何客户都是不可见的，即使它们存在于可以被其它客户访问的种类中。然而，扩展站点的客户可以看到在存储中创建的指定产品及由管理目录过滤的一批产品。
附加及替代
在先前的部分中，您看到了通过使用存储路径共享的目录数据是如何由客户存储（或者目录资产存储中的过滤器产品）指定的添加数据功能来控制的。
类似的功能对于所有经由存储路径所共享的资源都是可用的。例如，客户存储可能源于资产存储的某些活动，它可以添加自己的活动，该活动是由存储所服务的客户部门所特有的。客户存储可能需要重做在表示资产存储中定义的一些视图，定制它们以适合于特定的客户部门的需求。服务于运输部门的存储可以从资产存储中获得一些政府客户通用的基本合约。可以定义客户特定的合约，该客户是由存储服务的。
回页首
使用扩展站点共享的资源
目前您已经了解了资产存储及存储路径的概念是如何位于扩展站点共享的配置数据的核心的。每个扩展站点都定义了它的存储路径，说明它的配置数据源于哪里。存储路径列出一套资源，例如目录、表示、活动、促销、命令等等。对于每种资源，存储路径列出了应查询的相关数据的资产存储。例如，存储路径应当表明首先在客户存储中搜索目录数据，然后在目录资产存储中搜索。理论上，可以为每个存储路径资源创建独立的资产存储。但是，通常从同一资产存储中查询多个资源。因此，在上面的实例中，扩展站点的存储路径表明从同一表示资产存储中查找营销活动数据及表示信息。
Websphere Commerce 5.6 通过使用存储路径来共享大量资源：
- 目录：不同站点可能呈现同样的目录信息，这通过使用目录内容过滤的功能来实现。
- 定价：不同站点可以基于同一价格列表中的定价，这通过使用每个存储特定的调整或重写来实现。
- 活动：不同站点可以通过使用添加站点特有的活动的功能来向他们的客户呈现同一广告活动。
- 促销：不同站点可以共享全球所有站点的客户所用的促销。
- 业务策略：不同站点可以共享同一业务策略，例如支付或运输策略。
- 基本合约：不同站点可以共享全球性的合约，例如政府合约或行业部门的典型合约。在添加客户特有的例外或附加的价格调整时每个客户的合约可以参考这样的基础合约。
- 表示：不同站点可以共享它们的表示，但个别站点可以重写一些特定的页面或视图。
- 业务逻辑：不同站点可以共享包含商业业务逻辑的同一套命令，但是个别站点可以重写那些包含他们环境特有的逻辑的命令。
- 整个组织结构和访问控制策略：所有 WebSphere Commerce 实例中创建的扩展站点共享同一组织结构。这意味着独立的管理用户可以管理多个站点，这是由适当的拥有每个扩展的权限下的用户角色所指定的。管理员被赋予了特定的角色来管理一个或更多扩展站点并赋予管理资产存储中的数据的访问能力。客户在扩展站点中注册以获得访问存储的能力。但是，赋予客户在不必维护多个概要文件的情况下使用多个扩展站点的能力。
结束语
WebSphere Commerce 中扩展站点的功能使得企业销售者能够扩展现有的数据资产并管理大量的站点。使用该功能，独立的基础架构可以满足每个站点的目标客户的需求。每个扩展的站点可以从各种资产存储中继承一些或全部数据，并添加其它的由该站点服务的目标客户所指定的数据。您可以创建、定制并将扩展的站点设置在合适的地区、品牌、市场部门或大的企业客户。扩展站点的基础架构使得销售者可以实现多个营销策略、使得增加销售并提高客户可信度。这很大程度上减少了操作和管理的耗费。由于减少耗费及扩大市场范围的组合的影响，销售企业与使用先前的技术建立的站点相比有巨大的竞争优势。