目标管理大前置的目标功能模式.docx
《目标管理大前置的目标功能模式.docx》由会员分享，可在线阅读，更多相关《目标管理大前置的目标功能模式.docx（11页珍藏版）》请在冰豆网上搜索。
目标管理大前置的目标功能模式
（目标管理）大前置的目标功能模式
1大前置的目标功能模式
2
3
3.1大前置系统的建设目标
3.2
3.3
⏹整合各类功能的前置
⏹
⏹
目前建设银行内普遍的前置的功能，可分为以下几种类型：
1）外联交换型：
以联网交易为主，如异地卡/金卡工程、电子汇划、SWIFT、人行支付等。
2）
3）
4）终端驱动型：
以专用终端的管理和控制为主，如网点终端、ATM、Kiosk、POS、查询补登机、电子汇单等。
5）
6）
7）增值服务型：
如CallCenter、网银、企业银行等
8）
9）
10）中间/特色业务型：
如代收付、外汇买卖、银证卡折炒股、代办保险、代缴税款等
11）
12）
13）全国性业务前置系统：
如国际业务开放式基金代理、综合报表系统等
14）
15）
毕博认为：
2）终端驱动型和3）增值服务型的前置功能，能够统称为设备前置，应该整合到大前置系统，而其他前置功能，建设银行能够考虑整合到信息总线。
对于规划中之所以将设备前置放于大前置中，而不是和其他前置功能壹起整合到全行的信息总线，这里要做壹个简单说明：
从逻辑和理论上来讲，为了结构清晰，设备前置应该是由整个信息总线来完成。
可是于目前的情况和实际应用中，由于我们要保证建设银行交易的效率，我们应该将设备前置单独提出来，因为大前置涉及到大量的交易处理，需要的是快速反应，所以我们应该单独从专有技术，主要是TPMonitor中间件，例如Tuxedo和CICS来实现设备前置。
于逻辑上我们能够将它当作信息总线的壹部分，于物理上，它归属于大前置，而大前置系统接入全行的信息总线（参见规划总图）。
目前的信息总线的其他部分包括工作流仍是用于实现那些异步方式，系统交互要求高的功能。
当然，我们仍是要求设备前置要和整个信息交换平台的其他部分有良好的接口，以便实现壹些和设备前置有交互的功能。
于可预见的将来，等系统性能提高后，我们再将设备前置于物理上和信息总线的其他部分融为壹体。
⏹支持多通讯协议（如SNA、TCP/IP、MQ等），提高和外部系统的连接能力；支持多报文种类、格式（如SWIFT、ISO8583、XML等），且通过报文转换来完成外部报文和内部报文之间的转换，且留下有关的痕迹以便勾稽核对；且含报文字段检查功能
⏹
⏹
⏹交易预处理能力使分行能够于提交主机前进行壹些简单而非业务性的处理，减轻主机的压力；支持统壹的外部系统接入点，使不断增加的外部接口不会对主机系统造成压力；本地交易的处理平台使前台以至后台的处理能够更有规范的进行，提高系统的整体性能
⏹
⏹
⏹进行交易流程定义/控管；支持进程定义，以配合把复杂的处理流程进行进程分解，且提高进程的可重用性
⏹
⏹
1）标准的交易控管能够更有效的实现银行的安全机制（如复核、授权等）
2）
3）
4）标准的异常处理让用户更容易掌握系统所发生的问题，且且更快的处理已发生的异常情况
5）
6）
⏹可扩充性及可维护性使系统能够更容易的作出功能上的提升，更灵活的面对同业的挑战
⏹
⏹
⏹业务前置机功能使系统能够发挥业务前置机（如银证转帐、代收付业务、代理业务等），简化分行系统的维护工作量，且能够更有效的使用计算机资源
⏹
⏹
因此，简言之，建设银行大前置系统的实现目标是：
实现高效、稳定的信息交换；支持多种协议和数据格式的转换；提供应用的路由选择和交易的组装、调度、完整性壹致性控制；进行文件传输和安全加密等功能；支持多样性的中间业务的整合；支持多种外联系统的接入；支持柜面、ATM、POS等自助设备，callcenter、网上银行等多渠道服务；支持信息服务、报表处理、系统监控、安全控管等功能；支持多机负载均衡，具有进程动态伸缩控制；最终建立集信息交换、业务整合、渠道整合、信息服务等功能的结构化、参数化的整合性平台。
大前置架构说明
3.4
交换及应用服务系统实现协议转换、加密处理、安全管理、报文转发、文件传输、交易组合、提供外围系统接口等功能，负责交易完整性控制；于交易同时登记交易流水，为主机故障时应急支付提供可能。
渠道整合系统连接现有各种金融电子服务渠道，以及外连单位系统。
中间业务系统负责完成各项中间业务的预处理以及和外单位的联机处理和日终批处理。
信息服务系统负责接收关联帐本数据、生成报表且拆分下发、存储各项管理数据，且于此基础上提供各种管理信息服务。
监控管理系统负责对系统运行情况及业务运行情况的监控，为系统的运行管理提供手段。
Web-svr服务系统提供具有灵活扩展性的、符合J2EE技术标准的、对浏览器等图形化界面提供支持的服务系统。
配置管理系统对前置系统进行资源配置和系统维护。
大前置系统功能说明
3.5
⏹协议转换
⏹
⏹
1）前置系统和前端（包含自助设备）或外部系统之间的通讯连接采用TCP/IP协议；
2）
3）
4）前置系统和主机之间的通讯应当支持SNA、TCP/IP等通讯协议。
同时实现ASCII码制和EBCDIC码制之间的转换。
5）
6）
⏹交易组合
⏹
⏹
为满足分行本地特色业务的需要，前置系统应具备快速封装交易的功能，能够将复杂的业务功能通过多个主机系统内部交易的组合或主机内部交易及外部系统交易的组合的方式实现，以达到迅速适应业务需求的目标。
且且交易组合的实现过程应当保证交易的壹致性和完整性。
⏹版本控制
⏹
⏹
1）前置系统应当能够自动接收数据中心下发的新版本自动进行更新，且能够保证不影响分行自行扩展的功能。
2）
3）
4）前置系统应当能够主动下发端末的新版本，同时能够控制版本下发的结果，版本生效时应当能够检查端末的应用版本是否正确。
5）
6）
⏹对外接口
⏹
⏹
前置系统应当具备完善的外部系统接入功能，能够将基于不同通讯协议下的多种报文格式转换成内部统壹的报文格式或进行反向转换，且进行报文转发；同时能够根据业务的拓展，通过可视化开发的方式，方便灵活的扩展和外部系统的接口。
于通讯协议上，能支持同步、异步等多种通讯方式。
⏹中间业务
⏹
⏹
前置系统中，应当构建处理中间业务的应用平台，通过对中间业务处理模式和流程的归纳统壹，将繁杂的特色业务处理屏蔽于主机系统之外，而仅通过统壹规范的帐务接口和主机系统发生关联。
同时，中间业务平台所处理的业务项目应当是可定制的，能够通过可视化的集成开发环境进行二次开发，方便的添加新交易和新业务品种。
另外，于中间业务平台的设计和实现上应当充分考虑系统的可移植性和可靠性。
⏹web-teller
⏹
⏹
由于个人理财等业务逐渐对界面表达提出了更高的要求，需要现有的系统能够兼顾支持传统的字符界面和功能更强的图形终端及和之相连的外设机具，因此，前置系统中应当具有对图形终端方式的支持和管理功能。
⏹文件传输
⏹
⏹
基于分行信息管理的需求，前置系统应当提供接收数据中心下传的大数据量文件且存储和下发二级分行的功能，通过文件压缩、断点续传等方式，提高数据传输时效，满足业务管理需求。
⏹管理报表
⏹
⏹
提供管理报表所需要的数据源，从而满足各级分行或外系统对各种管理信息自行定制、生成的需要。
⏹系统管理
⏹
⏹
前置系统中需要提供监控平台，分别从系统运行情况和业务运行情况俩方面，使用开放式的设计方式，提供对整个前置系统于不同层面，不同区域的运行监控功能，实现对整个前置业务系统的信息采集、汇总、分析，协助系统运行人员和业务运行人员快速的发现问题，且提供长效管理决策的依据。
⏹安全管理
⏹
⏹
前置系统应当于数据传输过程中对数据进行基于可靠安全算法的数据加密解密，且提供相应的密钥管理功能；同时实现对各种类型的前端的身份合法性认证控制。
⏹系统恢复方案
⏹
⏹
前置系统的设计和部署应当能够通过群集技术、均衡负载技术等，于局部设备或应用系统出现异常的情况下能够由部署于其他设备上的系统进行自动接管，保证系统的安全可靠连续运行。
前端设备
3.6
这里仅就建行的前端柜员系统进行讨论：
目前建行的前端柜员系统主要是基于SCOUnix终端方式，而图形化界面尤其是浏览器方式是今后前端系统（尤其是低柜）的发展方向，设计的前端系统应支持三种模式（主要是前俩种）：
（1）基于PC的浏览器方式
（2）基于ScoUnix终端（DummyTerminal）的字符界面方式
（3）前端是基于C/S机构的图形化界面
因此，柜员系统应仍以支持SCOUNIX终端为主。
技术考虑事项
3.7
整体系统性能
系统的可扩展性
高可靠性及高可恢复性
冗灾备份及恢复能力
端到端的系统管理
系统安全性
投资保护及降低业务风险
总体成本
升级会员 