kamalblogs: Towards Dynamics Ax Product Certification – Best Practices (Part I)

[Blog bot]

Источник: http://kamalblogs.wordpress.com/2010...ctices-part-i/
==============

At Innovites the last couple of months have been a challenging period. We prepared our product for Dynamic Ax Certification along with two live implementations. In this multi post article, I will try to detail the derailing issues that we tackled to keep us in track. I thought this would be an interesting source of input for people who are planning be certified like us.

In order to get the product certified there are quite some criteria’s but as a product manager my whole responsibility was on ensuring the quality of the application in par with the Ax ceritification requirements.

On a very high level following is what we aimed at.

• Application should have “0” errors and warnings
• Best practice errors should be Zero
• No “To Do” tasks should be in the application
• Well documented help system

We planned to prepare for certification almost one year after commencing our product development. We felt it is a quite a late decision after seeing the number of BP errors, warnings and Todo tasks crossing the 500 mark.

Since our development environment was entirely on TFS it was easy to make the start even with such large number of violations. The options of “reject check in” with Bperror warning and Tasks  in Source controlled helped us implement this. The following article from the X++ team was highly helpful in resolving our warnings.

X++ team link – http://blogs.msdn.com/x/archive/2007...-warnings.aspx

http://blogs.msdn.com/x/archive/2007...g-message.aspx

Once we started this practice we found a steep increase not just in quality but also in terms of reliability in the code.

By the mean time we had slowly built strong Development infrastructure on top of TFS includes an automated build system that publishes Aod, Patches along with their release notes automatically to an PTP ( will details this in a article later). This automated system helped us keeping in track of our development quality every day.

After a month long practice we realized that the total number came down below the 100 mark , we reached “Ground Zero”(a internal project code) in the next couple of days.

The quality improvement in the application through this exercise interested us to get more disciplined. So this time we dived to fix the BP warnings as next step which is not a pre-condition forcertification. There were too many warnings from which it became difficult for us to identify the ones that we wanted to fix.

To our surprise we unraveled so many interesting things when we tried to fix these warnings. It even further delayed our certification process. …

Let’s look at them in my next article….

see you for now…




Источник: http://kamalblogs.wordpress.com/2010...ctices-part-i/

[gl00mie]

А вот интересно, как при сертификации приложения борятся с ошибками и предупреждениями Best Practices, вылезающими на стандартном приложении? Не править же стандартное приложение только ради того, чтобы при компиляции измененных на твоем слое объектов не вылезали "чужие" ошибки BP? См. также Проверки Best Practices только для объектов на текущем слое
Или вот, к примеру, \Classes\SysBPCheckClassNode\checkRunBaseImplementation блюдет возможность классов-наследников RunBase переключаться между клиентом и сервером при выполнении prompt() и ругается, если у класса свойство RunOn отличается от Called from. Но пардон, ведь есть класс-наследник RunBase, у которого выставлен, к примеру, RunOn Server, а ты наследуешь свой класс от него, ты же в наследнике никак на это свойство не можешь уже повлиять. Так что эта проверка BP должна по идее ругаться только на тот класс-наследник RunBase, у родительского класса которого RunOn еще равно Called from, а она вместо этого ругается на все семейство классов, производных от класса-"нарушителя". Это я к чему: есть, к примеру, класс LedgerJournalCheckPost, наследник RunBase, у которого на sys-слое выставлено RunOn Server, и вот создаешь ты производный от него класс разноски журналов ГК, в котором свойством RunOn управлять уже не можешь. И что, теперь твой класс должен по жизни вылезать в списке нарушителей BP?..

[Maxim Gorbunov]

О, отличный пример! Спасибо.

Похоже, в таком случае единственное правильное (с точки зрения сертификации) решение - не наследовать свой класс от LedgerJournalCheckPost.

А вообще, непонятно, зачем LedgerJournalCheckPost вообще наследует RunBase. Напрямую он всё равно не вызывается, да и других вызовов наследованных методов я что-то не нашёл. Похоже на какой-то рудимент.