AX 2012 - Security for Developers - Part I

Hi there!

Roles, duties and privileges security levels cover access to single elements, for example forms, and groups of elements needed to perform a duty. As developers we are responsible for defining more granular security levels by setting access on tables and controls in a form, and/or by associating classes that perform an action with permission (i.e. an action menu item)

In this article I would like to discuss, in detail, form permissions, code access permissions and how to create security policies using the extensible data security (XDS) method.

Form Permissions

Each form in the Application Object Tree (AOT) has a permissions node. It contains either four or five sub-nodes - Read, Update, Create, Delete and Correct. Now, correct is only displayed if a table in the form has Date Effective data.

Further, under the above nodes are four additional nodes - Controls, Tables, Server Methods and Associated Forms. When we add a table to a form data source, this table is automatically added to the Tables node for each of the Permissions sub-nodes.  In addition, each of the nodes under the Tables node has an EffectiveAccess property which sets what access is allowed to the table and the EffectiveAccess property is automatically set based on properties on the data source.  

So, this is where all makes sense, if the data source property AllowDelete is set to No, the EffectiveAccess property is set to Update. If the data source property AllowEdit is set to No, the EffectiveAccess property is set to Read.

NOTE: To set the security access for a form control, we need to set the Securable property on the control to Yes. Then, this control can then be added to the Controls node under each of the permissions nodes.

Code Permissions 

These are a set of custom permissions that are created manually in the AOT under Security > Code Permissions.

For example, action menu items, can use these by setting the LinkedPermissionType property to CodePermission and the LinkedPermissionObject to the name of the code permission. Now, the great benefit about code permissions is that it can be extended to Service operations as well. This can be done by setting the Code Permission property under the Service operation > Operation method > Permissions > Associated Code Permissions node.

The following image depicts an access to post a Free-Text Invoice

Security policies - Developing an XDS Policy 

The following walkthrough will show how to create a security policy that limits users from viewing other user’s prospects. This can be seen a lot in a sales environment, where one sales person does not want the other to see his/her prospects, well who wouldn’t?

So for this example, we are going to use the smmBusRelTable where leads can hopefully become the future buyers of our products.

A lead/prospect is stored in smmBusRelTable, and the employee who is responsible for the prospect is stored in the MainContactWorker field.  In AX 2012, an employee is connected to the current user through the DirPerson and DirPersonUser tables.

There are two stages in creating the XDS policy:

1-      Create the policy query.

2-      Create the security policy.

Creating a Policy Query 

The steps to create the policy query are as follows:

1. In the AOT, create a new query, rename it to HcmWorkerUser.
2. From a second AOT, locate the table Data Dictionary > Tables >  HcmWorker. Drag the table HcmWorker to the Data Sources node of the query.
3. In the property sheet of the Fields node of the HcmWorker_1 data source, set the Dynamic property to Yes.
4. From the second AOT (Press CTRL + D to open a new AOT), locate the table Data Dictionary > Tables > DirPerson.
5. Drag the table DirPerson to the Data Sources node of the HcmWorker_1 data source.
6. In the property sheet for the DirPerson_1 data source, set the Relations property to Yes.
7. In the property sheet for the Fields node of the DirPerson_1 data source, set the Dynamic property to Yes.
8. From the second AOT, drag the table DirPersonUser to the Data Sources node of the DirPerson_1 data source.
9. In the property sheet for the DirPersonUser_1 data source, set the Relations property to Yes.
10. In the property sheet for the Fields node of the DirPersonUser_1 data source, set the Dynamic property to Yes.
11. Right-click the Ranges node of the DirPersonUser_1 data source, and select New Range.
12. In the property sheet for the new range, set the Field property to User, and the Value property to (currentUserId()) as it appears.
13. Save your changes to the query.

Creating a Security Policy 

Follow these steps to create the security policy:

1. In the AOT, expand the Security node.
2. Right-click the Policies node and select New Security Policy.
3. In the property sheet for the security policy, set the Name property to SmmBusRelUser, set the Label property to Limit Prospects by User, set the Primary Table property to HcmWorker, set the Query property to HcmWorkerUser, set the ContextType property to RoleName, set the RoleName property to TradeSalesRepresentative, and set the Enabled property to Yes.
4. Expand the SmmBusRelUser security policy.
5. Right-click the Constrained Tables node and select New > Add table by relation.
6. In the property sheet for the new constrained table, set the Table property to smmBusRelTable, set the TableRelation property to MainContactWorker. Save your changes to the policy.

Now, if you were to login with the name of a sales person, you could see that you will only have access (view) your prospects because when creating the policy query we set the currentUserId() to the value of the query range.  Also, because a user is related in DirPerson and DirPersonUser tables, the policy is able to associate the user id with records in the smmBusRelTable.

