在这篇文章中，我不会讨论IFS Cloud的功能部分。相反，我将分享我们在技术方面发现的内容：配置、报告、界面、修改、工作流程、API 和部署周期。
我的一位客户选择IFS Cloud作为 ERP 迁移项目的一部分。该环境现在是 25R2 版本，在该客户现场，我担任应用平台主管。
CRIM理解CRIM
IFS 项目中遇到的第一个词汇项是术语 CRIM：
配置
低代码改编、页面、字段、实体、投影和 BPA。
报告
快速报告、商业报告、版本和运营报告。
接口
REST/OData API、中间件、平面文件和 IFS Connect。
变化
Developer Studio、Marble、PL/SQL、构建和交付。
这种分类看似简单，但同一个需求可以调动多个技术对象。例如，添加字段可能需要配置属性、页面编辑，还可能需要验证工作流程。因此，CRIM并不总是对应于单个技术对象。
CC 作为配置
配置是在不直接修改 IFS 标准代码的情况下进行的改编。这项工作的很大一部分可以通过IFS Cloud Web 完成。
字段、实体、页面和投影
可以添加自定义属性、创建自定义实体、配置页面或扩展某些投影。然而，我们必须避免常见的捷径：实体不仅仅是一个表，投影也不仅仅是一个SQL视图。
一个实体代表一个数据模型对象，并且可以依赖多个数据库对象。投影将部分功能域公开为 REST 服务。它包含实体集，还包含操作、函数、结构、枚举和其他控件。
发布配置后，IFS 可以生成必要的数据库对象、刷新元数据并使新项目在受影响的投影中可访问。
对于习惯于直接探索 RDBMS 表的开发人员来说，入门可能会很混乱。该模型通过实体、投影、系统信息和 Explorer API 进行记录，但它并不总是显示为经典的关系图。
BPA 和工作流程
业务流程自动化 (BPA) 基于受 BPMN 启发的工作流设计器。它们允许您围绕 IFS Cloud 中执行的操作添加逻辑，而无需立即自定义标准代码。
特别是三个主要家庭：
- Validation：控制操作并在不遵守规则时阻止其验证；
- Process Enrichment：丰富或修改处理过程中传输的值；
- 用户交互：在此过程中向用户请求附加信息。
BPA 是IFS Cloud 的真正优势，但它们并不能取代通用编程语言。可能性已经确定，有时需要重新考虑是否需要保持在配置范围内。
Lobbies
大厅是个性化门户，提供流程、角色或一组指标的概述。用户通常喜欢它们，因为它们避免了通过多个屏幕来查找重要信息。
大厅确实有页面设置。这些参数可以存储在用户的个人资料中或在导航 URL 中传输。另一方面，所提出的控制措施并不总是提供丰富的真实商业价值列表。因此，用户可能需要了解公司、站点或项目代码。
最佳实践是限制参数的数量，使用相关的默认值，并在可能的情况下构建直接打开具有正确上下文的大厅的链接。
RR 类似报告
单词report涵盖了IFS Cloud中的多个工具系列。区分快速报告、操作报告和更高级的分析工具很重要。
快速报告
快速报告满足临时报告的需求。对于简单的表，可以使用 SQL 查询或查询设计器，然后将结果导出到 Excel。
它们对于快速生成列表非常有效，但是当您乘以过滤器时，参数可能会变得不可用。默认值会有所帮助，但您应该避免将快速报告变成完整的应用程序。
对于更高级的 Excel 需求，IFS 现在转向 Business Reporter。用于运营报告的旧 Excel 插件已在多个版本中被弃用，不应与 Business Reporter 混淆。
版本和运营报告
发票、订单或交货单等文件属于运营报告。 IFS Cloud 现在提供两种本机工具：安装在工作站上的 IFS Report Designer 和可通过 Web 访问的 IFS Report Studio – Designer。
当我们的项目在 23R2 开始时，可用工具的体验并没有达到我们对稳定性和生产力的期望。因此，我们为某些版本和某些高级屏幕选择了补充解决方案 Ootary。
这一观察必须注明日期：自项目启动以来，本机产品已经不断发展，特别是在 Report Studio 中。第三方解决方案可以消除阻塞需求，但它也引入了新环境、新语言、特定技能和额外的依赖关系。
II 作为接口
在我们的上下文中，IFS Cloud与其他应用程序之间的交换主要通过Blueway中间件。
IFS Cloud的开幕是其真正的亮点之一。 Explorer API 列出了可用的 OData 投影和服务及其实体集和文档。调用依赖于经典的 HTTP 方法和 JSON 交换。
寻找正确的 API
实用的方法是打开相关界面，激活IFS开发工具，观察网络调用情况。然后可以直接在API Explorer中打开相应的投影。
这种方法可以让你快速了解接口的作用，但页面使用的 API 不一定是系统间集成的最佳 API。 IFS 特别区分了高级 API、集成 API、标准 API 和实体服务 API。选择应取决于用例、预期稳定性和支持级别。
IFS连接
当集成依赖于消息、文件或更传统的协议时，IFS Connect 充当集成代理。它支持不同的连接器，包括 HTTP/HTTPS、FTP/SFTP、Mail 和 JMS，并具有转换机制。
因此，当目标系统不提供 API 时，仍然完全可以管理平面文件。它是有效的，尽管这种方法通常需要更多的监视、错误处理和命名约定。
MM 更改
修改是我在实践中掌握最少的部分。当配置工具不再足够并且有必要扩展IFS Cloud的内部功能时，它会进行干预。
在 IFS 文档中，这种方法称为内部扩展或定制。它是通过 IFS Developer Studio 执行的，可以使用 IFS 模型、用于客户端的 Marble、用于服务器逻辑的 PL/SQL，以及在某些情况下还可以使用 Java。
开发必须在定制层进行，不能直接修改标准文件。开发是使用 IFS Developer Studio 进行的，可以使用 PL/SQL 作为服务器部分，以及使用 Marble 作为IFS Cloud Web 屏幕。
Git、Sanity 构建和交付周期
交付变更的过程比从前端完成的简单配置更加结构化。在我们的项目中，理论进展如下：
- 1 在客户解决方案 Git 存储库中创建一个新分支；
- 2在Build Place的开发环境中进行开发和首次测试；
- 3 提交更改并将其推送到存储库；
- 4 创建合并请求，检查代码，然后将分支合并到主分支中；
- 5 在相关提交上启动Sanity Build；
- 6 纠正任何生成、数据库部署或编译错误，直到获得状态
san-OK； - 7从Build Place生成Delivery；
- 8 在为此目的提供的环境中测试此交付；
- 9 请求将其部署在Use Place 的环境中，按照正确的顺序：测试环境、登台或 UAT，然后是生产。
Sanity Build 不仅仅检查文件是否存在。特别是，它控制数据库代码的生成、部署和解决方案的编译。成功后，会生成一个健全的映像，并使用标签san-OK来标识提交。在准备可靠的交付之前，此步骤至关重要。
我不会假装掌握了整个部分：我知道流程和交付阶段，但当今最具结构化的定制仍然主要由我们的集成商执行。
ACP带有ACP的传输配置
直接在IFS Cloud中进行的配置必须进行组织并从一个环境传输到另一个环境。为此，IFS 提供应用配置包或ACP。
ACP 可以包含多种类型的配置对象：属性、页面、配置的投影、工作流、事件或其他支持的元素。
重要的一点：一个配置对象一次只能属于一个ACP。此外，从源包中删除对象不会在后续导入期间自动将其从目标环境中删除。
BDR尽早启动BDR
最后我提出一条建议，该建议更关注项目而不是开发：让用户尽快处理 BDR。
在IFS词汇中，BDR对应于基本数据需求，即流程运行所必需的配置数据。例如，这包括税码、付款条件、会计组、状态、位置和许多其他存储库。
WEB对我们帮助很大的社区资源
在项目过程中， DSJ 的博客给了我们很大的帮助。官方 IFS 文档仍然很重要，但它非常广泛，有时描述的平台的可能性比解决现场遇到的问题的具体方法更多。
相反，DSJ 发布了直接可用的示例，包括围绕工作流程、REST 调用、身份验证、集成、故障排除和报告的实际案例。有几次，他的文章让我们能够快速理解我们仅从文档中难以重建的机制。
根据我们的经验，这个博客通常比 IFS 论坛对我们更有用。该论坛包含许多有趣的信息，但具体的技术问题可能很长一段时间都得不到解答。一篇详细的文章，加上一个完整且可重现的示例，比在最初的问题之后中断的讨论线程提供更多的价值。
非常感谢 DSJ 博客作者的分享工作。在IFS Cloud这样庞大的生态系统中，这种类型的独立资源可以让项目团队节省大量时间。
✓我记得IFS Cloud
IFS Cloud是一个功能强大且特别开放的平台。它创建配置、自动化流程和公开 API 的能力使集成项目变得更加容易。
这种力量伴随着词汇、开发模型和需要时间的生命周期。你必须学会在配置、报告、界面和修改之间进行选择，但也要接受一个看似简单的需求可以调动几块砖头的事实。
我们的团队在项目阶段直接学习了大部分这些概念。本文当然仍然包含简化内容。因此欢迎大家在评论中交流和指正。
当我写下这些文字时，我还参加了 IFS 法国用户俱乐部，这是一个将我们的体验与其他客户的体验进行比较的绝佳机会。
评论
0 条评论暂无已发布评论，欢迎率先参与。