What is sure step methodology in ax 2012

Microsoft Dynamics Sure Step is the prescribed methodology for deploying Microsoft Dynamics AX. The Sure Step application

provides product-specific and general project-based templates, workflows, process maps and tools to assist the implementation partners. Sure Step is currently available as an online tool or for download from Partner Source.

The Sure Step methodology is divided into the following phases:

        Try to observe the above picture and explained below briefly.

Diagnostic
Evaluate a customer's business processes and infrastructure Assist the customer with their due diligence cycle, including
ascertaining requirements and their fit with the solution,and assessing the resource needs for the solution delivery Prepare
the project plan, proposal, and the Statement of Work.

Analysis
Analyze current business model and finalize the Functional Requirements document Finalize the fit-gap analysis Develop
the Environment Specification documentation.

Design
Develop the Functional Design, Technical Design, and Solution Design documents Finalize the data migration design Establish
test criteria.

Development
Finalize configurations and setup of the standard solution Develop and finalize the custom code that is required to support
the solution Conduct functional and feature testing of the solution Create the user training documentation.

Deployment
Set up the production environment Migrate data to the production environment Conduct user acceptance test of the system Train
users and finalize the user documentation Conduct go-live check and promote the system to production.

Operation
Resolve pending issues Finalize user documentation and knowledge transfer Conduct a post-mortem of the project Provide on-going
support (activities that continue through any future involvement with the customer after the project is closed).

The Sure Step methodology also provides guidance for the following areas:

Optimization
Leverage Review Offerings to determine proactively if the system is being designed and delivered optimally to meet the customer’s
requirements Analyze the system to determine how it can be optimized for the best performance based on customer's needs.

Upgrade
Assess the customer's current business processes and solution Document the requirements for new functionality Upgrade the system
to new release—including the addition of new functionality, promotion of existing customization that are required, and elimination
of custom code no longer required.

Methods sequence details executed at various events in ax 2012

This gives the information of method calls in the form level while

1. Opening the Form.

2. Creating/Updating/Deleting the record in the Form.

3. Closing the Form.

Sequence of Methods calls while opening the Form

Form --- init ()
Form --- Datasource --- init ()
Form --- run ()
Form --- Datasource --- execute Query ()
Form --- Datasource --- active ()

Sequence of Methods calls while closing the Form

Form --- canClose ()
Form --- close ()

Sequence of Methods calls while creating the record in the Form

Form --- Datasource --- create ()
Form --- Datasource --- initValue ()
Table --- initValue ()
Form --- Datasource --- active ()

Sequence of Method calls while saving the record in the Form

Form --- Datasource --- ValidateWrite ()
Table --- ValidateWrite ()
Form --- Datasource --- write ()
Table --- insert ()

Sequence of Method calls while deleting the record in the Form

Form --- Datasource --- validatedelete ()
Table --- validatedelete ()
Table --- delete ()
Form --- Datasource --- active ()

Sequence of Methods calls while modifying the fields in the Form
Table --- validateField ()
Table --- modifiedField ()

Data validation methods at table level available in AX

The validation methods allow the programmer to verify that certain conditions are fulfilled before an action is executed.

In Axapta, methods of validation at two levels can be programmed:

1. Table
2. Origin of data of a form

It is important to know that the methods of validation of the tables are executed whenever they are introduced or erase registries. Whereas if the validation is made in the form, it will only work when we are working with that form.

1. Whenever it is possible, the validation of data must be made in the table.

Methods

The methods of validation in tables are the following ones:

ValidateField

It is executed when we move the cursor from a field from the form to another one, that is to say, when we left a field. It gives back a data of boolean type. If the result is false, the cursor will remain in the field.
The call to the super method () verifies the validation relations, that is to say, relations in a field where the Validate property has affirmative value. Therefore, we must respect the task made by this super method ().

1. Validations do not have to be codified that can be made with some property. Thus, we will avoid to write code in the ValidateField method if the conditions can be verified with the Validate property of a relation.

ValidateWrite

It is executed before inserting or updating a registry in the table. It gives back a data of boolean type. If it gives back false, the registry is not inserted or updates.
The call to the super method () examines all the fields to verify the value of the Mandatoryproperty. Therefore, we must respect the task made by this super method ().

1. We will avoid to introduce code that it verifies if a field has value, whenever we pruned to use the Mandatory property.

ValidateDelete

It is not necessary to forget, that often also we want to verify certain conditions before erasing a registry of a table. In order to do this, we used the ValidateDelete method ().
ValidateDelete () is called automatically from forms and is used to verify if the present registry can be erased.
The call to the super method () verifies if there are registries related in tables toDeleteActions of the Restricted type. If that is the case, the super method () gives back false. Therefore, we must respect the task made by this method.

