ESB部署WebService接口统一用户和待办.docx

上传人:b****1 文档编号:10331285 上传时间:2023-05-25 格式:DOCX 页数:28 大小:444.86KB
下载 相关 举报
ESB部署WebService接口统一用户和待办.docx_第1页
第1页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第2页
第2页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第3页
第3页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第4页
第4页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第5页
第5页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第6页
第6页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第7页
第7页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第8页
第8页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第9页
第9页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第10页
第10页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第11页
第11页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第12页
第12页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第13页
第13页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第14页
第14页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第15页
第15页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第16页
第16页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第17页
第17页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第18页
第18页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第19页
第19页 / 共28页
ESB部署WebService接口统一用户和待办.docx_第20页
第20页 / 共28页
亲,该文档总共28页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

ESB部署WebService接口统一用户和待办.docx

《ESB部署WebService接口统一用户和待办.docx》由会员分享,可在线阅读,更多相关《ESB部署WebService接口统一用户和待办.docx(28页珍藏版)》请在冰点文库上搜索。

ESB部署WebService接口统一用户和待办.docx

ESB部署WebService接口统一用户和待办

1统一待办(WebService方式)

1.1概述

门户系统做为用户访问各集成应用系统的统一入口,用户访问企业内部信息资源时只需要登录到门户系统,就可使用门户系统集成的各个应用,而待办做为各系统中用户需要处理的工作,门户系统需要提供收集建投内部应用系统中产生的待办信息,并且进行统一展现的功能,即统一待办功能。

统一待办应用业务涉及到的系统其中包括本期门户系统建设过程中所需集成的OA、WCM、EAM系统。

为保证门户系统接入各应用系统待办信息的规范性,现就各应用系统接入实现做统一要求,以确保门户系统统一待办功能实现的规范性、重用性及安全性。

不满足本技术方案提供的接入规则的相关应用系统,应参考本文档完成对应用系统改造后方可进行门户系统统一待办接入工作。

统一待办实现共分为以下部分:

Ø系统待办信息获取

Ø系统待办信息展示

Ø系统待办信息处理

1.2待办信息获取

设计思路:

应用系统通过门户系统提供的webservice接口向门户系统统一待办系统库写入代表信息,如下图

数据获取设计示意图

步骤如下:

1.应用系统需获得最新的待办信息。

2.应用系统通过门户接口,将获得的最新待办信息发送到门户系统。

3.统一待办系统将应用系统提供的待办信息展示给用户。

4.应用系统通过调用集成接口后获得信息,可以判断发送信息操作是否正常。

1.3待办信息展示

设计思路:

应用系统将最新的待办信息发送到统一待办系统中,并最终展示到门户首页上的待办栏目上,如下图

待办集中展示设计示意图

场景如下:

在所有的待办类标题前加上”请办理”,待阅类标题前加上”请审阅”。

此外,如果信息是未办或者未阅,用红色表示

1.4待办信息处理

设计思路:

用户点击门户系统上“待办栏目”里的一条待办时,弹出一个新页面,首先同应用系统实现SSO,然后跳转到应用系统的待办页面,完成待办处理后,由应用系统调用门户接口通知门户系统,并关闭弹出的待办处理页面,门户系统负责即时刷新门户待办页。

如下图:

待办信息集中处理设计示意图

1.5系统待办规范

1.5.1WebService服务端

服务地址:

http:

//域名:

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

待办对应的应用系统编号

String

10

由门户系统事先编制,参考应用系统统一编码表(1.3)

PCODE

待办编码

String

50

待办编码,各应用系统待办的唯一标识

PTITLE

待办标题

String

200

待办标题

PDATE

待办时间

String

20

待办时间,日期格式如下:

yyyy-MM-ddHH:

mm:

ss

PPRINCIPAL

待办人标示

String

100

待办负责人标示,即用户登录名

PURL

URL地址

String

400

待办信息URL,应用系统提供相对的URL

PSTATUS

待办状态

String

2

待办状态0:

待办(阅),1已阅,2:

已办

PORANIGER

待办发起人标示

String

100

待办发起人标示,不要

PTYPE

待办类别:

是待办类还是待阅类

String

2

待办类别:

1.待办类(包括0、1、2三个状态):

2待阅类(包括0、1两个状态)

PSCODEZH

应用系统编号对应的中文名称

String

30

Eg:

oa—oa系统

Eam—企业资产管理系统

NGRERSON

拟稿人

String

20

拟稿人

