把公司的内容管理系统全面迁移到Docker上重新部署,把备份的归档文件导入时发现报错没法导入,最后把自定义的元数据去掉后导入成功。但是原来利用文件类型的层级关系定义了很多子类型,都去掉的话很多查询的条件不能使用,积累的内容基本废了一半。
[heading]问题描述[/heading]
尝试在WebCenter Content里更新内容元数据信息,但是每次更新都报[highlight dark=”no”]Unable to update the content item information for ‘XXXX’. Unable to execute service method ‘validateCheckinData’. Null pointer is dereferenced.[/highlight]的错误。在Oracle Support上找原因,搜到的结果都不对。把自定义的表、视图、关系重建,把元数据删除重建,无数次的修改重启,就是不起作用。折腾了大半个月,差点发疯。
[heading]解决办法[/heading]
今天下班没事又开始看,无意识的打开Oracle Support,以[highlight dark=”no”]Unable to execute service method ‘validateCheckinData'[/highlight]为关键字搜索,没想到一下子跳出了Doc ID 2225215.1,说这是WebCenter Content 12c的一个bug,当用dDocType做为元数据层级关系的依据时,检入文件或更新时会报错。
按文档的指引下载了patch 23753742,打了补丁后在配置文件加上NoServerDependantFieldValidate=true,重启WebCenter Content服务,更新元数据,一切正常。
想起自己这个经历,心里只想骂他大爷的O记。

[heading]1.问题描述[/heading]

把WebCenter Content从11g升级到12c,用归档程序把原有的文件迁移到新版本,文件ID使用与原来相同的自动编号规则,当签入新文件时,系统总是报 “Content Server Request Failed Content item ‘TF_XXX’ was not successfully checked in. The content ID ‘TF_48509’ is not unique.”。

查看Content Server日志,错误信息如下:

An error has occurred. The stack trace below shows more information.

!csUserEventMessage,jeetqiu,139.159.32.66!$!csUnableToCheckIn,TF_007207!csCheckinIDNotUnique2,TF_007207
intradoc.common.ServiceException: !csUnableToCheckIn,TF_007207!csCheckinIDNotUnique2,TF_007207
*ScriptStack CHECKIN_NEW_SUB
3:doScriptableAction,dDocName=3:doSubService,dDocName=CHECKIN_NEW_SUB,dDocName=3:makeNewRevClass,dDocName=
at intradoc.server.ServiceRequestImplementor.buildServiceException(ServiceRequestImplementor.java:2259)…

[heading]2.解决方法[/heading]

第一时间上Oracle Support找相关的答案,Doc ID 446390.1Doc ID 1320842.1都有相关的描述,不过都是修改counters表的RevClassID来达到目的。照着文章修改了RevClassID,但不知道是WebCenter Coneent 12C的机制更新还是什么原因,修改后并没有起作用。

后来无意中在一个链接看到Doc ID 1395583.1 How WebCenter Content 11g Uses Sequences to Uniquely Identify Content,从中知道IdcSeqRevClassID是管自动生成序号的,于是找到当前最大序号。
Select MAX(dDocName) from revisions
再修改IdcSeqRevClassID的起始值至最大序号+1,重新回到content系统,签入新文件,一切正常。

继续试用WCC 12c,比起11g,WCC 12c最大的改进当属是采用了全新的Alta UI,当然了,其它的一些功能就只有慢慢试了。

和WCS一样,安装的前提是JDK 8,Oracle Database 12c,Weblogic Server 12c,具体的安装步骤可以参考这篇文章安装Oracle WebCenter Sites 12c (part 1) ,RCU的设置及安装可参考安装Oracle WebCenter Sites 12c (part 2) 。这篇文章从安装WCC开始。

[highlight dark=”no”]1. 安装WCC软件[/highlight]

1.1 启动安装向导

