Maximo二次开发入门：MboSet、工作流与后台任务实战

简介《Maximo入门培训》是一份面向企业资产管理系统EAM初学者与初级开发者的系统化培训文档围绕Maximo的J2EE技术架构、程序结构及二次开发配置展开帮助读者建立从基础概念到实际开发的完整认知。压缩包仅含1个docx文件约436KB以目录化文档形式组织便于按章节查阅和学习。内容覆盖Maximo使用技术介绍、程序结构、页面开发与常用控件、工作流模型及组件标记、后台任务界面配置与代码开发、数据库配置与更新并附MboSet、Mbo、FldXX等代码示例及Mbo常用类说明。文档结合J2EE、RMI、JSP/Servlet/EJB等技术背景梳理资产、工作订单、库存等模块的开发要点适合作为入门教材、培训讲义或开发时的查阅资料。目前已有360人学习可帮助读者理解Maximo页面、工作流、后台任务与数据库配置的基本开发流程为后续实施和定制系统打下基础。1. 从一张要加签的工单说起这套培训资料解决的到底是什么问题去年接了个活客户系统里的工单审批要临时加一级顺带加两个字段再挂一个每天凌晨清理临时表的任务。打开工程目录才发现页面不是手写的 JSP是存在数据库表里的 XML业务逻辑不在 Service 层在 Mbo 和 MboSet 里定时器也不是框架自带的调度是后台任务配置加一个继承 SimpleCronTask 的类。三个需求三种改法全靠翻文档。这套 Maximo 入门培训就是按这个顺序排的技术介绍、程序结构、页面开发、工作流开发、后台任务开发、数据库配置最后落到 MboSet、Mbo、Fld 三层代码和常用类清单。适合刚接手 Maximo 二次开发的人也适合从别的资产管理系统切过来、需要快速看懂这套 EAM 老架构的人。2. 技术底座与包结构一次 /ui/* 请求进来后发生了什么2.1 J2EE、RMI 与半自动 OR 映射业务对象为什么能跨进程调Maximo 整体跑在 J2EE 架构上业务对象之间不走本地方法调用而是用 RMI 把对象暴露成远程接口。这件事带来的直接后果是你在本地new一个 Mbo和拿到一个远端 Mbo 的代理写起来的代码几乎一样但两边的异常类型、序列化要求完全不同。第一次写自定义 Mbo 时漏了serialVersionUID编译能过运行时报 RemoteException翻了两小时才定位到这种写法里。几个绕不开的技术点培训目录里原样列了出来实际开发中每一个都会碰到RMI业务对象跨 JVM 通信的基础。分布式部署时Mbo 可能不在同一个进程里。Ajax前端交互靠它页面局部刷新而不是整页提交这是 Maximo 用起来不卡的原因。半自动对象关系映射不是全自动 ORM字段和对象的绑定关系配置在数据字典里代码里只声明扩展点。XML 驱动的页面应用页面和信息交互都是 XML 格式存在表里改页面等于改数据。事务处理框架提供自动事务但长事务要手动塞进事务队列这一点后面踩坑章会再提。OR 持久化系统级的映射和持久化你只需要继承基类。缓存机制系统级缓存数据变化时自动重载——注意是“自动重载”不是“立刻重载”这是后面页面改了不生效的根因之一。日志与异常Log4j 被扩充过有自己的根 logger 和分类策略异常也被包装成对用户友好的形式。我一般把这段当“心智模型”来记Maximo 是“配置驱动的 Java 应用”页面的真相在表里业务的真相在 Mbo 里流程的真相在工作流定义里。搞清这三条真相在哪改起来就不会乱。2.2 部署包清单businessobjects.jar 与 maximouiweb.war 各管什么源码目录摊开大致是这么些东西。搞清谁是谁是排查“我改的代码为什么不生效”的第一步包 / 目录内容改动频率businessobjects.jar业务相关类psdi.app.*、psdi.workflow.*、psdi.mbo.*都在这高二次开发主战场mbojava.jar一些自测试的包低mboejb.jar集成相关低meajmsejb.jar集成相关消息类低maximouiweb.warWeb 客户端前台应用中mboweb.war启动时加载的 Web 应用放 web.xml中meaweb.war集成相关的 Web 应用低properties.jar配置文件maximo.properties在这里中环境相关resources相关资源中Lib类库资源低META-INF描述文件低businessobjects 的内部再按包分组结构本身就是在告诉你该往哪儿加代码psdi.app.*业务对象 Mbo、MboSet描述应用相关的业务逻辑。psdi.server.*系统级服务数据库连接管理、session 管理、线程管理、数据字典加载、服务实例化、Mbo/MboSet 访问。psdi.util.*克隆 app、删除 app、HttpSession 管理、加解密、客户化应用生成。psdi.workflow.*工作流逻辑处理。psdi.mbo.*核心持久层操作OR 映射的实现。提示自己写的包名别用psdi开头避免和产品类冲突。常见做法是公司缩写加模块名比如maxdemo.lesson1。2.3 启动链路MAXIMOStartupServlet 到 MXServer.start服务端启动这一步全部压在mboweb的部署描述符里。原文给的就是这段值得逐行看servlet descriptionServer used to load MAXIMO Business Objectsenvironment/description display-nameMAXIMO Startup Servlet/display-name servlet-nameMAXIMOStartupServlet/servlet-name servlet-classpsdi.servlet.MAXIMOStartupServlet/servlet-class load-on-startup2/load-on-startup /servletload-on-startup为 2意味着容器启动到第二阶段就加载它不是等第一个请求进来才初始化。它的职责很单一读maximo.properties把内容包成Properties对象然后调用MXServer.start(properties)。MXServer.start之后做的事情可以拆成系统服务和应用服务两块系统服务建数据连接池、实现缓存、调 MaximoDD 从库里读出并加载全部数据字典、实例化系统服务与应用服务对象、做远程应用服务的定位、注册 RMI、管 MaxSession 的线程。应用服务与业务相关的 MBO也就是你写的那堆扩展类。这段链路的价值在于排错顺序。启动失败时先看maximo.properties有没有解析问题再看数据字典加载有没有报错多半是数据库连不上或版本不匹配最后才怀疑自己的扩展类。顺序反了就是在错误的地方花时间。2.4 WebClientServlet 与表现层页面为什么在表里前台这边最核心的是一个 servlet所有/ui/*的 URL 都映射到它servlet servlet-namewebclient/servlet-name servlet-classpsdi.webclient.servlet.WebClientServlet/servlet-class init-param param-namechar_encoding/param-name param-valueUTF-8/param-value /init-param /servlet servlet-mapping servlet-namewebclient/servlet-name url-pattern/ui/*/url-pattern /servlet-mappingchar_encoding定死 UTF-8这一点别改改了中文必乱。WebClientServlet 负责定义页面内容类型然后交给 WebClientSession 处理。表现层的关键事实是除了登录验证那几步其余页面内容全部由 XML 提供这些 XML 存在MAXPRESENTATION表里。XML 由 JSP 控制标签组件组成components组件配合 JavaScript 脚本生成最终页面CSS 文件夹定义通用样式。这就解释了为什么“改页面”在 Maximo 里是“改数据”——应用程序设计器改的其实是表内容最终由这套 servlet 渲染出来。也解释了为什么改完之后刷新浏览器没变化XML 已经被读进缓存了得走应用配置变更或重启才重新加载。3. 页面开发与工作流开发设计器能改到什么程度3.1 应用程序设计器拖拽能解决的与不能解决的应用程序设计器的定位很清楚让技术用户和非技术用户都不写代码就能配置应用。它支持拖放移动字段和部分、创建新字段、表和标签页高级一点的功能包括创建或复制应用、定义签名选项、编辑工具栏和“选择操作”菜单。我把它能做的事分三档这样接需求时能快速判断该不该上代码纯配置档挪字段位置、加标签页、调工具栏按钮顺序、复制一个应用到新对象上。这类改完走一遍应用配置变更就能看效果。半配置档加新字段。要先在数据库配置里加对象属性再在设计器里把它拖到页面上两步缺一不可顺序也不能反。必须写代码档字段联动、跨对象校验、按钮点了要跑一段业务逻辑。这些在设计器里做不了得落到 Mbo、Fld 或者自定义 Action 上。实际项目里最容易翻车的是第二档——只加了字段没加属性或者加了属性没重启页面上就是看不到。这个后面单独说。3.2 常用控件与页面结构字段、表、标签页怎么摆页面结构基本是三层主标签页 → 区块section→ 字段 / 表格。常用控件覆盖了大部分业务场景文本框、下拉列表、按钮、日期控件、表格多行子表。设计器里拖的时候有几个细节值得提前知道字段的“签名选项”决定它是否必填、是否只读但这些是界面级的真正的强制校验还得在 Mbo 的appValidate()里做否则接口直接调进来就绕过去了。表格控件绑定的是子表的 MboSet 关系关系没配好表格永远是空的。复制应用比重头建应用省事得多但复制完记得改 APPLIK 这类主键字段不然两个应用会互相覆盖配置。3.3 工作流模型过程、活动、转换、条件、角色工作流设计的本质是给记录画一张路径图。一个工作流定义由这几部分构成过程模型、活动、转换、条件、相关数据、角色以及需要激活的内部或外部程序。配套的应用不少各自负责一块应用作用Actions操作定义Communication Templates通信模板发通知用Escalations上报、自动触发Inbox / Assignments Setup收件箱与任务分配设置People人员Person Groups人员组Roles角色Workflow Application工作流应用配置Workflow Designer工作流设计器本体Workflow Inbox工作流收件箱用户处理任务的地方角色这一层经常被低估。任务分配给“角色”而不是具体的人角色下面还能挂表达式只有满足表达式时才真正分配到。这个机制在组织架构变动时特别有用不用改流程改角色成员就行。3.4 节点组件逐个说开始、停止、任务、条件、手动输入、子过程、交互、等待工作流画布上的每种节点都有明确语义用错了流程就会卡住开始节点任何过程只能有一个新建过程时自动放上去。停止节点标记流程结束、记录脱离工作流控制的点可以有多个。任务节点指引记录路径至少有一条出线。需要用户对邮箱任务做出肯定或否定响应时用它。最多两条出线——正向对应接受反向对应拒绝入线可以有多条。条件节点根据记录里的信息自动判断走向。出线必须一正一反节点内写 SQL 表达式表达式解析为真走正连接为假走负连接。手动输入节点让用户从菜单里选下一步常放在交互节点之前。子过程节点嵌入另一个完整工作流。除了正向线还能引一条反向线子过程遇到停止节点后沿原路返回主过程把终止原因带回来。交互节点必须有一条或多条入线只能有一条出线。通过预设选项把终端用户引导到特定解决路径上。等待节点流程走到这里暂停直到指定事件发生才从单一出口继续。任务节点上有几个参数直接决定流程能不能跑通标题图标下显示的文字、描述、应用程序、时限超时后任务回流给“升级角色”、任务分配分配的角色 表达式、接受操作全部接受才算接受或任意一人接受即算接受。这些参数在设计器里都是表单填错了不会报错只会在运行时表现为“任务没人收到”。3.5 一次工单审批流的实践改 APPWFWO 走一遍培训里给的实践路径很实在拿 demo 库里的工作流实例练手找到过程 APPWFWO改它然后到工单里实际跑一遍。改的过程我一般按这个顺序先在设计器里打开 APPWFWO把现有的任务节点、条件节点、连接关系抄一遍到纸上搞清楚当前有几条分支。要加一级审批就在原任务节点后面插一个新的任务节点把正向线接过去再把新节点的正向线接回原来的下一节点。给新任务节点配角色和表达式表达式写成status WAPPR这类能解析出真假的条件。保存后回到工单选一条测试记录发起流程用自己的账号走一遍再用另一个角色的账号走一遍确认任务确实分到了对的人。走完看收件箱确认停止节点后记录真的脱离了流程控制。血泪经验是别在生产库上直接改流程定义。工作流实例一旦跑起来改定义对在途记录的影响是不可预测的常见做法是复制一份新过程改动在副本上做验证完了再切。4. 后台任务与持久层代码从 Cron Task 到 MboSet/Mbo/Fld4.1 界面配置新建一个后台任务后台任务的第一步不在代码里在界面里。新建后台任务配置相关参数——任务名、类名、计划多久跑一次、是否启用。这一步决定了任务的“壳”代码只负责“瓤”。配置时容易忽略的是计划表达式和系统的时区关系。页面上的时间按服务器时区算跨时区部署时差几个小时任务就跑在了意料之外的时间点。我一般配置完之后先把间隔调成一分钟观察两次执行日志确认时间对得上再改成正式的计划。4.2 代码骨架SimpleCronTask 的 init 与 cronAction任务类的骨架非常固定原文给的就是这个结构public class CrontaskTest extends SimpleCronTask { // 任务被加载时调用一次适合做参数读取、资源初始化 public void init() throws MXException { super.init(); // 参数初始化 } // 每次到达计划时间点都会执行这一段 public void cronAction() { // 执行相应逻辑 } }两个方法分工明确init()是初始化参数解析、连接准备放这儿cronAction()是真正干活的地方每次触发都进来。写cronAction()时有三个约定我基本不会破不要抛受检异常出去内部 catch 住再记日志否则任务会静默失败第二天才发现数据没清。处理大批量数据要分批提交一次几千条全塞进一个事务锁表时间是灾难级的。幂等设计。任务可能因为重启被重复触发清理逻辑写成“删除 N 天前的数据”这类天然幂等的形式比写“删除今天的数据”安全得多。4.3 数据库配置对象、属性、索引、关系数据库配置这一块界面上要做四件事新建对象、创建对象属性、建索引、建关系。它们对应到数据库里就是表、列、索引和外键关联但 Maximo 把元数据也存了一份在自己的数据字典里两边要同步。顺序不能乱先有对象表再加属性列属性加完才能建索引关系要等主外对象都齐了才能配。属性这里有两个关键选项——类型和长度类型选错了不会立刻报错等到页面上存值的时候才炸报的还是很抽象的转换异常。关系配置是子表能不能显示的前提。配关系时要指定源对象、目标对象、匹配的字段少配一个匹配条件子表就会把全表数据拉出来性能直接崩。4.4 更新数据库管理方式与应用配置变更界面配完不等于生效还得推一把# 第一步切到管理方式Admin Mode期间禁止普通用户操作 # 第二步应用配置变更把元数据变更同步到数据库这两步在界面上点没有命令行。管理方式的意义是独占变更期间别人改动数据结构会导致不一致。应用配置变更则是把设计器里的改动落库并触发数据字典重载。注意应用配置变更本身也可能失败失败信息通常在日志里界面上只给一句“配置变更未完成”。遇到这种情况先去看日志里最后一条 SQL 错误八成是属性类型或长度跟已有数据冲突。4.5 MboSet 骨架构造方法与 getMboInstanceMboSet 是持久层的核心类超类是psdi.mbo.MboSet。应用对象与 MboSet 直接关联创建对象时必须指定关联的 MboSet 类。自定义 MboSet 的规矩是继承psdi.mbo.MboSet实现对应的 Remote 接口必须有构造方法必须实现getMboInstance。package maxdemo.lesson1; import java.rmi.RemoteException; import psdi.mbo.Mbo; import psdi.mbo.MboServerInterface; import psdi.mbo.MboSet; import psdi.util.MXException; public class CustDemoMboSet extends MboSet implements CustDemoMboSetRemote { private static final long serialVersionUID 3918526761961603733L; // 构造方法把服务端上下文交给父类连接池、缓存都从这里来 public CustDemoMboSet(MboServerInterface arg0) throws RemoteException { super(arg0); } // 框架每需要一个新的 Mbo 实例时回调这里 protected Mbo getMboInstance(MboSet arg0) throws MXException, RemoteException { return new CustDemoMbo(arg0); } }参数说明MboServerInterface是服务端上下文句柄别自己造由框架传入getMboInstance的入参是当前 MboSet 自身直接透传给 Mbo 的构造方法即可。这里最容易翻车的地方是serialVersionUID。少了它单独跑没问题一旦跨 JVM 调用就报序列化不匹配错误信息还很不直观。我现在的习惯是新建类第一件事就把这行写上。4.6 Mbo 与 Fld字段校验放哪一层三个类的职责边界很清楚MboSet 管“一批”Mbo 管“一条”Fld 管“一个字段”。public class CustDemoMbo extends Mbo implements CustDemoMboRemote { public CustDemoMbo(MboSet ms) throws RemoteException { super(ms); } // 对象初始化设默认值、初始化标志位 public void init() throws MXException, RemoteException { super.init(); setValue(STATUS, NEW); } // 保存前的整体校验跨字段、跨表的规则放这里 public void appValidate() throws MXException, RemoteException { super.appValidate(); if (isNull(OWNER) getString(STATUS).equals(APPR)) { throw new MXApplicationException(custdemo, ownerRequired); } } }字段级校验放到 Fld 里走的是适配器模式public class FldCustDemoQty extends MboValueAdapter { public FldCustDemoQty(MboValue mbv) { super(mbv); } // 每次该字段值变化时触发 public void validate() throws MXException, RemoteException { super.validate(); double qty getMboValue().getDouble(); if (qty 0) { throw new MXApplicationException(custdemo, qtyNegative); } } }分层的实际意义Fld 里的校验对这个字段的所有写入路径都生效包括接口调用Mbo 的appValidate()在保存时统一跑一次适合做“必须两个字段一起看”的规则init()只在新对象初始化时执行别把业务校验写进去。常见误用是把所有校验都堆在appValidate()里结果用户填一个字段就报一堆错体验很差。4.7 常用 API 速查Mbo 的方法按用途分组原文列了二十多个 Mbo 方法直接背没意义按用途分组记更实用分组方法用途取值赋值getXXXX(attributeName)、setValue(name, attributeName)、setValueNull(attributeName)按属性名读写getXXXX按类型分getString / getDouble / getDate状态判断isNew()、isModified()、isModified(attribute)、isNull(attributeName)、isSelected()、toBeAdded()、toBeUpdated()、toBeDeleted()、toBeSaved()判断当前记录处于什么阶段toBe*系列是待提交状态生命周期add()、delete()、copy()、clear()、init()、initialize()、modify()增删改的基础操作校验与权限appValidate()、canDelete()、checkFieldAccess()业务校验与字段级权限检查标志位setFieldFlag(attributeName, flag, state)、setFlag(flag, state)控制字段是否只读、必填等回滚rollbackToCheckpoint()回到检查点长事务场景用上下文getThisMboSet()、getInsertCompanySetId()、getInitialBaseLanguageString()拿所属 MboSet、公司集、多语言基础串MboSet 那边的方法少但都关键save()提交、cleanup()清理、close()关闭、commit()提交事务。它们的调用顺序错了会出现“数据看着存了一刷新就没了”的情况——save()之后没commit()事务没提交。5. 踩坑排查六个高频问题现象、原因、解决5.1 部署与配置阶段现象一应用设计器里改了页面刷新浏览器完全没变化。原因页面 XML 存在MAXPRESENTATION表里同时被读进系统缓存改的是表内容缓存没重载。解决走一遍应用配置变更必要时重启。改完先别急着怀疑设计器先确认缓存刷新了没有。现象二数据库里加了新属性页面上就是拖不出这个字段。原因只做了数据库配置没走应用配置变更数据字典里没有这个属性。解决数据库配置 → 应用配置变更 → 重启三步走完再进设计器。顺序反了就是白忙。现象三后台任务改了参数跑起来还是老行为。原因任务定义已被注册进调度器参数缓存在内存里。解决停用任务、改参数、重新加载任务定义、再启用。我吃过一次亏改完参数直接等第二天结果白等一晚。5.2 开发与运行阶段现象四自定义 MboSet 编译通过运行时抛 RemoteException堆栈指向序列化。原因漏了serialVersionUID或者类没打进 businessobjects.jar或者应用设计器里没把应用对象绑定到这个 MboSet 类。解决补齐序列化 ID确认打包路径去应用设计器里核对关联的 MboSet 类名三个地方挨个查。现象五工作流走到条件节点永远只走一个方向。原因正负连接接反了或者 SQL 表达式写成了恒真/恒假。解决把表达式单独拿到数据库里跑一遍看返回结果再检查两条出线的正负标记。条件节点的出线必须一正一反少一条流程就断在那个节点上。现象六字段改了值校验方法里的判断却用了旧值。原因在setValue之前读值或者用了绕过 Fld 的写入方式。解决校验写在 Fld 的validate()里它由框架在值变化后触发跨字段规则放appValidate()。别在init()里做业务校验那是新对象初始化阶段值是空的。6. 二次开发改造与验证把培训里的 Demo 换成自己的业务培训里的例子跑通只是起点真接需求时第一步永远是判断改动落在哪一层。我的做法是先画一张四象限页面问题看 XML 和设计器流程问题看工作流定义定时问题看后台任务业务规则问题看 Mbo、Fld、Action。四个方向逐一排除比漫无目的地翻代码快得多。验证也有套路。单个 Mbo 的校验逻辑我一般写一个临时的后台任务类在里面构造 MboSet、add()一条记录、改字段、调appValidate()用cronAction()当测试入口跑一遍日志里就能看到异常有没有按预期抛出。这种做法比在页面上点半天靠谱尤其是那些需要构造特殊数据状态的校验。改完之后的回归清单我固定跑这几项检查项方法页面显示设计器改完走应用配置变更换两个角色登录看权限表现数据落库新建、修改、删除各来一次刷新后确认数据还在工作流用测试记录从头走到停止节点看收件箱任务分配是否正确后台任务间隔调成一分钟观察两次执行日志和实际数据处理结果日志搜索自定义包的 logger确认没有吞掉的异常还有个技巧值得单说改造前先把原始类备份到版本库里改坏了能立刻回滚。Maximo 的扩展类一旦打包进 businessobjects.jar靠“改回去再重新打”是很慢的有备份能省掉大量等待。从那以后我每次动数据库配置都强制走一遍“变更 → 应用配置变更 → 重启 → 换角色验证”不管改动看起来多小。这套流程看着笨但省下来的排查时间远比多等的几分钟值。希望帮到你。本文还有配套的精品资源点击获取