从 Project Service 自动化升级到项目作

我们很高兴宣布从 Microsoft Dynamics 365 Project Service Automation 升级到 Microsoft Dynamics 365 Project Operations 的三个阶段中的第二个阶段。 本文概述了踏上这一令人兴奋的旅程的客户。

升级交付计划分为三个阶段。 阶段 3 现在适用于客户。

升级过程功能

在升级过程中，升级日志将添加到站点映射，使管理员能够更轻松地诊断故障。 除了新接口之外，还添加了新的验证规则，以确保升级后的数据完整性。 以下验证将添加到升级过程。

先决条件

若要符合升级条件，必须满足以下条件：

• 必须将有效的 Project Operations 许可证分配给所有活动用户。
• 必须在至少一个非生产环境中验证升级过程，其中包含与生产环境一致的代表性数据集。
• 目标环境必须更新到最新的 Project Service Automation 可用版本。
• 允许包含违反 Project for Web 限制 的项目的环境使用 Project Operations 的 Microsoft Project 桌面加载项（ 此处的文档）。 不包含包含 >包含 500 个任务的项目的环境无法使用外接程序。

随着第 3 阶段升级的发布，各个项目需要独立于环境进行升级。 升级项目后，它内置于 Microsoft Project for the Web，并且可从“项目作”中的“任务”选项卡进行编辑。 在查看项目实体时选择升级按钮时，验证检查将开始，以确保项目符合 Project for the Web 的项目和任务 限制 。 仍可使用 外部计划 或 Project 桌面加载项管理未升级或无法升级的项目。 升级的项目将不再可使用 Project 桌面加载项进行编辑。

许可

如果你有 Project Service Automation 的活动许可证，则可以安装和使用 Project Operations，其中包括 Project Service Automation 的所有功能等。 这样，就可以在生产环境中继续使用 Project Service Automation 时测试 Project Operations 的功能。 项目服务自动化许可证过期后，必须转换到 Project Operations。 规划此转换时，必须考虑到 Project Operations 许可证不包含 Project Service Automation 许可证的事实。

测试和重构自定义

首先，将所有自定义项导入到干净的 Project Operations Core 环境中，以确认导入是否成功，并且业务运营按预期方式运行。

以下是需要注意的一些事项：

• 由于缺少依赖项，导入可能会失败。 换句话说，自定义项引用了项目作中删除的字段或其他组件。 在这种情况下，请从开发环境中删除这些依赖项。
• 如果非托管解决方案和托管解决方案包含未自定义的组件，请从解决方案中删除这些组件。 例如，自定义 Project 实体时，仅向解决方案添加实体标头。 不要添加所有字段。 如果以前添加了所有子组件，则可能需要手动创建新解决方案并向其添加相关组件。
• 窗体和视图可能不会按预期显示。 在某些情况下，如果自定义了任何现用窗体或视图，则自定义项可能会阻止项目作中的新更新生效。 若要识别这些问题，我们建议你并行查看项目作的全新安装，并安装包含自定义项的项目作。 比较企业中最常用的表单，以确认窗体的版本仍然有意义，并且不缺少表单的干净版本的内容。 对已自定义的任何视图执行同一类型的并行审阅。
• 业务逻辑在运行时可能会失败。 由于在导入时未验证对插件中的字段的引用，因此业务逻辑可能会失败，因为对字段的引用不再存在，因此可能会收到类似于以下示例的错误消息：“'Project'实体不包含 Name = 'msdyn_plannedhours' 和 NameMapping = 'Logical'的属性。在这种情况下，请修改自定义项，使其使用新字段。 如果在插件逻辑中使用自动生成的代理类和强类型引用，请考虑从干净安装重新生成这些代理。 通过这种方式，可以轻松识别插件依赖已弃用字段的所有位置。

更新自定义项以完全导入项目作后，请继续执行后续步骤。

开发环境中的端到端测试

启动升级

1. 在 Power Platform 管理中心，找到并选择你的环境。 然后，在应用程序中找到并选择 Dynamics 365 项目作。

