本文不讨论 IFS Cloud 的业务功能，而是分享我们在技术层面的实践：配置、报表、接口、修改、工作流、API 与部署生命周期。

我的一位客户在 ERP 迁移项目中选择了 IFS Cloud。环境目前运行 25R2 版本，我在该客户项目中负责应用平台主管工作。

25R2客户使用的 IFS Cloud 版本
4CRIM 技术类别
2独立空间：Build Place 与 Use Place

CRIM理解 CRIM

IFS 项目中最先遇到的技术术语之一就是 CRIM：

C

配置

低代码扩展、页面、字段、实体、投影和 BPA。

R

报告

Quick Reports、Business Reporter、文档输出与运营报表。

I

接口

REST/OData API、中间件、平面文件和 IFS Connect。

M

修改

Developer Studio、Marble、PL/SQL、构建和交付。

这种分类看似简单，但同一项需求可能涉及多个技术对象。例如，新增字段可能需要配置属性、调整页面，还可能需要检查工作流。因此，一个需求并不总是只落在 CRIM 的单一类别中。

CC：Configuration（配置）

Configuration 指在不直接修改 IFS 标准代码的前提下进行扩展，其中很大一部分可以通过 IFS Cloud Web 完成。

字段、实体、页面和投影

IFS Cloud 用于配置或探索技术对象的屏幕
IFS Cloud 配置阶段使用的界面示例。

可以添加自定义属性、创建自定义实体、配置页面或扩展某些投影。然而，我们必须避免常见的捷径：实体不仅仅是一个表，投影也不仅仅是一个 SQL 视图。

一个实体代表一个数据模型对象，并且可以依赖多个数据库对象。投影将部分功能域公开为 REST 服务。它包含实体集，还包含操作、函数、结构、枚举和其他控件。

发布配置后，IFS 可以生成所需数据库对象、刷新元数据，并让新元素通过相关投影可用。

对于习惯直接查看 RDBMS 表的开发者，这套模型一开始可能不够直观。信息分散在实体、投影、系统信息和 API Explorer 中，并不总能以传统关系图的形式呈现。

BPA 和工作流程

IFS Cloud 中包含 REST 调用的 BPA 工作流程示例
IFS Cloud 中在 BPA 工作流内调用 REST API 的示例。

业务流程自动化（BPA）基于受 BPMN 启发的工作流设计器，可以围绕 IFS Cloud 中执行的操作添加逻辑，而无需立即修改标准代码。

主要包括三类：

  • Validation：控制操作并在不遵守规则时阻止其验证；
  • Process Enrichment：丰富或修改处理过程中传输的值；
  • User Interaction：在流程中向用户请求补充信息。

BPA 是 IFS Cloud 的重要优势，但不能替代通用编程语言。它的能力边界是明确的，有时需要重新判断需求是否应继续停留在配置层。

Lobbies

Lobbies 是可定制的门户，用于汇总流程、角色或一组指标。用户通常很喜欢这种方式，因为无需在多个页面之间切换才能找到关键信息。

Lobbies 支持页面参数，这些参数可以保存在用户配置中，也可以通过导航 URL 传递。但现有控件并不总能提供带有业务名称的丰富选择列表，因此用户有时仍需知道公司、站点或项目代码。

较好的做法是限制参数数量、设置合适的默认值，并在可能时构造能够直接以正确上下文打开 Lobby 的链接。

RR：Reports（报表）

report 一词涵盖 IFS Cloud 中的多个工具系列。区分 Quick Reports、操作报告和更高级的分析工具很重要。

Quick Reports

Quick Reports 适合临时报表需求。对于简单列表，可以使用 SQL 查询或查询设计器，并将结果导出到 Excel。

它们非常适合快速生成列表，但过滤条件过多时，参数界面会变得难以使用。默认值可以改善体验，但不应把 Quick Report 变成完整应用。

对于更高级的 Excel 需求，IFS 现在转向 Business Reporter。用于运营报告的旧 Excel 插件已在多个版本中被弃用，不应与 Business Reporter 混淆。

文档输出与运营报表

发票、订单和送货单等文档属于运营报表。IFS Cloud 目前提供两种原生工具：安装在工作站上的 IFS Report Designer，以及可通过 Web 使用的 IFS Report Studio – Designer。

我们的项目从 23R2 开始时，原生工具在稳定性和开发效率方面没有达到预期。因此，我们为部分文档输出和高级页面选择了 Ootary 作为补充方案。

这一观察必须注明日期：自项目启动以来，IFS 原生产品一直在演进，特别是在 Report Studio 中。第三方解决方案可以解除关键阻塞，但也会引入新的环境、语言、专项技能和额外依赖。

II：Interfaces（接口）

探索IFS Cloud中的接口及其投影
识别屏幕使用的投影通常是集成的起点。

在我们的上下文中，IFS Cloud 与其他应用之间的数据交换主要通过 Blueway 中间件完成。

IFS Cloud 的开放性是其明显优势之一。API Explorer 会列出可用的 OData 投影与服务，包括实体集和文档。调用使用标准 HTTP 方法并交换 JSON。

寻找正确的 API

