Month: February 2013

Product Configuration – Physical data model for user selected values

A constraint-based configurator was shipped with Microsoft
Dynamics AX 2012. In this post, we will provide an overview of the data model
that is used to persist the values that you can select when you configure a
product using the constraint-based configurator.

 

 

 

 

At first glance, you will notice that there are several
tables involved. If you are not familiar with previous versions of Dynamics AX
and the Product Builder configurator, this might not surprise you. However, if
you are familiar with the Product Builder, you will know that the old
configurator persisted all user selections in one table, namely the
PBATableInstance Table. This implies that retrieving the user selected values
is not as simple as writing a select statement against a single table. In the
following, I will use a report as an example and show you how you can retrieve user
selections in tables.Building a report

The report** that we use as an example displays all the user
selected values that are related to the configurations for a given product configuration
model.

**Disclaimer:
The report is not performance optimized. The purpose of the report is solely to
illustrate traversal of the data structure.

 

In the report, each element is indented to show the
parent-child relationship between, for example, the HomeTheaterSystem root
component and the “Color” attribute. The “Color” attribute can be assigned
other values, such as “Red”, but in the data on which the report was executed
no such configuration existed.

Note: I have used the Contoso dataset.

Data requirements

The data required to build the report can be broken down
into three parts:

  1. Get the instances of the root component from a
    given product configuration model. Here we only want the instances that are
    created for product variants and not the ones that are created for configuration
    templates.
  2. Get the attributes and their user selected
    values for a component instance.
  3. Traverse the subcomponent instances recursively
    and repeat part 2.

 

Let’s take a look at how to retrieve the data requirements to
build the report. The following statements will meet the data requirements and you
can also see the table involved:

Get the instances of the root component from a product configuration model

 

 protected void
  provideDataForModel(PCProductConfigurationModel _productConfigurationModel)

{

   PCVariantConfiguration              variantConfiguration;

   PCComponentInstance                 componentInstance;

   PCComponentInstanceRootComponent    rootComponentInstance;

   PCClass                             rootComponent;

…

   // get all
  configurations made for the given product configuration model

   while select componentInstance

   // only get instances which belong to a variant configuration, not a configuration template

  join TableId from variantConfiguration

  where variantConfiguration.RecId == componentInstance.ProductConfiguration

  // find the
  root component instances of the selected model

  join TableId from rootComponentInstance

  where rootComponentInstance.ComponentInstance == componentInstance.RecId

  join  rootComponent

  where   rootComponent.RecId ==  rootComponentInstance.RootComponentClass

        &&      rootComponent.RecId == _productConfigurationModel.RootComponentClass

    {

        //  handle data for component

        …

    }

}

 

Get the attributes and their user selected values for a component instance

 

    PCComponentInstanceValue    componentInstanceValue;

    EcoResAttribute             attribute;

    EcoResAttributeValue        attributeValue;

    EcoResValue                 value;

    

    // get all attribute value assignments
  related to the component instance

    while select  value

        join TableId from attributeValue

        where  value.RecId == attributeValue.Value

        join TableId from componentInstanceValue

        where componentInstanceValue.RecId  == attributeValue.InstanceValue

        &&    componentInstanceValue.ComponentInstance  == _componentInstance.RecId

        join attribute

        where attribute.RecId == attributeValue.Attribute

    {

   // handle data for attribute and attribute value

    …

    }

 

The values as such are sub-typed to model their respective data type.

Traverse the subcomponent instances

 

   

    PCComponentInstance    componentInstance;

    PCComponentInstanceSubComponent  subComponentInstance;

 
    PCSubComponent  subcomponent;

    PCClass                  childComponent;

 

// get all the subcomponents that have been associated with values

while select component

        join TableId from subcomponent

        where  subcomponent.ParentComponentClass == _parentComponent.RecId

        &&    subcomponent.ChildComponentClass  == childComponent.RecId

        join TableId from subComponentInstance

        where subComponentInstance.SubComponent == subcomponent.RecId

        &&  subcomponentInstance.ParentComponentInstance == _componentInstance.RecId

        join componentInstance

        where componentInstance.RecId == subComponentInstance.ChildComponentInstance

    {

   // handle data for component

    …       

    }

 

 

