Public site setup in Dynamics AX

1                             1. Deploy latest build if you don’t have already.

2                             2. Install regular EP with VS tools.

3                             3. Setup public site following are the steps.

Step 1 - Public Site Creation

1. Launch SharePoint Central Administration

2. Under Application Management, click Manage web applications

3. Select the Web Application hosting the public site. It is SharePoint - 80 in our case.

4. Click Authentication Providers button from the ribbon

5. Click the Default Zone

6. Under Anonymous Access, uncheck Enable anonymous access (required for EP Public Site Creation)

7. Click Save

8. Under Application Management, click Create Site Collections

9. On the following page, enter page Title as EP Public Site

10. Set Web Site Address URL as /sites/Public

11. Select Microsoft Dynamics Public template under Custom tab

12. Set Primary Site Collection Administrator as your alias

13. Press OK

14. After the site has successfully been created, click on the site URL to verify that you can access it

Step 2 - Configure IIS

1. Open Internet Information Services (IIS) Manager (Start > Administrative Tools > Internet Information Services Manager).

2. Select the Web Site SharePoint-80

3. Double click on Authentication

4. Enable Anonymous Authentication

5. Enable Windows Authentication

Step 3 - Enable Guest Account in AX

1. From a Microsoft Dynamics AX client, click System Administration > Common -> Users -> Users.

2. Double click the Guest User

3. Click on Edit

4. Select the Enabled check box.

5. Assign Guest user to Guest role and Vendor anonymous (external) role.

Step 4 - Configuring SharePoint

1. Launch SharePoint Central Administration

2. Under Application Management, click Manage web applications

3. Select Web Application hosting the public site. It is SharePoint - 80 in our case.

4. Click Authentication Providers button from the ribbon

5. Click the Default Zone

6. Under Anonymous Access, check Enable anonymous access

7. Click Save

8. Now go to the EP Public site http://<MACHINE NAME>/sites/public

9. Click Sign In and use the system account

10. Navigate to Menu Site Actions > Site Permission

11. From the Ribbon click Anonymous Access button

12. In the popup dialog, select Entire Web site and click OK

13. Launch SharePoint Central Administration

14. Click Application Management > Web Applications > Configure alternate Access Mapping

15. Click Add Internal URLs

16. Choose Alternalte Aceess Mapping collection to be the Web application Sharepoint-80

17. Type http://localhost as the internal URL and Zone =Default.

18 Click Save

Step 5 - Setup Internet Explorer for anonymous access

To ensure that you are accessing the page in anonymous access mode and not automatically logged in using Windows authentication:

1. In Internet Explorer, Go to Tools > Internet Options > Security tab

2. Select the Trusted zone

3. Click on Custom Level

4. Scroll to the bottom, under User Authentication > Login

5. Select Anonymous logon.

6. Click OK 

API Deprecation in Dynamics AX 2012

In order to minimize code upgrade cost for minor version upgrade we need to minimize the footprint of changes to the APIs. The basic need is to ensure that customers who took dependency on the API that needs to be changed will have easy time up taking the changes, ideally the code that worked in a previous release would also work in current release. In case when the changes are required the API needs to go through proper deprecation process that will ensure that customers will get quality help during code upgrade enabling them to quickly uptake all changes.

Proper deprecation of APIs for minor version upgrade

Changes from one of the below categories:
 

•       API signature changed (class and table methods)
•       API return type changed
•       API number of parameters changed
•       API parameter types changed
•       API access specifier became more restricted
•       API parameter order changed
•       API parameter changed from optional to mandatory
•       Deleted public/protected APIs (class and table methods)
•       Deleted classes
•       Changing inheritance hierarchy
•       Reducing the number of interfaces implemented

should be deprecated in the following way:

• API marked with SysObsoleteAttribute attribute
• SysObsoleteAttribute supplied with detailed information about how to migrate code that has dependency on deprecated API (provide an alternative or link to white paper in case of major rework)
• If the API is no longer functioning set isError = true in the SysObsoleteAttribute attribute so the compiler will report any usage of that API as an compiler error

In order to deprecate an API use the SysObsoleteAttribute on a method level as on the below
example:

[SysObsoleteAttribute('Use method Args::create() instead', false)]
public static Args create(container _pack)
{
    Args sysArgs = new Args();
    sysArgs.unpack(_pack);
    return sysArgs;
}

In order to deprecate class use the SysObsoleteAttribute on a class level as on the below example:
[SysObsoleteAttribute('Use Args class instead', false)]
class SysArgs extends Args
{
}

If an API is no longer functioning use the SysObsoleteAttribute and set the isError parameter to true, that way the compiler will report any usage of that API as an error
[SysObsoleteAttribute('Use method Args::create() instead', true)]
public static Args create(container _pack)
{
    Args sysArgs = new Args();
    sysArgs.unpack(_pack);
    return sysArgs;
}

Additionally, for APIs that return void  you should remove all the code from the method body, for APIs that returns non void value you should replace the method body with the following code:

throw error(Error::wrongUseOfFunction(funcname()));

Adding new parameters:

• New parameters should be added as the last ones in the parameter list.
• In case when a new parameter can be added with default value the deprecation is not necessary as that does not break the contract.
• In case when new parameter does not have a default value and the API has parameters with default value the API should be deprecated and a new one should be introduced.

Changing inheritance hierarchy:

• Changing inheritance hierarchy has tremendous impact on during code upgrade. The general recommendation is to avoid it unless it’s absolutely necessary. Then depending on the magnitude of changes and the impact on API compatibility either provide a new hierarchy and deprecate the old one providing detailed information how to move dependent code forward.
• Deprecation of metadata artifacts that can be used in the code
• Changing EDT type of fields
• Changing EDT type of field to a non-compatible EDT (outside of hierarchy) is considered as breaking public contract because if there is a customer code that relies on field type this code will no longer compile. If possible  such changes should be avoided or documented (use known issues process).

