The objectives of this chapter are to:
Introduce the architecture of Microsoft Dynamics AX 2009.
Describe how Dynamics AX applications are developed through application modeling and program specification.
Provide an overview of the application model layering system.
Provide an overview of the application framework.
Explain the design of Enterprise Portal and the Reporting Framework.
Provide an overview of the operations environment.
The architecture of Dynamics AX comprises client and server components that scale to support many concurrent users who integrate with external applications and interoperate with many Microsoft products and technologies. This architecture includes a layered application model and the X++ programming language; it is supported by the MorphX development environment and executed by the Dynamics AX runtime environment.
The Dynamics AX architecture also provides an application framework that takes care of some of the technology requirements for business applications, allowing developers to focus on meeting enterprise resource planning (ERP) domain requirements for rich client, Web client, and integration applications.
This chapter gives a developer’s-eye overview of the Dynamics AX architecture, starting with a description of the Dynamics AX application development and runtime configurations, followed by a description of the components of the Dynamics AX architecture, and concluding with an overview of the operations environment.
Before diving into the specifics of the architecture, let’s look at how the architectural design enables developer productivity.
The architecture of Dynamics AX has been designed to make it easy to build, customize, and extend Dynamics AX ERP applications. One of the design goals of the architecture is to enable application developers to focus on business domain requirements by reducing and simplifying the technological aspects of a developer’s job. This design philosophy is enabled by a software design methodology, called model-driven development, that is based on developing a model for an application rather than writing actual code.
For example, the design of the Dynamics AX architecture can help you spend your time meeting financial, production, and logistics domain requirements rather than meeting user interface, client/server, and database access technology requirements. Dynamics AX makes this possible by satisfying technology requirements for the following set of typical application developer tasks:
Create a database schema and bind it to forms and reports, allowing users to enter and view data.
Navigate users between forms and reports while ensuring that role-based security is enforced.
Exchange data and calculated data with external applications.
The Dynamics AX development and runtime environments support three logical configurations, as illustrated in Figure 1-1:
The rich client is the primary client for Dynamics AX. It is a regular Windows application with a user interface consisting of menus, toolbars, forms, and so on.
You can develop a rich client application configuration using only the MorphX development environment. The rich client application is hosted by the Dynamics AX runtime environment. Rich clients communicate with the Application Object Server (AOS) using the Microsoft remote procedure call (RPC) communication technology.
The Web client is a client for Dynamics AX that runs inside a Web browser. It supports many of the same capabilities as the rich client does.
You develop a Web client application configuration by using the MorphX development environment, Microsoft Visual Studio 2008, and the Windows SharePoint Services framework. A Web client application is hosted by the Dynamics AX runtime, the ASP.NET runtime, and the Windows SharePoint Services runtime environments. SharePoint and ASP.NET components communicate via the Dynamics AX .NET Business Connector. For more information on the Dynamics AX Enterprise Portal, see Chapter 7, and for more on .NET Business Connector, see Chapter 10.
An integration client application brings Dynamics AX functionality into external applications, such as Microsoft Office Excel and Microsoft Office Outlook. An integration client application configuration is mostly developed using Visual Studio or other tools with .NET support or Windows Communication Foundation (WCF) support. Integration client applications are hosted by the Microsoft Dynamics AX runtime environment. ASP.NET Web services and IIS are required for hosting Web services. The external application communicates with the Dynamics AX runtime via the Dynamics AX Application Integration Framework (AIF) server or .NET Business Connector. For more on the AIF, see Chapter 17.
As a developer of Dynamics AX applications, your primary focus should be on modeling application elements to meet business requirements, relying on the rest of the architecture to meet technical requirements. Before looking at application modeling, explained in the following section, take some time to review the stack diagram in Figure 1-2, which illustrates the key functional areas of the Dynamics AX architecture.
The following sections explore key elements of this diagram and tell you where you can find more information about each.
The Dynamics AX development environments are MorphX and Visual Studio. MorphX is described in Chapter 2. Visual Studio, primarily used for developing Enterprise Portal and reports, is covered in Chapter 7 and Chapter 11. These environments provide a set of application modeling and programming tools for developing and extending Dynamics AX applications. Chapter 3, provides more information about the individual tools.
Application modeling is a method of declaratively specifying the structure and behavior of an application that is faster, less error-prone, and more precise than imperative programming. Specifying that data is mandatory for a field in a database record, for example, is fairly easy in the Dynamics AX application model because the Dynamics AX runtime environment ensures that the condition is true in all parts of the application that manipulate data in the table. This obsoletes the programming effort that would otherwise be required to maintain data integrity throughout the application.
The Dynamics AX application model also supports defining workflows. The defined workflows describe states and available actions for types of business documents. For example, a developer could model a Purchase Order Approval workflow that maps the tasks required to approve a purchase order. The workflows are honored by the Dynamics AX runtime environment, and the Windows Workflow Foundation engine is used for processing and configuring the workflows. Workflows are discussed in more depth in Chapter 9.
Because application modeling typically isn’t flexible enough to meet all business requirements, the Dynamics AX business logic is specified by the X++ programming language. X++ is an object-oriented language, much like C# and Java, that supports inheritance, encapsulation, and polymorphism. The language also includes syntax for writing database statements, much like those found in the SQL database manipulation language.
The following X++ code snippet uses the X++ SQL syntax. The language combines the simplicity of data lookup from SQL with the expressive power of object-oriented programming. You can invoke a method call directly on an object retrieved from the database.
while select customer
where customer.zipcode == campaignZipCode
{
customer.sendEmail(campaignId);
}For more details on the X++ programming language, refer to Chapter 4.
The model elements and X++ source code that comprise an object’s definition are called application elements, and they are managed with the Application Object Tree (AOT) development tool. The AOT is a user control in the MorphX environment that manages a dictionary of application elements.
Note
The name Application Object Tree is something of a misnomer. Application objects are instantiated only by the Dynamics AX runtime environment, and their definitions are developed with the help of the AOT. The tree also contains resources and references in addition to application object definitions. This book uses the abbreviation AOT to refer to the tree control, but it describes the nodes in the tree as mapping to application elements contained in a dictionary.
While developing your application, you can leverage a range of built-in application frameworks that provide typical technology requirements such as batching, number sequence generation, and error logging. The application frameworks in Dynamics AX are described in greater depth later in this chapter.
The Dynamics AX runtime environment and the Dynamics AX Enterprise Portal runtime environment execute the ERP application defined by the application model elements. The Dynamics AX runtime environment has model-driven features that are required for the support of user interaction with ERP database applications. For example, if you specify that a column model element on a user interface grid control requires mandatory data entry, the Dynamics AX runtime environment ensures that users enter data in that particular column.
The Dynamics AX runtime environment also has client and server features that are required to support the three-tier operations environment. For example, by automatically marshalling parameters, return values, and object references across the tiers, the Dynamics AX runtime environment ensures that all X++ business logic marked to run on the server tier will execute on the AOS. As a developer, you still need to pay attention to these aspects because they can impact performance. For more details, see Chapter 12.
Dynamics AX leverage many different standard communication protocols, including RPCs, HTTP, and SOAP, to invoke Web services.
As an application developer in Dynamics AX, you don’t have to understand the implementation details of these protocols, but you must pay close attention to the performance aspects when invoking logic on remote tiers. You need to keep in mind network properties such as bandwidth and latency to ensure the resulting application is responsive.
A cardinal requirement of an ERP system is that it be able to meet the customer’s needs. If you’re in the business of building general solutions that many customers license and install, you need a way for individual customers to customize your solution.
The application model layering system supports fine-grained partner and customer customizations and extensions. The MorphX development environment manages the application elements that exist in multiple layers of the model, and the runtime environment assembles the application elements from different layers so that application object instances can be created with customized and extended structure and behavior. The application model layering system is described in greater depth later in this chapter.
Any ERP application has technical requirements for licensing, configuration, and security. In Dynamics AX, the developer can control the behavior of these aspects directly in the application model. Licensing, configuration, and role-based security are enforced at run time—for example, the only enabled user interface components the user sees are those that he or she has access to. For more information see Chapter 13.
User and external application interactions are authenticated by the Windows integrated security system before any application features can be accessed. After authentication, the Active Directory service is used to associate a Windows user with a Dynamics AX user. Dynamics AX provides a security framework for authorizing Dynamics AX user and user group access to menu items and database data.
The Dynamics AX database layer supports both SQL Server and Oracle database systems. The database layer enables developers to focus on modeling the tables and fields required for various business scenarios without being concerned about SQL Server or Oracle specifics. For example, you can use the same X++ logic to query data regardless of which physical database engine the data is persisted in. Refer to Chapter 14, for more details.
The Windows XP, Windows Vista, and Windows Server operating systems provide the technology that components use to communicate with the Dynamics AX runtime environment.
Application model layering is the architectural principle in Dynamics AX that allows granular customizations and extensions to model element definitions and hence the structure and behavior of applications. When a version of Dynamics AX is released that is not specific to any country/region, all model elements that define the application reside in the lowest layer of an element layering stack. The Dynamics AX runtime environment, however, uses more than these element definitions when it instantiates application objects—it assembles an element definition from model elements at all levels of the element layering stack. Elements defined at higher levels of the element layering stack override elements defined at lower levels of the stack. The object that the runtime environment eventually instantiates is thus an instance of a dynamic type definition composed of model elements at multiple layers of the element layering stack.
Figure 1-3 illustrates the components in the application model layering system. Model elements are stored in a separate file on each layer whenever they are saved from MorphX. Element definitions are read from these files and dynamically composed by the Dynamics AX runtime environment. Object instances are created on either the server or the client, based on the model element definition. The client can be the MorphX development environment, the rich client, or the .NET Business Connector client.
Figure 1-4 shows the element layers in the application model layering system.
Table 1-1 contains a description of each element layer, including ID ranges.
Table 1-1. Layer Descriptions
Layer | Description | ID Range |
|---|---|---|
USP USR | User Individual companies or companies within an enterprise can use this layer to customize unique customer installations. | 50001–60000 |
CUP CUS | Customer Companies and business partners can modify their installations and add company-specific modifications to this layer. This layer is included to support the need for in-house development without jeopardizing modifications made by business partners. | 40001–50000 |
VAP VAR | Value-added reseller Business partners use this layer, which has no business restrictions, to add any development done for their customers. | 30001–40000 |
BUP BUS | Business solution Business partners develop and distribute vertical and horizontal solutions to other partners and customers. | 20001–30000 |
SL3 SL2 SL1 | Certified solutions Partners certified under the Microsoft Dynamics Industry Solution program distribute their solutions in the SL layers. | 1–20000 |
HFX | Hotfix The Dynamics AX Sustained Engineering team delivers critical hotfixes using the HFX layer. | 1–20000 |
GLP GLS | Global solutions The Dynamics AX Global Development and Localization team provides a set of GLS layers that contain country/region-specific functionality. | 1–20000 |
SYP SYS | System This is the lowest model element layer and the location of the standard Dynamics AX application. Only Microsoft has access to the element definitions at this layer. | 1–20000 |
As you see in Figure 1-4, the lowest layer is the system layer, and the highest is the user layer. You use the client configuration utility to specify the layer at which you want to customize and extend the Dynamics AX application. When the MorphX environment is launched, it adds or modifies elements at this layer, the working layer, of the model layering system. It cannot, however, modify or delete a model element defined at a higher model layer.
Note
The Dynamics AX runtime environment always composes model elements starting with the user layer, regardless of the layer in which you are working.
When you modify a model element at a layer lower than the working layer, the element is copied to the working model element layer. A class header or method element, for example, is copied to the working layer when it is modified. A table header, field, field group, index, or method element is copied to the working layer when modified. An entire form or report element is copied if any of its members are modified. For example, if you add a button to a form, the entire form is copied to the current layer. If you delete the model element from the working layer, the model element at a lower layer is used instead. In this way, you can undo modifications and easily return to the original model element definitions. You can also compare objects from two different layers by using the MorphX Compare tool.
As shown in Figure 1-4 all model element layers (except HFX and SL1 through SL3) have an associated patch layer. Patch layers handle patches, minor updates, service packs, and hotfixes. Logically, a patch layer is placed directly above the layer that it is patching. A patch layer’s name contains the first two characters of the element layer’s name and then the letter P. For example, the first three patch layers are named SYP, GLP, and BUP. As a best practice, you should move the content of the patch layer into the main layer with each release of the application.
The solution layers (SL1, SL2, and SL3) are new in Dynamics AX 2009. They are intended for Microsoft certified solutions. Any of these solutions can be installed in the SL1, SL2, SL3, BUS, or BUP layer. Prior to installation, rename the layer file to match the desired layer. These solution layers enable customers to use up to five certified solutions simultaneously.
Most model elements have a unique identifier (ID) that is represented as an unsigned 16-bit integer. To avoid conflict, each layer has a range of available IDs, as listed in Table 1-1. The lower four layers share one ID range. Microsoft avoids ID conflicts in these layers by using version control and the Team Server. For more information on version control and the Team Server, see Chapter 3.
You should never change model element IDs. When an element is deprecated, the IDs can be reused. The IDs must not be altered because they are used as business data and in element definitions. In business data, IDs are typically used to model polymorphic relationships. In element definitions, they are used as references between elements and to relate class and table members across layers. Changing an element ID after it is deployed to an operations environment would result in data inconsistency and require model element ID scrubbing. Because either of these situations is highly undesirable, you must ensure that you use the appropriate layer when deploying application customizations and extensions to operations environments.
A model element can be moved between layers and retain its ID. This procedure can be used to free up a layer, but it puts limitations on the freed layer because IDs are still used, even if they are in another layer. This procedure can be applied if both layers can be fully controlled. For example, Microsoft successfully moved all model elements from the Axapta 3.0 GLS layer to the Dynamics AX 4.0 SYS layer. Keeping the element IDs from the GLS layer provides consistency for business data and element definitions, but it prevents Microsoft from reusing the IDs of the moved model elements in future GLS layers.
Note
Two features make ID management easier. The Team Server, which is a model element ID generator for version control, ensures that unique IDs are allocated across multiple developer application installations. Also, best practice rules detect whether a model element ID value has changed, providing an early warning that can help you solve potential problems before the application is deployed to an operations environment.
The Dynamics AX application framework is a set of model elements that provide most of the technology requirements for ERP applications. You can utilize these frameworks when you design the business process requirements so that you can focus on meeting the domain requirements rather than focus on the underlying technology. These frameworks also provide a consistent user experience across existing and new features. Presenting all the Dynamics AX application frameworks in this book would be impossible, so only the most commonly used frameworks are described in this section.
The RunBase application framework runs or batches an operation. An operation is a unit of work, such as the posting of a sales order or calculation of a master schedule. The RunBase framework uses the Dialog framework to prompt a user for data input. It uses the SysLastValue framework to persist usage data and the Operation Progress framework to show operation progress.
The Batch application framework creates batch entries in the Dynamics AX batch queue. These entries execute at time intervals specified by a user interacting with a dialog box provided by the framework. The RunBaseBatch framework extends the RunBase framework, and X++ classes that extend this framework can have their operations enlisted in the batch queue. For more information about the Batch framework, see Chapter 16.
The Dialog application framework creates a dynamic dialog box that is not defined in the AOT. You can customize the dialog box by setting the caption and adding fields, field groups, menu items, text, and images. You typically use the Dialog framework to create dialog boxes when data input is required from the user.
The Operation Progress application framework displays a dialog box that shows the progress of a processing task. You can customize the framework by setting the total number of steps in the operation and the dialog box caption and animation type. You control the progress by increme0nting the progress value in derived classes.
Best Practices
Include setting the total step count only if it is known (or if it can be accessed rapidly), partitioning the process task into as many steps as possible, and ensuring that steps have similar durations. If you use multiple progress bars, the first bar should show overall progress. The framework automatically calculates the time remaining for an operation.
The Number Sequence application framework creates a new sequential number for uniquely identifying business transaction records in database tables. You can specify whether the numbers are continuous or gaps are allowed in the generated sequences. You can also specify the number format by using a format string.
The SysLastValue application framework stores and retrieves user settings or usage data values that persist between processes. You use this framework to save, retrieve, and delete containers of usage data.
The Application Integration Framework (AIF) sends business transactions to external applications and responds to requests from external applications. This framework comprises XML document classes, message queue management, Web services, and data mapping features. For details on how to use this framework to build integration applications, see Chapter 17.
The Wizard application framework helps users configure application features. You can use the Wizard wizard to generate a set of default classes that extend the Wizard framework. (See Chapter 6, for more information about the Wizard wizard.) The resulting wizard provides start and finish pages and a user-defined number of empty pages in between. You customize the generated classes by populating the wizard pages with controls and controlling the page flow.
You use the Infolog application framework when business transaction status logging is required. The information log form control displays the logged message. The Infolog framework is also the default exception handler, so it catches any exception not caught by application code. You can extend this framework to provide customized logging features.
The Dynamics AX Enterprise Portal enables customers, vendors, business partners, and employees to access relevant business information directly and conduct business transactions with Dynamics AX through personalized, role-based Web portals called Role Centers.
Enterprise Portal is built on Windows SharePoint Services; it combines the content and collaboration functionality of an unstructured SharePoint site with the structured business data in Dynamics AX. It also serves as the platform for front-end application integration and business processes.
Enterprise Portal is a complete SharePoint site. It comes with a site definition that includes hundreds of standard Web pages and content and collaboration elements.
Enterprise Portal Web parts are the front-end user interface elements that connect to Dynamics AX through .NET Business Connector, and they render the HTML generated by the ASP.NET Web user controls. Web parts are used in the Enterprise Portal Web part pages together with other Windows SharePoint Services Web parts. These pages, along with page templates and Windows SharePoint Services elements, are packaged as a SharePoint site definition. All the content and collaboration functionality comes from Windows SharePoint Services, and Enterprise Portal Web parts expose the business data from Dynamics AX.
You author Web pages by using page designer tools in Windows SharePoint Services. The pages define the layout and host the Web parts and their properties. You author Web User Controls by using Visual Studio tools, and you then add them to the AOT. The Web User Controls define the user interface for interacting with the business data. They connect to Dynamics AX via .NET Business Connector and Enterprise Portal framework. The Windows SharePoint Services Web parts connect to the Windows SharePoint Services database for content and collaboration functionality. The page definition from Windows SharePoint Services Web pages is imported into the AOT so that those pages are automatically created when the site is created.
The Web elements in the AOT can be categorized into three groups:
Content definition elements, including data sets, Web controls, and Web content. These elements define the data source, the business logic, the user interface, and security.
Navigation definition elements, including the Web menu, Web menu items, and Web modules.
Files and definitions used to deploy Enterprise Portal sites and components to the Web server.
Enterprise Portal Web elements are placed under the Web nodes in the AOT, as you can see in Figure 1-5.
When a user browses to the URL, the Web part connects to the Web framework through .NET Business Connector and gets the Web content. The Web content security key setting is checked and, depending on the user’s permission, the Web user control generates the HTML to be rendered by the Web part.
Enterprise Portal uses Integrated Windows authentication for authorization, and it leverages Dynamics AX user groups and security models for the business data and uses SharePoint site groups for the content and collaboration data. Web content, Web menu items, and Weblets are secured with Dynamics AX security keys. Users are granted permission to these objects based on their Dynamics AX user groups. Windows SharePoint Services document libraries and lists are secured with SharePoint site groups. Users are granted permission to these objects based on their site groups.
Enterprise Portal provides a common integrated search across the business data contained in Dynamics AX and Windows SharePoint Services. The Dynamics AX Data Crawler indexes application data, and Windows SharePoint Services indexes the document libraries and lists. Enterprise Portal search uses both indexes to provide a combined search result.
The production reporting framework for Dynamics AX uses a model-based reporting framework build on top of Visual Studio 2008. It enables developers, partners, and independent software vendors (ISVs) to build Microsoft SQL Server Reporting Services reports using meta-data available from Dynamics AX. You can use the Reporting Framework to build reports that source data from multiple data sources, such as Dynamics AX for Online Transaction Processing (OLTP) data, Microsoft SQL Server Analysis Services for aggregated analytical data, and other third-party databases.
Reports built using the Dynamics AX Reporting Framework are deployed to a Reporting Services report server, which provides the run-time engine. Users can access these reports from a variety of locations, including the Dynamics AX rich client, Role Centers, Enterprise Portal, and Report Manager in Reporting Services.
Dynamics AX ships with hundreds of reports built on the Dynamics AX Reporting Framework. Some of these reports source data from the Dynamics AX transactional system via .NET Business Connector. Other reports source analytical data from the Dynamics AX OLAP database built on top of Analysis Services. In addition to these reports, Dynamics AX ships a number of style and layout templates that you can use to define the look and feel of your reports.
You can author new reports or customize existing ones using the Dynamics AX Reporting Extensions built on top of Visual Studio. The Dynamics AX reports library project in Visual Studio lets you define the different facets of your reports, such as types of reports, data sources, style templates, layout templates, and images in a model-based development environment similar to the AOT. You can build reports that connect to Dynamics AX data using queries defined in the AOT or via managed business logic that can connect to Dynamics AX via .NET Business Connector. Once built, these reports can be integrated into the Dynamics AX application via Menu Items in the AOT. The menu items can be started from Menus in the rich client or Dynamics Report Server Report Web parts in Role Centers and Enterprise Portal.
When a user tries to access a report from a Dynamics AX rich client, a report viewer form opens. This form issues a request to the Reporting Services report server to render the report for the current company in the user’s current language. The report server then connects to Dynamics AX via .NET Business Connector to fetch data. Once the data is retrieved from Dynamics AX (and potentially other data sources), the Reporting Services report server renders the report and returns it to the client, which then displays the report to the user.
The Reporting Services report server uses Windows integrated security for authorization. It uses the Dynamics AX security model for securing business data from the Dynamics AX database and Reporting Services roles for securing content on the Report Manager. Menu items are secured using Dynamics AX security keys. Users are granted access to these objects based on their membership in Dynamics AX user groups.
Dynamics AX is a three-tiered client/server application that is typically deployed in operations environments configured to meet the needs of customers.
The Dynamics AX Application Object Server (AOS) can be hosted on one machine, but it can also scale out to many machines when more concurrent user sessions or dedicated batch servers are required. The server can also access one database or a scaled-out database cluster if the database becomes a processing bottleneck. For more information on performance in Dynamics AX, see Chapter 12.
Dynamics AX rich clients communicate with the AOS by using Microsoft RPC technology. For example, an Excel component hosted on a rich client form communicates directly with Analysis Services via Web services. A SQL Server reporting client communicates directly with Reporting Services via Web services. The application database servers update the Analysis Services databases, and Reporting Services reads data from the application databases. Dedicating one or more batch servers for batch processing jobs is common. For more information on reporting with Dynamics AX, see Chapter 11.
The Dynamics AX Enterprise Portal is typically hosted on its own machine or on many scaled-out machines that also host IIS, Microsoft Office SharePoint Portal Server, and Windows SharePoint Services. Enterprise Portal communicates with Dynamics AX via .NET Business Connector, which communicates with the application servers by using RPC technology. For more information on Enterprise Portal, see Chapter 7.
Dynamics AX uses the Application Integration Framework (AIF) to interoperate with Microsoft BizTalk Server, Microsoft Message Queuing (MSMQ), and the file system. The AIF also hosts Web services that respond to requests for data from external applications. Dynamics AX can also interoperate with Component Object Model (COM) components and Microsoft .NET components via the COM and Microsoft common language runtime (CLR) interoperability technologies. For more information on AIF, see Chapter 17.
Dynamics AX uses the Windows Workflow Foundation for processing and configuring workflows. The Windows Workflow Foundation Server is typically hosted on its own machine, one that also hosts IIS. Dynamics AX communicates with the Windows Workflow Foundation Server via .NET Business Connector. For more information on .NET Business Connector, see Chapter 10.
Microsoft Office clients can interoperate directly with the AOS via .NET Business Connector, and Dynamics AX application servers can interoperate natively with Microsoft Exchange Server.