NGDEPT

拟稿部门

String

40

拟稿部门

WENHAO

文号

String

60

文号eg:

中建投发文XX号

NGDATE

拟稿日期

String

20

日期格式如下:

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("http:

//").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应用系统:

publicstaticvoidmain(String[]args){

Stringurl=null;

try{

url=.Inet4Address.getLocalHost().getHostAddress().toString();

}catch(UnknownHostExceptione1){

//TODOAuto-generatedcatchblock

e1.printStackTrace();

}

StringBufferserviceURL=newStringBuffer();

serviceURL.append("http:

//").append(url).append(":

8080/jicpending/services/IPandingInterfaceWebservice");

try{

IPandingInterfaceWebserviceservice=XfireClientFactory.getClient(serviceURL.toString(),IPandingInterfaceWebservice.class);

//新增待办

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);

System.out.println("新增待办成功吗?

"+addValue);}catch(Exceptione){

e.printStackTrace();

}

}

1.5.3修改、删除待办

●第一步:

应用系统需要修改待办信息时,调用门户系统接口,将数据传递给门户系统提供的接口,流程如下:

传输数据方式

在此过程中,需要从应用系统获得的值包括以下几个:

 

属性名

说明

类型

长度

备注

optType

操作类型

String

10

只出现数值型字符,分别代表1:

add2:

modify3:

delete,此外,修改操作时只修改pstatus一个字段

psCode

待办对应的应用系统编号

String

10

待办对应的应用系统编号,由门户系统事先编制,并在集成时提供给各应用系统

pCode

待办编码

String

50

各应用系统待办的唯一标识

Ptype

待办类别

String

2

待办类别:

1.待办类(包括0、1、2三个状态):

2待阅类(包括0、1两个状态)

PPRINCIPAL

待办人标示

String

100

待办负责人标示,即用户登录名

表描述2

1.5.3.1.1WebService应用系统样例

应用系统:

publicstaticvoidmain(String[]args){

Stringurl=null;

try{

url=.Inet4Address.getLocalHost().getHostAddress().toString();

}catch(UnknownHostExceptione1){

//TODOAuto-generatedcatchblock

e1.printStackTrace();

}

StringBufferserviceURL=newStringBuffer();

serviceURL.append("http:

//").append(url).append(":

8080/jicpending/services/IPandingInterfaceWebservice");

try{

IPandingInterfaceWebserviceservice=XfireClientFactory.getClient(serviceURL.toString(),IPandingInterfaceWebservice.class);

//修改、删除待办,应用系统调用该接口进行待办数据修改、插入操作,

/**

方法名:

changePangdingStatus()

参数名:

optType,psCode,pCode,pTitle,pDate,pOraniger,pPrincipal,pURL,pStatus,Ptype等各个参数具体定义如上图说明

**/

//修改待办,当optType=2

StringmodifyValue=service.changePangdingStatus(optType,psCode,pCode,Ptype);

System.out.println("修改待办成功吗?

"+modifyValue);

//删除待办,当optType=3

StringdeleteValue=service.changePangdingStatus(optType,psCode,pCode,Ptype);

System.out.println("删除待办成功吗?

"+deleteValue);

}catch(Exceptione){

e.printStackTrace();

}

}

统一代办新增:

putOaPandingInfo、putPandingInfo

属性名

说明

类型

长度

备注

OPTTYPE

待办操作类型,不能为Null

String

10

只出现数值型字符,分别代表1:

add2:

modify3:

delete

PSCODE

待办对应的应用系统编号,不能为Null

String

10

由门户系统事先编制,参考应用系统统一编码表

PCODE

待办编码,不能为Null

String

50

待办编码,各应用系统待办的唯一标识

PTITLE

待办标题,不能为Null

String

200

待办标题

PDATE

待办时间,不能为Null

String

20

待办时间,日期格式如下:

yyyy-MM-ddHH:

mm:

ss

PPRINCIPAL

待办人标示,不能为Null

String

100

待办负责人标示,即用户登录名

PURL

URL地址,不能为Null

String

400

待办信息URL,应用系统提供相对的URL

PSTATUS

待办状态,不能为Null

String

2

待办状态0:

待办(阅),1已阅,2:

已办

PTYPE

待办类别:

是待办类还是待阅类,不能为Null

String

2

待办类别:

1.待办类(包括0、1、2三个状态):

2待阅类(包括0、1两个状态)

PSCODEZH

应用系统编号对应的中文名称,不能为Null

String

30

Eg:

oa—oa系统

EAM—企业资产管理系统

NGRERSON

拟稿人,不能为Null

String

20

拟稿人

NGDEPT

拟稿部门,不能为Null

String

40

拟稿部门

WENHAO

文号

String

60

文号eg:

中建投发文XX号

NGDATE

拟稿日期,不能为Null

String

20

日期格式如下:

yyyy-MM-dd

PNOTE

备用,当做待办所属模块

String

255

Eg:

发文管理

修改、删除:

changeOaPangdingStatus、changePangdingStatus

属性名

说明

类型

长度

备注

optType

操作类型

String

10

只出现数值型字符,分别代表1:

add2:

modify3:

delete

psCode

待办对应的应用系统编号

String

10

待办对应的应用系统编号,由门户系统事先编制,并在集成时提供给各应用系统

pCode

待办编码

String

50

待办编码,各应用系统待办的唯一标识

Ptype

待办类别

String

2

待办类别:

1.待办类(包括0、1、2三个状态):

2待阅类(包括0、1两个状态)

PPRINCIPAL

待办人标示

String

100

待办负责人标示,即用户登录名

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服务端

服务地址:

http:

//域名:

8080/jicdsource/services/IDsInterfaceWebservice?

wsdl

服务参数:

具体定义如下表

Name

Type

Nullable

属性描述

C_CODE

VARCHAR2(10)

Y

员工编号

C_NAME

VARCHAR2(200)

Y

员工姓名

C_UNITCODE

VARCHAR2(200)

Y

员工所属部门唯一标识,可以有多值,以#分开

C_UNITNAME

VARCHAR2(200)

Y

员工所属部门名称,可以有多值,因为一个员工可以同时在多个部门,以#分开

C_GENDER

VARCHAR2

(2)

Y

性别:

1男2女

CUIDENTITYNUMBER

VARCHAR2(20)

Y

身份证号码,只针对实名用户

MAIL

VARCHAR2(50)

Y

个人内网电子邮件

CUEXECPOSITIONLEVEL

VARCHAR2(10)

Y

行政职务级别

MOBILE

VARCHAR2(20)

Y

手机号码

TELEPHONENUMBER

VARCHAR2(20)

Y

办公电话

PHYSICALDELIVERYOFFICENAME

VARCHAR2(200)

Y

办公地点

CUORDER

VARCHAR2(20)

Y

部门内人员排序,无排序写"50000"

CUPOST

VARCHAR2(50)

Y

现从事岗位

CUEXECPOSITION

VARCHAR2(50)

Y

行政职务

CUFORMAL

VARCHAR2(10)

Y

当前用户是实名还是虚拟,1:

实名

2:

虚拟

CHANGETYPE

VARCHAR2(20)

Y

修改类型,1:

add,2:

modify,3:

delete

CHANGETIME

VARCHAR2(20)

Y

修改时间,格式如:

218

PRINCIPAID

VARCHAR2(10)

Y

虚拟用户:

负责人唯一标识

TUSERID

VARCHAR2(10)

Y

虚拟用户:

使用人唯一标识

PRINCIPANAME

VARCHAR2(10)

Y

虚拟用户:

负责人姓名

TUSERNAME

VARCHAR2(10)

Y

虚拟用户:

使用人姓名

SYSTEMCODE

VARCHAR2(50)

Y

业务系统编号

SYSTEMNAME

VARCHAR2(100)

Y

业务系统名称

2.虚拟用户:

即临时用户。

包括负责人和使用人两个属性,负责人必须从实名用户中选择,使用人可以是多人,来自于文本填写,或者也可以提供选择非实名的用户。

具体信息如实名用户表说明

2.2.5门户部门数据源

门户部门数据来自于OA流程。

WebService服务端

服务地址:

http:

//域名:

8080/jicpending/services/DSInterfaceWebservice?

wsdl

服务参数:

具体定义如下表

Name

Type

Nullable

属性描述

C_CODE

VARCHAR2(20)

N

部门唯一标识

C_UNITNAME

VARCHAR2(200)

Y

部门全称

C_PARENTUNITID

VARCHAR2(200)

Y

上级部门编码,真实的直属上级

CUORDER

VARCHAR2(200)

Y

排序号,若无排序号写1000

CUFORMAL

VARCHAR2(10)

Y

是否是临时部门:

1.正式2.临时

CHANGETYPE

V

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 经管营销 > 经济市场

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2