mfp: Channel9 - AX screencast on Smart customizations

[Blog bot]

Источник: http://blogs.msdn.com/mfp/archive/20...mizations.aspx
==============

The next installment of AX screencasts is now available on Channel9. It is a 30 minute video on Smart customizations in Dynamics AX 4.0.
Here is the link:
http://channel9.msdn.com/ShowPost.aspx?PostID=267428
Over the coming months I plan to create more screencasts on general development topics in Dynamics AX. If there are any specific topics you would like a screencast to cover, please let me know.


==============
Источник: http://blogs.msdn.com/mfp/archive/20...mizations.aspx

[Blog bot]

Источник: http://channel9.msdn.com/ShowPost.as...=267428#267428
==============
?This 30 minute talk explains how you can customize the business logic in Dynamics AX 4.0, in a way that makes future code upgrades easier.

The talk also covers the layer technology of Dynamics AX, and will create a small customization using an approach with minimal overlayering, implement unit test cases for the customization - and finally do a code upgrade of the customization.

For more information see "Chapter 1 - Architectural Overview" and "Part 2 - Developing with Dynamics AX 4.0" in "Inside Dynamics AX 4.0".

Watch the screencast(WMV)

==============
Источник: http://channel9.msdn.com/ShowPost.as...=267428#267428

[Blog bot]

Источник: http://axcoder.blogspot.com/2007/01/...t-smarter.html
==============

If you haven't watched the video Dynamics AX 4.0 - Smart customizations - watch it! (especally if you are novice Dynamics Ax developer).

I can just add few thoughts:

First of all - this sceencast recommends to subclass existing class, but i thing there asre some cases when it is better to tweak existing class. The most often case - when existing class has bad structure (for example LedgerJournalCheckPost in 3.0 - i don't know about 4.0 so much). If you have one large method which does all you can not just overide it to add some functionality - you often have to copy all it's body to the child and tweak it. I you do so you will have more problems when upgrading to the next version: you have not only to upgrade method of existing parent, but to modify all copied parts of the child and there is no obvious clues to find what parts to modify.

Second, what can be done to make upgrades less painful:

• Interfaces - there havte to be more documented interfaces - so Ax devs will know what they can change and what cannot to make Ax backward compatible.
• Unit tests as part of Ax package - all unit tests developed by Ax team have to be shipped with Ax to enable partner or customer developers ensure they haven't breaked anything
• Events - SAP R/3, as i know, have concept of events - you have not to modify existing code to be informed about some thing ocuured in system - you just subscribe, say, to journal posting and can make extra transaction if you want. So your customisation code isn't mixed with the existing code.Better code structure - i think there is no excure for very big methods for example. Better code structure can be easy reused by customer programmers and can be seft documented and testable.

Источник: http://axcoder.blogspot.com/2007/01/...t-smarter.html