微软MBS关键技术概览.docVIP

微软Dynamics AX技术概览 1．微软ERP系统源代码分层技术架构 Dynamics AX 向用户开放源代码并为用户提供强大开发环境和语言。Dynamics AX是一个完全方面向对象体系架构和开发环境， 业务逻辑存放在名为“类”较小模块化对象中。用户界面存放在表单、报表和菜单中。能够自由添加、修改或置换任意 Dynamics AX 对象。 表 表 (1616) 类 (5041) 表单 (1894) 菜单 (65) 报表 (721) 商务逻辑 用户模板层 Dynamics AX：面向对象体系架构 对象源代码是以多层代码形式提供。标准 Dynamics AX 代码进入系统（SYS）层。微软在 DIS层(包含处理方案，分销商，当地)对语言、货币、规则等进行当地化。我们竞争对手方法将只提供其系统或DIS代码，直接对该代码进行修改。这个方法存在问题是：在升级过程中保留定制唯一方法是在成百上千代码行中一行行地重新修改定制，而且一次只能重新申请一行。Dynamics AX 则不存在这么问题；我们提供了能够控制四个代码层，分别为业务、合作伙伴、用户和使用人员层。只需将对象从SYS/DIS 层继承（或复制）到这四个层中，然后在这四个层中进行定制，改写标准 Dynamics AX 系统中逻辑。因为 Dynamics AX 将业务逻辑拆分为很多很小对象，而不是巨大整体模块，才得以实现这种分层方法。 Dynamics AX分层技术见下图： 从选择商务管理应用软件开始，每个用户全部见面临两难境地：她们必需决定：1) 对软件包进行定制，以满足企业业务实践，从而保持自己独特竞争优势。不过软件包经过修改后，可能难以甚至无法进行升级，或 2) 更改企业业务实践，方便适应软件包。?Dynamics AX 方法无须面临这种两难境地，而且在应用软件和业务步骤之间能够找到最好平衡点。使用 Dynamics AX，能够使软件适应您自己管理方法而不是供给商认为管理方法！进行定制后，经过将定制内容导入下一版本，仍然能够以极低成本升级 Dynamics AX 系统，且大多数情况下无须重新编码。这么，就能够充足利用微软在 Dynamics AX 研发 (RD) 方面注入巨大投资。 我们能够看一个用户案例。用户甲选择根据其整体业务架构来组织四个代码层。将适适用于全局用户修改放在业务层（这些修改是由 Dynamics AX Global Design Team 进行，该小组由 Columbus IT、TECTURA和eBEC组成）。用户甲发觉，和标准 Dynamics AX 相比，Columbus IT信贷管理、TECTURA 高级分发和eBEC精益制造更适合企业业务，加上组成“全局构建”24处用户甲全局修改。所以，她们将此对象插入了业务层。保留合作伙伴层以存放适适用于全部全局用户、修改过对象，用户甲自己IT部门修改代码时能够使用该层。? 用户甲业务被划分为三个地域：美国、欧洲和亚太地域。这些地域有时可能存在不一样业务规则。比如，各地域订购项商品处理逻辑各不相同，所以 用户甲将该对象三个不一样版本放在用户层中。使用人员层用于隔离各国不一样系统版本。比如，用户甲为每个国家制订了不一样发票格式。所以，她们使用人员层能够存放29种差异很小发票对象。 Dynamics AX 内核按指定优先级次序调用对象进行工作，内核会从上向下搜索层极，并调用首先找到对象。比如，当内核调用发票对象时，它将立即在使用人员层找到和该用户所在国家匹配发票。不过，当调用全局计划对象时，内核最终在业务层上找到并实施该对象之前，将首先搜索合作伙伴、用户和合作伙伴层。当用户甲运行MRP时，因为用户甲或她们合作伙伴在系统层上方任意一个层中全部没有对该对象进行修改，内核将调用 Dynamics AX 标准MRP展现对象。 ? 2. 微软ERP系统支持环境及对象服务器 Dynamics AX 处理方案支持应用程序对象服务器（AOS）三层体系结构。下图是使用AOS三层处理方案简单示例。 三层体系结构 使用这种三层体系结构，一部分应用程序在用户端上实施，另一部分应用程序在 AOS 上实施。所以，全部和用户界面相关进程全部在由用户操作用户端上实施，而全部业务逻辑则在服务器上实施。 比如，当用户决定更新分类账时，用于选择此进程菜单是在用户端上实施，不过分类账更新进程本身是在服务器上实施。也就是说，无须将全部数据从数据库中经过 AOS 发送到要更新用户端，再经过系统返回到服务器。 远程用户端 因为三层体系结构使部分应用程序在用户端上实施，另一部分应用程序在 AOS 上实施，所以用户端计算机无须像双层处理方案要求那样含有很高性能。 群集功效和负载均衡 Dynamics AX 支持群集功效。群集功效意味着，当用户端数量增加到AO