U9研发体系(BP服务开发手册)

U9 BP服务开发指南
文件编号：
版本号： 1.0
修改状态：0
编写人：祁宏伟
审核人：
适用对象
该规范适用于U9所有BP和服务的开发人员
版本记录
【此部分要记录该文档形成过程中的历次版本变更过程及变更的内容】
版本修改与
参与人
修改时间修改原因修改概述审批人
1.0 祁宏伟 2008-7-10 原始版本创建
1.1 祁宏伟 2008-7-30 增加模型设计，调整格式
相关文档
名词解释
BP： business operation 业务操作，指一个业务操作单元．可以理解成一个有平台元数据和框架引擎支撑的业务方法．
主要用于对于UI调用后台的业务数据操作和后台业务操作的逻辑封装． SV：服务，和BP一样同样也是业务操作单元， 但服务从设计上是用于为外部服务组外部应用提供的业务接口，可以进行webService发布．
U9中使用BP和服务的主要场景：
对于支持IIS和应用服务可分布的场景，UI在IIS服务器，调用应用服务器的处理必须要走BP，来支持跨进程，机器调用．此时该BP主要用于对UI的数据请求作处理和返回．对于应用服务间业务逻辑的处理过程中，常常有需要对业务逻辑进行一定的封装，此时用BP封装业务逻辑，主要是包装多个业务操作，提供功能接口．
对于服务，只用于跨服务组，跨组织，跨Site情况下的业务功能接口访问．
手册正文
1BP，SV模型设计：
BP与SV的模型设计是一样的，下面用BP的模型来演示．
1.1创建BP项目
打开UBF，解决方案中右键 “Solution’demo’”弹出菜单选择新建
弹出创建对话框
1.选择区域1操作项目 BP
2.项目名称 SubmitSOBP
3.点击确定保存退出
这时解决方案中就多了一个项目” SubmitSOBP.ubfb”
1.2 设计BP
第一步: 双击SubmitSOBP进入BP设计区
第二步: 拖入操作BP
从工具箱中选择‘操作’拖入工作区中如图区域2所示修改操作属性名称为SumitSO
显示名称为审核
第三步新增BP传入参数
在模型图中选中BP，在详细信息视图中添加传入参数
类型的设置，同实体的设置方法一样
第四步 设置BP属性
选中BP, 点属性窗口
1．修改名称
2．修改显示名称
3．修改返回类型，在这里默认为空类型，也就是V oid型
4．是否是实体的主键
5．事务类型选择
6．是否需要权限的控制。

第五步引用实体
如果在一个解决方案中可以拖动下图区域1到区域2 Reference中
第六步引用实体
如果不在一个解决方案中我们可以在发布浏览器中找到PMBE,BaseBe,PubBE拖入Reference
在后边的开发中会用到两个实体
拖入后如下图所示
2BP，SV模型概念：
2.1 BP,SV的模型区分：
目前，BP,SV在元数据模型上是同一模型，仅靠一个是否服务的元数据标识来区分。

并通过IDE建的项目文件来控制。

BP项目中只能建立BP操作。

SV项目中
只可以建立SV操作。

一般来说，同一个服务组的SV项目是引用BP项目。

但BP项目不会引用SV 项目。

BP主要用于本服务组的业务操作单元，并且一般给UI使用，而SV是对外
部服务组，或外部组织可见的服务。

2.2 BP,SV的元数据模型：
扩展属性中异常：该BP,SV可能会报出的异常类型。

目前没有使用，无用状态。

返回类型： 目前基本上的类型都可以作为返回类型。

并且支持集合。

实体主键：当返回类型为实体或实体集合类型时，该项可用。

表示返回的实体的
KEY。

事务类型： 具体参考持久化事务文档。

是否权限控制： 是否进行权限控制。

2.3 BP,SV的属性和实现策略：
BP,SV的属性是作为其传入参数，调用BP,SV时，给属性赋值，在实现方，使用其属性来进行逻辑处理。

