活动拆解结构图：

蓝色部分为0.2设计一些概念。

模块： 完成一类功能需求的集合。例如抽奖、调研、报名。

功能块：模块内按操作界面来分的功能集合，分拆原则是这些部分同属于一个模块，但是会在活动的不同地方进行展示。例如抽奖中分三块：领取记录、轮播、抽奖按钮。

接口：即一个单独的程序。目前可以是http或idip。按照AME规范输出。

条件：执行动作的前提。由接口和AME的配置（比如根据返回值配置大于，小于等）组合而成。

动作：通过调用接口来完成需求。

资格：属于AME内置，由条件返回结果换算而来。当资格未耗尽的时候，不会去调用条件。

白模版：由功能块提供的模板，完成功能语义。

流程：对外即一个通过AME配置的程序调用。他通过条件+资格+动作配置而成。满足条件或资格后会执行动作。

默认流程：每个功能块有特定的逻辑。这些逻辑是预先可以知道的，例如领取按钮，肯定要调用领取的接口。目第是默认配置好，减少创建活动时候重复配置。

自定义流程：用户按需对条件和动作自由组合。

默认流程和自定义一样，功能一致，差别就是预先配置的还是自定义配置的。

TDS核心主要以下面两块进行：

一），TDS管理端界面，也就是 ams.ied.com/ams0.2 。

这是大家配置活动时都能看到的界面；但是在这里配置完成后，并不能用。

打个比喻：每配置一个活动，就好比造一辆车。在TDS管理端界面配置完成以后，就相当于生成了一个“车壳子”。

这个时候的“车壳子”，方向盘并不能控制方向，不能刹车，不能油门，不能坐乘客…. … 那怎样，才能让这个“车壳子”实际有用呢？ 那就是AME。

二），AME，E就是 Engine，“引擎”(用户端的主要部分)。

有了这个引擎，前面所说的“车壳子”，就能起作用了，方向盘能控制方向了，能刹车了，能油门了，能坐乘客了…. …

这两块的职责：

一） TDS管理端配置。能够很好地获取用户的活动配置需求，能够造好一个用户想要的“车壳子”。

包括模块接口管理，功能块管理，活动配置，创建模块，模块配置，流程配置，规则及关系配置，条件及关系配置，动作配置，活动发布，白模版生成，运营管理等。

所以大家在使用ams.ied.com/ams0.2配置时，通常所遇到的一些配置bug，或者界面优化调整，都是 属于这块的。

二） AME（引擎）。能够真正执行用户的需求，将管理端所造好的“车壳子”变得真正有用。

包括活动时间控制，流程执行，规则执行及规则关系控制，条件检测及条件组合关系检测，资格频率控制，资格回滚，动作执行，动作补发，调用各模块，解析各类接口等。

所以大家在使用ams.ied.com/ams0.2配置时，一般是看不到AME的bug的。但是并不是说这块就高枕无忧了。

AME的bug，主要是由活动测试人员及用户发起的，例如有可能：并发问题，资格回滚问题，补发问题，规则关系控制题，条件检测问题，各类接口请求问题等等。而且这类bug，大多数来说，时间一般比较紧急，一旦出现就得尽快解决的。若处理不好，就引起“突发”。

这两块的关系：

一） TDS管理端配置界面的改动，可能会带来AME的逻辑结构的增加修改。

例如：在管理端配置界面上，需要增加IDIP,积分类的配置,抽奖V3条件CGI的配置； 那么在AME里，得增加IDIP的处理，抽奖V3条件CGI的处理。

例如：在管理端配置界面上，需要增加一些变量参数的配置，例如{date},{dateTime}等； 那么在AME里，得增加对这种变量参数的处理。

否则，TDS管理端配置界面改动了也无效。

二） AME的一些逻辑结构的增加修改，可能会带来TDS管理端界面的改动

例如：AME增加了对动态参数的支持；那么TDS管理端界面得增加配置，让用户可以配置选择动态参数；当然管理端可以想个好的方式去展现界面。

例如：AME规则关系改为了“全部执行”、“成功退出”，“失败退出”；那么TDS管理端界面的规则关系也得这样改；当然管理端可以想个好的方式去展现界面。

否则，AME就算支持了该功能，TDS管理端界面无相应配置，AME也是白做。

总之，这两者的关系就是相辅相成的， 是相连的。

这两块是如何相连合作的呢?

管理端界面配置完成以后，会生成一个“车壳子”，也就是AME的描述文件。然后AME引擎，根据这个“车壳子”，来执行。

所以这个“车壳子”非常重要。如果管理端在生成“车壳子”的时候，把放“刹车”的位置，误生成了“油门”。那么就会出现“误把刹车当油门”的悲剧了。