AOSAuthorzation property on Tables

The AOSAuthorization table property enables you to specify which data access operations must undergo user permission checking.

The four fundamental data access operations are create, read, update, and delete.

1. None (Default)
2. CreateDelete
3. UpdateDelete
4. CreateUpdateDelete
5. CreateReadUpdateDelete

the above operations  are represented the combination of AOSAuthorization enumaration values.

No permission checking is done when the AOSAuthorization property is set to None.

Ex: Suppose AOSAuthorization is set to CreateDelete on a given table.
In this case, create and delete operations would be allowed to execute only if the Application Object Server (AOS) can confirm that the user has the appropriate permissions.
Update and read operations would execute without checking user permissions, because they are not mentioned in the chosen AOSAuthorization value.

The AOSAuthorization property also applies to views.

Ex: For example, suppose view Vew2 reads data from table Tab3. You have no read permission to either Vew2 or Tab3. The AOSAuthorization value on Vew2 is None, but on Tab3 it is CreateReadUpdateDelete. When you try to read from Vew2 the outcome will be a successful retrieval of data.

 

TableGroup

Table groups provide a method for categorizing tables according to the type of data they contain.

Use:When exporting data, you can use table groups to filter records.
For example, if you wanted to specify that customers should be exported but customer transactions should not. The table group that a table belongs to is defined by the TableGroup property of the table.
The groups available are defined by the system Enum TableGroup.

Parameter:
The table contains data primarily used as parameters or setup information for one of the main tables (a table that has a TableGroup property of Main).
The table typically contains only one record per company.
Ex: CustParameter, VendParameter

Group:
The table contains data primarily used to categorize one of the main tables (a table that has a TableGroup property of Main).
There is a one-to-many relationship between a Group table and a Main table.
Ex: CustGroup, VendGroup

Main:
The table is one of the principal tables in the application and contains data for a central business object. The table typically holds static, base information.
There is a one-to-many relationship between a Main table and a Transaction table.
Ex: CustTable VendTable

Transaction, Transaction header, and Transaction line
The table contains transaction data. The table is typically not used for data entry directly.

The tables in the Transaction header table group categorize the tables in the Transaction line table group.

There is a one-to-many relationship between a Transaction header table and Transaction line tables.

Ex: CustTrans, VendTrans

Worksheet, Worksheet header, and Worksheet line

Tables that contain information that is validated and made into transactions.

Unlike the data that is contained in the tables in the Transaction table groups, data in the Worksheet table groups is temporary.

There is a one-to-many relationship between a Transaction header table and Transaction line tables.

Miscellaneous:
The table does not fit in any of the other categories. This is the default value for a new table.
Ex: TableExpImpDef

Framework :
Tables that are used by the underlying Microsoft Dynamics AX frameworks, such as Application Integration Framework (AIF). These tables are created during installation and are not associated with configuration keys.

Reference : Tables that contain reference data.

components in ax 2012

                                              Server components

                                                   BI Components

                                                  client components

developer tools

Integration components

                                        Retail Components

Full Text Indexes on Tables

Ax 2012 provides full text functionality that enables Ax to search the business data over a large volume of text data or documents.

we can create full text indexes on tables of type Main and Group.

Before we use full text functionality in application we must configure SQL Server full text.

How to create a Full Text Index:

http://msdn.microsoft.com/EN-US/library/gg845129.aspx

How to use :

http://msdn.microsoft.com/EN-US/library/gg879757.aspx

 

TableType property in Ax 2012

In Ax- 2012 all tables have TableType property that replaces Temporary property found in Ax-2009.

Regular: The default value. These are permanent Tables.These tables are used for storing data permanently in database.

InMemory: These temporary tables are hosted in the client, the data will wipe out as soon as instance of the form or report is closed.
Joins and other Set operations with InMemory tables are usefull inefficient.
These tables are same thing as what was previously called a temporary table in ax 2009.
An InMemory table is held in memory until its size reaches 128 KB. The dataset is then written to a disk file on the server tier.
The disk file for an InMemory table has the naming convention $tmp<nnnnnnnn>.$$$.
http://msdn.microsoft.com/EN-US/library/bb314749.aspx

TempDB: This is the new type of temporary table that is hosted in the sql server database.
These temporary tables can be joined in the database with regular tables.
Joins and other Set operations on TempDB tables are can be efficient.This was the joining problem we have InMemory Tables.
http://msdn.microsoft.com/EN-US/library/gg845661.aspx

Difference between InMemory table and Container:

• Data in containers are stored and retrieved sequentially, but an InMemory table enables you to define indexes to speed up data retrieval.
• An index is of no benefit if you are working with only a few records. In such cases a container might involve less overhead and perform faster than an InMemory table.

Another important difference between InMemory tables and containers is how they are used in method calls.
When you pass an InMemory table into a method call, it is passed by reference.
Containers are passed by value.
When a variable is passed by reference, only a pointer to the object is passed into the method.
When a variable is passed by value, a new copy of the variable is passed into the method. If the computer has a limited amount of memory, it might start swapping memory to disk, slowing down application execution. When you pass a variable into a method, an InMemory table may provide better performance than a container.


 

Deploy SSRS reports in Ax 2012

To deploy reports from Microsoft Dynamics AX:

1. In the AOT, expand the SSRS Reports node. 
2. Expand the Reports node. 
3. Right-click the report that you want to deploy, and then click Deploy Element.

To deploy reports from Microsoft Visual Studio:

In Solution Explorer, right-click the reporting project that contains the reports that you want to deploy, and then click Deploy.
Reports are deployed for the neutral (invariant) language only.

Microsoft PowerShell:
open Windows PowerShell and view a list of the reports that are included with Microsoft Dynamics AX.
Open Windows PowerShell as an administrator by following these steps:

1. Click Start > Administrative Tools.
2. Right-click the Microsoft Dynamics AX 2012 Management Shell option.
3. Click Run as administrator.

Retrieve a list of the report :

Open Windows PowerShell

$reports = Get-AXReport -ReportName *

View the list of reports by entering the following command:  

$reports

 

Deploy the reports:

 

1. Type the following command to deploy the report. Ex: CustTransList

Publish-AxReport –ReportName CustTransList.

2. To deploy multiple reports.
Publish-AxReport –ReportName Sales, SalesAnalysis.

3. Deploy All the reports.

Publish-AxReport –ReportName *

4. Deploy reports to a different server

Publish-AxReport –ReportName  -ServiceAOSName  –ServiceAOSWSDLPort

 

 

Types of SSRS reports in Ax 2012

   2 types of SSRS reports in Ax 2012

Development Tasks for reports

http://technet.microsoft.com/EN-US/library/cc653472.aspx