现在，我不是在谈论技术或代码，而是定制（二开）设计。正如我之前所说的，AX7引入的扩展不是为了新技术而发明的，而是为了实现更快、更简单的更新和升级。在讨论中很容易被忽视的一点是：在很多情况下不仅需要在代码中使用扩展，还要设计自定义以允许轻松更新。因此，这意味着一些定制无法从叠加到像这样的扩展中移植。但这并不意味着你不能给用户一个简单的按钮，她所要求的。 现在我们的应用程序版本8.0已经发布，但是没有过度分层的时代已经到来。为了说明以上几点，我想分享一个客户定制的例子，我从一个来自AX2012的客户那里获得了大量的现有代码，其中大部分都是“侵入式”（如in，not-easily-可升级，因为它改变了现有的代码）。当平台包最初被封装在平台更新2中时，这种特定的定制给这个客户带来了问题。与仅仅是一个客户要求一个特定的挂钩点（代表等）相比，他们需要一个定制，我们回到绘图板讨论最初的需求，看看我们是否可以用一种“较软”的方式重新实现它。
这是定制。有问题的客户有时会有大量采购订单，部门负责人需要批准适用于其部门的特定生产线。他们通常会筛选这些行以检查适用于他们的内容，然后只需单击一个按钮而不是逐行批准整个批次。他们希望直接从采购订单屏幕中查看所有详细信息。在AX2012中，对工作流框架（红旗）进行了定制，该框架向批准功能区添加了一个选项。而不仅仅是取消/拒绝/批准，新增了一个选项：批准所有行。然后，它将批准此PO中分配给用户批准的所有行。该框架被锁定在平台上，所以这个改变不能保留，也不能用扩展来完成...... 虽然可能不如原来那么好，但解决方案相对简单。我们没有改变框架本身，而是对批准步骤进行了定制。当用户批准一条线路时，我们可以提示她有其他线路，并询问她是否要批准所有线路。这有几个明显的优势：没有更多的框架更改（可能需要在下次升级时进行合并/更改），此外我们使用表面的公共API批准项目（而不是在批准本身内部添加逻辑）。因此，当框架改变其逻辑或增加新功能时，我们的定制将会自动利用这些功能。
这可以追溯到我一直希望尽可能遵守AX定制的原则：不要更改流程，而是要自动化现有流程。当一个请求进入时，我喜欢问一个简单的问题：不管这个过程多么复杂，你会如何手动执行这个操作？例如，客户需要额外的金融交易以某种方式发生在现有的逻辑中。问题：你会如何手动执行此操作？这让他们思考过程。通常他们会在某处引用原始交易来创建某些日记帐。好的，我们现在可以自动创建/发布该日志并确保它可以被捆绑回来吗？这与在原始流程内部创建单独的额外分类帐交易相反，这会非常干扰，我意识到会有这样的例子，即使这不适用。但是我质疑你是否会提出这样的问题：这意味着定制是否真的是一个好主意，以及如果应用套件改变了实现的某些细节，它将如何受到影响。从以前的版本升级的客户肯定会面临这些困境，但现在是重新考虑设计的时候，或者甚至可以完全地质疑定制的存在。
在其他情况下，这些侵入式定制中的一部分是为了纠正应用程序中奇怪或不正确的行为。我们中的大多数人都在那里：一些XPO坐在本地份额上，每位客户都可以重复使用。其中还有另一种心态变化：请提出支持请求！不要要求连接点，以便纠正错误行为，而是要求Microsoft修复这些行为！我认识并从经验中得知，“按设计”的答案很快就会变得非常累人，但事情正在迅速改变，这是每个人都可以改进产品并减少摩擦的方法之一。您的AX用户将感谢您，并且您的组织/客户将在下次升级时感谢您。
There's a lot of change that has come with AX7 (Dynamics 365 for Finance and Operations), ranging from plentiful technical changes but also the way implementations are being run. Any large change is usually disruptive to existing users of the product, and it takes time to learn the changes and get used to them. There's been plenty of changes in some major releases of AX, but one type of change has now come around that we haven't had to deal with before: rethinking how we design customizations.
Now, I'm not talking about technology or code but rather DESIGN of customizations. As I've stated before, the extension paradigms in AX7 weren't invented for the sake of new technology, but as an enabler to get to quicker and easier updates and upgrades. What's largely overlooked in discussions is that in many cases this requires not just using extensions in your code, but also to design your customization to allow for easy updates. And as a result, this means that some customizations cannot be ported from over-layering into extensions just like that. But that doesn't mean you can't give the user the easy button she was asking for. Now that our version 8.0 of the Application is released, the era of NO over-layering is upon us. And to illustrate the points from above, I'd like to share an example of a customization I dealt with at a customer who came from AX2012 with plenty of existing code, and much of it "intrusive" (as in, not-easily-upgradable because it changes existing code). When the platform packages were originally sealed in Platform Update 2, this particular customization posed a problem for this customer. As opposed to being just one customer asking for a specific hook point (delegates, etc.) they need for one customization, we went back to the drawing board to discuss the original requirement and see if we could reimplement it in a "softer" way.
Here's the customization. The customer in question sometimes has large purchase orders and department heads need to approve specific lines that apply to their departments. They typically filter the lines to check what applies to them, and then just want to approve the whole lot with a click of a button as opposed to each line individually. They want to do this straight from the purchase order screen where they're reviewing all the details. In AX2012, a customization was made to the workflow framework (red flag) that adds an option to the approval ribbon. Instead of just cancel/reject/approve, a new option was added: approve all lines. It would then approve all the lines in this P.O. assigned to the user approving. The framework is locked in platform, so this change could not stay and couldn't be done with extensions... Although perhaps not as nice as the original, the solution was relatively simple. Instead of changing the framework itself, we made a customization on the approval step. When the user approves a line, we can prompt her that there are other lines and ask if she wants to approve all. This has several clear advantages: no more framework change (which may have to be merged/changed on next upgrade), plus we use the superficial public API to approve an item (as opposed to adding logic inside the approvals itself). So when the framework changes its logic or adds new features, our customizations will just use advantage of those automatically.
This goes back to a principle I always like to adhere to in AX customizations as much as possible: don't change the process, but automate existing processes. When a request comes in, I like to ask the simple question: how would you do this manually, regardless of how convoluted that process would be? For example, the customer needs an extra financial transaction to happen somehow somewhere in existing logic. Question: how would you do this manually? It makes them think about the process. Typically they would create some journal somewhere with references to the original transaction. Ok, so can we now just automate creating/posting that journal and make sure it can be tied back? This opposed to creating an individual extra ledger transactions inside the original process, which would be very intrusive, error-prone and would have to be reviewed with each upgrade to make sure we're in line with the original code or changes to the transactions frameworks.
I realize there will be examples where even this doesn't apply. But I challenge you to ask the question whether that means the customization is really a good idea at all, and how it would be impacted if the Application Suite changed some of the details of the implementation. Customers upgrading from previous releases will face these dilemmas for sure, but now is the time to rethink the design, or perhaps even question the existence of the customization entirely. In other cases, some of these intrusive customizations are done to correct strange or incorrect behavior in the application. Most of us have been there: some XPO sitting on a local share which you can re-use at every customer. And therein lies another mindset change: please file support requests! Don't ask for hookpoints so you can correct wrong behavior, rather ask Microsoft to fix the behavior! I realize and know from experience that the "by design" answer gets very tiring very quickly, but things are changing rapidly and this is one way everyone can improve the product and reduce friction. Your fellow AX users will thank you, and your organizations/customers will thank you on the next upgrade.