DreamForce从事Endeca架构设计与开发有半年之多，Endeca其实也不算是什么神奇的东西，大可以认为就是一个搜索引擎同时配置了一个以数据为驱动的视图引擎。

不过遗憾的是，Endeca在中国的份额并不多，而且Endeca对于大多数IT从业人员来说也较为陌生，所以关于Endeca的自动化流程管理也并没有所谓的最佳实践，DreamForce就谨此以半年左右的所思所想进行一下总结。

Concepts

在谈Endeca自动化流程管理之前，先需要解释一下Endeca有哪些基本元素，同时有哪些数据或者配置是需要管理起来的。 如果对Endeca较为熟悉的看客可以略过此节。

Dimension

Dimension在Endeca中作为数据的维度，好比如，你去个商场， 男装，女装，这种分类就属于数据维度。 这个维度的粗细是由Business User来定义。 而Dimension在Endeca中成为数据结构化的关键 。 通过Dimension， Business User可以将扁平化的数据变成复杂的结构化数据。

Records

Records即指Endeca中的元数据，比如：

作为一款搜索引擎，数据对于它来说是必不可少的。

Properties

Properties是Endeca提供的一套强大且灵活的配置文件，你可以用Properties来配置Records的各项属性，以及Records与Dimesnion的映躲关系（你需要定义这种映射关系让Endeca知晓哪些Records分别属于哪些Dimension）

同时Properties也可以针对搜索引擎进行特殊的配置，比如数据聚合，分词等等。

Location

Location是Endeca数据与视图引擎的枢纽。 Location即是Dimension，比如用户在女装这个类别的时候，由于女装是一个Dimension，所以Endeca也就知晓当前的用户Location是女装。  所以可以想象，通过数据维度（Dimension）的划分，Endeca可以很轻松的进行数据驱动与视图导向。

Experience Manager

Experience Manager可以说是Endeca的核心，也是最为吸引用户的关键组件。 它就是之前Dreamforce一直提及的视图引擎。

Experience Manager是基于Location来定义用户视图， 举例来说，    当前我们有两个Dimension： 男装和女装。 Business User可以在Experience Manager 上面选择相应的Location，即可创建页面，选择相应的布局与视图，即可描绘出男装和女装两个可以说是完全不一样的购物体验风格的电商页面。 这就是Experince Manager的强大之处。 想象一下，如果今天你的网站需要立马出一个Promotion的特惠页面或者需要增加一个新的风格页面， 你是愿意叫着一帮开发花数小时的Coding时间来完成，还是愿意边喝着咖啡惬意的选择你所需要版面和样式??!!

Cartridge Templates

Cartridge Templates 即是上面Experience Manager中所提及的模版，一般来说，根据需求，开发团队会提供多种布局给Business User，可能有单页设计的，双横排设计，三列设计等等，Business User创建页面时就可以选择相应的模块即可。

同时Cartridge可以拆的很细，比如一般我们有各种导航的Templates， 各种搜索框的Templates，以及产品列表， Header， footer 等等。 Business User可以在特定的页面加入想要的元素放置在相应的Section上面。 而这些是所见及所得的。 Business User只需要保存视图配置，立马生效。

Site Configurations

Site Configurations也就是上面针对Experience Manager的各项配置以及Workbench的相关配置数据。    一般来说，我们需要做 Daily Backup以保证我们视图引擎上面的数据得以维护。

CAS

CAS是Endeca的数据仓库，CAS可以设定爬虫任务进行自行的数据抓取，比如到相应的CMS，FTP等进行定时的数据抓取，分析并更新自己的数据仓库。

同时CAS也可以接受各种格式的数据Feed（Word, Excel , TXT , PDF , CSV ….） 同时CAS有一套强大的API可以进行第三方模块的对接。   Dreamforce极力推荐Endeca使用CAS来作为数据Feed的首选 。

Experience Manager Develop Process

在基本概念阐述完之后，先来看一下针对视图引擎的开发模式以及开发流程是什么样的：

从上图可以看出，和传统的页面开发有所不同的是，开发人员不仅要给出相应的Code页面（JSP或HTML），同样要创建相应的模块配置文件（XML文件）。 然后由相应的Content Manager将模块上传到Experience Manger。

Endeca Records Feed

之前描述了Endeca的视图引擎，接下来这里会提及Endeca的数据集成。

如图，一般来说，Feed Endeca的数据需要Records , properties 以及Dimension。 实现这种Feed有很多种方式。

通常来说：

Records可以以一份TXT等格式的文件存在，同时在Endeca的Adapter指定Recordes的数据文件路径，在运行Endeca Baseline Index命令即可开始数据编录索引。

Properties配置最常见的做法就是使用Endeca自带的DeveloperStudio开发工具进行显式的更改。 更改完之后存放到相应的App目录里。

Dimension文件一般是以XML的形式存在的，通常由第三方工具生成然后放置于指定路径下即可。

以上是最通常简便的数据生成及管理方式，Dreamforce在此会提及另外一种可利于管理的数据录入方案：

如上图，数据管理引入CAS Server进行数据管理。在数据管理的时候，我们分为两步：