1. Whenever we pruned to use a DeleteAction, we will avoid to introduce code in the ValidateDelete method.

Structure of the validation methods

In order to maintain a good structure of programming, he is recommendable that the code for the verifications is not located directly in these methods of validation. It is more advisable than we create verification methods that will be called from the methods of validation previously described.
Example of validation method
Boolean validateWrite ()
{
Boolean ret;

ret = checkSomething () && checkSomethingElse ();

return ret;
}
When some of the conditions is not fulfilled, the verification method must make two things:

1. to present/display to the user an error message
2. to give back the false value like result

The CheckFailed method (`Message of error') writes the text chain that receives as parameter in the information window (Infolog) and gives back the false value. Therefore, by means of the use of this method, we obtained simultaneously both objective.
Example of use of CheckFailed
Boolean checkSomething ()
{
Boolean ret;

if (! something)
{
ret = checkFailed (`Something is wrong');
}
return ret;
}
We could use the previous structure, but cases exist in which it interests to us to verify the same Something condition, present in the CheckSomething method (), without presenting/displaying no message to the user. In this case we would need an additional method, that verified the condition but that it did not show any message.
Nevertheless, this would not be very efficient, because we would be duplicating the verification code, therefore is more recommendable to create a called method Something (), to which we will be able to call when we want, that it will be in charge to make this verification.
We will have, in addition, to change the CheckSomething method (), so that it makes a call to this new method. The CheckSomething method () we will use it solely when we want to show a message the user.
Example of complete validation
Boolean something ()
{
if (! something)
{
return false;
}
return true;
}

Boolean checkSomething ()
{
Boolean ret;

if (! something ())
{
ret = checkFailed (`Something is wrong');
}
return ret;
}

1. We can consider a standard of nomenclature of Axapta, the use of the Check area code, in the name of all those methods that make a call to the global method CheckFailed (). Of this form we will know what methods present/display messages in the Infolog window.

Used methods of system more

Next we are going to describe some of the used methods more in the tables, that by their importance deserve a treatment something more exhaustive. The examples of the methods have been obtained from the CustTable table.

InitValue

The InitValue method is executed when we added a new registry. Also it is called automatically from the forms. Therefore, we will use the method to assign initial values or by defect in a new registry.
Example
void initValue ()
{
CustParameters custParameters;

super ();
this.languageId = CustParameters:: languageId ();
this.currency = CompanyInfo:: find () .currencyCode;
}
It is necessary to indicate that the call to the super method () does not do anything.

Insert

The Insert method is executed when a new registry in the table is introduced. It is very important to assure any related transaction to assure integrity the data base. The techniques of control of transactions will be seen in a later chapter.
Example
void insert ()
{
this.setNameAlias ();
super ();
}
If the registry cannot be inserted in the table, the call to the super method () gives back an error.

Update

The Update method is executed before modifying an existing registry in the table. In this case, also it is very important to control any related transaction to assure integrity the data base.
Example
void update ()
{
CustTable this_Orig = this.orig ();

ttsbegin;
this.setNameAlias ();
super ();
this.setAccountOnVend (this_Orig);
if (this_Orig.custGroup! = this.custGroup)
ForecastSales:: setCustGroupId (this.accountNum,
this_Orig.custGroup,
this.custGroup);
ttscommit;
}
In the example the method is used orig (). This one method gives access us to the registry before the update.

Delete

The method delete is executed when a registry is eliminated. It is very important to assure any related transaction to assure integrity to us the data base.
Let us suppose two related tables calls TableA and TableB. If in TableA we have defined a DeleteAction of type cracked (Cascade) with respect to TableB, when a registry ofTableA erases erase the registries related in TableB.
For yield reasons, one is due to avoid to write code in the Delete method of these related tables (in the example, TableB). If code has not been added, the cascade erasures can be made quickly by the system database manager using directly instructions of erasure SQL.
Nevertheless, if we added code in those tables (what it can be necessary in some occasions), the system creates an instruction while select and executes the Deletemethod in all the tables related daughters. Of this form the yield is minor that when we directly used instructions of erasure in SQL.

How to open a form through code (X++) in AX

Hi Friends,
Today I will show you that how we can open any form through code in AX

For achieving this target we need to write:

new MenuFunction(MenuItemDisplayStr(form menuitem name),MenuItemType::Display).run();

In this code at the place of "Form MenuItem Name" you need to create a menuitem of your form and paste that name at this place.

Task Done.........