pub.xml:transform常失败的根本原因是stylesheet参数必须为Document对象而非字符串或路径，且XSL中import/include的样式表需预加载、命名空间前缀须严格匹配源XML；调试需用pub.xml:saveXML验证XSL完整性，性能场景应缓存Document并避免XPath深度遍历及UTF-8 BOM。
WebMethods Integration Server 中的 XML 转换，核心依赖于 pub.xml:transform 服务，而不是 XSLT 直接嵌入或外部调用——它封装了 Saxon，但行为受 IS 运行时约束，不完全等同于标准 XSLT 1.0/2.0 环境。
为什么 pub.xml:transform 经常失败或输出为空
常见现象是输入 XML 正确、XSL 文件能本地运行，但在 IS 中返回空字符串或抛出 java.lang.NullPointerException。根本原因通常是：
-
pub.xml:transform的stylesheet输入参数必须是 已加载到内存的 Document 对象（即ISDocument或WmXmlDocument），不能传文件路径或字符串内容（即使格式正确） - XSL 中若含
pub.xml:loadXML预加载并作为参数传入，则静默失败 - 命名空间处理不一致：XSL 中声明的
xmlns前缀必须与源 XML 实际使用的前缀严格匹配（IS 不自动做 prefix-URI 映射归一化）
如何安全传入 XSL 并避免 ClassCast 异常
必须分两步构造 XSL 输入：
- 先用
pub.xml:loadXML加载 XSL 文件（路径如/Resources/XSL/myTransform.xsl），输出为document类型变量 - 将该变量直接连入
pub.xml:transform的stylesheet参数；不要试图用pub.string:stringToXML转换字符串——这会生成不可用的XmlObject类型，触发ClassCastException - 若 XSL 依赖外部参数（如
），需在pub.xml:transform的parameters参数中传入java.util.Map结构（键为字符串名，值为字符串或 Boolean）
调试时如何快速验证 XSL 是否被正确解析
在调用 pub.xml:transform 前插入一个临时服务：
pub.xml:saveXML
input:
document → [上一步 pub.xml:loadXML 输出的 document]
filename → "/tmp/debug_xsl.xml"
encoding → "UTF-8"
然后 SSH 登录 Integration Server 主机，检查 /tmp/debug_xsl.xml 内容是否完整、无乱码、无截断。如果该文件本身已损坏（如含 BOM、编码混用、或 IS 读取时丢弃了 声明），后续 transform 必然失败。
性能敏感场景下应避开的写法
当单次转换 XML 超过 5MB 或每秒调用超 20 次时：
- 禁用
pub.xml:transform的动态加载模式：每次调用都重新 parse XSL，开销极大。应提前用pub.xml:loadXML加载一次，缓存其document输出到全局变量或 JDBC 存储中复用 - 避免在 XSL 中使用
//root/items/item - 不依赖
count()手动计算
最易被忽略的是 XSL 文件保存时的编码与 BOM：Windows 记事本默认存为 UTF-8 with BOM，而 pub.xml:loadXML 无法跳过开头的 EF BB BF 字节，直接报“Content is not allowed in prolog”。务必用 VS Code 或 Notepad++ 保存为 UTF-8 no BOM。
