ESB部署WebService接口统一用户和待办Word下载.docx
《ESB部署WebService接口统一用户和待办Word下载.docx》由会员分享，可在线阅读，更多相关《ESB部署WebService接口统一用户和待办Word下载.docx（25页珍藏版）》请在冰豆网上搜索。
8080/jicpending/services/IPandingInterfaceWebservice?
wsdl
服务文件：
服务方法：
方法1.
putPandingInfo：
新待办
方法2.
changePangdingStatus：
当OPTTYPE值为2时，则表示修改待办，当为3时，则表示删除待办
方法3.仅供OA系统使用
.putOaPandingInfo：
新待办，
方法4.仅供OA系统使用
changeOaPangdingStatus：
当OPTTYPE值为2时，则表示修改待办，当为3时，则表示删除待办，仅供OA系统使用
服务参数：
具体定义如下表表描述1
1.5.2新待办
第一步：
应用系统有新待办信息时，调用门户系统接口，将数据传送给门户系统提供的接口，流程如下：
WebService接口图
在此过程中，各个应用系统以传递对象的形式传递参数，提供的参数自身包括的值为以下表说明，另外，OA系统传递参数的时候不用传递对象，只要依次传入以下表说明即可。
属性名
说明
类型
长度
备注
OPTTYPE
待办操作类型
String
10
只出现数值型字符，分别代表1:
add2:
modify3:
delete,此外，修改操作时只修改pstatus一个字段
PSCODE
待办对应的应用系统编号
由门户系统事先编制，参考应用系统统一编码表（1.3）
PCODE
待办编码
50
待办编码,各应用系统待办的唯一标识
PTITLE
待办标题
200
PDATE
待办时间
20
待办时间,日期格式如下:
yyyy-MM-ddHH:
mm:
ss
PPRINCIPAL
待办人标示
100
待办负责人标示,即用户登录名
PURL
URL地址
400
待办信息URL,应用系统提供相对的URL
PSTATUS
待办状态
2
待办状态0:
待办（阅），1已阅，2:
已办
PORANIGER
待办发起人标示
待办发起人标示，不要
PTYPE
待办类别：
是待办类还是待阅类
待办类别:
1.待办类（包括0、1、2三个状态）：
2待阅类（包括0、1两个状态）
PSCODEZH
应用系统编号对应的中文名称
30
Eg:
oa—oa系统
Eam—企业资产管理系统
NGRERSON
拟稿人
NGDEPT
拟稿部门
40
WENHAO
文号
60
文号eg:
中建投发文XX号
NGDATE
拟稿日期
日期格式如下:
yyyy-MM-dd
表描述1
1.5.2.1.1WebService应用系统样例
OA应用系统：
publicstaticvoidmain（String[]args）{
Stringurl=null;
try{
url=.Inet4Address.getLocalHost（）.getHostAddress（）.toString（）;
}catch（UnknownHostExceptione1）{
//TODOAuto-generatedcatchblock
e1.printStackTrace（）;
}
StringBufferserviceURL=newStringBuffer（）;
serviceURL.append（"
//"
）.append（url）.append（"
:
8080/jicpending/services/IPandingInterfaceWebservice"
）;
try{
IPandingInterfaceWebserviceservice=XfireClientFactory.getClient（serviceURL.toString（）,IPandingInterfaceWebservice.class）;
//新待办,应用系统调用该接口进行待办数据插入操作，
/**
方法名：
putPandingInfo（）
参数名：
optType,psCode,pCode,pTitle,pDate,pOraniger,pPrincipal,pURL,pStatus,Ptype等各个参数具体定义如上图说明
**/
StringaddValue=service.putPandingInfo（optType,psCode,pCode,pTitle,pDate,pOraniger,pPrincipal,pURL,pStatus,Ptype）;
System.out.println（"
新增待办成功吗?
：
"
+addValue）;
}catch（Exceptione）{
e.printStackTrace（）;
}
非OA应用系统：
//新增待办
RPendingVovo=newRPendingVo（）;
vo.setOptType（"
vo.setPCode（"
vo.setPscode（"
vo.setPTitle（"
vo.setPstatus（"
vo.setPOraniger（"
vo.setPPrincipal（"
vo.setPDate（"
vo.setPURL（"
vo.setPtype（"
StringaddValue=service.putPandingInfo（vo）;
1.5.3修改、删除待办
●第一步：
应用系统需要修改待办信息时，调用门户系统接口，将数据传递给门户系统提供的接口，流程如下：
传输数据方式
在此过程中，需要从应用系统获得的值包括以下几个：
optType
操作类型
psCode
待办对应的应用系统编号,由门户系统事先编制，并在集成时提供给各应用系统
pCode
待办编码
各应用系统待办的唯一标识
Ptype
待办类别
表描述2
1.5.3.1.1WebService应用系统样例
应用系统：
//修改、删除待办,应用系统调用该接口进行待办数据修改、插入操作，
changePangdingStatus（）
//修改待办，当optType=2
StringmodifyValue=service.changePangdingStatus（optType,psCode,pCode,Ptype）;
修改待办成功吗?
+modifyValue）;
//删除待办,当optType=3
StringdeleteValue=service.changePangdingStatus（optType,psCode,pCode,Ptype）;
删除待办成功吗?
+deleteValue）;
统一代办新增：
putOaPandingInfo、putPandingInfo
待办操作类型,不能为Null
delete
待办对应的应用系统编号，不能为Null
由门户系统事先编制，参考应用系统统一编码表
待办编码,不能为Null
待办标题,不能为Null
待办时间,不能为Null
待办人标示,不能为Null
URL地址,不能为Null
待办状态,不能为Null
是待办类还是待阅类,不能为Null
应用系统编号对应的中文名称,不能为Null
oa—oa系统
EAM—企业资产管理系统
拟稿人,不能为Null
拟稿部门,不能为Null
拟稿日期,不能为Null
PNOTE
备用,当做待办所属模块
255
发文管理
修改、删除:
changeOaPangdingStatus、changePangdingStatus
2统一用户管理
2.1统一用户管理的必要性
在门户系统建设之前，各应用系统分别具有各自独立的用户账户和权限管理体系，企业内部不同的用户群体在访问不同的应用系统时，需要分别进行身份的认证和授权，用户与应用系统之间相互交叉形成了一个网状的身份管理架构，如下图所示。
用户在访问不同的系统时需要输入不同的账号和口令，不仅不方便，而且有安全隐患。
门户系统的建成和投入使用，使用户能够通过Portal这个统一的入口、利用单点登录（SingleSign-On）技术实现对后台多个应用系统的统一访问，解决了上述的网状身份架构带来的问题。
这是门户系统的一项重要功能和收益。
但是对于IT系统管理和维护人员来说，目前并没有带来方便。
甚至经常为门户与后台各应用系统身份信息不能自动保持一致等一系列问题而感到头疼。
其原因在于虽然通过门户实现了用户的统一登录，但是对身份信息的维护和管理仍然是分散的，如下图所示。
用一句话来概括就是：
用户可以通过门户实现统一登录，但是用户信息的维护和管理仍然是分散的，即“统一登录，分散管理”。
分散的用户管理必将带来以下各种弊端：
1.系统之间无法共享用户基本数据，造成信息冗余
2.用户的身份信息不能在系统间自动保持一致和同步
3.用户管理分散，维护工作量巨大
4.存在安全隐患
5.缺乏用户管理流程保障
6.难以量化管理用户身份信息，不能满足身份安全审计的要求
2.2用户信息同步设计
按照各应用系统及应用使用数据库类型进行区分，数据同步设计分为如下几种同步方式：
2.2.1邮件系统用户数据同步
和J2EE类应用系统用户数据同步一致，调用门户中间数据库接口。
2.2.2DominoOA用户数据同步
通过邮件系统同步用户到dominoOA的names.nsf库，但是如果OA系统需要同步部门的话，则调用门户提供的部门同步服务接口。
2.2.3J2EE类应用系统用户数据同步
对于J2EE类通过JAVA开发实现的应用系统，统一安全层的用户数据采用“主动”方式与应用系统进行用户数据交互，如下图所示：
一、主动方式说明
应用系统通过中间数据库提供的JAVA应用API接口，按照一定时间规则通过轮寻方式读取中间用户数据库中的用户数据，并同步到应用系统对应用户数据库表中。
设计步骤如下图所示
具体步骤：
1.TDI脚本通过LDAPChangelog读取变化的用户或者组织机构数据
2.TDI脚本将数据写到TIM中完成标准动作，同时也将数据写到中间数据库中。
3.各应用系统按照一定时间规则通过轮寻方式调用门户的webservice接口请求从中间数据库中读取有变化的用户或组织机构数据。
4.门户webservice接口将获得的数据返回给各应用系统，各应用系统将数据同步到对应的用户或机构数据库表中
2.2.4门户用户数据源
门户系统用户分为两类，第一是：
实名用户，第二是：
虚拟用户
1.实名用户：
此类用户可以同时存在多个部门，产生自OA流程，在OA流程审批后，调用门户系统提供的WebService接口，把数据放入门户系统中间数据库。
WebService服务端
8080/jicdsource/services/IDsInterfaceWebservice?
具体定义如下表
Name
Type
Nullable
属性描述
C_CODE
VARCHAR2（10）
Y
员工编号
C_NAME
VARCHAR2（200）
员工姓名
C_UNITCODE
员工所属部门唯一标识，可以有多值，以#分开
C_UNITNAME
员工所属部门名称，可以有多值，因为一个员工可以同时在多个部门，以#分开
C_GENDER
VARCHAR2
（2）
性别：
1男2女
CUIDENTITYNUMBER
VARCHAR2（20）
身份证号码，只针对实名用户
MAIL
VARCHAR2（50）
个人内网电子邮件
CUEXECPOSITIONLEVEL
行政职务级别
MOBILE
手机号码
TELEPHONENUMBER
办公电话
PHYSICALDELIVERYOFFICENAME
办公地点
CUORDER
部门内人员排序，无排序写"
50000"
CUPOST
VARCHAR2（50）
现从事岗位
CUEXECPOSITION
行政职务
CUFORMAL
当前用户是实名还是虚拟，1:
实名
2:
虚拟
CHANGETYPE
修改类型，1：
add，2：
modify,3：
delete
CHANGETIME
修改时间,格式如：
218
PRINCIPAID
虚拟用户：
负责人唯一标识
TUSERID
使用人唯一标识
PRINCIPANAME
负责人姓名
TUSERNAME
使用人姓名
SYSTEMCODE
业务系统编号
SYSTEMNAME
VARCHAR2（100）
业务系统名称
2.虚拟用户：
即临时用户。
包括负责人和使用人两个属性，负责人必须从实名用户中选择，使用人可以是多人，来自于文本填写，或者也可以提供选择非实名的用户。
具体信息如实名用户表说明
2.2.5门户部门数据源
门户部门数据来自于OA流程。
8080/jicpending/services/DSInterfaceWebservice?
N
部门唯一标识
部门全称
C_PARENTUNITID
上级部门编码，真实的直属上级
排序号，若无排序号写1000
升级会员 