MuleSoft的一般开发最佳实践是什么

如何解决MuleSoft的一般开发最佳实践是什么

在为客户开发MuleSoft中的应用程序时，需要重点考虑哪些常见的最佳做法，这些重点是 Anypoint Studio 7.x.x和Mule 4 。

列出所有客户都遵循的建议。

请注意：我问这个一般性问题是关于SO的MuleSoft开发最佳实践的专门部分，而不是在用户拥有个人议程\用户驱动案例的情况下使用相似的标题。

请注意： >

解决方法

M子开发人员必须将其视为关键主题。

下面给出的是App开发阶段涉及的多种MuleSoft最佳实践。

发展最佳实践通常分为三类：

1. M子一般最佳做法
2. Mule Munits最佳做法
3. M子错误处理和异常方案最佳实践

M子一般最佳做法

注意：建议放在中。这些只是最佳实践，不是一种强制。

1. 命名约定
   • 流和子流名称。 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>
2. 属性参数化
   • 配置属性。 <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>
3. 将转换消息代码外部化为dw脚本文件。 A common rule of thumb is to use script files when the lines of code is greater than 10>
4. RAML和Project Files文件夹结构
   • 将所有.properties文件放入src / main / resources / properties
   • 将所有dw脚本文件放在src / main / resources / scripts中。
   • 在Design Center中进行设计时，将RAML示例，库，数据类型，securitySchemes和Traits放在专用文件夹中。
   • 为API Kit Router及其所有生成的流保留单独的文件。
   • 错误处理必须具有其自己的单独文件。除了此文件以外，其他任何地方都不能看到错误流。
5. 将所有连接器配置/全局元素移动到单独的“ global-config.xml”文件中。 This keep the rest of mule xml files clean and tidy>
6. 硬编码值
   • 必须知道哪些代码值必须“硬编码”，哪些不是。
   • 大多数全局元素配置必须经过属性参数化，而不是硬编码。例如，“重新连接策略，“连接空闲超时”，“最大空闲超时”，“主机”，“端口”，“用户名”，“密码”等）。
7. 属性值加密。重要信息必须加密。 Using secure-properties-tools.jar or Mule property editor>
8. 自动隐藏在云中心的“运行时管理器”选项卡中传递的敏感属性值。 Achieved using 'mule-artifact.json'>
9. 在Transform消息中使用函数，局部/全局变量来实施DRY
10. 为流程，选择等添加详细的内联XML注释。
11. 为Transform消息中的任何复杂转换添加描述性的多行代码注释。
12. 在数据编织中替换长重复的'if / else'语句'with match / case'。
13. 如果使用更多的选择路由器来增加流量。将每个选择范围重构为自己的子流。

    一个好的经验法则是，如果必须前后滚动Mule画布才能看到整个流程，那么它太复杂了，应该重写。

14. 尽可能避免Mule异步作用域调用。根据一些开发人员的投诉，它导致了数据完整性问题。
15. 请勿使用m子对象存储库进行长时间的重复操作。了解您的TPS。始终根据需求随时清除您的m子循环执行中的对象存储。
16. 跟踪流程执行中初始化的每个“变量”。使用完变量后，请务必确保清除或删除它们。 Helps you to have a clean process,removing unnecessary code manipulation and heap limitations>
17. 完成开发后，将m子记录器从“ 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>

确保不要超过仪表板中显示的应用程序70％的CPU使用率。相应地创建应用。 18.始终注意由致命错误\应用程序重新启动引起的数据丢失。 Always use a backup data centers like AWS,Database,Object stores,Mule Load Balancers etc>

M子穆尼特最佳做法

1. 永远不要忘记使用间谍和断言。
2. 基于场景的测试用例。
   • 成功方案。 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”中，而不是直接放置在Mocks或Events中。 use #[MunitTools::getResourceAsString('testExample.json')]>
3. 在“ src / test / resources”下包含Munit测试运行所需的文件，类似于具有“ src / main / resources”。

M子错误处理和异常方案最佳实践

1. 必须根据要求适当地包括所有错误状态代码。
2. 错误必须在“ global-error-handling.xml”文件中单独指定。
3. 所有异常\错误必须正确分配，如下所示
   • 系统异常Source related data exceptions>
   • 业务异常Target\End System exceptions (Not to be bothered by the Mule APP,but must be handled)>
   • 系统\应用程序错误
4. 欣赏对象存储和数据队列对失败消息和记录重新处理的用法。
5. 具有针对所有基于HTTP的错误的重试机制。

---

您能想象通过遵循一些简单的建议可以避免的所有痛苦时刻吗？

希望对您有所帮助！