输入命令,[highlight dark=”no”]”c:\Program Files\Java\jdk1.8.0_65\bin\java.exe”[/highlight] -jar fmw_12.2.1.0.0_wccontent_generic.jar启动安装向导。

wcc1

 

wcc2

1.2 自动更新

跳过,点Next.

wcc3

 

1.3 安装位置

选择Oracle Home位置,Next

wcc4

1.4 先决条件检查

检查成功后,Next

wcc5

1.5 安装汇总

点Install,开始安装WCC软件。

wcc6

安装进行中

wcc7

1.6 完成WCC软件安装

wcc8

[highlight dark=”no”]2. 配置WCC域[/highlight]

2.1 运行RCU创建所需的数据库表空间

wcc9

 

wcc10

wcc11

2.2 创建域

转至 ORACLE_HOME/oracle_common/common/bin目录下,运行config.cmd,启动WCC应用域创建向导。

创建新Domain

wcc12

选择域模板

wcc13

Domain模式和JDK

wcc14

数据源

wcc15

数据库配置

[highlight dark=”no”]输入信息后点Get RCU Configuration[/highlight]

wcc16

 

wcc17

 

wcc18

 

Credentials

wcc19

配置管理服务器

wcc20

 

wcc21

 

wcc22

 

wcc23

 

wcc24

 

wcc25

wcc26

 

wcc27

 

完成域配置及安装

wcc28

 

wcc29

wcc30

 

wcc31

2.3 启动管理服务器

利用命令startNodeManager.cmd和startWeblogic.cmd启动Node Manager和Admin Server,通过地址http://localhost:7001/console登入控制台。

wcc32

启动UCM_Server1

wcc33

确认管理服务器已处于Running状态。

wcc34

2.4 访问WCC服务器,完成初始化配置

访问地址http://localhost:16200/cs,登录WCC,完成初始化设定

wcc35

 

wcc36

 

wcc37

 

重新启动服务器,即可正常使用WCC了。

wcc38

 

wcc39

如果要使用Alta UI,必须启动WCCADF_server1,通过地址http://localhost:16225/wcc,即可体验New UI。

wcc40

 

wcc41

 

 

 

 

 

安装组件

下载地址

访问webcenter content管理服务器界面

http://127.0.0.1:16200/cs/idcplg/cs-admin/pxs?IdcService=GET_ROOT_IDC_ADMIN_PAGE

注:此组件依赖于ContentBasket组件,所以在安装装先启用ContentBasket组件。

进入组件管理器,勾选ContentBasket组件。


 

在安装之前,需要修改组件的一个环境变量配制文件:可以使用winRAR等压缩软件打开组件压缩包,修改下图文件:


改成你UCM所在domain的路径:修改完成后替换掉zip包该文件,

第二个环境变量23的意思是,每天晚上的23点,会将批量下载所产生的临时文件清空,为服务器节省空间。


 

选择组件管理器à高级组件管理器


选择组件zip包,然后点击安装


安装成功后启用组件,再重启UCM所在的weblogic server


重启完成后进入管理操作
à[发布静态, 字符串和动态文件] 



 

使用效果:

在搜索结果页面则会出现下载菜单:


 

下载的zip文件中则会只包含选择过的文件:


 

RIDC调用:

服务名称:BATCH_DOWNLOAD_AS_ZIP

传入参数:SelectedDocs(文档dDocName属性,多个则以逗号分开)

返回结果:在返回DataBinder实例中拿Local参数zipFilePath的值,会返回一个zip文件的相对路径。

很多用户在使用Oracle WebCenter Content一段时间后,会发现系统生成索引的速度越来越慢,影响到用户的使用体验。当使用OracleTextSearch或FullText索引方式的时候,就象我们使用电脑时不时要进行磁盘碎片整理一样,需要定时进行索引的碰片整理。

 在默认情况下,当WebCenter Content每索引5000个文档会自动进行全文索引优化,但在实际使用过程中,往往需要我们在使用过程中人工进行干预。 下面是我们公司实际生产环境中的WebCenter Content,长时间没有进行索引整理,从下图可以看到有超过75%的索引碎片。

