dax-ideas: Creating a new Item through Code

[Blog bot]

Источник: http://dax-ideas.blogspot.com/2010/1...ough-code.html
==============

For Creating a new Item in AX 2009 we have to make a entry in four imp tables
They are
1) InventTable
2) InventTableModule
3) InventItemLocation
4) InventTxt

Below is a simple job which will create a new Item in AX 2009

static void Item(Args _args)

{
InventTable inventTable;
InventTableModule inventTableModule;
InventItemLocation inventItemLocation;
InventTxt inventTxt;
int counter;
;
inventTable.initValue();
inventTable.ItemId = "NIK-1000";
if(InventTable::exist(inventTable.ItemId))
{
throw error ("Item already exist,You cannot create duplicate items");
}
else
{
inventTable.ItemGroupId = "Television";
inventTable.ItemName = "LCD Plasma";
inventTable.ModelGroupId = "STD Cost";
inventTable.DimGroupId = "N-W";
inventTable.ItemType = ItemType::Item;
inventTable.insert();
}
<span style="color: blue;"><strong>for(counter=0; counter

[lev]

вы меня простите, но что то у меня какая то повышенная притензия к тому что публикуется в блогах
опять какой то непонятный код... точнее сказать понятный, и даже он отработает, но в нем как то все коряво написано... а так как интернет читают очень много людей, которые могут этим примером воспользоваться, считаю необходимым внести некие поправки.

0. Нет транзакции (ttsbegin, ttscommit). Т.е. у нас может куда то добавиться запись, а куда то нет. Потом будут висеть не понятные записи в таблицах, и при создании номенклатуры руками вдруг начнет на неё ругаться что мол такая уже есть, хотя на самом деле её нет.
1. Далее бросилось в глаза - это:

...
if(InventTable::exist(inventTable.ItemId))
{
throw error ("Item already exist,You cannot create duplicate items");
}
else...

в таблице InventTable есть уникальный индекс по ItemId, который не позволит создать две одинаковые записи. Зачем тут проверка на существование с прекращением выполнения? Я бы понял если бы выполнялась проверка, и в зависимости от этого создавалась или не создавалась запись в InventTable, а так это излишний код.
2. Не перед одним из инсертов нет validateWrite()! Это не есть гуд. Ну конечно тут возможно программисту нужно создать эти записи во что бы то не стало, не обращая внимания ни на какие бизнес требования. Но это тоже странно.
3. Для inventTableModule, inventItemLocation и inventTxt не вызывается перед заполнением полей initValue(). А ведь в этих таблицах (кроме inventTxt) заполняются нужные поля по умолчанию. Да даже если бы не заполнялись, в будущем в этот метод может быть добавлен код, который будет заполнять важные поля и тогда этот джоб добавит номенклатуру криво. Т.е. в итоге получаем не совсем заполненные таблицы, что так же не очень корректно.

Вот как то так.

[S.Kuskov]

Цитата:

Сообщение от lev

вы меня простите, но что то у меня какая то повышенная притензия к тому что публикуется в блогах

А вы поставьте Blog bot'у минус . А то у него вон какая репутация, и как выясняется не всегда заслуженная

А если серьёзно, то полностью с вами согласен.

P.S.: К стати родилась идея. Вместо репутации Blog bot'а (средней температуры по больнице), вести отдельные репутации для каждого источника-блога. У каждого блога будет своя оценка. Тогда читающие смогут объективно оценивать компетентность, того или иного автора.

[EVGL]

... и не хватает еще 3 таблиц из AX2009, которые стоило бы заполнять.

[Vadik]

Цитата:

Сообщение от EVGL

... и не хватает еще 3 таблиц из AX2009, которые стоило бы заполнять.

InventItemXXXSetup в InventTable.insert() заполняются

[Ievgenii]

Цитата:

в таблице InventTable есть уникальный индекс по ItemId, который не позволит создать две одинаковые записи. Зачем тут проверка на существование с прекращением выполнения? Я бы понял если бы выполнялась проверка, и в зависимости от этого создавалась или не создавалась запись в InventTable, а так это излишний код.

К слову и совершенно абстрагируясь от контретного примера.
Нет ничего плохо в том чтобы проверить существует ли айтем - и если нет, то сообщить пользователю об этом в более приятной и дохочивой форме (что нет, и как это исправить). Index duplication exception – очеееень далеко от того что называеться world class usabiltiy and user experience.

Конечный пользователь – это обычный человек который может вообще не знать что такое индекс и так далее.

Еще лучше до этого не доводить. Пример - блокировать кнопку на форме чтобы он не мог нажать “дальше”, если указаный им айтем уже существует + иконку красную возле поля рисовать c хелп текстом чтоне так. А если все хорошо – то зеленую иконку и пускай себе уверено кликает дальше.

[Vadik]

Цитата:

Сообщение от Ievgenii

Index duplication exception – очеееень далеко от того что называеться world class usabiltiy and user experience

А что, в следующей версии пользователю будут Exception-ы оказывать? Просто до сих пор показывали Infolog на родном языке пользователя (см. скриншот)

Цитата:

Конечный пользователь – это обычный человек который может вообще не знать что такое индекс и так далее

Евгений, простите, Вы в систему (не в среду разработки) часто заходите? Вам как пользователю система часто что-то про индексы сообщает?

[Ievgenii]

Цитата:

А что, в следующей версии пользователю будут Exception-ы оказывать? Просто до сих пор показывали Infolog на родном языке пользователя (см. скриншот)

Уважаемый Vadik,

Спасибо за вопрос.

Infolog никуда не деваеться. Речь идет не о способе как выдаеться сообщение (infolog), а - о качество самого сообщения и том что разработчик должен об этом думать (мое убеждение)

Вот в вашем примере – вам конечно же сообщение знакомо и понятно.

Но вот новому пользователю оно ничего не говорит. Более того – оно ему не понятно.
1. Что такое ключ? - пользователь пытаеться создать новый айтем. В определении айтема “ключей” нет. Сообщение как “айтем с именем ХХХ который вы указали уже существует в системе ” звучит более логично.
2. Где указано в сообщении что пользователю надо сделать чтобы исправить ошибку? Сообщение как “Пожалуйста укажити другое имя айтема и повторите операцию” поможет ему продолжить его работу.

В системе есть и будут гораздо более сложные примеры где сущности (как айтем) представлены не одной таблицей а многими таблицами по сложным связям и ключам. В более сложном примере подобное сообщение может быть более сложным (например не указаны составные ключи (более чем одно поле), или тот же index violation по составным или сурогатным ключам)

Цитата:

Евгений, простите, Вы в систему (не в среду разработки) часто заходите? Вам как пользователю система часто что-то про индексы сообщает?

10-12 часов, 5-6 дней в неделю на протяжении последних почти 5 лет.

Если у Вас будет возможность принять участие в технической конференции по Ax “6” в январе в Редмонде – пожалуйста дайте знать, поговорим при встрече.
http://www.microsoft.com/dynamics/DynamicsAXtechnicalconference2011/default.aspx

[Vadik]

Цитата:

Но вот новому пользователю оно ничего не говорит. Более того – оно ему не понятно

И это нормально Есть категории пользователей, которым и со второго, и с третьего раза будет непонятно. А бывает, что тройке "консультант+разработчик+отладчик" без ста грамм непонятно, что им сейчас система сказала и что им с этим делать. Такая у нас жизнь, такая система и такие пользователи, других наверное уже не будет

Цитата:

Сообщение как “Пожалуйста укажити другое имя айтема и повторите операцию” поможет ему продолжить его работу

Ну вот если мне вендор даст возможность один раз в одном месте (и имя ему AOT) настроить такие вот кастомные сообщения о стандартных ошибках (duplicate key, delete actions и пр) и повторно их использовать, я ему в ноженьки поклонюсь. Но писать такие вот заковыристые проверки в куче мест - не буду.
Мое глубокое убеждение - валидация должна делаться один раз там, где она действительно жизненно необходима (а не сто раз где придется на всякий случай) и где она делается максимально эффективно (в примере - ее все равно придется делать на уровне БД, где она не зависит от синхронизации кэшей нескольких AOS-ов). Вы же к примеру при генерации журналов ГК не проверяете, не существует ли уже журнал с таким номером, а по Вашей логике должны бы (ну мало ли)

Цитата:

В системе есть и будут гораздо более сложные примеры где сущности (как айтем) представлены не одной таблицей а многими таблицами по сложным связям и ключам

Именно. Плюс функциональность, используемая несколькими модулями. И если объект одного слоя (расноска по складу к примеру) может выполнить свою работу, он не будет проверять, не запрещен ли постинг в GL (пусть об этом у GL голова болит). Потому что число и стоимость таких вот встречных проверок при увеличении сложности сущности будет расти чудовищно. Главное - обеспечить атомарность (если все честно отработали - commit, кто-то не смог - ругаемся и откатываем всю транзакцию словно и не было ничего)
Тем более - идея выполнять валидацию данных типа

Цитата:

блокировать кнопку на форме чтобы он не мог нажать “дальше”, если указаный им айтем уже существует + иконку красную возле поля рисовать

в процессе ввода (фактически - на каждый клик) выглядит красиво, но работает только в простейших визардах. Натягивать ее на реальные формы аксапты - это трата ресурсов и нервов реальных людей, которым с этим придется работать

Цитата:

10-12 часов, 5-6 дней в неделю на протяжении последних почти 5 лет

It's a rhetorical question, Ted, но, раз уж так - респект

Цитата:

Если у Вас будет возможность принять участие в технической конференции по Ax “6” в январе в Редмонде – пожалуйста дайте знать, поговорим при встрече

За предложение спасибо, но видимо не в этот раз (если вообще когда-нибудь удастся попасть). Это уж скорее Вы дайте знать, если соберетесь к нам на Колыму