1. Feed Data， 即 将 Records , Dimenson , Schema（Properties）三类数据分别以对象流的形式输入到CAS相应的schema中. 对象流的录入使用CAS的API，以Java为例，Feed Records Data只需要将Records元数据封装为Records对象并加入相应的标识即可。 而CAS中的Schema可以理解为数据库中的Schema概念。

2. Call Remote EAC Baseline ：此步就是远程调用Endeca的索引命令(Baseline 是指全编录，与之对应的还有Partial Index ，即局部更新。此文全以Baseline为例进行阐述)。此命令首先会去读取CAS中相应的数据，然后针对数据进行数据索引。

至此，此文已经阐述了视图引擎与数据搜索引擎的流程。 当然在此之前也算是各种信息碎片的描述。而接下来Dreamforce还会描述另外一块非常重要及核心的Endeca载体：  Endeca APP

之前一直没有提及Endeca App 这个概念，是因为他本身只是一个载体，比如你要使用Endeca做数据搜索，那么在做搜索之前，你先需要建立Endeca 的App来存放你相应的搜索配置及数据，也就是说，Endeca支撑Multiple Configurations . 你可能会有三个站点的网站，同时有不同的数据及视图配置，那么你就需要在Endeca的引擎上面建立三个与之对应的App。 这些可以有效的进行数据分离与管理。 而如果你使用ATG的话，你可以用多个APP来很方便的实现Multi-Site， Multi-Locale。

上图是Endeca App 的流程， 可以看到有如下几步：

1. Deploy App， 此步会用APP Templates（可以用Endeca官方原生，也可以是基于项目定制的） 进行项目发布，同时会将Templates里相应的配置占位符替换成真实的APP环境值。

2. Initial APP， 此步是进行App 初始化 ， App初始化依赖Pipeline文件（Pipeline文件即Dimension， Properties等配置），如果App配置了相应的CAS规则，那么此步也会同时进行CAS Schema的初始化。

3. Feed Data ， Feed Data如当之前提到的CAS数据Feed。

4. Update Rules and configurations ， 这里是进行视图引擎的更新，视图引擎更新所需要的数据一般有：Cartridge Templates以及Site Configurations。

以上就是一个App大致的生命周期。以及日常维护所需的Task。

至此，关于Endeca的APP， Data 以及 Experience Manager 全部阐述完毕，我相信业内关于Endeca的各模块的流程都是如出一辙，而接下来，Dreamforce会分享一下如何将三个模块的管理统一起来并实现自动化的方案。

文件管理

如图，Endeca和Estore进行文件分离管理，开发团队需要将相应的文件提交到对应的SVN目录中（此处，Endeca以及Estore由SVN进行版本管理）。

App_templates : App 模板，推荐模板定制化

Cartridge_templates: 视图模板，通常情况下，开发团队需要同时提交相应的页面（JSP）及与之对应的视图模板。

Pipeline： Properties 配置

Scripts: 自动化脚本文件

Site_configurations: Experience Manager数据存放目录

lib :相关包

在项目中，通常情况下使用Jenkins等辅助工具配合使用，这样可以避免开发团队或者维护团队使用命令操作，同时在多环境布署和发布的情况，效果尤为突出。

接下来，Dreamforce会阐述一下自动化流程的大体思路，如下图：

1. Generate Dimension File：

a).脚本会远程去触发 生成Dimension文件组件（SOAP或者JMS等方式）

b).生成Dimension的组件会依据相应的逻辑生成Dimension文件，并存放到指定目录

2. Run Deploy-app Task  :

此步只会在初发发布App时候用的，在日常的项目维护中可以略过此步

a).使用App Templates 进行App发布，用户需在发布前在相应的配置文件中指定正确的参数。

3. Run Initila-app Task :

a).将之前生成的Dimension文件拷贝到APP 目录

b).将SVN目录下的Pipeline文件拷贝到APP相应目录

c). 调用App的Initial 指定（此指令是Endeca原生指令，一般情况下只需要将相应的文件放在指定目录即可，Dreamforce在此脚本做了一定的客户化，但不影响主流程）

d). Initial步骤，会将发布好的App按相应的文件进行初始化，同时将此App纳入Endeca Mdex（Endeca的核心引擎）的管理

4. Do Baseline Update in ATG service

Dreamforce由于使用的ATG环境，而ATG自带针对Endeca的Feed，如果使用非ATG 环境，此步可以加入CAS的API，然后将元数据封装为Records对象，然后开启CAS的对象流，进行数据Feed。

a). 第一步会远程触发 数据Feed的组件，远程系统会将相应的数据Feed到CAS系统中去

b). 调用Baseline指令（Endeca原生指令），会从CAS指定的Schema中抓取数据然后进行索引。索引数据最终存放在MDEX引擎中。

5. Run Update-service Task

a). 拷贝SVN目录下Configurations文件到App指定目录

b). 拷贝视图模板到APP指定目录

c). 调用App的Update指令（Endeca原生指），更新相应的配置数据及视图模块到Mdex引擎中，同时配置立即生效。

此四步皆可用Jenkins等辅助工具进行管理，关于Endeca的日常维护及更新皆在此四步之内。

后续：

此方案Dreamforce至设级之初到此没有遇到瓶劲问题，但是细节方面还是有较多的不足，待改善之处。如果看客有更好的建议或设想，欢迎拍砖。对Endeca有兴趣之士，欢迎交流~