进行碎片整理优化后,索引文件大小降低,碎片降低到零。
begin 
ctx_ddl.optimize_index(‘FT_IDCTEXT1′,’FULL’, parallel_degree =>’1′); 
end;
 

注意:当动活动的索引不同索引名称有可能不同,具体请参考WebCenter Content在线文档。

当然,我们也可以设置数据库的调度程序作业来定时进行索引优化,打开SQL Developer,以SYS用户连接数据库,运行脚本以创建调度作业。

WebCenter Content安装实施后,只有进行持续的优化才能保证以最佳的性能运行。上海同富能为您提供包括Weblogic\WebCenter Conter\WebCenter Portal的整体优化方案。
 

客户系统上线前,发现在生产环境的Oracle Enterprise Linux 6.1上的UCM 11gR5打开文件时,一直显示索引错误,信息“Text conversion of  the file …… failed. Content has been indexed with Info only. Resubmit should only be performed if the problem has been resolved.”如下图所示:

打开indexer的trace,点击重新提交后,得到以下信息,初步判断是因为textexport找不到必要的库文件导致。

>indexer/7 01.13 14:10:03.450   index update work InputFilePath is:   indexer/7  01.13 14:10:03.450   index update work OutputFilePath is: >indexer/7    01.13 14:10:03.450   index update work Sending document to conversion >(internal)/7  01.13 14:10:03.496  TextExport #7531#8FDB#7A0B ‘TextExport’ #610F#5916#4E2D#6B62#3002 intradoc.common.ServiceException: !csErrorReturnedByProcess,TextExport!$/u01/app/oracle/Middleware/Oracle_ECM1/ucm/idc/components/ContentAccess-linux/linux/lib/contentaccess/textexport: error while loading shared libraries: libz.  (internal)/7   01.13 14:10:03.496   TextExport         at intradoc.taskmanager.TaskLauncher.launchExe(TaskLauncher.java:381)  (internal)/7  01.13 14:10:03.496  TextExport         at intradoc.taskmanager.TaskMonitor$1.run(TaskMonitor.java:116)  (internal)/7  01.13 14:10:03.496   TextExport         at java.lang.Thread.run(Thread.java:662)

没有仔细看trace信息内容,开始在网上和oracle support网站找text conversion相关的信息,相关的解决方案主要是确认textexport的执行权限或者是设置LD_LIBRARY_PATH和ContentAccessExtraLibDir(在intradoc.cfg文件)几种方式,但是试过这几种方式都不奏效,如此试了几次,也只好放弃。

再一次回到正常分析的路子上来,从trace信息中可以看出是找到到共享库libz.,尝试在/usr/lib和/usr/lib64找libz.so,有64位的文件,但是没有32位的文件。难道象很多程序一样,UCM也是用32位的libz.so来执行text conversion的命令,google了一把,发现libz.so是zlib包里,用yum install zlib.i686实现相关包的安装,确认libz.so存在于相关的文件夹下,重新启动Content Server,再点击重新提交,问题解决。

Repository Manager重新提交所有文档,再重建索引,完成已检入文件的全文索引支持。

在做Oracle WebCenter Content(以前叫Oracle UCM)项目中,经常有客户觉得系统中的文字不够友好,需要去更改界面文字。UCM的资源文件都存在于ww_strings类似的文件中,最直接的方法当然去直接去改写该文件,但这种做法对于一个有经验的实施人员来讲显得太粗鲁了点。基于UCM良好的架构设计,可以直接通过组件来修改。方法如下:
1.创建组件,增加一个资源文件,利用定制字串代替系统文本。
格式为:<@stringID=Text string@>  中文语言为:<@zh-CN.stringID=Text string@>
2.当然你也可以定义自己的字符串,然后在UCM页面中调用,利用Idoc Script <$lc("wwStringID")$>.