Implementation of the report

 

The data in the report is hierarchical in nature because of
the relationship between components and subcomponents.

The report that we build includes the parent-child
relationship between a component and a subcomponent and it also includes the parent-child
relationships between, for example,  an
attribute and an attribute value. This data cannot be retrieved from Dynamics
AX using a single query[1]
so we will use a data provider to populate a temporary table. The table has the
following structure:


[1]
This is not completely true because in Dynamics AX 2012, each component is
brought about as a reference to the configured variant. Thus, you could
retrieve all the data and then resolve the parent/child relations once the data
is retrieved.

 

A quick explanation of why the fields are required:

  • ID : this is used because the report framework
    will not expose the RecId field of the temporary table
  • Name : this is the name, such as Color, that we choose to display for the
    element
  • Parent : this is a reference to the parent
    record ID that helps grouping the SSRS report hierarchically
  • UniquePath : this is used to distinguish the
    attributes that belong to subcomponents of the same type. The path will be
    unique since it describes the path from the root component to each element in
    the model.

 

For more information about how to build a simple
hierarchical report in SSRS, go to:

http://technet.microsoft.com/en-us/library/dd255243(v=sql.105).aspx

For details on the implementation, take a look at the
attached X++ project.

Enjoy

PrivateProject_PCSessionValues.xpo

Microsoft Dynamics AX 2012 R2 – Developer perspective on the Selection list

Microsoft Dynamics AX 2012 R2 – Developer perspective on the Selection list

Extending the Selection list to other list pages

In a previous blog titled Microsoft Dynamics AX 2012 R2 – Selection List, I described how this simple feature can help you keep and manipulate a persistent selection on list pages for planned orders and production orders. In that blog I also mentioned that you can extend other list pages so that they can also use the Selection list feature. In this blog, I’ll provide developers with the specifics of just how to do that. I’ll also describe the foundation beneath the implementation of the Selection list.
During implementation, the conceptual name of this feature was Production Record Basket. This name became the ProdRecBasket prefix, which is assigned to the elements of the feature and will help us to locate the artifacts in the system that we’ll need for the extension.

 
Figure 1: The artifacts related to the Selection List

 

The Selection list is implemented in a context-agnostic manner. The feature recognizes only that records from the root data are displayed in the grid, and is neither domain specific nor dependent on the type of records it displays. One important note is that the Selection list works only with the source of the root data for the list page. The root data source for a form is easy to identify. It’s the one data source that has the Joins property clear and usually appears first on the list of data sources.

For this exercise, the most relevant artifacts to keep in mind are the following:

  1. The ProdRecBasket configuration key
    1. You must enable this configuration key to use the feature because it controls access to the table definitions and menu items.
  2. The Selection list button group
    1. These are buttons that need to add to the Action Pane of the list page that are the front-end UI for this feature.
      Their functions are detailed in the previous post. I recommend using the form ReqTransPOListPage as a data point to retrieve these.


      Figure 2: The Selection list buttons, as implemented in the ReqTransPOListPage form.

  3. The ProdRecBasketPart (the Selection List Factbox part)

    1. This is the form part to attach to the list page. It functions as the engine that
      supports the feature.

  4. The ProdRecBasketUse (the security privilege)

    1. This security privilege enables the user roles to read and write to the tables.

Using these four elements I’ll go through the process of extending another list page so that it consumes the Selection list.
For this example, I’ll use the EcoResProductListPage form.

My first concern is security. I must ensure that the user role can read and write to the selection list tables. I’ll start by locating the duties that are related to the Products form, which are EcoResProductDefinitionMasterInquire and EcoResProductDefinitionMasterMaintain. To these duties I’ll then add a reference to the privilege called ProdRecBasketUse.



Figure 3: Extending the duties for the Products list page to be able to use the Selection List.

Now that I’ve taken care of security, my next step is to add the buttons to the EcoResProductsListPage form. I’ll use the ReqTransPOListPage as the source of the metadata information. I’ll copy the button group from the planned orders list page, and paste it on the Action Pane of the Products list page. When you do this, please remember to change the metadata property called
DataSource to match the root data source of the form. In this case, the root data source of the Products form is called EcoResProduct.



