MuleSoft 中的一般开发最佳实践是什么
What are the General Development Best Practices in MuleSoft
在 MuleSoft 中为客户开发应用程序时需要考虑哪些常见的最佳实践，重点是 Anypoint Studio 7.x.x 和 Mule 4。
列出您对任何客户都遵循的建议。
请注意：我问这个一般性问题是为了在 SO 上有一个专门的 MuleSoft 开发最佳实践部分，而不是让用户拥有自己的个人 agendas\user 驱动案例场景。
Mule 开发人员必须将此视为一个关键主题。
下面给出了应用程序开发阶段涉及的范围广泛的 MuleSoft 最佳实践。
开发最佳实践通常分为三类：
- Mule 一般最佳实践
- Mule Munits 最佳实践
- Mule 错误处理和异常场景最佳实践
Mule 一般最佳实践
注：建议放在<>中。这些只是最佳实践，并非强制。
- 命名约定
- 流程和子流程名称。 <
Must use camelCase>
- XML 个文件和属性文件 <
Must be all lower case with '-' in between words>
- 其他常见文件（示例、JSON 文件、脚本）<
Must use camelCase>
- 其余所有（组件、转换器、范围、流控制）。 <
First letters of each word must be capitalized. Spaces must be used between words>
- 属性参数化
- 配置属性。
<All configurations must be declared as *key=value* in the property files>
- 基于环境的属性。 <
Configuration properties must be segregated into files based on the *Environment* we deploy the app. Example "config-dev.properties", "config-qa.properties", "config-prod.properties">
- 运行时属性变量。
<Should be used to fetch appropriate ".properties" files needed for the environment we deploy. Example, name your environment files as "/config-${env}.properties" using Configuration properties in global elements and pass 'env=dev' or 'env=qa' as a Runtime variables in Run Configurations. We can also pass global arguments like 'crypto.key=w4ref$%wrfw3', used to decrypt encrypted values>
- 将转换消息代码外部化为 dw 脚本文件。 <
A common rule of thumb is to use script files when the lines of code is greater than 10>
- RAML 和项目文件文件夹结构
- 将所有 .properties 文件放入 src/main/resources/properties
- 将所有dw脚本文件放在src/main/resources/scripts.
- 在设计中心进行设计时，将 RAML 示例、库、数据类型、securitySchemes 和 Traits 放在专用文件夹中。
- 为 API Kit Router 及其生成的所有流保留一个单独的文件。
- 错误处理必须有自己单独的文件。除此文件外，不得在其他任何地方看到错误流。
- 将所有连接器 Configurations/Global 元素移动到单独的 'global-config.xml' 文件中。 <
This keep the rest of mule xml files clean and tidy>
- 硬编码值
- 必须知道哪些代码值必须 'Hard code' 哪些不需要。
- 大多数全局元素配置必须 属性 参数化而不是硬编码。例如，'重新连接策略，'Connection Idle Timeouts'、'Max Idle Timeouts'、'host'、'port'、'usernames'、'passwords' 等等。
- 属性 值加密。关键信息必须加密。 <
Using secure-properties-tools.jar or Mule property editor>
- 自动隐藏敏感信息 属性 在云中心的运行时管理器选项卡中传递的值。 <
Achieved using 'mule-artifact.json'>
- 使用函数，local/global Transform 消息中的变量来执行 DRY
- 为流程、选择等添加详细的内联 XML 评论
- 为转换消息中的任何复杂转换添加描述性多行代码注释。
- 替换数据编织中的长重复 'if/else' 语句 'with match/case'。
- 如果使用更多的路由器选择流量越来越大。将每个选择范围重构为它自己的子流程。
A good rule of thumb is that if you have to scroll the Mule canvas back and forth to see the whole flow, it's too complex and should be rewritten.
- 尽可能避免 Mule 异步范围调用。根据多个开发人员的投诉，它导致了数据完整性问题。
- 不要使用 mule-objectstores 进行 fast-long 重复操作。了解您的 TPS。始终根据要求不时清除 mule 循环执行中的对象存储。
- 跟踪流程执行中初始化的每个 'variable'。始终确保在使用完变量后清除或删除变量。 <
Helps you to have a clean process, removing unnecessary code manipulation and heap limitations>
- 完成开发后，将您的 mule 记录器从 'INFO' 更改为 'DEBUG'。
<Helps you by not over-burdening the Mule APP when deployed in cloudhub. Keeps the mule health monitor in check, so that the APP does not auto restart>
Make sure to never cross an App's 70 percentage CPU usage shown in dashboards. Create Apps accordingly.
18. Be always aware of Data losses caused by Fatal Errors\Application Restarts. <Always use a backup data centers like AWS, Database, Object stores, Mule Load Balancers etc>
Mule Munits 最佳实践
- 永远不要忘记使用 Spy 和 Asserts。
- 基于场景的测试用例。
- 成功案例。 <
Have one major test case to run through the entire API once>
- 失败场景。
<Have multiple test cases for each flow or subflows, testing for all possible failure situations, like testing mapping, choice routing etc>
- 始终模拟所有外部服务调用，例如 HTTP、DB、SQS 连接器。
<Never call your actual endpoints in Munits>
- 考虑将您的测试负载放在 'src/test/resources/testExample.json' 中，但不要直接放在模拟或事件中。 <
use #[MunitTools::getResourceAsString('testExample.json')]>
- 包括 'src/test/resources' 下 Munit 测试运行所需的文件，类似于 'src/main/resources'.
Mule 错误处理和异常场景最佳实践
- 必须根据要求适当包含所有错误状态代码。
- 必须在 'global-error-handling.xml' 文件中单独指定错误。
- 所有 Exceptions\Errors 必须正确分支，如下所示
- 系统异常 <
Source related data exceptions>
- 业务异常 <
Target\End System exceptions (Not to be bothered by the Mule APP, but must be handled)>
- System\Application 错误
- 欣赏对象存储和数据队列对失败消息和记录重新处理的使用。
- 为所有基于 HTTP 的错误提供重试机制。
您能想象我们可以通过遵循一些简单的建议来避免多少小时的痛苦吗？
希望对您有所帮助！
在 MuleSoft 中为客户开发应用程序时需要考虑哪些常见的最佳实践，重点是 Anypoint Studio 7.x.x 和 Mule 4。
列出您对任何客户都遵循的建议。
请注意：我问这个一般性问题是为了在 SO 上有一个专门的 MuleSoft 开发最佳实践部分，而不是让用户拥有自己的个人 agendas\user 驱动案例场景。
Mule 开发人员必须将此视为一个关键主题。
下面给出了应用程序开发阶段涉及的范围广泛的 MuleSoft 最佳实践。
开发最佳实践通常分为三类：
- Mule 一般最佳实践
- Mule Munits 最佳实践
- Mule 错误处理和异常场景最佳实践
Mule 一般最佳实践
注：建议放在<>中。这些只是最佳实践，并非强制。
- 命名约定
- 流程和子流程名称。 <
Must use camelCase> - XML 个文件和属性文件 <
Must be all lower case with '-' in between words> - 其他常见文件（示例、JSON 文件、脚本）<
Must use camelCase> - 其余所有（组件、转换器、范围、流控制）。 <
First letters of each word must be capitalized. Spaces must be used between words>
- 流程和子流程名称。 <
- 属性参数化
- 配置属性。
<All configurations must be declared as *key=value* in the property files> - 基于环境的属性。 <
Configuration properties must be segregated into files based on the *Environment* we deploy the app. Example "config-dev.properties", "config-qa.properties", "config-prod.properties"> - 运行时属性变量。
<Should be used to fetch appropriate ".properties" files needed for the environment we deploy. Example, name your environment files as "/config-${env}.properties" using Configuration properties in global elements and pass 'env=dev' or 'env=qa' as a Runtime variables in Run Configurations. We can also pass global arguments like 'crypto.key=w4ref$%wrfw3', used to decrypt encrypted values>
- 配置属性。
- 将转换消息代码外部化为 dw 脚本文件。 <
A common rule of thumb is to use script files when the lines of code is greater than 10> - RAML 和项目文件文件夹结构
- 将所有 .properties 文件放入 src/main/resources/properties
- 将所有dw脚本文件放在src/main/resources/scripts.
- 在设计中心进行设计时，将 RAML 示例、库、数据类型、securitySchemes 和 Traits 放在专用文件夹中。
- 为 API Kit Router 及其生成的所有流保留一个单独的文件。
- 错误处理必须有自己单独的文件。除此文件外，不得在其他任何地方看到错误流。
- 将所有连接器 Configurations/Global 元素移动到单独的 'global-config.xml' 文件中。 <
This keep the rest of mule xml files clean and tidy> - 硬编码值
- 必须知道哪些代码值必须 'Hard code' 哪些不需要。
- 大多数全局元素配置必须 属性 参数化而不是硬编码。例如，'重新连接策略，'Connection Idle Timeouts'、'Max Idle Timeouts'、'host'、'port'、'usernames'、'passwords' 等等。
- 属性 值加密。关键信息必须加密。 <
Using secure-properties-tools.jar or Mule property editor> - 自动隐藏敏感信息 属性 在云中心的运行时管理器选项卡中传递的值。 <
Achieved using 'mule-artifact.json'> - 使用函数，local/global Transform 消息中的变量来执行 DRY
- 为流程、选择等添加详细的内联 XML 评论
- 为转换消息中的任何复杂转换添加描述性多行代码注释。
- 替换数据编织中的长重复 'if/else' 语句 'with match/case'。
- 如果使用更多的路由器选择流量越来越大。将每个选择范围重构为它自己的子流程。
A good rule of thumb is that if you have to scroll the Mule canvas back and forth to see the whole flow, it's too complex and should be rewritten.
- 尽可能避免 Mule 异步范围调用。根据多个开发人员的投诉，它导致了数据完整性问题。
- 不要使用 mule-objectstores 进行 fast-long 重复操作。了解您的 TPS。始终根据要求不时清除 mule 循环执行中的对象存储。
- 跟踪流程执行中初始化的每个 'variable'。始终确保在使用完变量后清除或删除变量。 <
Helps you to have a clean process, removing unnecessary code manipulation and heap limitations> - 完成开发后，将您的 mule 记录器从 'INFO' 更改为 'DEBUG'。
<Helps you by not over-burdening the Mule APP when deployed in cloudhub. Keeps the mule health monitor in check, so that the APP does not auto restart>
Make sure to never cross an App's 70 percentage CPU usage shown in dashboards. Create Apps accordingly. 18. Be always aware of Data losses caused by Fatal Errors\Application Restarts. <
Always use a backup data centers like AWS, Database, Object stores, Mule Load Balancers etc>
Mule Munits 最佳实践
- 永远不要忘记使用 Spy 和 Asserts。
- 基于场景的测试用例。
- 成功案例。 <
Have one major test case to run through the entire API once> - 失败场景。
<Have multiple test cases for each flow or subflows, testing for all possible failure situations, like testing mapping, choice routing etc> - 始终模拟所有外部服务调用，例如 HTTP、DB、SQS 连接器。
<Never call your actual endpoints in Munits> - 考虑将您的测试负载放在 'src/test/resources/testExample.json' 中，但不要直接放在模拟或事件中。 <
use #[MunitTools::getResourceAsString('testExample.json')]>
- 成功案例。 <
- 包括 'src/test/resources' 下 Munit 测试运行所需的文件，类似于 'src/main/resources'.
Mule 错误处理和异常场景最佳实践
- 必须根据要求适当包含所有错误状态代码。
- 必须在 'global-error-handling.xml' 文件中单独指定错误。
- 所有 Exceptions\Errors 必须正确分支，如下所示
- 系统异常 <
Source related data exceptions> - 业务异常 <
Target\End System exceptions (Not to be bothered by the Mule APP, but must be handled)> - System\Application 错误
- 系统异常 <
- 欣赏对象存储和数据队列对失败消息和记录重新处理的使用。
- 为所有基于 HTTP 的错误提供重试机制。
您能想象我们可以通过遵循一些简单的建议来避免多少小时的痛苦吗？
希望对您有所帮助！