论文部分内容阅读
【摘要】 目前电信运营商各省公司均在大力推进IT系统的移动互联网化改造，但是在移动应用的开发过程中，各厂商独立开发，缺乏统一的规划，多数用户需安装多套客户端，用于支撑日常的移动化办公。笔者结合多年来在电信运营商企业信息化规划咨询的经验，提出了运营商移动应用门户的整合思路。
【关键字】 运营商 移动应用门户 应用
一、引言
目前电信运营商各省公司均在大力推进IT系统的移动互联网化改造，如电信公司的爱营销、爱运维、销售助手、数据门户手机版等，移动公司的CRM移动版、ESOP移动版等；但是在移动应用的开发过程中，一般各运营商都是由各厂商独立开发，缺乏统一的规划，多数内部用户需安装多套客户端，用于支撑日常的移动化办公，系统缺乏统一的移动应用入口、统一的应用发布、统一的安全接入服务。
二、当前移动应用所用的三种开发模式
2.1原生开发模式
原生应用程序是某一个移动平台（比如iOS或安卓）所特有的，使用相应平台支持的开发工具和语言（比如iOS平台支持Xcode和Objective-C，安卓平台支持Eclipse和Java）。原生应用程序看起来（外观）和运行起来（性能）是最佳的。
原生应用程序提供了最佳易用性、最佳特性以及最佳总体移动体验，诸如多点触控、快速图形API、内部部件（摄像头、地址簿等）等相关功能都智能通过原生应用来实现。
2.2 WEB模式
WEB应用程序使用标准的Web技术，通常是HTML5、JavaScript和CSS。这种只编写一次、可到处运行的移动开发方法构建的跨平台移动应用程序可以在多个设备上运行。虽然开发人员单单使用HTML5和JavaScript就能构建功能复杂的应用程序，但截至本文截稿时仍然存在一些重大的局限性，具体包括会话管理、安全离线存储以及访问原生设备功能（摄像头、日历和地理位置等）。
2.3混合模式
混合应用程序让开发人员可以把HTML5应用程序嵌入到一个细薄的原生容器里面，集原生应用程序和HTML5应用程序的优点（及缺点）于一体。应用可以通过容器来访问原生平台功能。
三、移动应用门户整合思路
3.1总体思路
纯WEB模式开发的应用可以直接通过PC版WEB应用的门户整合方式进行应用门户整合，但是目前各运营商移动应用众多，绝大多数都存在原生或混合模式开发的移动应用，故此无法简单的采用纯WEB方式进行移动应用的整合。
笔者将当前移动应用的功能进行了梳理，发现当前移动应用功能主要分为以下三类：
用户待阅：包括OA邮件、会议通知、系统通知等需要用户阅读而无需反馈的内容。
用户代办：包括流程审批、装维接单、计划任务等需要用户接受并反馈的内容。
主动应用：包括诸如业务受理、请假申请等需要由用户主动发起的内容。
根据上述分类，当前各类应用均可按照上述思路进行拆分整合，整合后的移动应用界面将如下图所示。
3.2待阅整合
待阅整合建议通过移动应用门户平台整合所有平台的待阅信息（包括通知、公告等）。
移动应用门户平台需提供模板定制功能，根据用户角色来定义要收取的待阅类型（如OA待阅、邮件、CRM平台通知、计费通知等），或者由用户自定义要获取的待阅类型。移动应用门户通过接口获取各个平台的待阅内容。用户登陆后，移动应用门户根据设置展示用户所对应的待阅内容列表，待用户点击后，门户应用直接进行待阅信息的展示。
3.3待办整合
考虑到各个应用待办功能的复杂性，待办整合可以考虑前期只实现统一的待办列表，待办的处理可由原有应用客户端来实现。同待阅整合一样，移动应用门户客户端需提供模板定制功能，实现待办内容类型的定制，门户客户端根据类型设置，展示不同类型的待办任务。
用户在门户客户端点击某一条待办信息后，门户客户端根据待办的类型启动对应的原有移动应用，并将此待办的相关参数传递给相应的移动应用，原有应用收到门户客户端参数后，直接进入待办处理页面，完成待办任务的处理工作。
3.4应用整合
各业务应用可由不同客户端实现，但建议通过移动应用门户实现统一管理、展现，以减少业务层级。如移动终端版CRM中存在业务受理、客户信息查询等相关应用，建议移动应用门户中应用的展示应该为业务受理、客户信息查询等，而不应该是移动终端版CRM。移动应用门户客户端同样需提供业务定制功能，支持页面展示的应用的自助化定制。门户客户端启动后，根据定制显示不同的应用内容。当用户通过门户客户端点击相应的应用后，客户端根据应用归属启动相应的客户端，并传入对应应用的参数。原有客户端启动后，根据传入的参数，直接转入相应的页面即可。
3.5其他改造要求
3.5.1 接口建设
移动应用门户客户端需要与原有移动客户端建设以下两个接口：
单点登陆接口：移动应用门户客户端与原有客户端之间需实现单点登陆，用户点击待办事宜或者启动相应的业务应用时，原有客户端需为已登陆状态；
待办待阅信息同步接口：原有应用需将待办列表、待阅信息同步给移动应用门户平台，以支持其对待办待阅的整合；
3.5.2原有客户端改造
原有移动客户端需做以下两方面的改造：
启动时接受移动应用门户客户端传递的相关参数，将页面自动跳转到相应的待办处理或业务应用界面。
记录启动时跳转的页面，当用户在此返回时直接返回到原有门户客户端。
四、小结
本文分析了移动应用功能的三种分类，提出运营商移动应用门户的整合方案，并对三种分类的整合方式进行了说明，文中思路可为移动应用门户整合咨询设计方案做参考。
【关键字】 运营商 移动应用门户 应用
一、引言
目前电信运营商各省公司均在大力推进IT系统的移动互联网化改造，如电信公司的爱营销、爱运维、销售助手、数据门户手机版等，移动公司的CRM移动版、ESOP移动版等；但是在移动应用的开发过程中，一般各运营商都是由各厂商独立开发，缺乏统一的规划，多数内部用户需安装多套客户端，用于支撑日常的移动化办公，系统缺乏统一的移动应用入口、统一的应用发布、统一的安全接入服务。
二、当前移动应用所用的三种开发模式
2.1原生开发模式
原生应用程序是某一个移动平台（比如iOS或安卓）所特有的，使用相应平台支持的开发工具和语言（比如iOS平台支持Xcode和Objective-C，安卓平台支持Eclipse和Java）。原生应用程序看起来（外观）和运行起来（性能）是最佳的。
原生应用程序提供了最佳易用性、最佳特性以及最佳总体移动体验，诸如多点触控、快速图形API、内部部件（摄像头、地址簿等）等相关功能都智能通过原生应用来实现。
2.2 WEB模式
WEB应用程序使用标准的Web技术，通常是HTML5、JavaScript和CSS。这种只编写一次、可到处运行的移动开发方法构建的跨平台移动应用程序可以在多个设备上运行。虽然开发人员单单使用HTML5和JavaScript就能构建功能复杂的应用程序，但截至本文截稿时仍然存在一些重大的局限性，具体包括会话管理、安全离线存储以及访问原生设备功能（摄像头、日历和地理位置等）。
2.3混合模式
混合应用程序让开发人员可以把HTML5应用程序嵌入到一个细薄的原生容器里面，集原生应用程序和HTML5应用程序的优点（及缺点）于一体。应用可以通过容器来访问原生平台功能。
三、移动应用门户整合思路
3.1总体思路
纯WEB模式开发的应用可以直接通过PC版WEB应用的门户整合方式进行应用门户整合，但是目前各运营商移动应用众多，绝大多数都存在原生或混合模式开发的移动应用，故此无法简单的采用纯WEB方式进行移动应用的整合。
笔者将当前移动应用的功能进行了梳理，发现当前移动应用功能主要分为以下三类：
用户待阅：包括OA邮件、会议通知、系统通知等需要用户阅读而无需反馈的内容。
用户代办：包括流程审批、装维接单、计划任务等需要用户接受并反馈的内容。
主动应用：包括诸如业务受理、请假申请等需要由用户主动发起的内容。
根据上述分类，当前各类应用均可按照上述思路进行拆分整合，整合后的移动应用界面将如下图所示。
3.2待阅整合
待阅整合建议通过移动应用门户平台整合所有平台的待阅信息（包括通知、公告等）。
移动应用门户平台需提供模板定制功能，根据用户角色来定义要收取的待阅类型（如OA待阅、邮件、CRM平台通知、计费通知等），或者由用户自定义要获取的待阅类型。移动应用门户通过接口获取各个平台的待阅内容。用户登陆后，移动应用门户根据设置展示用户所对应的待阅内容列表，待用户点击后，门户应用直接进行待阅信息的展示。
3.3待办整合
考虑到各个应用待办功能的复杂性，待办整合可以考虑前期只实现统一的待办列表，待办的处理可由原有应用客户端来实现。同待阅整合一样，移动应用门户客户端需提供模板定制功能，实现待办内容类型的定制，门户客户端根据类型设置，展示不同类型的待办任务。
用户在门户客户端点击某一条待办信息后，门户客户端根据待办的类型启动对应的原有移动应用，并将此待办的相关参数传递给相应的移动应用，原有应用收到门户客户端参数后，直接进入待办处理页面，完成待办任务的处理工作。
3.4应用整合
各业务应用可由不同客户端实现，但建议通过移动应用门户实现统一管理、展现，以减少业务层级。如移动终端版CRM中存在业务受理、客户信息查询等相关应用，建议移动应用门户中应用的展示应该为业务受理、客户信息查询等，而不应该是移动终端版CRM。移动应用门户客户端同样需提供业务定制功能，支持页面展示的应用的自助化定制。门户客户端启动后，根据定制显示不同的应用内容。当用户通过门户客户端点击相应的应用后，客户端根据应用归属启动相应的客户端，并传入对应应用的参数。原有客户端启动后，根据传入的参数，直接转入相应的页面即可。
3.5其他改造要求
3.5.1 接口建设
移动应用门户客户端需要与原有移动客户端建设以下两个接口：
单点登陆接口：移动应用门户客户端与原有客户端之间需实现单点登陆，用户点击待办事宜或者启动相应的业务应用时，原有客户端需为已登陆状态；
待办待阅信息同步接口：原有应用需将待办列表、待阅信息同步给移动应用门户平台，以支持其对待办待阅的整合；
3.5.2原有客户端改造
原有移动客户端需做以下两方面的改造：
启动时接受移动应用门户客户端传递的相关参数，将页面自动跳转到相应的待办处理或业务应用界面。
记录启动时跳转的页面，当用户在此返回时直接返回到原有门户客户端。
四、小结
本文分析了移动应用功能的三种分类，提出运营商移动应用门户的整合方案，并对三种分类的整合方式进行了说明，文中思路可为移动应用门户整合咨询设计方案做参考。