移动办公集成方案

系统集成

集成总体设计

以不影响各个系统的独立性为上，以移动办公系统不参杂各个业务系统的业务逻辑及其业务数据为上。

机构信息

方案

1. 在使用机构下拉的页面，通过api的方式调用业务系统接口拉取机构下拉数据，可以考虑延迟加载
2. 在手机客户端中的Sqlite数据库中为各个系统专门建立机构表，需要增加机构数据同步功能模块
3. 在移动办公平台系统数据库中为各个系统单独建立机构信息表，或者将机构信息进行整合

可以考虑方案1和方案2。

方案2的同步方式有两种：

1.MOP后台开发接口，各业务系统机构信息发生改变，通过调用此接口推送机构变更信息。然后MOP后台通过WebSocket的方式将更新的机构信息分别推送给各个移动终端。T+0
2. 通过版本更新的方式，每次版本更新的时候初始化机构信息。T+1

用户信息

各个系统有自己的独立性存在，同一个银行用户的唯一编号，在各个系统存在不一样的情况，也应该允许存在不一样。
因此，主要考虑不同系统的用户如何确定为同一个人、以及如何解决映射的问题。

如何认定不同系统的用户为同一个用户：

1. 如果银行员工有员工编号，以员工编号为准
2. 身份证编号
3. 用户姓名、证件类型、证件号码为

新建系统优先以员工编号作为用户编号，没有员工编号以身份证号后10位作为用户编号。
在建系统不改动，按照上面的同步方案确认同一用户。

用户确认或映射工作，由第三方系统做映射。例如移动办公系统向业务系统发起API请求时，会携带用户相关信息（USER_ID_MOP，USER_NAME，ID_CARD），业务系统根据这些条件去查询在自己系统的用户。

角色权限

移动办公系统不同于其他各个业务系统，只需要部分特定岗位才可以登录，移动办公系统是所属农商行员工都是可以登录的。

建议首先收集整理农商行所有岗位角色、其次对所有岗位角色进行抽象整合出几个大类的角色，最终形成移动办公系统自己的角色。比如管理类角色，操作类角色。

移动办公后台提供配置功能（目前只有数据库配置），可以根据岗位角色对可操作菜单进行配置，也可以给具体某个人配置可操作菜单。

1. 根据个人配置（覆盖权限级别最高）
2. 根据角色配置（覆盖权限级别适中）
3. 根据机构配置（覆盖权限级别最低）

Cros跨域问题

鉴于手机客户端直接连接业务系统API服务，不方便管理，以及Cros跨域不好解决的问题，决定系统架构方式稍作调整。业务系统原服务不需要做任何改动（已经解决了Cros跨域问题的相关代码，后面可以取消）。

考虑改造原因主要有以下节点：

• Cros跨域问题不好解决，主要是QT服务端
• 业务系统的API_URL在手机端配置不方便管理，需要置于后端进行配置
• 移动办公系统作为API请求响应的中转站，方便进行业务埋点
• 为业务系统的API服务的扩展提供更多的可能性（例如API鉴权）
• 手机端作为API请求客户端，那么业务系统的API服务就必须置于公网环境，提高了安全隐患
• 遵从前端极简原则，复杂的业务逻辑置于后端去实现

现在：

改造后：

API鉴权

移动办公系统后台置于公网环境，基于安全因素需要对无状态的API服务增加鉴权模块。

移动办公内部（移动端<-->MOP-API）使用JWT的鉴权方式。移动办公系统对业务系统暴露的API服务，后期暂时考虑采用业界通用的Oauth2.0鉴权方式。各业务系统需要熟悉Oauth2.0准备好开发前准备工作。