2. 选择 “安装 ”以开始升级。 Power Platform 管理中心将此安装作为新安装提供。 但是，检测到早期版本的 Project Service Automation，并且将升级现有安装。

   升级完成后，环境应显示已安装 Project Operations，并且未安装 Project Service Automation。

   根据环境中的数据量，升级可能需要几个小时。 管理升级的核心团队应在非业务时间内相应地计划并运行升级。 在某些情况下，如果数据量很大，则应在周末运行升级。 有关计划的决定应基于较低环境中的测试结果。

3. 根据需要升级自定义解决方案。 此时，请在本文的 “测试和重构自定义 ”部分中部署对自定义项所做的任何更改。

4. 转到 make.powerapps.com，从门户右上角的下拉列表中选择环境，从左侧菜单中选择 “解决方案 ”，选择 “项目作已弃用的组件 ”解决方案，然后选择“ 卸载”。

   此解决方案是一种临时解决方案，用于保存升级期间存在的现有数据模型和组件。 通过删除此解决方案，可以删除不再使用的所有字段和组件。 这样，就可以帮助简化接口，并简化集成和扩展。

升级到 Project Operations Core

以下步骤描述了升级过程和关联的错误日志记录：

1. PSA 版本检查： 若要安装 Project Operations，必须安装最新的 Project Service Automation Release。
2. 预验证： 当管理员启动升级时，系统会对项目作解决方案的核心的每个实体运行预验证作。 此步骤验证所有实体引用是否有效，并确保与 WBS 相关的数据在 Project for Web 的已发布限制范围内。
3. 元数据升级： 成功预验证后，系统会启动对架构的更改，并创建已弃用的组件解决方案。 完成所有必需的自定义重构后，可以删除此已弃用的解决方案。 此步骤是升级过程最长的一部分，最长可能需要四个小时才能完成。
4. 数据升级： 在元数据升级步骤中完成所有必需的架构更改后，数据将迁移到新架构，并完成任何必需的默认值和重新计算。
5. 项目计划引擎更新： 成功升级数据后，主页上的 “计划 ”选项卡将重新标记 “任务”。 当用户在升级后选择此选项卡时，会定向到跟踪网格以查看 WBS 的只读版本。 若要编辑 WBS，它们必须启动计划 转换过程。 没有预先存在的 WBS 的所有项目都可以直接使用新的计划体验，而无需转换。

验证常见方案

验证特定自定义项时，建议还查看跨应用程序支持的业务流程。 这些业务流程包括但不限于销售实体（如报价和合同）的创建，以及创建包含 WBS 的项目以及实际项目的审批。

Project Service Automation 和 Project Operations 之间的重大更改

本部分汇总了 Project Service Automation 和 Project Operations 之间的重大更改。

项目规划

Project Operations 中的项目规划功能不再依赖于客户端逻辑和服务器端逻辑的组合。 相反，Project Operations 使用 Project for web 作为其计划引擎。 这种计划功能的更改可实现多种新功能，例如开发板和甘特视图、资源驱动规划、 任务清单项和项目计划模式。 新的计划功能也受一组丰富的新 应用程序编程接口（API）支持。 这些 API 旨在帮助确保 WBS 中创建、更新或删除实体的编程作会损坏计划中的计算字段。

计费和定价

作为对项目运营的持续投资的一部分，计费和定价中提供了多个新功能。 下面是一些示例：

• 记录项目和项目任务的材料使用情况
• 分包合同管理
• 预付款和保留款合同
• 合同上限状态和验证
• 基于任务的计费

资源管理

Project Operations 为通用资源计划（URS）板和计划助手提供可选支持。 这种新体验在 2023 年 4 月的浪潮中成为强制性的。

常见问题

当前支持哪些部署类型进行升级？

如何在升级工具可用之前安装项目作？

在升级工具可用之前，有两个选项可用于安装 Project Operations：

• 预配新环境。
• 在 Project Service Automation 不存在的任何销售组织中单独部署 Project Operations。

如果项目服务自动化安装在组织上，但未使用，则可以将其卸载。 完全删除 Project Service Automation 后，可以在同一组织中安装 Project Operations。