2015.03.05-在导入时可以先批量插入再批量更新，通讯录、呈现、client管理方案评审，设计时需要考虑对其它网元的影响、多种应用场景的了解与满足，站在用

今日任务：

1.研究web server关键技术：批量导入、日志记录功能、XCAP


2.下午通讯录方案评审


实际：

批量导入导出完成

企业通讯录批量导入：部门数据有层级关系，所以先批量插入再批量更新



收获：

1.批量插入：

insert into DepartmentInfo (ID, DepartmentName, ParentID, IsRoot, Remark) vlaues

(1, 'xxx', 'xx3', 0,'xxx'), (1, 'xxx', 'xx3', 0,'xxx'), (1, 'xxx', 'xx3', 0,'xxx');



2.批量更新：

DepartmentInfo

ID DepartmentName ParentID IsRoot Remark
1  总经办                   0
2  市场部                   0
3  研发部                   0
4  开发一部                 1     研发部
5  中国市场部               1     市场部



把这样的表变成下面的样子

依据Remark找到ParentID
ID DepartmentName ParentID IsRoot Remark
1 总经办 0
2 市场部 0
3 研发部 0
4 开发一部 3 1
5 中国市场部 2 1



SQL: update DepartmentInfo inner join (select ID, DepartmentName from DepartmentInfo) b set DepartmentID = b.ID, Remark = '' where Remark = b.DepartmentName;


3.关于方案
通讯录： a. 在UCS网管删除企业通讯录的管理员时，提示用户：该操作会删除企业通讯录所有的信息
b.客户端第一次获取通讯录信息时，分两次发送GET，第一次携带用户的Sip号码，server端 检测用户的合法性，并返回用户自己的信息，第二次GET所有企业通讯录的信息。好处是安=全、便于实现
c.设计方案要考虑到所有涉及到的网元的影响，如网管、客户端的配置影响、可操作的影响；
d.由客户端进行显示和操作权限的控制
c.遗留问题：企业通讯录管理员，添加企业通讯录信息与批量导入通讯录信息时，用户数据的有效性检测。

呈现： a. 状态呈现的权限控制应该由客户端执行。状态呈现服务器给客户端下发全部企业成员的状态。
b. 如果用户集体掉线，如何预防状态通知的消息风暴？ 本次设计没有考虑，在设计文档的遗留问题中加入此问题。后期的完善设计中考虑风暴控制方案。如加入时间限制，时间可以通过配置
c. 基于状态呈现的业务控制有哪些？ 目前对不在线的用户可以发起语音呼叫，但是不能发送即时消息。
d. 状态订阅的周期是多长时间？ 订阅周期由subscribe消息的expires字段决定，实现时可以尽量延长订阅周期，减少消息交互次数

客户端管理：
a.IMP板出厂是否有客户端版本。 答复：默认有，也可以没有。
b. 提供二维码保存在本地按钮或者直接支持邮件发送 答复：暂时提供保存到本地按钮。
c. 客户端发布描述信息 答复：xxx确定客户端发布打包格式，包括版本描述及MD5值。
d. 提供服务器地址下载版本功能。 答复：预留接口，可以从固定服务器检测下载最新客户端。

设计方案时需要考虑以下几点：
对于其它网元的影响，包括接口、实现、配置、操作等
对于可能有多种应用场景的情况，为了保证可用性、友好性，一定不要限定一种实现方式，可以在方案中列出多种实现方式以应对不同场景的需求
多站在用户（包括测试组、企业用户、公众消费者用户）的角度考虑设计，考虑用户的使用感受、操作习惯、便利性、友好性等