BP的属性支持几乎全部类型。

具体类型问题参见下面
代码构架。

实现策略：是BP,SV的一种实现，目前支持添加多种实现策略。

2.4 版型的支持：
BP,SV支持应用版型，但版型的支持依赖于TPL上的特殊处理。

所以，目前TPL上已经支持的特殊版型有：
查询BP版型：用于标识该BP为查询BP,用于查询列表生成特殊代码片断。

不明BP类型注册版型：用于在BP，SV使用OBJECT类型时，INDIGO需要其显示注册其中可能的类型。

生成代码时，会生成INDIGO标签标明其中注册的
类型。

3BP，SV代码框架：
3.1 调用方式：
目前BP,SV支持本地Local和远程Agent两种方式来调用。

本地调用方式示例：
GetDateExchangeRate getDateExchangeRateBP = new GetDateExchangeRate();
getDateExchangeRateBP.FromCurrency = ..;
getDateExchangeRateBP.ToCurrency = ..;
ExchangeRateDTO rateDto = getDateExchangeRate.Do();
代理调用方式示例：
GetDateExchangeRateProxy getDateExchangeRateBPproxy = new GetDateExchangeRateProxy
();
getDateExchangeRateBPproxy.FromCurrency = ..;
getDateExchangeRateBPproxy.ToCurrency = ..;
ExchangeRateDTOData rateDtodata = getDateExchangeRateBPproxy.Do();
3.2 生成的代码项目和类型：
3.2.1 每个BP,SV都会生成３个项目：
**.Deploy 部署项目
**.Agent 代理项目
** 实现项目
Deploy项目中为异常，DTOData等类型，作为BP的Agent和实现项目都需要使用和依赖。

Agent和实现项目相互不依赖。

3.2.2 每个BP,SV都会生成5个相关类型．例：CheckOrder
ICheckOrder : BP,SV的接口类型，同时存在于Agent和实现两个项目中，用的相同的Indigo契约标签ServiceContractAttribute().
CheckOrderAgent : 代理类型，用于远程调用时，使用该类型实例化并执行其Do().
CheckOrderStub : 代理调用的桩.用于与代理调用的通讯．并处理与本地调用的接口类型转化处理．
CheckOrder : 实现类型，用于本地调用时，使用该类型实例化并执行其Do().
CheckOrderImplement :生成在实现项目的Extend文件中，仅此是由开发需要实现BP,SV的实现策略．在Do()方法中编写业务逻辑．
ICheckOrder是将BP属性扁平为一个Do()带参数的方法，将BP属性作为传入参数，BP返回值为方法的返回值。

所以，不要考虑将BP的属性当成返回值来使用。

CheckOrderAgent和CheckOrderStub均实现了ICheckOrder接口。

3.3 多实现策略的支持：
在BP,SV模型上画上多个实现策略，生成的代码中就会有多个实现策略类，但是注意，由于该部分是生成在Extend中，所以，如果Extend代码已经改写存在，那就不会再生成覆盖．
实现策略类可以在模型设计时，选择其哪个为默认的实现策略，生成的代码中会默认调用其策略．该逻辑也在Extend中．
实现策略的选择是可以用代码逻辑来处理，可以直接选择某个实现策略，也可以添加你的逻辑来决定使用哪个实现策略．
public partial class CheckOrder
{
internal BaseStrategy Select()
{
//可以在此处直接选择某个实现策略，也可以添加你的逻辑来使用哪个实现策略．
return new CheckOrderImpementStrategy();
}
}
3.4实现与代理的类型处理：
对于实现调用和代理调用，其接口类型是不一致的。

原因是：对于实体，枚举,DTO等类型在服务端和客户端类型都不一样。

实体在客户端不可见，只能见到实体Data。

所以同样对于BP,SV的属性也就有不同接口类型。

对于BP,SV的实现代码，只针对实现编程，对于调用代理类型转换成服务端实现类型，由Stub类型负责处理其转换。