Figure 4: Adding the selection list buttons to the Products list page.

The last step is to add the controlling fact box to the Products list page. I’ve just created it, but I also could have copied it from the Planned orders list page. Now that it’s added, I’ll align the metadata properties as shown in Figure 5.


Figure 5: Adding the Selection list part to the Products list page.

When the process is done, my Products list page should be ready for the Selection list.



Figure 6: The Products list page extended to support the selection list

Please make sure to add a comment or send me a message with any questions or concerns regarding this topic.

 

Andre Lamego,
reviewed by Brent Holtorf and Roxana Christina Diaconu

Microsoft Dynamics AX R&D

 

 

 

Microsoft Dynamics AX 2012 R2 – Selection List

Microsoft Dynamics AX 2012 R2 – Selection List     

A feature that enables persistent selections on list pages

In earlier versions of Microsoft Dynamics AX, the paging, selection methods, and actions that were available on list pages varied across the different areas of the product. For example, some list pages let you select only one line at a time in the grid while others allowed multiple selections. Some list pages had a Mark column with check boxes, which were handled by background code on the forms, while others would not let you mark rows in the list.


Figure 1: On the left: custom row marking. On the right: kernel-managed (standard) row marking

Microsoft Dynamics AX 2012 brought consistency to the selection behaviors. The kernel now manages row selections, and the overall selection experience is aligned with other Microsoft products such as Excel, as shown in Figure 2.

Figure 2: Row selection in Microsoft Excel 2013 

 

The new kernel behavior has replaced prior methods. Some of the requirements that were addressed in earlier versions were not compatible with the new mechanics and have been removed. One of these requirements is the ability mark a record independently of the row selection. For example, a collection of records could be marked while others would be selected. This scenario is no longer possible.
Some customers expressed concerns that the new behavior would prevent them from selecting some records while investigating the details of others. For example, for a production planner it’s important to be able to mark the production orders that he or she expects to firm (at the same time) while looking at the details of other orders to determine whether to firm them as well. According to the new behavior, the planner’s selections are cleared when a second record is selected or the details form is opened.
We’ve worked closely with these customers, and in the Microsoft Dynamics AX 2012 R2 release we’ve delivered a solution that adheres to the standard selection experience and enables this scenario.
The feature is called the Selection list, and it’s available on the Action Pane.

Figure 3: Selection list-enabled Production Order list page in Dynamics AX 2012 R2

The Selection list feature is not enabled by default. To use the feature, you must enable the Selection list usage configuration key for the Production series I license key. The Selection list is then available on the list pages for planned orders and production orders.

Figure 4: The Selection list configuration key

The Selection list is similar to the Task list in Microsoft Outlook. You can select a group of records on the list page and add them to the Selection list. You can query the records, and you can also filter the records on the list page to match the list, or show only those records that are not in the list. This gives you better control of the amount of information that is displayed.

Figure 5: The Selection list Action Pane Group

The following functions are available:

  • Add to selection
    • Adds the selected record(s) from the list page to the Selection list.
  • Remove from selection
    • Removes the selected record(s) from the Selection list.
  • Clear selection
    • Clears all records from the Selection list.
  • View selection
    • Applies a view to the contents of the list page that shows only records that are included in the Selection list. The view is applied until you click the button again.

      Left: View is on. Right: View is off.
  • View unselected
    • Applies a view to the contents of the list page that shows only records that are not included in the Selection list. The view is applied until you click the button again.

      Left: View is on. Right: View is off.

The Selection list feature also includes the Selection list FactBox, which is available to the right of the list. The Selection list FactBox displays all of the records that have been added to the Selection list. Additionally, you can also use the FactBox to apply the View selection view.


Figure 6: The Selection List fact box

The Selection list remains available when you close and reopen the client. The selections in the list are saved for a user in the context of one legal entity.
A separate blog post will show how partners can consume and extend the Selection list for use on other list pages. Many other list pages can be customized to take advantage of this feature.

Andre Lamego,
reviewed by Brent Holtorf and Roxana Christina Diaconu

Microsoft Dynamics AX R&D