TIM 之组织人员设计

2.1 组织部门

2.1.1 组织部门名称及属性

TIM把人员附着在特定的组织下面。国外以及IBM的观点是淡化组织单元的概念，并非严格要求建立和真实的环境完全一致的组织结构。IBM的一些例子里面按照区域或者职能把公司的组织结构分成几个简单的比较大的部分，然后在TIM里面维护。但是目前在我参与的项目里，都建立了和真实环境很一致的组织结构单元。

在项目里，由于不同子公司的组织部门名称可能相同，所以不能把简单的组织名称作为ou，否则可能会引发同步到其他的系统时的各种问题。

其中的情况分为

1 没有提供部门编码，自己又没有手工编码。

此时组织单元的名称ou 可以重复，但是在部门的description 属性里面按照"子部门+ 下划线+上级部门"的结构进行区分，例如“财务部_B公司_A集团”的描述信息。

2 没有提供编码，自己手工对组织部门编码。

可以设计部门ou为编码+下划线+部门名称的方式。例如A0100_集团总部，其下A0101_公司领导，等等。

3 提供了编码，编码没有规则。

可以在组织单元的description里面添加编码属性，或者增加扩展属性填写部门编码和上级部门编码。

4 提供了编码，编码有规则。

可以参考2 。

2.1.2组织单元同步

组织一般放置在结构树的根节点。组织单元的同步可以利用TDI 监听changelog 实现，注意要设定TDS的日志条目数以及过期时限，否则可能导致日志过大的问题。

具体分析如下

1 changelog 需要tim 和业务系统都保存共有的属性，erglobalid，查看changelog的日志时，在删除时候只有dn 可见，所以组织单元的erglobalid的属性是必须的。在业务系统也必须存在。

2 业务系统开发接口分2种情况考虑。

 只能调整部门的名称及编号，无法对其下的人员属性进行调整。考虑到业务系统自身的能力，在修改部门后可以修改部门下人员的功能肯定是可以有的，但是未必在接口中提供该功能的调用。如果需要TIM重新对业务系统的数据进行调整，则必须触发人员的部门属性修改的动作，此时不可以只用erglobalid 的属性，还要增加与部门编号或者部门名称相关的属性。此时要求tim 修改后，帐户的部门属性和真实的人员所在部门属性不一致。当直接修改部门名称的时候，即使帐户的属性是来自于部门属性，也不能直接调用帐户的修改工作流，必须通过提交供应策略等方法进行帐户的修改。

 业务系统可以修改自己的部门编号和其下的人员。可以采用帐户的部门属性以 erglobalid 的形式存在，所以在更改部门名称后，人员的属性不会变化。通过changelog方式调用对方的部门修改接口，然后由对方系统自己修改人员属性。

2.1.3 组织单元初始化

可以用TDI直接写TIM 的org 节点，进行组织单元的初始化。

可以设置初始数据的格式

可以设计对数据源首先进行循环add操作，然后再循环更新erparent 等属性。

可以自己产生随机数，或者对现有的随机数进行增加并查询判断从而产生erglobalid

2.2 人员设计

一般人员设计要尽量使用现有的属性，在特殊情况下可以修改TDS的schema，以实现对扩展属性的支持。在默认的inetorgperson 里面，有些不常用的属性可以换作他用，比如利用某个属性作为修改标示等等，并非一定要扩展schema。人员的lastmodifytime之类的属性可以作为按照时间因素进行处理的属性，该属性由TIM进行修改。因为帐户的属性是读自人员的属性，所以人员的属性要尽量满足帐户的需要，否则将来会面对重新进行人员的初始化等问题。对重名用户可以在名称后加数字或字母进行区分。

2.2.1 人员导入和更新

可以采用csv导入，IDI数据供给等方式导入人员到TIM。IDI数据供给可以采用协调或者jndi的方式进行协调。注意在配置服务的时候，可以选择是否钩选工作流。

选择了使用工作流，则会在导入和更新的时候，根据服务策略实施以及供应策略参数的方式设置，执行对人员的导入和更新操作，同时会进行策略评估和帐户修改的执行。如果考虑到服务器性能的问题，可以去掉使用工作流的钩选。在对用户进行导入和更新后，再通过对不同供应策略的提交，调用不同服务的帐户创建和修改操作。