That is all for now, and stay tune for the next series of security for developers as I will go in detail on consuming a secured class and setting authorization for display methods.

Until then!



WALKTHROUGH - Creating Fact Boxes in AX 2012 - Part IV (Final Post)

Hi,

This is the last post (http://axwonders.blogspot.com/2011/12/walkthrough-creating-fact-boxes-in-ax_29.html) on the series WALKTHROUGH - Creating Fact Boxes in AX 2012. In my last post we took care of primary indexes for the Eduardo_CustCarTable. In addition, we also talked a little bit about Parts and FactBoxes in AX 2012, and that we needed to create a query before displaying data inside a FactBox.

In this post we are going to create 4 forms, 2 info parts, 2 menu items, 2 queries, and finally will create a new form part in the CustTableListPage to see how everything links together.

First we are going to create the Eduardo_VehicleTypeTable, Eduardo_VehicleModelsTable, and Eduardo_VehicleMakeTable, and Eduardo_CustCarTable forms. The four have the same requirements, and the only element that changes is the data source table they use.

In addition,  three these forms (Eduardo_VehicleTypeTable, Eduardo_VehicleModelsTable, and Eduardo_VehicleMakeTable) will have an ActionPane with only two buttons; (1) new and, (2) delete.

The  Eduardo_CustCarTable form, however,  will contain an extra ActionPaneTab to hold the butons to open the orther three forms.

Steps:

1.       In the AOT, right-click the Forms node and select New Form.

2.       Rename the form to Eduardo_VehicleTypeTable.

3.       In a second AOT, locate the table Eduardo_VehicleTypeTable.

4.       Drag the table Eduardo_VehicleTypeTable to the DataSources node on  the Eduardo_VehicleTypeTable form.

5.       Expand the Designs node on the Eduardo_VehicleTypeTable form.

6.       Right-click the Designs node and select New Control > ActionPane.

7.       Expand the ActionPaneTab and then the ButtonGroup.

8.       Right-click the ButtonGroup node and select New Control > CommandButton.

9.       Set the following properties:

a.       ButtonDisplay: Text & Image Left

b.      Text: New

c.       NormalImage: 11045

d.      ImageLocation: EmbeddedResource

e.      Primary: Yes

f.        Command: New

 

10.   Right-click the ButtonGroup node and select New Control > CommandButton.

11.   Set the following properties:

a.       ButtonDisplay: Text & Image Left

b.      Text: Delete

c.       NormalImage: 10121

d.      ImageLocation: EmbeddedResource

e.      SaveRecord: No

f.        Primary: Yes

g.       Command: Delete Record

12.   Right-click the Designs node and select New Control > Group. Change the Name to Body.

13.   Right-click the Group [Body] node and select New Control > Group. Change the Name to GridContainer.

14.   Right-click the Group [Body] node and select New Control > Group. Change the Name to Splitter.

 

NOTE: To make the Splitter work, you will need to overwrite the Form's init method with the following code:

15.   Right-click the Group [GridContainer] node and select New Control > Grid.

16.   Expand the DataSources > Eduardo_VehicleTypeTable > Fields node.

17.   Drag all the fields to the grid control.

18.   Save your changes to the form.

19.   Open the form by pressing Ctrl+O.

20.   If you haven’t already done so, populate the table by entering your own data in to the form.

Repeat steps 1- 20 for the other three forms (Eduardo_VehicleMakeTable and Eduardo_VehicleModelsTable, and Eduardo_CustCarTable ).
The following image depicts the Eduardo_VehicleModelsTable form, so you get an idea how the three forms created above should look like.

Then if you open the Eduardo_VehicleModelsTable you should see the following (if you have some data)

Now, we are going to add anew ActionTab to the existing ActionPane control in the Eduardo_CustCarTable form. This action will create a new tab and three buttons (within the tab) that will open the three forms we created earlier.

Steps

1.       Right-click the ActionPane node and select New Control > ActionPaneTab.

2.       Change the following properties:

a.       Name: Vehicles

b.      Caption: Vehicle Management

3.       Create 4 new Display Menu Items by dragging each form to the Menu Items >Display Node.

4.       Drag the Eduardo_VehicleMakeTable, Eduardo_VehicleTypeTable, Eduardo_VehicleModelsTable Menu Items to the ButtonGroup located in the Form Eduardo_CustCarTable form > Designs>ActionPane>ActionPaneTab:Vehicles> ButtonGroup

The following image shows how a Menu Item is created after I dragged the first form to the MenuItem>Display node.

5.       Set the following properties for each Menu Item Button:

a.       NormalImage: This will allow you to “attach” an image to the button.

b.      Big: Yes (This will make it big)

The form should look like the following image:

Now that all our forms are ready, we are going to start developing to display data in a FactBox in both the Eduardo_CustCarTable and the CustTableListPage forms.
To better understand what we are doing, I would like to review what a List Page is before moving forward with the FactBoxes.

List pages are the primary method of displaying data in Microsoft Dynamics AX. They can show lots of data from many tables, in a number of formats. They have consistent designs and functions. They can easily be displayed in the enterprise portal.

The components of a list page are:

1.   The Grid displays a list of records. It displays only a few of the most important fields for each record.

2.   The Filter bar is used to enter search criteria. This filters the list in the data grid to show only the records which an end-user is interested in.

3.   The Preview Pane displays more fields about the selected record. This helps to ensure you have selected the correct record in your search.

4.   FactBoxes display more information about the selected record from related tables.

5.   The Action Pane contains menu items you can use to do typical tasks related to the highlighted record.

Now, let’s create a FactBox for the Eduardo_CustCarTable. The main idea of this FactBox is to show only the related detail data of Car's model for a selected record.

We need to first create a query. Because we need to for this project, we’ll create the two.

Steps:

1.       In the AOT, right-click the Queries node and select New Query, and rename the new query to Eduardo_VehicleModelsQuery.

2.       In a second AOT, locate the Eduardo_VehicleModelsTable.

3.       Drag the Eduardo_VehicleModelsTable to the DataSources node on the Eduardo_VehicleModelsQuery .

4.       Expand the Eduardo_VehicleModelsTable _1 data source.

5.       In the property sheet for the fields node set the Dynamic property to Yes. This means all fields in the table will be included in the query.

Repeat steps 1 to 5 for the Eduardo_CustCarQuery.

Now it is time to create a Part for each of the queries we just created.

Steps:

1.       Right-click the Info Parts node and select New Info Part.

2.       In the property sheet for the new info part, set the Name property to Eduardo_VehicleModelsInfoPart, set the Caption property to Cars Models, set the Query property to Eduardo_VehicleModelsQuery.

3.       Right-click the Layout node in the info part, and select New Group.

4.       In the property sheet for the group, set the Repeating property to Yes.

5.       Right-click the new group and select New Field.

6.       Set the data source and data field for each of the fields exist in the Eduardo_VehicleModelsTable _1 data source (VehicleModelID, VehicleTypeID, VehicleMakeID, Status, Description)

Repeat steps 1 to 6 for the Eduardo_CustCarsInfoPart. The InfoPart should look like the following image:

NOTE: For the Eduardo_VehicleModelsInfoPart to work correctly in Eduardo_CustCarTable form, we need to tell the Eduardo_VehicleModelsTable that the relationship we have with the index Eduardo_VehicleModelIdx is on the EDT (See next image)

Now the step we all have been waiting for, lets add a new FactBox to the Eduardo_CustCarTable form.

Steps:

1.       Create a new menu item for the info part, by dragging the Eduardo_VehicleModelsInfoPart to the Menu Items > Display node in the AOT.

2.       Locate the Eduardo_CustCarTable form in the AOT.

3.       Drag the Eduardo_VehicleModelsInfoPart menu item to the Parts node in the Eduardo_CustCarTable form.

4.       In the property sheet for the new part reference, set the DataSourceRelation property to Eduardo_CustCarTable.Eduardo_VehicleModels.

5.       Save your changes to the Eduardo_CustCarTable form.

Press CTRL+O to open the Eduardo_CustCarTable, and if everything went OK the form should look like the following image:

Pretty cool, isn't? If you click on a different record, the FactBox information will change to the specified relationship with the VehicleModelID field.
Now, let's do the same with the CustTableListPage.

Steps:

1.    Create a new menu item for the info part, by dragging the Eduardo_CustCarsInfoPart to the Menu Items > Display node in the AOT.

2.    Locate the Eduardo_CustCarTable table in the AOT.

3.    Expand Eduardo_CustCarTable table.

4.    Right-click the Indexes node and select New Index

5.    Rename the index to CustIdx

6.    From the fields node on the table, drag the CustAccount field to the CustIdx index.

7.    Save your changes to the table.

8.    Locate the CustTableListPage form in the AOT.

9.    Drag the Eduardo_CustCarsInfoPart menu item to the Parts node

10. In the property sheet for the new part reference, set the DataSourceRelation property to EDT.VetCustPetTable.CustAccount.

The CustTableListPage should look like this:

This concludes this series of posts about FactBoxes in AX 2012. I hope you have enjoyed this tutorial and that you will share it.

Take Care!

WALKTHROUGH - Creating Fact Boxes in AX 2012 - PART I

Hi There!

I hope everybody had a great holiday weekend, and that you are preparing for next weekend’s big new year’s party (if you have one).

Before the end of the year I would like to highlight some of the changes that AX 2012 has when creating new Forms through a basic small project (Auto Rental).  As we you already know, Forms in AX 2012 contain FactBoxes, which is a small selection of data related to the current record in a Form List Page template.  

The goal of these set of posts is to (1) create three extended data types (EDT), (2) create four tables, (3) create relationships on the EDTs, (4) create a simple form to display the Auto Rental Data, (4) add a menu item to the Customer Details List Page to access the Auto Rental forms, (5) add controls to a form, and (6) create the relationship between the customer and Auto Rental records in a FactBox.

For now let’s focus on a few new definitions we’ll use a lot when creating FactBoxes in AX 2012 Forms. Basically, we can have three types of FactBoxes, (1) InfoPart, (2) Form Part, and (3) Cues.

1-      Info Part: This has its own data source and a number of controls. It is limited in what can be displayed. However it is simple and quick to create, and can also be displayed in the Enterprise Portal.

2-      Form Part: This is a link to a form. The form can have the same controls as a standard form. However since this is displayed in the FactBox section of the list page, adding too many controls can crowd the part.

3-      Cues: This is a count of a number of records related to the current record in the list page. For example, it might show the number of outstanding invoices for a customer.

In AX 2012, most forms have at least one factbox on the right side of the form. They will contain information pertaining to a highlighted record on a grid. But sometimes, we would like to see other in one of these boxes.

Go to http://msdn.microsoft.com/en-us/library/gg847986.aspx for more information about fact boxes.

Now, to create a FactBox there are a few things we need to have in place before displaying the right data. In fact, we need to have a good concept around indexes, tables and form relationships, Form Parts and their EDT relationships.

Let’s start the project by creating a basic Table Relationship diagram.

 

The diagram above is really simple. Basically we have the following:

1-    AutoRentalVehicleTypeTable , which is a table to store types of vehicles  (i.e. Compact, Mid-Size, etc.).

2-   AutoRentalVehicleMake , which is a table to store the make of a vehicle (i.e. Ford, Toyota, etc.)

3-   AutoRentalModels, which is a table that a store the vehicle models and at the same time relates to both the AutoRentalVehicleMake Table and the AutoRentalVehicleTypeTable.

4-   Finally, we have the AutoRentalCustCarTable where we store the car rental information based on a rental ID and the customer account. This table has a relationship to the AutoRentalModels Table.

In my next post we will create the four tables mentioned above along with new fields, indexes and relationships.

Take Care!

Intelligent Data Management Framework (IDMF)

Hi there,

There has been a lot of talk about the Intelligent Data Management Framework (IDMF) in AX 2012, and for a good reason!  This is because the Intelligent Data Management Framework allows the system administrators optimize the performance of Microsoft Dynamics AX installations, which is something that we all should be concerned about when implementing AX 2012.

Why? Well, first of all, the system requirements for AX 2012 are going to be much more than the ones for AX 2009.

This has been proved by a recent installation in Bank of America where they thought the hardware required was much more of what is needed for AX 2009. For this reason, the IDMF assesses the health of the Microsoft Dynamics AX application, analyzes current usage patterns, and helps reduce database size.  In addition, the IDMF lets you analyze the database and maintain an optimal database size by providing the purge and archive functions.

A Microsoft articles says “the purge function removes or deletes data from a set of related entities, or tables, from the production database. The archive function moves data from all related tables from the production database to a standby database called the archive database. Users can use the archive database for reporting purposes but cannot update it”

Further, both the purge and archive operations depend on a hierarchical relationship tree of related tables based on the Microsoft Dynamics AX metadata, and to create a hierarchical relationship, you select a parent table and discover all related tables based on the AX metadata.  

Moreover, the parent table in the relationship is put at the root level of the tree and the discovery process creates a nested relationship tree from a parent entity to a child entity. This is done until there are no relationships left at the lowest level.

Also, a purge object is used to remove selected records from all tables in the relationship tree from the AX database. Similarly, an archive object is used to move selected records from all tables in the relationship tree from the AX database to the archive database.

After creating a purge object or an archive object, you can apply business rules and selection criteria to entities and transactions to determine which records are deleted or moved from the production database.

System architecture

The IDMF was created using the Microsoft .NET development environment and provides a single document interface (SDI). In addition, the IDMF uses a database, called the management database, for the storage and retrieval of data, and communicates with Application Object Server (AOS) through COM Business Connector or .NET Business Connector.

Now, just be aware that during installation, the IDMF installs a Windows service called the Intelligent Data Management Framework for Microsoft Dynamics AX service. This service is used to run scheduled jobs and is referred to as the scheduler service for the Data Management Framework.

The following diagram provides a high-level overview of the Data Management Framework system architecture.

Deployment scenarios

Single-server deployment

Multi-server deployment

Distributed deployment

Take care!