EP 2009 comes with a whole new way to data bind and access AX data and yet it is still very familiar (as you will learn in this post) if you have developed EP WebForms and AX client Forms. The new way is the DataSet. Since EP 2009 is implemented using ASP.NET we needed to come up with a new way to enable data binding for the ASP.NET based UI since the existing data binding in AX is tied to specific display targets that I just mentioned. So enabling ASP.NET data binding to AX data was one of the major design goals for the DataSet. Another important design goal for the DataSet was to deliver the rich and familiar programming model from the AX client forms around data binding which essentially means the FormDataSource.
So what we ended up with was the new DataSet node in the AOT which looks like an AX Form node except it does not have a Design node. At the heart is the FormDataSource. The DataSet comes with the same data shaping constructs (join types) to combine many tables via the FormDataSource as well as a similar programming model:
- X++ event overrides (init, run, validateField, modifiedField, validateWrite, write, etc.)
- Access to the runtime instance of the FormDataSource’s
- Access to the Query and QueryRun objects
The list is probably incomplete but it highlights the concepts that are known from developing an AX Form.
The DataSet is natively supported by the AX kernel (client and BC.NET) via two new classes available in X++
- DataSet – implements the design time functionality around the DataSet AOT node
- DataSetRun – implements the runtime functionality
The DataSet thus provides AX data binding functionality independent of the UI. But how does this make it into ASP.NET?
The answer is the managed DataSet. To bridge the gap between ASP.NET and other managed clients there is a new managed DataSet which is shipped with EP 2009. The managed DataSet is a set of classes that are implemented in the Microsoft.Dynamics.Framework.Data.Ax assembly. At a quick glance the DataSet and it its related classes look somewhat similar to the ADO.NET data set but there is not much in common between the two.
The managed DataSet serves three main purposes:
- Formalize and expose the DataSet Views concept
- Enable data binding
- Provide a managed programming model for the MorphX DataSet
In this post I will talk about 1 and 2. In a later post I will dig into the programming model around the managed DataSet with some samples.
The form datasource enables combining multiple tables via joins to shape the data surfaces in the UI. When doing an inner or outer join the tables are combined into one execution unit which basically means one SQL query issue against data base. That is in contrast to an active join which results in two queries – one for each execution involved in the active join (an active join is basically a filter applied to the child table). An inner or outer join is exposed as a DataSet View through the managed DataSet. A view is rectangular representation of the data in the tables involved in the join by changing the projection list to include all the fields of the tables. A view corresponds to one execution unit. The view adds a layer of abstraction on top of the tables so that the data is no longer access via the tables but through the view. The DataSet view is implemented by the class DataSetView in the Microsoft.Dynamics.Framework.Data.Ax assembly.
Side Note: The DataSet does not support Exist and Not Exist joins.
In the example on the right the various join types in a MorphX DataSet are mapped to DataSet Views. Table1, Table2 and Table3 are all joined into one view (View1) as a result of the join types and Table4 is represented by View2. The DataSet thus contains two views.
A DataSetView can be thought off as a uber-table that makes it easy to data bind to multiple tables in a control (a view can just as well only contain one table). The DataSetView implements the necessary interfaces to enable data binding. The AxDataSource control which is the primary way for controls to bind to AX data in EP contains a reference to a DataSet. The data set is determined by the value of the DataSetName property on the AxDataSource control. The data source control contains a list of type AxDataSourceView which inherit from DataSourceView and each AxDataSourceView contains a reference to a DataSetView in the list of views defined on the DataSet that is referenced by the AxDataSource. Finally the DataSetView contains a list of type FormDataSource for each form datasource that makes up the view.
When binding a DataBoundControl in ASP.NET you pick a DataSourceView from the list of views in the data source control by setting the DataMember property on the control. As a result of this when binding a control to the AxDataSource control you are effectively picking the DataSetView (and ultimately the AX tables) that you are binding to when setting the DataMember property.
Side Note: The fields in a DataSetView follow a special naming guideline to prevent name clashes. The fields off the inner joined tables are prefixed with the name of the form datasource and a ! character. For example in the previous examples the fields in View1 from Table2 would be named Table2!Field1, Table2!Field2, etc.
The picture on the left shows the interaction between the AxDataSource control, the DataSetViews and the kernel DataSet.
The notion of the current record is heavily used in AX form data binding. Typically you have the overview tab in an AX form displaying a grid of records and the subsequent tabs display further information for the currently selected record in the grid. The form datasource defines a notion of a current record and most of the controls display only data from the current record. Furthermore when leaving the current record (e.g. through the VCR controls on a form) any changes made to the record are automatically saved before moving to the next record in the form datasource cache. Moving to a new record will trigger the controls to rebind and thus display the information for the new record.
These concepts are also available in EP 2009. The DataSetView exposes the current record and to enable EP controls to easily data bind against the current record a special view called the Current view is exposed by the AxDataSource control. As described for each DataSetView in the DataSet the AxDataSource control will create AxDataSourceView’s and in addition it will create a current view for each DataSetView e.g. in the previous example there would be two additional views named View1_Current and View2_Current.
The AxForm should always be bound to the current view i.e. it’s DataMemeber property is always set to e.g. View1_Current. The AxForm is ideal to display information from the current record in the DataSetView. In a similar fashion as the grid control in an AX form the EP grid control (AxGridView) will change the current record to the record that is selected in the grid. So if you data bind an AxGridView and AxForm to the same AxDataSource control and the grid is bound to View1 and the form to View1_Current the form will automatically rebind and display information from the currently selected record in the grid.
So this was the first post on the managed DataSet and the concept of DataSetViews. It showed how the MorphX DataSet defined in the kernel is made available for data binding in ASP.NET via the AxDataSource control. As the title of the post indicates there will a second part where I will give concrete samples on how to program against the managed DataSet.