- 场景描述： 功能非常不好用，体验非常差，主要体现在以下几方面： 1、通过swagger的形式提取API的出入参非常不好用，一般业务人员不清楚swagger的格式要怎么填。另外也弄不明白普通API，外键依赖API，纯关系API到底有什么区别。 2、在后续的API与数据实体/关系实体做映射时，API的出参不支持多层json嵌套格式，目前出参格式限制为data.[*].xx的一层形式，不是这种格式在API映射调试时（例如result.[*].xx或者result.[*].xx.xx这类形式），就各种报错，非常的不友好 建议方案： 1、入参由用户直接输入，做成类似postman添加入参的形式，简单明了。 2、出参通过调用一次API后自动识别出来，不要让用户一个一个的在swagger中填写。 3、不要限定出参格式，要灵活支持各种出参形式，支持多层json嵌套格式，任意一个出参都可以与数据实体的属性映射上。 场景描述： 功能非常不好用，体验非常差，主要体现在以下几方面： 1、通过swagger的形式提取API的出入参非常不好用，一般业务人员不清楚swagger的格式要怎么填。另外也弄不明白普通API，外键依赖API，纯关系API到底有什么区别。 2、在后续的API与数据实体/关系实体做映射时，API的出参不支持多层json嵌套格式，目前出参格式限制为data.[*].xx的一层形式，不是这种格式在API映射调试时（例如result.[*].xx或者result.[*].xx.xx这类形式），就各种报错，非常的不友好 建议方案： 1、入参由用户直接输入，做成类似postman添加入参的形式，简单明了。 2、出参通过调用一次API后自动识别出来，不要让用户一个一个的在swagger中填写。 3、不要限定出参格式，要灵活支持各种出参形式，支持多层json嵌套格式，任意一个出参都可以与数据实体的属性映射上。
- 场景描述： 1、按照现有实验手册做完，生成jar包后，后续怎么使用？工业数字模型驱动，到底该如何使用？ 建议方案： 1、最好扩充实验手册，jar包在服务器的使用、整个部署全流程走一遍，有个整体的印象更好。 场景描述： 1、按照现有实验手册做完，生成jar包后，后续怎么使用？工业数字模型驱动，到底该如何使用？ 建议方案： 1、最好扩充实验手册，jar包在服务器的使用、整个部署全流程走一遍，有个整体的印象更好。
- 场景描述： 我在进行到这个创建idme模型这一步时，按照指导手册登录设计态，但是进去里面是是空白的，如图2所示，与指导手册所显示的配置页面完全不同，我反复核对过是不是点进来的跳转链接不对，但是只有这个地方是进入设计态的。[图片][图片] 场景描述： 我在进行到这个创建idme模型这一步时，按照指导手册登录设计态，但是进去里面是是空白的，如图2所示，与指导手册所显示的配置页面完全不同，我反复核对过是不是点进来的跳转链接不对，但是只有这个地方是进入设计态的。[图片][图片]
- 需求描述：PIXDMDEV_dev，PIXDMUAT_uat，PIXDM_production三个共有云环境应用，需要能修订服务编排 期望解决日期：尽快，期望在8月份帮放开 业务场景：PLM上层业务系统许多业务场景用到了js和java服务编排。环境用了70个左右服务编排，服务编排使用范围广，有saas客户需求变更、标准产品增加功能或修复bug等情况，后续服务编排有需要修改的情况，故申请白名单，支持修改服务编排。 三个saas环境的服务编排需要能正常使用。前面能正常用，后面关闭，对功能影响较大。 [图片] 具体业务场景举例：1）查询部件BOM，查询工艺计划BOM，创建变更请求，删除业务数据等 2）比如CAD结构，增加sql需要查询的字段 [图片][图片] 相关项目：公有云saas 需求交付时间：9/3 工作量：2天 需求描述：PIXDMDEV_dev，PIXDMUAT_uat，PIXDM_production三个共有云环境应用，需要能修订服务编排 期望解决日期：尽快，期望在8月份帮放开 业务场景：PLM上层业务系统许多业务场景用到了js和java服务编排。环境用了70个左右服务编排，服务编排使用范围广，有saas客户需求变更、标准产品增加功能或修复bug等情况，后续服务编排有需要修改的情况，故申请白名单，支持修改服务编排。 三个saas环境的服务编排需要能正常使用。前面能正常用，后面关闭，对功能影响较大。 [图片] 具体业务场景举例：1）查询部件BOM，查询工艺计划BOM，创建变更请求，删除业务数据等 2）比如CAD结构，增加sql需要查询的字段 [图片][图片] 相关项目：公有云saas 需求交付时间：9/3 工作量：2天
- 紧急需求：公有云PIXDMDEV_dev应用，支持修订服务编排 期望解决日期：今天或明天 业务场景：公有云PIXDMDEV_dev应用，poc功能。CAD文档结构，js服务编排，sql查询中需要增加字段 [图片] [图片] [图片] 紧急需求：公有云PIXDMDEV_dev应用，支持修订服务编排 期望解决日期：今天或明天 业务场景：公有云PIXDMDEV_dev应用，poc功能。CAD文档结构，js服务编排，sql查询中需要增加字段 [图片] [图片] [图片]
- 场景描述： 项目2- iDME：带您走进新一代工业软件数据建模 访问该项目，提示：无权限查看当前内容 [图片] 建议方案： 场景描述： 项目2- iDME：带您走进新一代工业软件数据建模 访问该项目，提示：无权限查看当前内容 [图片] 建议方案：
- 场景描述： [图片] [图片] 链接：https://lab.huaweicloud.com/experimentalStudy_qpxelhufts_3039_0_1724165247265 点击项目名词跳转后出现空白页？沙箱也能出bug么？建议修复下 建议方案： 场景描述： [图片] [图片] 链接：https://lab.huaweicloud.com/experimentalStudy_qpxelhufts_3039_0_1724165247265 点击项目名词跳转后出现空白页？沙箱也能出bug么？建议修复下 建议方案：
- 场景描述： [图片] 链接：https://lab.huaweicloud.com/experimentalStudy_qpxelhufts_3039_0_1724165247265 实验手册引导的图片和当前页面不符，建议不仅更新图片把沙箱也给更新以下，如找设计服务页面图片中是在左侧，沙箱是在下方？ 建议方案： 场景描述： [图片] 链接：https://lab.huaweicloud.com/experimentalStudy_qpxelhufts_3039_0_1724165247265 实验手册引导的图片和当前页面不符，建议不仅更新图片把沙箱也给更新以下，如找设计服务页面图片中是在左侧，沙箱是在下方？ 建议方案：
- 场景描述： 立讯场景下，由于业务的复杂性、及其扩展性，原生的API 接口已经不能满足需求。 场景1：以产品需求为例，产品需求模型 有基本属性---（参考对象）原始需求、扩展属性---（参考对象）成品料号 在产品需求查询的表格视图中，需要展示 产品需求信息、原始需求信息、成品料号编号等信息，还需要支持搜索。 场景2：以更改通告关联的受影响数据查询为例，更改通告模型 通过 link 与 部件、文档、CAD 文档 三种模型进行关联。 在该视图中，需要支持 link 的source 基本属性、扩展属性 、target 端的 基本属性、扩展属性 展示与过滤。 场景3：在全局搜索中，使用关键字 在多个模型中的编码与名称字段上进行数据匹配， 难点在于：数据量大，模型字段不统一（不一定有编码和名称字段，或者定义名称不一致） 客户要求指标： 由于业务人员关注的差异性，还需要支持多视图功能，实现可以配置个人所见的自定义表格视图。 由于客户的数据增长系数大，所以接口性能的要求高，常用的搜索场景分页查询不得超过2S， 使用 200 并发压测 20S 秒内完成不得超过5S。 建议方案： 因原生的API 接口无法满足需求，当前湃睿通过业务配置封装sql后，调用服务编排进行搜索，但是随着业务越来越复杂，调用方的sql复杂度大大提升，并且会带来各种的性能问题。 场景描述： 立讯场景下，由于业务的复杂性、及其扩展性，原生的API 接口已经不能满足需求。 场景1：以产品需求为例，产品需求模型 有基本属性---（参考对象）原始需求、扩展属性---（参考对象）成品料号 在产品需求查询的表格视图中，需要展示 产品需求信息、原始需求信息、成品料号编号等信息，还需要支持搜索。 场景2：以更改通告关联的受影响数据查询为例，更改通告模型 通过 link 与 部件、文档、CAD 文档 三种模型进行关联。 在该视图中，需要支持 link 的source 基本属性、扩展属性 、target 端的 基本属性、扩展属性 展示与过滤。 场景3：在全局搜索中，使用关键字 在多个模型中的编码与名称字段上进行数据匹配， 难点在于：数据量大，模型字段不统一（不一定有编码和名称字段，或者定义名称不一致） 客户要求指标： 由于业务人员关注的差异性，还需要支持多视图功能，实现可以配置个人所见的自定义表格视图。 由于客户的数据增长系数大，所以接口性能的要求高，常用的搜索场景分页查询不得超过2S， 使用 200 并发压测 20S 秒内完成不得超过5S。 建议方案： 因原生的API 接口无法满足需求，当前湃睿通过业务配置封装sql后，调用服务编排进行搜索，但是随着业务越来越复杂，调用方的sql复杂度大大提升，并且会带来各种的性能问题。
- 场景描述： 后续的项目现在都是springboot3.x版本，都是客户硬性要求，经过昨天的测试，目前iDME客户端SDK不支持springboot3.x版本，这让我们目前没法使用，只能自己去集成，得花费大量时间，不得不放弃使用。 建议方案：建议支持springboot3.x版本，现在3.x已经是主流了，2.x版本有很多漏洞 场景描述： 后续的项目现在都是springboot3.x版本，都是客户硬性要求，经过昨天的测试，目前iDME客户端SDK不支持springboot3.x版本，这让我们目前没法使用，只能自己去集成，得花费大量时间，不得不放弃使用。 建议方案：建议支持springboot3.x版本，现在3.x已经是主流了，2.x版本有很多漏洞
- 工业数字模型驱动引擎（iDME）云服务链接：https://console.huaweicloud.com/dme/?region=cn-north-4#/ 需求描述：iDME要能够适配多种数据库类型。比如一个iDME应用能同时适配mysql和pg数据库 应用场景：iDME要能够适配多种数据库类型，不能说每个数据库分别创建一个应用，模型分别要用导入导出，这就相当于创建了多个代码分支。违背了单一分支的设计理念。 优先级：中级 工业数字模型驱动引擎（iDME）云服务链接：https://console.huaweicloud.com/dme/?region=cn-north-4#/ 需求描述：iDME要能够适配多种数据库类型。比如一个iDME应用能同时适配mysql和pg数据库 应用场景：iDME要能够适配多种数据库类型，不能说每个数据库分别创建一个应用，模型分别要用导入导出，这就相当于创建了多个代码分支。违背了单一分支的设计理念。 优先级：中级
- 工业数字模型驱动引擎（iDME）云服务链接：https://console.huaweicloud.com/dme/?region=cn-north-4#/ 需求描述：设计态模型添加属性时，要规避所有数据库的关键字。不能说PG中创建时只规避PG关键字，mysql创建时只规避mysql关键字 业务场景：我们使用iDME开发产品，要兼容很多的数据库。希望iDME在校验属性是数据库关键字时，能同时把pg和mysql的都校验。而不是pg只校验pg，mysql只校验mysql。容易导致两种类型应用中的属性名不一样。 比如：如下场景，index是mysql数据库的关键字，期望它在pg应用中也校验住。能保证模型的属性在不同的数据库类型应用中都是一样的[图片] 优先级：中级 工业数字模型驱动引擎（iDME）云服务链接：https://console.huaweicloud.com/dme/?region=cn-north-4#/ 需求描述：设计态模型添加属性时，要规避所有数据库的关键字。不能说PG中创建时只规避PG关键字，mysql创建时只规避mysql关键字 业务场景：我们使用iDME开发产品，要兼容很多的数据库。希望iDME在校验属性是数据库关键字时，能同时把pg和mysql的都校验。而不是pg只校验pg，mysql只校验mysql。容易导致两种类型应用中的属性名不一样。 比如：如下场景，index是mysql数据库的关键字，期望它在pg应用中也校验住。能保证模型的属性在不同的数据库类型应用中都是一样的[图片] 优先级：中级
- 场景描述： 根据业主需求，HCSO数据湖要从iDME直连取数 建议方案： 1 在HSCO上，部署一个只读数据库实例，该实例能从iDME读取数据2 该实例每天从iDME更新增量数据3 该实例与HCSO数据湖通信打通，数据湖能从该实例直连取数 不需要修改代码，但需要进行变更，根据项目实施周期，请于8月20日前完成实例创建 场景描述： 根据业主需求，HCSO数据湖要从iDME直连取数 建议方案： 1 在HSCO上，部署一个只读数据库实例，该实例能从iDME读取数据2 该实例每天从iDME更新增量数据3 该实例与HCSO数据湖通信打通，数据湖能从该实例直连取数 不需要修改代码，但需要进行变更，根据项目实施周期，请于8月20日前完成实例创建
- 场景描述：设计态枚举导入时，若枚举已存在，导入时不支持覆盖，且导入对值的检验与新建对值的校验条件不一致 建议方案：支持导入覆盖已存在枚举，且导入与新建值校验一致 场景描述：设计态枚举导入时，若枚举已存在，导入时不支持覆盖，且导入对值的检验与新建对值的校验条件不一致 建议方案：支持导入覆盖已存在枚举，且导入与新建值校验一致
- 场景描述： 在立讯项目上，客户要求对系统功能进行压测，但是我们基于DME 做的系统大量使用了 拼装sql 去服务编排查询数据的情况，因为原生的API 接口已经不满足多模型查询的业务需求，只能使用这种方式进行查询，但是发现因业务复杂，sql复杂度提升，服务编排的性能较差。 建议方案：服务编排层面开启缓存机制，优化查询性能。 场景描述： 在立讯项目上，客户要求对系统功能进行压测，但是我们基于DME 做的系统大量使用了 拼装sql 去服务编排查询数据的情况，因为原生的API 接口已经不满足多模型查询的业务需求，只能使用这种方式进行查询，但是发现因业务复杂，sql复杂度提升，服务编排的性能较差。 建议方案：服务编排层面开启缓存机制，优化查询性能。
上滑加载中
推荐直播
-
华为云码道Agent集成与鸿蒙实战2026/08/11 周二 19:00-21:00
王一男-华为云码道产品规划专家；李炎-华为云码道产品专家；彭江敏-华为云鸿蒙端云一体化开发专家
本次直播带你解读华为云码道7月份产品新特性、新功能。更有专家演示码道Agent Space × 钉钉机器集成实战，从0到1打通消息通道；码道鸿蒙端云一体化实战，快速搭建员工签到系统。
回顾中 -
华为云开发者AI素养直播课·第五期2026/09/04 周五 16:00-18:00
林华鼎-华为云AI开发者运营负责人；蒋春阳-华为云AI开发者案例开发专家
本期直播内容： AI工具体验营 · 第5-8课连讲。Agent-Team 多智能体协作完成毕业设计实践
回顾中 -
华为云开发者AI素养ClassRoom·第六期2026/09/08 周二 19:00-20:00
樊渊-2026华为软件挑战赛冠军
高手来了：看软挑高手解析二维排样问题—从工业难题到算法突破
回顾中
热门标签