Starring31功能扩展说明V12Word文件下载.docx
《Starring31功能扩展说明V12Word文件下载.docx》由会员分享，可在线阅读，更多相关《Starring31功能扩展说明V12Word文件下载.docx（13页珍藏版）》请在冰豆网上搜索。
V1.2
蒋岭
2007-7-25
增加新功能说明
目录
编写说明1
目录i
1.前言3
1.1.编写目的3
1.2.阅读建议3
2.Starring3.0VS2.04
2.1.定制平台结构更清晰4
2.2.开发和部署分开4
2.3.增加数据继承、映射功能4
2.4.增加公共流程（模板）4
2.5.流程定制平台实现4
2.6.新增设计文档导出4
2.7.新增调试功能5
2.8.强化平台监控管理，增加动态刷新功能5
2.9.多机协作和负载均衡功能得到完善5
2.10.增加自动任务、自动冲正服务5
2.11.平台与环境分开,平台安装自动化5
2.12.报文定制功能极大增强5
2.13.平台规范化、DTA/ALA标准化5
2.14.易用性、可扩展性更强6
2.15.路由功能大大增强6
2.16.日志更清晰6
2.17.复用和框架能力更强6
3.Starring3.0.1.1VS3.0.1.836
3.1.资源列表增加查找功能6
3.2.任务逻辑属性修改7
3.3.根据xml报文自动生成数据元素、报文定制7
3.4.标记集定制优化7
3.5.数据库3层封装扩展7
3.6.报文定制优化7
3.7.通讯接口导入优化8
3.8.用户密码加密8
3.9.定制资源锁定功能8
3.10.根据运行数据库表结构生成数据元素和报文格式的XML文件8
3.11.增量上线查询9
3.12.报文解析组织功能扩充9
4.Starring3.1VS3.0.1.839
4.1.多种部署方案9
4.2.变量池API扩充9
4.3.变量池内存优化9
4.4.运行平台变量池扩充10
4.5.元件定制10
4.6.增加项目公用节点10
4.7.定制资源分类10
1.Starring3.0VS2.0
1.1.定制平台结构更清晰
定制平台区分业务,子业务,公共资源等,使得开发资源结构变得清晰,不再是所以dta/ala混在一块。
另外,数据元素、处理函数等增强或者说真正使用了集合的概念，不再是所以数据元素、处理函数混在一起，检索起来更加容易；
更容易进行相关性检查；
更适合进行公共流程或者通用处理函数的定制/处理。
在eSWITCH2.0中，定制一个DTA是非常复杂的工程。
1.2.开发和部署分开
在eSWITCH2.0中，开发和部署都使用Escustomize，开发和部署同时进行，开发一个DTA是，就同时绑定了运行的参数和环境，不利于复用。
在Starring3.0中，开发时一般只涉及业务流程、通信格式等，至于DTA/ALA在什么机器上运行，以什么参数运行（如源DTA的端口、地址，并发数等，目的DTA的请求地址、端口等），则可以在部署时进行定制。
1.3.增加数据继承、映射功能
新增的数据映射功能，省去eSWITCH2.0中内部调用时，进行大量变量赋值或者拷贝的编码处理。
1.4.增加公共流程（模板）
使得流程定制可以复用，改变eSWITCH2.0每个服务都需要定制流程，或者大量编写服务处理逻辑的工作。
Starring3.0从理论上已经完全可以实现纯定制就完成服务逻辑。
流程定制部件分类明确化，如通信有通信部件，数据库操作有数据库部件，文件解析、组织有文件处理部件等，另外新增switch部件，在2.0中仅有判定（if,else）。
1.5.流程定制平台实现
eSWITCH2.0中流程定制是集成Visio（并且是不完全的集成），由Visio定制流程，并生成xml，然后导入到开发平台中使用，定制和修改极不方便。
1.6.新增设计文档导出
开发平台ESBuilder提供详细设计文档导出功能，导出各种设计要素的设计文档。
因此现在可以做完概要设计后，根据需求和概要设计进行定制开发，然后使用平台的文档导出功能导出详细设计文档，省略了详细设计文档编写的时间。
同时，如果定制有修改，可以重新导出文档。
以前先写详细设计文档（往往其实并不详细，只是名字“详细”），然后开发，如果有变更，要修改设计文档，同时修改定制。
现在则不需要这么麻烦了。
1.7.新增调试功能
开发平台提供了报文、流程以及脚本调试功能，运行平台提供了各种模拟器，更容易进行测试和验证。
1.8.强化平台监控管理，增加动态刷新功能
eSWITCH2.0平台监控和统计功能较弱，在Starring3.0中，esclient,estat等管理和监控统计工具功能更完善，管理功能增加业务参数、部署信息的动态刷新功能，监控功能可以看到各个DTA/ALA、服务、实例的运行状态，并增加运行统计信息如交易完成数、成功数、单笔交易最大最小耗时，总耗时等信息。
1.9.多机协作和负载均衡功能得到完善
在eSWITCH2.0中，多机协作和负载均衡功能并不完善，尤其是跨平台的协作和负载均衡有一定缺陷，在Starring3.0中得到了很好的完善。
1.10.增加自动任务、自动冲正服务
Starring3.0增加了自动任务、批量任务、自动冲正以及异步数据库操作服务，提高了开发了运行效率，业务开发也更容易。
更好的保证了数据一致性。
1.11.平台与环境分开,平台安装自动化
在Starring3.0中，平台基本环境分离（如中间件、数据库等），在安装平台时才根据环境配置增加数据库、中间件的库。
在eSWITCH2.0中，编译平台时就决定了使用什么数据库什么中间件，如ESLISEN,ESLISTEN_NOTUX分别表示使用TUXEDO和不使用TUXEDO的ESLISTEN版本，而在Starring3.0中不存在这种情况。
平台安装方面，在eSWITCH2.0中，虽然也提供了平台安装脚本，但由于eSWITCH2.0绑定了运行环境，导致安装脚本形同虚设。
1.12.报文定制功能极大增强
可定制流式报文、结构报文、xml报文和标记报文（如8583,类FML等）等几大类报文。
而对标记报文的支持，很大的提高了报文定制的便利性。
1.13.平台规范化、DTA/ALA标准化
包括平台模块化更清晰，接口、变量命名更规范。
平台提供更多实用接口。
扩充平台类别DTA无需编制DTA的流程代码，只需通过客户化通信API,并可以将新类别增加到定制平台中。
而客户化通信API平台也提供的模板。
因此DTA的客户化在标准化的基础上已经变得非常简单。
另外，在2.0中，基本上每个ALA都需要应用去写流程，即便有aps_init,aps_app_flow等一系列模板函数，但是增加一个ALA依然不是容易的事情。
毕竟在eSWITCH2.0中，ALA还是一个新事物。
但是在3.0中，ALA的定制就像DTA一样简单，除了客户化事件的处理，甚至于不需要编写任何代码就可以生成一个ALA（包括Makefile都是平台导出的，并且可以直接编译）。
1.14.易用性、可扩展性更强
平台提供DTA,ALA的规范和通用接口，使得用户更简单的客户化DTA/ALA。
在eSWITCH2.0中，光搭建一个运行环境就是一件非常恐怖的事情（至少对我来说是这样的）。
Starring3.0基本上可以做到开发、导出、上传、编译、运行这样简单化的环境搭建流程。
1.15.路由功能大大增强
增加了交易码路由，并由路由决定同步、异步通信方式。
也就是说同一个DTA，对于不同的服务，他可能是同步DTA，也可能是异步DTA，这可以根据服务的路由定义来决定。
1.16.日志更清晰
日志文件进行了拆分，并可在运行过程中进行动态控制；
日志内容更清晰，查错更方便。
1.17.复用和框架能力更强
在Starring3.0中，因平台功能更强大，框架结构清晰，开发更规范，因此应用开发的复用能力更强，目前产品维护组和一些项目组已经整理了一些高复用性的模块，并编译成libblk.a，提供源代码。
内容包括响应码转换、流水号管理、重控管理等。
而在同一行业项目中，应用包也经常被复用。
2.Starring3.0.1.83VS3.0.1.1
2.1.资源列表增加查找功能
增加了资源列表全局查找功能，点击Ctrl+F弹出“查找”对话框，输入查找的内容和类别，点击“查找”即可，查找结果将在下面列表列出，双击列表中的某个定制项将定位到资源列表上该资源的具体位置。
2.2.任务逻辑属性修改
任务逻辑增加超时时间属性，防止任务调度时出现AUTOTASK接收响应超时、响应队列堵塞的问题。
2.3.根据xml报文自动生成数据元素、报文定制
编写工具程序，用于自动根据xml报文，生成相应的数据元素、报文格式的xml文件，供开发平台直接导入。
生成的数据元素类型默认采用字符串型，长度、精度等由使用者自行修改。
开发人员可以通过编写一个标准的xml模板文件，提供给工具程序，完成xml定制的自动生成，减少定制开发的工作量。
2.4.标记集定制优化
标记集列表提供重新排序功能，便于查找标记集中的某个标记，但是重新排序应当不影响真正的顺序。
增加查找输入编辑框，将要查找的某个标记名称输入到编辑框，将自动定位到列表上的复合查找条件的第一个资源，每输入一个字符就定位到名称符合的第一个标记的位置。
2.5.数据库3层封装扩展
由于SQL语句只有输入部分，可以动态由$数据元素或$$FORM的方式，存值到SQLDA区中，应用有表名、查询条件需要动态变化的需求，这时必须使用表达式或程序拼装SQL语句，通过扩展3层封装，使用@数据元素的方式，支持SQL语句替换成指定数据元素的值。
如：
select*INTO$$@BkTabNamefrom@BkTabName，运行时数据元素值为t_jrnl，经过3层封装转换，提交的动态SQL语句为：
select*INTO$$T_JRNLfromT_JRNL。
对于DB2/oracle数据库，不支持updateT_JRNLset（*）=（$$T_JRNL）的语法，必须列出T_JRNL表的所有字段，通过扩展3层封装，使用@@FORM的方式，支持SQL语句替换成指定FORM字段列表，如：
updateT_JRNLset@@T_JRNL，提交的动态SQL语句为：
updateT_JRNLsetPLAT_DATE=$T_JRNL_PLAT_DATE,SEQ_NO=$T_JRNL_SEQ_NO…。
2.6.报文定制优化
目前报文格式定制中格式项的定制，记录数是下拉列表形式，当数据元素过多，或数据元素名称过长时，查找十分费时。
将格式项定制中的记录数下拉列表变成编辑框，在编辑框后面添加“…”按钮，点击“…”按钮弹出数据元素选择框，用户可以选择所需要的数据元素，也可是直接在编辑框中输入数据元素名称，在保存定制信息时，增加程序校验数据元素的完整性，防止手工输入出错。
2.7.通讯接口导入优化
目前通讯接口DTAParam.xml文件导入时，会将原有的DTA节点信息全部删除后重新导入，致使ESConf中的节点定制信息全部被删除。
修改DtaParam.xml的导入，导入节点信息时不删除全部节点，而是根据XML的节点信息进行修改，增加操作，对已经不存在的节点信息才进行删除操作。
2.8.用户密码加密
增加用户密码加解密处理，在数据库中存放秘文。
用户可以自己设置密码加密密钥，如果不设置密钥，数据库中将继续存放明文。
2.9.定制资源锁定功能
定制资源锁定功能。
在资源列表的上点击右键弹出菜单，选择“加锁”或者“解锁”进行操作。
当前登录的普通用户只能锁定或解锁自己定制的资源，不能给其他用户定制的资源加锁或解锁，管理员用户可以给任意资源加锁和解锁。
在加锁后的资源前面出现“锁”的图标，没有加锁的资源显示的是“钥匙”的图标。
2.10.根据运行数据库表结构生成数据元素和报文格式的XML文件
根据运行数据库表结构和表字段，生成数据元素和记录格式的XML文件。
数据元素的默认命名规则是大写的“表名”＋“_”＋“字段名”，记录格式的默认命名规则是大写的“表名”。
2.11.增量上线查询
增量上线查询功能，查询某一选定日期后的资源修改情况，双击查询结果可以定位到资源列表查看具体的修改，并且可以导出该日期后修改的资源。
2.12.报文解析组织功能扩充
在维持原报文定制的基础上，可解析多重循环报文到变量池中。
3.Starring3.1VS3.0.1.83
3.1.多种部署方案
目前企业应用配置器（ESConf）只支持一种部署方案，当实际需要多种部署方案（如两组分开测试、或者测试部署和生产部署并存的情况）时，常常需要手工修改部署文件ESAdmin.xml，不太方便。
现修改ESConf，使其支持多个部署方案，配置管理和导出导入按照部署方案进行管理。
3.2.变量池API扩充
在保留原二维变量池的基础上，扩充多维变量池操作的API。
3.3.变量池内存优化
优化变量池模块的内存分配使用，减少内存碎块、分配次数，提高效率。
1．修改ep_reset_ep函数，对于已经有值的数据元素，保存数据结构数组，释放DEFTLEN以上的下标数组空间，保留0下标的数据指针，释放0下标DEFTLEN以上的数据空间。
2．修改变量池打包函数，预分配一块内部内存，存放临时数据，不再反复分配、释放内存。
如果预分配空间不够，内部自动扩展。
3．修改变量操作登记，分配过的操作记录保留50个，不全部释放，数据值预先按DEFTLEN分配好空间，不够再扩展，保留的50个操作记录只释放DEFTLEN以上的数据空间。
4．ESConf增加一个参数，需要压缩报文长度，默认4096，即交换时报文长度超过4096，才调用压缩算法。
3.4.运行平台变量池扩充
将Starring3.0变量池由2维扩充为多维，并在报文处理模块中支持二重或多重循环的报文解析和组织。
3.5.元件定制
可以封装元件，供服务逻辑/任务逻辑使用。
元件在注册C函数基础上，增加了输入、输出、内部数据元素的列表定义，可以使用元件映射完成输入、输出的加工处理。
元件限制了输入、输出数据元素，接口明确，修改和调用可控。
3.6.增加项目公用节点
项目公用资源节点是一个整个项目的公用业务节点，在此节点下定义的内容在整个项目中可以使用。
针对应用框架的功能可以定义在项目公用节点下，而以前必须放在平台级，没有项目公用。
项目公用节点可以逐步固化一些常用服务元件。
3.7.定制资源分类
在资源的一个节点下，还可以根据各种使用范围，划分集合，再次分类。
对于集合较大、差异较大的定制节点，通过集合划分，有效分解定制要素。
3.8.格式报表定制
定制报表格式，根据定制完成后台报表的生成。
避免了程序画格式，分离数据准备和报表展现。
3.9.枚举类型定制
可以定义枚举列表和转换关系，方便响应码处理。
3.10.多数据库支持
在ESConf中配置多个数据库连接信息，可以针对系统、机器、插件，选择需要连接的数据库，改变了原来整个平台只能连接一个数据的问题，可以根据需要连接多个数据库进行操作。
3.11.集成开发
在ESBuilder中增加了对客户化文件的管理和编辑功能，使得原来在运行环境下编辑和管理的客户化文件能够通过ESBuilder统一的管理和维护，并且可以通过ESBuilder完成对客户化文件的编译。
3.12.版本管理
在ESBuilder中增加了对版本管理工具客户端命令的调用功能，使得对客户化文件和定制信息的XML文件的版本管理和维护可以在ESBuilder中自动完成，减少了版本管理的手工操作，并充分保证了对XML文件和客户化文件版本的有效管理。
3.13.增量部署
在ESBuilder中增加了用户所属组的管理，用户修改的资源会被标记为其所属的组所有，导出时可以按照资源所属的组进行增量导出，从而实现的以组为单位的增量部署。
以组方式进行增量部署，可以避免原来以修改时间进行增量导出时把不需要导出的资源导出和无法准确确定需要导出资源的修改时间段的问题。
3.14.优先级控制
在平台中增加了交易优先级的控制机制，将交易划分为5个优先级，1级最低，5级最高，优先级高的交易会得到更多的系统资源进行处理，并且在平台队列中会被优先取出进行处理，从而确保高优先级交易的高效处理。
优先级可以静态设置也可以根据情况动态改变。
3.15.并发数控制
平台增加了对系统处理的交易流量的控制，通过设定目的方适配器的最大并发数控制进入系统中的交易数量，超过并发数的交易会被系统直接拒绝，从而提高系统的抗冲击性和稳定性，避免由于大量交易拥塞造成平台瘫痪。
平台提供了居于优先级的通道并发数控制和客户化并发数控制两种控制机制。
3.16.超时控制
平台改变原来每个适配器单独配置超时并进行控制的做法，改成有源方统一进行控制，源方将设定的超时减去自身处理的耗时作为下一个目的方的超时通过DRQ传送给目的方，目的方使用从DRQ中得到的超时进行目的方处理的超时控制，目的方再向下一目的发送请求时同样会将源方传送的超时减去本环节的耗时作为下一目的方的超时，同时发送前会检查剩余的超时时间是否小于统计的最小交易时间，如果小于则不再发送请求，直接向源方返回请求失败的错误。
3.17.故障客户控制
对于平台需要请求的某个外部服务系统出现故障交易无法正常进行的情况，平台增加了故障客户控制机制，对于出现故障的外部系统，平台会将故障的外部系统进行登记，并控制发送到此外部系统的最大并发数为1，超过的交易都会被平台直接拒绝，确保平台资源不被故障系统的交易过多占用，并最大限度减少交易异常引发的冲正。
当故障系统恢复正常后平台会将故障系统的最大并发数恢复正常，并从登记表中删除故障系统，从而使恢复正常后的外部系统的交易正常进行。
3.18.异步全双工DTA
平台提供了与外部系统采用同步方式通讯但自身处理流程采用异步进行处理的异步全双工DTA。
使用异步全双工DTA可以大幅减少需要的DTA实例，节约系统资源，并提高DTA的处理能力和抗冲击能力。
升级会员 