包括将EntityData与Entity互转等。

具体类型变换见下表：
BP、SV、DTO属性和中的设计的类型，在服务端与客户端的代码生成类型：模型中数据类型服务端(BE,或者BP实现的dll
中)
客户端（Deploy的dll中）简单类型相同相同
实体实体实体的Data
实体.Key 实体.Key long
通用实体通用实体通用实体Key
值类型值类型值类型的Data
数据传输对象数据传输对象数据传输对象的Data
可扩展枚举可扩展枚举对象普通枚举对象的int值
实体集合 Entity.EntityList IList<EntityData>
非实体类型集合 IList<类型> IList<Data类型>
其它非UBF支持类型Extend中可手工扩展（无法传
递到客户端）
目前无法生成
4服务的跨组织与跨Site调用：
目前只支持服务的跨组织和跨Site调用，BP不支持。

4.1跨组织服务的接口，代理类中增加的接口
public void Do(long targetOrgId)
调用的时候，将目标组织作为参数传入。

当目标组织与当前组织相同时，不进
行处理。

当成普通服务方式调用。

注：当前组织是从 ID中获取。

跨组织调用时，代码执行到Stub服务端，将会做一个当前组织切换的处理，将调用所传的目标组织切换成当前组织。

同时当前上下文也会做切换。

并
进行序列化Key处理。

4.2跨Site调用接口
public void Do(string targetSite)
跨Site调用是不进行组织切换，但是要进行site变换，可能要进行数据库的从新获取ID进行序列化处理，目前只用于Base的下发复制基础数据。

4.3跨组织,site时序列化处理机制
跨组织，Site调用时，最主要的一个工作是要进行数据序列化和反序列化。

原因：
由于U9基于多组织的系统.不同的组织可能会在不同的Site上并有不同的数据库…所以档案在不同的组织下是有不同的ID.
这在多组织的服务调用时,基于ID的数据传递调用就是不正确的.基础档案在不同的组织中,按下发复制的逻辑创建.要保持业务主键不变.
UBF提供了在跨组织调用时,自动将ID的数据序列化业务主键数据. 在目的组织方,再将业务主键数据再反序列化ID,来保证调用的正确性..
4.4调用过程举例说明:
例: AAASV 有一参数为 ItemMaster.EntityKey 返回类型为Warehouse.EntityKey
1. 调用方: 传入为LONG型 ItemMaster的ID . 返回当前组织的
Warehouse的ID.
2. AAASVAgent在调用组织处,将ItemMaster的ID,找到相应的ItemMaster
实体,将其序列化为业务主键数据.Org+Code.
然后,将其Org替换成目标组织ID .存入ItemMaster_SKey 中. (目前生成的代码中,EntityKey类型都会生成一个_SKey的属性,专门用于
传递序列化字段数据)
在目的组织AAASVStub服务端. 在得到序列死字段ItemMaster_Skey后,将按其业务主键数据作一个Finder查询.如果查询结果返回
0个或者是超过1个,均认为是错误数据情况…
服务端执行完成后,返回Warehouse.EntityKey 同理处理.将其序列为业务主键.
在AAASVAgent返回处,将 Warehouse.EntityKey 的序列化字段作一个Finder,返回该组织下的ID .
4.5其他相关说明:
1. 此处所说的业务主键实际上目前的UBF做法是取实体唯一索引的第一
个.(实体默认第一个唯一索引是自动根据业务主键生成,可手工调整)
2. 对于参数或者返回类型是DTO,Entity的,将会递归处理其中的每一项属性,
为Key的进行序列化和反序列化..
3. 对于任何档案或者单据,如果其业务主键中没有Org类型的,则不会进行相
应的目的组织替换,也就是序列化和反序列化结果ID还是一样的.
4. 对于业务主键为另一个实体时,将会递归序列化该实体ID.
5 BP,SV的AOP框架支持：
BP,SV的实现策略类ImplementStragy是继承于基类的BaseStrategy,通过该类上的Execute方法上对Do()方法进行了A OPService.PreProcess和
AOPService.PostProcess 的调用前和调用后的横切面处理。