IFS Cloud 带有 OData 文档的 API Explorer
API Explorer 可用于查找投影、实体、操作及其相关文档。

一个实用方法是打开目标页面、启用 IFS 开发工具并观察网络请求，再直接在 API Explorer 中查看对应投影。

这种方法可以快速了解界面的工作方式，但页面调用的 API 不一定最适合系统间集成。IFS 明确区分 Premium API、Integration API、Standard API 和 Entity Service API；选择时应结合使用场景、稳定性要求与支持级别。

IFS Connect

当集成依赖于消息、文件或更传统的协议时，IFS Connect 充当集成代理。它支持不同的连接器，包括 HTTP/HTTPS、FTP/SFTP、Mail 和 JMS，并具有转换机制。

因此，当目标系统没有 API 时，仍然可以使用平面文件完成集成。这种方式有效，但通常需要更严格的监控、错误处理和命名规范。

MM：Modifications（修改）

Modifications 是我实际接触最少的一类。只有当配置工具无法满足需求、必须扩展 IFS Cloud 内部能力时，才会进入这一层。

IFS 文档将这种方式称为 extending on the inside（内部扩展）或 customization（定制）。开发通过 IFS Developer Studio 完成，可涉及 IFS 模型、客户端使用的 Marble、服务器端的 PL/SQL，以及某些场景下的 Java。

开发必须位于 customization layer，不得直接修改标准文件。通常使用 IFS Developer Studio；服务器端可使用 PL/SQL，IFS Cloud Web 页面则使用 Marble。

Git、Sanity Build 与 Delivery 生命周期

交付修改的流程比前端配置更严格。在我们的项目中，标准流程如下：

  1. 1 在 Customer Solution Git 仓库中创建新分支；
  2. 2在 Build Place 的开发环境中完成开发和首轮测试；
  3. 3 提交更改并将其推送到代码仓库；
  4. 4 创建合并请求，检查代码，然后将分支合并到主分支中；
  5. 5 在相关提交上启动Sanity Build；
  6. 6 纠正任何生成、数据库部署或编译错误，直到获得状态san-OK；
  7. 7从 Build Place 生成Delivery；
  8. 8 在为此目的提供的环境中测试此交付；
  9. 9 请求按正确顺序部署到 Use Place 环境：测试、预生产或 UAT，最后是生产。

Sanity Build 不仅仅检查文件是否存在。特别是，它还会验证数据库代码的生成与部署，以及整个解决方案的编译。成功后，会生成通过验证的 Sanity Build 镜像，并使用标签san-OK来标识提交。在准备可靠的交付之前，此步骤至关重要。

我不会声称已经掌握这一整套领域：我了解流程和交付阶段，但目前结构性较强的定制仍主要由我们的集成商完成。

ACP使用 ACP 传输配置

直接在 IFS Cloud 中进行的配置必须进行组织并从一个环境传输到另一个环境。为此，IFS 提供 Application Configuration Package（应用配置包，ACP）。

ACP 可以包含多种类型的配置对象：属性、页面、配置的投影、工作流、事件或其他支持的元素。

重要的一点：一个配置对象一次只能属于一个 ACP。此外，从源包中删除对象不会在后续导入期间自动将其从目标环境中删除。

BDR尽早启动 BDR

最后我提出一条建议，该建议更关注项目而不是开发：让用户尽快处理 BDR。

在 IFS 术语中，BDR 指 Basic Data Requirements，即流程运行所必需的基础配置数据，例如税码、付款条件、会计组、状态、站点以及许多其他基础数据。

WEB对我们帮助很大的社区资源

社区资源

在项目过程中， DSJ 的博客给了我们很大的帮助。IFS 官方文档仍不可或缺，但覆盖面非常广，有时更侧重介绍平台能力，而不是给出解决现场问题的具体做法。

DSJ 则发布了可以直接借鉴的示例，涉及工作流、REST 调用、身份验证、集成、故障排查和报表。多次实践中，他的文章帮助我们迅速理解仅靠文档很难还原的机制。

根据我们的经验，这个博客往往比 IFS 论坛更直接有效。论坛包含很多有价值的信息，但具体技术问题可能长期没有答案。带有完整、可复现示例的详细文章，通常比中途停止的讨论串更有帮助。

非常感谢 DSJ 博客作者的分享工作。在 IFS Cloud 这样庞大的生态系统中，这种类型的独立资源可以让项目团队节省大量时间。

✓我对 IFS Cloud 的几点总结

IFS Cloud 功能强大且开放度较高。它在配置扩展、流程自动化和 API 暴露方面的能力，为集成项目提供了便利。

这些能力也带来了专门术语、开发模型和需要时间掌握的生命周期。团队必须学会在 Configuration、Reports、Interfaces 和 Modifications 之间选择，并接受一个看似简单的需求可能同时涉及多个组件。

我们的团队是在项目实践中学习这些概念的，本文不可避免地有所简化，欢迎在评论区交流和指正。

当我写下这些文字时，我还参加了 IFS 法国用户俱乐部，这为我们与其他客户交流并对照实践经验提供了很好的机会。

↗官方来源