Deprecation of enum items:

The general recommendation is not to delete enum items since it’s a change that’s intrusive from code upgrade. If the change is absolutely necessary it needs to be documented (follow known issues process). Additionally if that enum is being used in business data you have to provide appropriate data upgrade script.

Renaming fields:

In order to document data model changes please document every single field rename following known issues process.
Fields must not be deleted beetween minor versions.

Deprecation of metadata elements:

For minor version upgrade the goal is to limit intrusive changes that would have to be address during code upgrade as much as possible. If the changes are absolutely necessary the team owning given metadata needs to provide documentation concerning moving code/metadata that’s dependent on deprecated elements.

Delete Actions in Dynamics AX

Introduction:-

The DeleteAction element helps maintain database consistency when a record is deleted. Define delete actions to specify what should occur when data being deleted in the current table is related to data in another table.

Adding a delete action:-

• In the Application Object Tree (AOT), expand the Data Dictionary.

• Expand Tables, and then locate the table that you want to add a delete action to.

• Click the table, right-click DeleteActions, and then click New DeleteAction.

• Right-click the new delete action, and then click Properties.

• Select a related table from the Table property list.

• Set the DeleteAction property. The following table describes the available values.

Types of Delete action:-

Cascade:

A cascading deletion action will delete all records in the related table, where the foreign key is equivalent to the primary key of the current table. That is, deleting the parent record will also delete the child record(s) in the related table.

This cascading will take place whether the deletion is performed in code or directly by a user through the user interface.

Restricted:

A restricting delete action will raise an error message if the user tries to delete a record, where records exist in the related table where the foreign key is equivalent to the primary key of the current table.

This error will only appear if the deletion is performed through the user interface. A deletion from X++ code will be allowed to proceed and will not be cascaded to the related table. In this case the programmer should call .validateDelete() themselves prior to the call to .delete()

Cascade+Restricted:

This delete action normally works as a Restricted delete action. However if the deletion is performed through X++ code, no error will be raised and the deletion will be cascaded to the related table.

Enterprise Portal (EP) in Dynamics AX 2012

Introduction:

Enterprise Portal for Microsoft Dynamics AX provides a Web-based application framework that allows for users to interact with data in Microsoft Dynamics AX through a Web browser.You can create new content for Enterprise Portal, and also modify existing content. Most additions and changes can be made using resources in the Application Object Tree (AOT) in combination with SharePoint. More advanced applications and modifications can be created by using Visual Studio and the development framework for Enterprise Portal. 

Installation  & Configuration:

Prerequisites:

•          x64 Machine
•          Operating System
•          Windows Server 2008 SP2
•          Windows Server 2008 R2
•          SharePoint 2010

Installation:

Start MS Dynamics AX setup and select "Enterprise Portal (EP)" under web server components, reporting services extension (to install Dynamics AX reporting services - required to view AX reports on EP) and visual studio tools (required for EP development) 

click next button to proceed forward,

if there are no errors go to to next step and provide your domain and password,

select the components as below and proceed,

 go to next step,

 

go to next step,

click install,

when installation is done you can verify EP installation (go to */System administration(Area page)/Setup/Enterprise portal(fast tab)/web sites/ check internal and external URL's and click "view in browser" button, this will open EP role centre page). 

Enumerator and Iterator in Dynamics AX 2012

Difference between Enumerator and Iterator(use for list, Maps or Sets element’s traversing)

• We can traverse our List, Map or Set collections by using either an enumerator or an iterator 
• We can’t add/Delete elements in the List or Maps or Set using Enumerator class but we can do it via iterator class
• It is a best practice to use the Enumerator class instead of the Iterator class, because enumerators are automatically created on the same tier as the map (when calling the List.getEnumerator method)
• Enumerators require less code than iterators to initiate there instance, they perform slightly better.

For more information please refer to following link

Difference between Enumerator and Iterator in AX 2012

Automatic Events in Dynamics AX 2012

Introduction:

Automatic Events are those events that are triggered by the environment.

Types:

PreEvent:

The pre-event handlers are called before the execution of the designated method. Each of the pre-event handlers can access the original values of the parameters and modify them as required.

PostEvent:

Post-event handlers are called after the method call has ended. The post-event handlers can modify the return value of the called method.

Implementation:

Below is a sample project that shows how to implement Pre and Post Event Handlers in Dynamics Ax 2012.

This Project contains two Classes PrePostEvents and PrePostSample .  In PrePostSample Class there is a DemoMethod that contains Pre and Post Event handlers.

 

This Method takes an integer values passed from the Main method and has Pre and Post Event Handlers associated with it. The Properties Window of Pre and Post Event handler looks like this.

                            

                                          

The CalledWhen Property in the above Figure has the Value Pre Which Shows that it’s a PreEvent Handler.

 

                                    

Similarly, the CalledWhen Property shows that it is a PostEventHandler.

                                       

This method simply gets the _args passed by the Main Method.

 

This method gets the _args passed by the Main Method and replaces its value.

 

This method passes the value to the PreEvent Handler and the DemoMethod.

Work Flow in Dynamics AX 2012

A Work Flow can be defined as a sequence of steps where each steps follows the precedent without any gap or delay.It can also be defined as a movement of tasks within a process. The Dynamics AX Work Flow infrastructure enables user configurable workflows in Dynamics Ax application modules with specific focus on tasks and approval workflows.

Please refer to the following article for complete understanding

Work Flow in Dynamics AX