UBF目前使用标签Attribute的机制来进行AOP的处理。

已经实现的Aop标签的功能有事务，LOG，权限。

具体参见事务，权限等文档。

支持客户AOP注入：
只要实现UBF的基类AOPAttribute，再用版型在BP,SV上添加相应的AOP标签，
就可以实现客户化的AOP注入。

6 U9服务引擎：
6.1 U9的引擎进程：
IIS进程：Portal所在进程。

主要部署webpart，及BP的代理。

服务引擎进程： ApplicationServer进程，在Portal的ApplicationServer目录下。

负责挂载应用服务,应用服务器端。

主要部署BE,BP,SV的实现。

系统管理进程： SysManageServer进程，提供系统管理服务，获取企业连接，
Lincense服务等。

UBFEngineHosting.dll.config 是服务引擎配置的主要文件之一。

对于单机版本或者
服务器版本，都会有不同的配置。

6.2 U9系统引擎配置：
Engine节的配置是配置当前服务进程要挂载的服务引擎。

对于单机版本配置：
大部分的引擎（包括服务引擎）都是直接挂载到IIS进程中直接执行。

目前只有JOBEngine是在ApplciatonServer的进程中。

<Engine name="JobEngine" factoryType="UFIDA.U9.BS.Job.Engine.JobEngineFactory, UFIDA.U9.BS.Job.ServiceEngine.dll" factoryMethod="CreateInstance" />
SysmangerServer中配置了系统管理引擎和License引擎。

<Engine name="SystemManageEngine" factoryType="UFIDA.UBF.SystemManage.SystemManageEngine,
UFIDA.UBF.SystemManage.Service.dll" factoryMethod="CreateInstance"/>
<Engine name="License" factoryType="UFIDA.U9.BS.LicenseMgr.LicenseEngine,UFIDA.U9.BS.LicenseMgr.dll"
factoryMethod="CreateInstance" />
所以对于单机版本，一定要启动SysmanagerServer进程，用于来获取系统管理提供的服务，否则无法获取企业连接等信息。

而JobEngine所在的ApplicationServer
可以不用开启。

对于服务器版本配置：
包含服务引擎等大部分引擎是配置在ApplicationServer进程中。

系统管理和Lincense引擎配置在系统管理SysManagerServer进程中。

6.3 Provider的配置:
Provider是配置UBF的引擎中一些接口服务的提供者。

单机版本和服务器版本也会有不同的Provider配置方式。

6.4 代码生成的配置文件：
对于BP,SV均是通过Indigo来实现远程调用，目前通过ubfsvc的配置文件来进行BP,服务的挂载。

所以，新增的BP,SV一定要将相应的配置文件拷入到ApplicationServer的libs 下，使期能够加载起该BP,服务。

*.svc配置文件是针对单机版本的情况下，将服务挂载到IIS进程中，让其它进程可以调用的配置文件。

7 BP,SV的装配与部署
7.1 装配
新加的BP,SV必须要进行装配，并将其加入某应用中。

在代理方式调用时，系统管理检查，会先检查该BP,S V有没有加入应用或者所在的应用没有启用，如果失败，则会直接返回空的channel.整个调用就会返回default<返回类型>.
所以编写相关应用代码时，也需要注意，要用调用的服务是否存在的可能性逻辑，如果不存在，代码要有相应的兼容性。

具体装配使用－参见装配文档
7.2 dll部署位置：
Portal(客户端) ApplicationServer服
务端
说明
UI开发的webpart 部署无可以引用服务组的
Deploy,Agent中的类型，进
行编程。

组件开发的
Deploy，Agent
部署部署
组件开发的BE,BP实现无部署可以引用本服务组内的BE
和BP，服务实现，以及其它
服务组的BPAgent，Deploy.
Base,CBO_PUB,CBO_领域 组件概念上隶属于任何服务组。