Cross-company Support
Microsoft Dynamics AX can have multiple companies in one data base. Ex: container conCompanies = [ 'cee', 'ceu' ]; custTable custTable;
while select crossCompany : conCompanies custTable
{
print custTable.accountNum;
}
pause;
Friday, August 31, 2012
Eventing In Ax2012
Eventing
Lets the user use a publisher and subscriber model when modifying MDAX2012.
Events can be modeled in the AOT or be used as a programming construct and can be handled in either X++ code or in managed code.
NOTE: Modeled events are only available on classes and not tables or forms.
Eventing Terminology
MDAX2012 events are modeled after the .NET event concepts :
Producer :- The producer is the logic that contains the code that causes a change. This means that it is the entity that emits events.
Consumer :- The consumer is the application code that manifested an interest in being notified when a specific event occurs. This means that it is an entity that receives events.
Event :- An event is a representation of a change that happened in the producer. Microsoft Dynamics AX 6.0 supports Pre and Post events that occur before and after a method is called.
Event Payload :- The event payload is the information that the event carries with it. If a person is hired, for example, the payload includes the employee's name and date of birth, and so on.
Delegate :- A delegate is the definition of the information passed from the producer to the consumer when an event happens.
Event Handlers
Event handlers are methods that are called when the delegate is called, directly through code (for the coded events) or from the environment (in the modeled events). The relationship between the delegate and the handlers can be maintained in code or in the AOT.
Delegate is a keyword.
When program conditions meet the programmer's criteria for the event, the X++ code can call the delegate, and that causes the delegate to call all the event handler methods that are added to the delegate.
To create a delegate, right-click the class and select New->Delegate.
Adding Handlers in the AOT
The user must identify a static method to handle the event on the delegate. However, when adding event handlers from code, described in the following material, instance methods are also applicable as event handlers. Event handlers can be added to the delegate by dragging the event handler to the delegate node that represents the event to be handled.
Adding Handlers in Code
Use special X++ syntax to remove or add event handlers to events. The delegate name appears on the left side of the += operator.
private void AddStaticHandler()
{
;
this.MyDelegate += eventhandler
(Subscriber::MyHandler);
}
Pre and Post Events
You can subscribe an event handler to automatically run immediately before a method is run.
The event handler can change the parameter values before they are entered into the method. You can also subscribe an event handler to run immediately after a method is run. The event handler can change the value that is returned by the method, before the return value is received by the caller of the method.
Event handlers for these before and after events are visible in the AOT as sub nodes on the methods to which they apply.
Lets the user use a publisher and subscriber model when modifying MDAX2012.
Events can be modeled in the AOT or be used as a programming construct and can be handled in either X++ code or in managed code.
NOTE: Modeled events are only available on classes and not tables or forms.
Eventing Terminology
MDAX2012 events are modeled after the .NET event concepts :
Producer :- The producer is the logic that contains the code that causes a change. This means that it is the entity that emits events.
Consumer :- The consumer is the application code that manifested an interest in being notified when a specific event occurs. This means that it is an entity that receives events.
Event :- An event is a representation of a change that happened in the producer. Microsoft Dynamics AX 6.0 supports Pre and Post events that occur before and after a method is called.
Event Payload :- The event payload is the information that the event carries with it. If a person is hired, for example, the payload includes the employee's name and date of birth, and so on.
Delegate :- A delegate is the definition of the information passed from the producer to the consumer when an event happens.
Event Handlers
Event handlers are methods that are called when the delegate is called, directly through code (for the coded events) or from the environment (in the modeled events). The relationship between the delegate and the handlers can be maintained in code or in the AOT.
Delegate is a keyword.
When program conditions meet the programmer's criteria for the event, the X++ code can call the delegate, and that causes the delegate to call all the event handler methods that are added to the delegate.
To create a delegate, right-click the class and select New->Delegate.
Adding Handlers in the AOT
The user must identify a static method to handle the event on the delegate. However, when adding event handlers from code, described in the following material, instance methods are also applicable as event handlers. Event handlers can be added to the delegate by dragging the event handler to the delegate node that represents the event to be handled.
Adding Handlers in Code
Use special X++ syntax to remove or add event handlers to events. The delegate name appears on the left side of the += operator.
private void AddStaticHandler()
{
;
this.MyDelegate += eventhandler
(Subscriber::MyHandler);
}
Pre and Post Events
You can subscribe an event handler to automatically run immediately before a method is run.
The event handler can change the parameter values before they are entered into the method. You can also subscribe an event handler to run immediately after a method is run. The event handler can change the value that is returned by the method, before the return value is received by the caller of the method.
Event handlers for these before and after events are visible in the AOT as sub nodes on the methods to which they apply.
Primary Index
A primary key is one or more columns that uniquely identify one record in a table from all the other records. A primary index is a unique index for a table that defines the primary key for that table. To set an index as a unique index, set the index property Allow Duplicates to No.
To set the primary index on a table, open the property sheet for the table. The PrimaryIndex property allows any unique index with a key that is mandatory and cannot be edited.
Surrogate Key
When a primary index is not specified, Microsoft Dynamics AX 2012 uses a Surrogate Key as the primary index. This key is the RecId field and, if the table is saved per company, the DataAreaId. The surrogate key is used on many relations between tables.
A primary key is one or more columns that uniquely identify one record in a table from all the other records. A primary index is a unique index for a table that defines the primary key for that table. To set an index as a unique index, set the index property Allow Duplicates to No.
To set the primary index on a table, open the property sheet for the table. The PrimaryIndex property allows any unique index with a key that is mandatory and cannot be edited.
Surrogate Key
When a primary index is not specified, Microsoft Dynamics AX 2012 uses a Surrogate Key as the primary index. This key is the RecId field and, if the table is saved per company, the DataAreaId. The surrogate key is used on many relations between tables.
Tables Vs Classes In Ax2012
Tables as Classes
A table can be considered an independent class used to address fields or methods defined on that table. In fact when a table is instantiated, it is done so with the system class called xRecord. This class contains methods called when committing record changes to the database and some other system methods that operate on records.
Differences between tables and classes include the following:
• A place for a table buffer is automatically assigned in a table (in classes the new method is used).
• Fields in tables are public; they can be referred to from everywhere.
• Fields in tables can be referred to directly; for example, in a report, whereas variables in a method can only be referred to using accessor methods.
Table Code
The following example illustrates how table code differs from code for a class.
str text;
text = CustTable.name; // Fields in a table are public
print CustTable.name; // Fields in a table can be referred to directly
A table can be considered an independent class used to address fields or methods defined on that table. In fact when a table is instantiated, it is done so with the system class called xRecord. This class contains methods called when committing record changes to the database and some other system methods that operate on records.
Differences between tables and classes include the following:
• A place for a table buffer is automatically assigned in a table (in classes the new method is used).
• Fields in tables are public; they can be referred to from everywhere.
• Fields in tables can be referred to directly; for example, in a report, whereas variables in a method can only be referred to using accessor methods.
Table Code
The following example illustrates how table code differs from code for a class.
str text;
text = CustTable.name; // Fields in a table are public
print CustTable.name; // Fields in a table can be referred to directly
X++ Attributes In Ax2012
X++ Attributes
MDAX-2012 supports attributes being assigned to X++ code. This allows for a rich set of metadata to be built. It describes methods and types that are defined within X++ code. Attributes are defined as classes that are derived from the SysAttribute class. The following code for the SampleAttribute class is an example of an attribute class:
public class SampleAttribute extends SysAttribute
{
str sMetadata; // A field in classDeclaration.
public str GetMetadata()
{
return sMetadata;
}
public void new(str _sMetadata)
{
super();
sMetadata = _sMetadata;
}
}
Attributes can then be used on other classes and methods. The following example shows the structure of a new Attribute class, AuthorAttribute:
class AuthorAttribute extends SysAttribute
{
str author;
public str Author()
{
return author;
}
public void new(str _author)
{
super();
author = _author;
}
}
In the following example, AuthorAttribute is used to decorate other classes and methods:
[AuthorAttribute("Isaac")]
public class MyClass()
{
...
}
[AuthorAttribute("Isaac")]
void MyMethod()
{
...
}
MDAX-2012 supports attributes being assigned to X++ code. This allows for a rich set of metadata to be built. It describes methods and types that are defined within X++ code. Attributes are defined as classes that are derived from the SysAttribute class. The following code for the SampleAttribute class is an example of an attribute class:
public class SampleAttribute extends SysAttribute
{
str sMetadata; // A field in classDeclaration.
public str GetMetadata()
{
return sMetadata;
}
public void new(str _sMetadata)
{
super();
sMetadata = _sMetadata;
}
}
Attributes can then be used on other classes and methods. The following example shows the structure of a new Attribute class, AuthorAttribute:
class AuthorAttribute extends SysAttribute
{
str author;
public str Author()
{
return author;
}
public void new(str _author)
{
super();
author = _author;
}
}
In the following example, AuthorAttribute is used to decorate other classes and methods:
[AuthorAttribute("Isaac")]
public class MyClass()
{
...
}
[AuthorAttribute("Isaac")]
void MyMethod()
{
...
}
FactBoxes In Ax2012
FactBoxes
A FactBox is a small selection of data related to the current record in the list page.
Three types of Factbox exist:
• 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.
• 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.
• 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.
A FactBox is a small selection of data related to the current record in the list page.
Three types of Factbox exist:
• 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.
• 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.
• 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.
Form Templates In AX2012
Form Templates
Some form templates are available to help create the correct form type with the
appropriate controls, and to keep the design consistent across the application. The
following table shows the available form templates and where they should be
used.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEis5QcBKsPV_UIZa10s4KZ0Tb8Zz1Y4AH3eQnDcTU2ewNypO-WxGbFgsiIhLmxYz9P66j6YGbIQVNlsW5sM7k0oCoX8KN8irjqKGonNn-HWDe5qJ39sIAbcEucM6Q5vhubWDssgiDEMses/s320/FTemplates_1.PNG)
Examples of Templates
The following table gives examples of each form template
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPw_lhWtjHCwcgTQqpS8ul-EH-3OknW1dBdE6CCjl7dUnG7-nXNzk3pvF5kGG6G-pWQOvUsuhfaJDlmjkzIJro3WBzhmSpD046Ug-d3QfVIlEp43x19DmqOqWjYN2NFhUxZkvv8dasaDg/s320/FTemplates_2.PNG)
To create a form using a template, right-click the Forms node in the AOT, select New Form From Template, and then select the template. Try to create each template and examine the controls and design that is created.
Examples of Templates
The following table gives examples of each form template
To create a form using a template, right-click the Forms node in the AOT, select New Form From Template, and then select the template. Try to create each template and examine the controls and design that is created.
Table Relations (Normal , Related Field Fixed , Field Fixed)
Table Relations (Normal , Related Field Fixed , Field Fixed)
Lets say you have ClothesTable and ClothesOrders.
ClothesTable has the following fields: ClotheId, Name and CollectionTypeId
ClothesOrder has the following fields: OrderId, ClotheId, Qty OrderId could be a number sequence and Qty entered manually bby the user.
CollectionTypeId has the following elements:
0 - Men
1 - Women
2 - Children
Example 1: Related Fixed FieldOn MenClothesOrder we create a new relation to ClothesTable and specify the follwing two:
1. Normal = ClotheId to ClotheId (Best practice to specify this on the EDT) and
2. Related Fixed Field 0 = ClothesTable.CollecTionTypeId.
This shows that the lookup to the clothes table should show only clothes with the same ClotheId (point 1) AND clothes that are of type Men (point 2) because the our table deals with order for mens' clothes. We use 0 because Menis element 0 in the Enum.
Example 2: Fixed Field This kinda works the other way round:
Imagine you have a ClothesOrders table (generic) and you have seperate tables for MenClothesTable, WomenClothesTable and ChildrenClothesTable. Fixed field says that the specified normal relation (on ClotheId) to MenClothesTable only works if the CollectionTypeId of the current record is set to 0 (Men) else the relation is disabled.
Lets say you have ClothesTable and ClothesOrders.
ClothesTable has the following fields: ClotheId, Name and CollectionTypeId
ClothesOrder has the following fields: OrderId, ClotheId, Qty OrderId could be a number sequence and Qty entered manually bby the user.
CollectionTypeId has the following elements:
0 - Men
1 - Women
2 - Children
Example 1: Related Fixed FieldOn MenClothesOrder we create a new relation to ClothesTable and specify the follwing two:
1. Normal = ClotheId to ClotheId (Best practice to specify this on the EDT) and
2. Related Fixed Field 0 = ClothesTable.CollecTionTypeId.
This shows that the lookup to the clothes table should show only clothes with the same ClotheId (point 1) AND clothes that are of type Men (point 2) because the our table deals with order for mens' clothes. We use 0 because Menis element 0 in the Enum.
Example 2: Fixed Field This kinda works the other way round:
Imagine you have a ClothesOrders table (generic) and you have seperate tables for MenClothesTable, WomenClothesTable and ChildrenClothesTable. Fixed field says that the specified normal relation (on ClotheId) to MenClothesTable only works if the CollectionTypeId of the current record is set to 0 (Men) else the relation is disabled.
Thursday, August 30, 2012
What is a Model and how to create them?
Models
A model is a logical grouping of elements within a layer.
Models help in situations where multiple ISV solutions or projects must operate together.
This architecture allows many solutions to co-exist within each layer.
An element can exist in exactly one model in a layer. The same element can exist in a customized version in a model in a higher layer.
New models are easy to create in the MorphX IDE and are applied when modifying or adding objects in the AOT.
Models can be exported, installed, or uninstalled from the model store.
Models are identified by a name and a publisher, and have a set of properties that can be changed, including a version number.
How to create a new Model:
Tools > Model management > Create model.
A model is a logical grouping of elements within a layer.
Models help in situations where multiple ISV solutions or projects must operate together.
This architecture allows many solutions to co-exist within each layer.
An element can exist in exactly one model in a layer. The same element can exist in a customized version in a model in a higher layer.
New models are easy to create in the MorphX IDE and are applied when modifying or adding objects in the AOT.
Models can be exported, installed, or uninstalled from the model store.
Models are identified by a name and a publisher, and have a set of properties that can be changed, including a version number.
How to create a new Model:
Tools > Model management > Create model.
AX2012 Layer's Modified
AX 2012 Layer's
There are three layers available only to Microsoft to deliver the base application. (The xxP layer indicates the patch layer for each application object layer).
SYS, SYP:- System layer: The standard application is developed in this lowest layer. This includes the core application and the localization for most countries.
GLS, GLP :- Globalization layer: Includes features developed for some countries that were not yet moved into the SYS layer.
FPK, FPP :-Feature Pack layer: Includes industry feature packs that are controlled by Microsoft.
There are three layers available to partners and ISVs.
SLN, SLP :- Solution layer: Includes Microsoft endorsed industry solutions.
ISV, ISP :- Independent Software Vendor layer: Includes generic or vertical solutions developed by ISV's.
VAR,VAP :- Value Added Reseller layer: Includes multi-customer solutions developed by VAR's.
There are two layers available to both partners and customers who have a license to access the AX source code.
CUS, CUP :- Customer layer: Includes customer specific functionality.
USR, USP :- User layer: Includes installation specific functionality and customizations.
There are three layers available only to Microsoft to deliver the base application. (The xxP layer indicates the patch layer for each application object layer).
SYS, SYP:- System layer: The standard application is developed in this lowest layer. This includes the core application and the localization for most countries.
GLS, GLP :- Globalization layer: Includes features developed for some countries that were not yet moved into the SYS layer.
FPK, FPP :-Feature Pack layer: Includes industry feature packs that are controlled by Microsoft.
There are three layers available to partners and ISVs.
SLN, SLP :- Solution layer: Includes Microsoft endorsed industry solutions.
ISV, ISP :- Independent Software Vendor layer: Includes generic or vertical solutions developed by ISV's.
VAR,VAP :- Value Added Reseller layer: Includes multi-customer solutions developed by VAR's.
There are two layers available to both partners and customers who have a license to access the AX source code.
CUS, CUP :- Customer layer: Includes customer specific functionality.
USR, USP :- User layer: Includes installation specific functionality and customizations.
Subscribe to:
Posts (Atom)