Why is the approach taken to de-integrate everything in Ax?

[fed]

Цитата:

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

Возможно, тем кто делает видно, а не тебе. И тем, кто участвует в TAP.

Дык возникает вопрос - если они технологию слоев в VS и .net поддержали, то почему они об этом не пишут во всех блогах и Channel 9, а пишут про какие-то примочки к AOD и улучшения в компиляторе X++ ?

Цитата:

ты думаешь лиуензии продаются по себестоимости?

А какая мне разница - насколько сильно сэкономил вендор ? Вот если конечная цена для меня ТОЖЕ упала - вот тогда я готов радоваться что вендор сэкономил на разработке отдельного сборщика мусора или редактора отчетов.
Вообще - забавно. В классической экономической теории, после того как товар выходит из нишевого рынка на массовый, его цена должна СИЛЬНО упасть, поскольку падает доля затрат на R&D в единице товара. (Вспомни цены LCD-мониторов 10 лет назад и сейчас). Однако, в случае Аксапты, эта цена почему-то выросла в ДВА раза.Как раз недавно знакомые, которые на старой схеме лицензирования остались, считали во сколько им лицензия на одного пользователя в 2001 году обошлась и сколько она же стоит теперь.

Цитата:

В том, что используется распространенный компонент, выгода не только в том, что стоимость меньше - еще проще найти дополнения к нему и информацию по нему и глюков меньше.

Меньше глюков ? Я две недели назад как с одного проекта. Дык вот там программисты из лучших побуждений сделали так, чтобы закупку нельзя было разнести пока она не пройдет большую цепочку утверждений. Однако выяснилось, что из за уникальной глючности ядра workflow в Аксапте, этот самый workflow не может пройти быстрее чем за 4-5 часов. После почти месяца общения с саппортом, удалось решить эту проблему, только закомментировав большую часть проверок security и прав доступа в workflow. Похоже что разработчики не тестировали свой код при числе пользователей больше 50 и числе групп больше 1.

Цитата:

Пример, пожалуйста.

Вот тут mazzy жалуется на то что ему приходиться держать одного человека на X++ и одного на Visual Studio axtools: Navigating the AX Application Explorer in Visual Studio
Не думаю что ему человек на C# обошелся бесплатно
Ну и тут еще glibs чуть выше написал.

[belugin]

Цитата:

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

Дык возникает вопрос - если они технологию слоев в VS и .net поддержали, то почему они об этом не пишут во всех блогах и Channel 9, а пишут про какие-то примочки к AOD и улучшения в компиляторе X++ ?

...в ценах не разбираюсь...

Цитата:

Меньше глюков ? Я две недели назад как с одного проекта. Дык вот там программисты из лучших побуждений сделали так, чтобы закупку нельзя было разнести пока она не пройдет большую цепочку утверждений. Однако выяснилось, что из за уникальной глючности ядра workflow в Аксапте, этот самый workflow не может пройти быстрее чем за 4-5 часов. После почти месяца общения с саппортом, удалось решить эту проблему, только закомментировав большую часть проверок security и прав доступа в workflow. Похоже что разработчики не тестировали свой код при числе пользователей больше 50 и числе групп больше 1.

Обрати внимание, что в предыдущей версии такой возможности вообще не было. Интересно, что Mazzy отвечает на форуме на вопросы про WF, причем, его ответы отличаются от фразы "не используйте WF"

Цитата:

Вот тут mazzy жалуется на то что ему приходиться держать одного человека на X++ и одного на Visual Studio axtools: Navigating the AX Application Explorer in Visual Studio
Не думаю что ему человек на C# обошелся бесплатно
Ну и тут еще glibs чуть выше написал.

про EP я не знаю. Насчет того, зачем mazzy человек на C# хотелось бы услышать подробнее.

[mazzy]

Цитата:

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

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

Я хотел бы напомнить о Project Green.
Хотя его теперь так не называют, но развитие идет в полном соответствии этим планом (разве что только сроки постоянно сдвигаются)

http://forum.mazzy.ru/index.php?showtopic=2508
хочу напомнить, что в рамках первой волны Майкрософт сделал более-менее одинаковый функционал. Не знаю как GP и SL, а вот объяснить обычному пользователю разницу между NAV и AX теперь стало практически невозможно (технологическая разница есть).

в рамках второй волны Майкрософт собрался перевести функционально одинаковые продукты на единую технологию. Что сейчас и происходит.

Опять же... У Navision переход осуществляется более плавно, бесшовно и более безболезненно, чем у Аксапты (хотя и там матричные формы потеряли... но зато нашли массу других вещей)
В частности В NAV 2009 код C/AL конвертится в C#, а что же будет в DAX?
и alexef: Navision - технический взгляд (NAV2009, SP1, ...)

Цитата:

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

Интересно, что Mazzy отвечает на форуме на вопросы про WF, причем, его ответы отличаются от фразы "не используйте WF"

1. Давайте оставим Mazzy в покое.
1.1. Его мнение может быть ошибочным.
1.2. Не думаю, что мнение является аргументом
2. кроме того, я не говорю "не используйте WF" потому что пока надеюсь на следующие версии и выражаюсь вежливо.

Цитата:

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

Насчет того, зачем mazzy человек на C# хотелось бы услышать подробнее.

Отчеты писать на VS. Сервисы для оборудования (например, терминалы сбора данных). Портал программировать.

в общем, все то что Майкрософт перевел на .net

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

Цитата:

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

Ну лично я предпочту немножко попереключаться между окнами, чем рисовать отчет в глюковатом MorphXном редакторе.

Возможно. Я тоже не против попереключаться.
Но как я уже писал меня просто выворачивает от того, что VS не знает кучу вещей, привычных для разработчика на X++. Прежде всего не знает о EDT, enum и relations.

[belugin]

Цитата:

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

Отчеты писать на VS.

ПОлучается, даже несмотря на все недостатки интеграциии, несмотря на необзодимость платить дополнительную ставку ты выбираешь создание отчетов под SSRS а не под X++. Почему?

Цитата:

Сервисы для оборудования (например, терминалы сбора данных).

Как это делалось под Ax3?

[mazzy]

Цитата:

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

ПОлучается, даже несмотря на все недостатки интеграциии, несмотря на необзодимость платить дополнительную ставку ты выбираешь создание отчетов под SSRS а не под X++. Почему?

Потому что Майкрософт объявил, что в ax6 не будет встроенных отчетов.
Мои попытки начать .net программинг начались еще с появлением rs в ax3.
проявилось здесь Посоветуйте хорошую книгу по Visual Studio, не очень сложную?
но очень долго у меня получалось игнорировать это веяние.

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

Но деваться некуда, придется выкручиваться и так или иначе придется осваивать дополнительные инструменты.

Цитата:

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

Как это делалось под Ax3?

Так же. Но тогда я просто искал человека по железу. И нашел.
Правда я зачем-то потянул его в программирование Аксапты... Дурень я... Нет, чтобы просто использовать его знания и позволить ему развиваться в ту сторону, куда его душа хотела.
Универсализм стоит очень-очень дорого...
А универсализм при несовместимых/разноинтерфейсных технологиях - еще дороже.

И мы снова возвращаемся к изначальному тезису, который процитировал EVGL в самом начале.
Why is the approach taken to de-integrate everything in Ax?

[belugin]

Цитата:

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

Потому что Майкрософт объявил, что в ax6 не будет встроенных отчетов.

Правильно ли я понимаю. что ты сейчас уже нанимаешь программера для Ax6?

Цитата:

Так же.

Правильно ли я понимаю, что в данном случае никакой деинтеграции не произошло - просто тебе дали новую возможность?

[mazzy]

Цитата:

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

Правильно ли я понимаю. что ты сейчас уже нанимаешь программера для Ax6?

Нет. Сейчас я ищу на ax2009.
Но надеюсь работать c ним же и тогда, когда выйдет ax6.

Цитата:

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

Правильно ли я понимаю, что в данном случае никакой деинтеграции не произошло - просто тебе дали новую возможность?

Тут важен глагол. и контекст.
Мне заменили одну возможность на другую - ведь старый COM-коннектор больше не поддерживается
Мы говорим о торговом оборудовании.

С таким глаголом и контекстом - Да.

[mifi]

Цитата:

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

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

Так это программисты сделали, без запроса от руководства проекта внедрить цепочку утверждений? Они, видимо, по ночам работали и потом тайком перенесли на рабочую версию?
Или это все-таки было бизнес-требование от ЛПР. Если это было бизнес-требование, то насколько проще, дешевле и безглюкавее это было бы сделать без встроенного workflow в AX?
Возвращаясь к дискуссии про SSRS. Ничего, кроме отвращения не могу вспомнить о собственном dev experience создания более-менее сложных отчетов в MorphX.
Этот движок хорош только для создания автоотчетов
Если считать за аксиому, что среда разработки ERP-системы должна позволять создавать сложные отчеты, включая графику, то тут есть два пути развития:
1. Изобрести велосипед, т.е. разработать новый движок внутри MorphX
2. Сделать хорошую интеграцию с уже имеющимся движком того же вендора, реализовав возможность создавать автоотчеты и обращаться к метаданным AX
В AX6 сейчас активно ведутся работы по направлению 2. Что в этом плохого - непонятно. Да, старым аксаптоведам (вроде меня) придется немного подучиться. И все.

[mazzy]

Цитата:

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

Возвращаясь к дискуссии про SSRS. Ничего, кроме отвращения не могу вспомнить о собственном dev experience создания более-менее сложных отчетов в MorphX.

Вы наверное рисовали эти безумные формы с рамочками как в Счете, счете-фактуре и т.п.?
Для рисования таких "красивых" объектов MorphX подходит плохо.

Вот если бы у постановщиков задач в Майкрософте зватило духу поставить задачу не так "сделать как в 1С", а так "сделать как стандартные в Аксапте", то и ваше мнение было бы другим, и мнение клиентов, и мнение многих программистов, которые работают с этими угребищными отчетами с рамочками.

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

Цитата:

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

Этот движок хорош только для создания автоотчетов

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

Нужны итоги по строкам заказа? нет проблем - делайте автоотчет.
Нужны итоги по строкам журнала? нет проблем - делайте автоотчет.
Нужны итоги по складским движениям? нет проблем...

Цитата:

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

Если считать за аксиому, что среда разработки ERP-системы должна позволять создавать сложные отчеты

Э-э-э... А зачем принимать такую аксиому?

Мне кажется, что аксиомы должны быть другими:
1. ERP-система должна позволять пользователю быстро и лего получить нужные ему данные из одной или двух-трех таблиц.
2. ERP-система должна позволять программисту быстро и легко сделать сложные связи и получить данные из нескольких таблиц
3. ВАЖНО! полученные данные ERP-система должна уметь выгружать в Excel.

Все! Большего от ERP-системы и не нужно по большому счету.
Если пользователям нужна графика, то переносим в Excel и применяем диаграммы/графики

Беда morphX отчетов в том, что там нет инструмента для выгрузки данных в Excel.

Цитата:

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

2. Сделать хорошую интеграцию с уже имеющимся движком того же вендора, реализовав возможность создавать автоотчеты и обращаться к метаданным AX

Я - за хорошую интеграцию.
Я против интеграции-только-для-того-чтобы-интеграция-была.

[mifi]

Цитата:

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

Вы наверное рисовали эти безумные формы с рамочками как в Счете, счете-фактуре и т.п.?
Для рисования таких "красивых" объектов MorphX подходит плохо.

Вот если бы у постановщиков задач в Майкрософте зватило духу поставить задачу не так "сделать как в 1С", а так "сделать как стандартные в Аксапте", то и ваше мнение было бы другим, и мнение клиентов, и мнение многих программистов, которые работают с этими угребищными отчетами с рамочками.

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


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

Нужны итоги по строкам заказа? нет проблем - делайте автоотчет.
Нужны итоги по строкам журнала? нет проблем - делайте автоотчет.
Нужны итоги по складским движениям? нет проблем...


Э-э-э... А зачем принимать такую аксиому?

Мне кажется, что аксиомы должны быть другими:
1. ERP-система должна позволять пользователю быстро и лего получить нужные ему данные из одной или двух-трех таблиц.
2. ERP-система должна позволять программисту быстро и легко сделать сложные связи и получить данные из нескольких таблиц
3. ВАЖНО! полученные данные ERP-система должна уметь выгружать в Excel.

Все! Большего от ERP-системы и не нужно по большому счету.
Если пользователям нужна графика, то переносим в Excel и применяем диаграммы/графики

Беда morphX отчетов в том, что там нет инструмента для выгрузки данных в Excel.


Я - за хорошую интеграцию.
Я против интеграции-только-для-того-чтобы-интеграция-была.

Правильно ли я понимаю, что с Вашей точки зрения рисовалки отчетов вообще излишни (раз уж они для ERP-системы ненужны), Excelя всем достаточно?

[mazzy]

Цитата:

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

Исключительно чтобы подготовиться к Ax6? Или зачем-то еще?

Проект у меня на ax2009.
Давай или в личку, или в ту тему.

Цитата:

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

- пришлось переписывать кучу кода?
- программеры на C# дороже чем на C++ и VB (или на чем там писали)?

- Пришлось все переделывать нафиг.
- Не так. Программеры на "C# & X++" стоят дороже чем программеры на C# или на X++

Цитата:

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

Правильно ли я понимаю, что с Вашей точки зрения рисовалки отчетов вообще излишни (раз уж они для ERP-системы ненужны), Excelя всем достаточно?

Нет, неправильно.

[belugin]

Цитата:

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

Давай или в личку, или в ту тему.

Я про то, что аргумент "сейчас маззи нанимает SSRS программера" скорее в пользу SSRS

Где я не прав:
1. Для проекта на Ax2009 тебе нужен SSRS девелопер
2. В Ax2009 пользоваться SSRS необязательно
=>
у SSRS настолько больше возможностей чем у MorphX, что это для каких-то случаев для тебя оправдывает траты на программиста.

Цитата:

- Пришлось все переделывать нафиг.

а много там было?

Цитата:

- Не так. Программеры на "C# & X++" стоят дороже чем программеры на C# или на X++

Я так понял, что раньше было то же самое, только буквы C# надо заменить на VB или C++?


Кстати, никто не может напомнить ссылку, где написали про SSRS отчеты в Ax6 - я бы попросил автора поподробнее про это написать?

[trud]

Цитата:

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

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

Кстати к вопросу о возможностях
Как к примеру в SSRS вы будете делать отчет типа списка поставщиков(фиксированный набор полей). При условии что пользователь может накладывать фильтры на любые поля поставщиков(в том числе и сложные фильтры) и связанных таблиц(тех которые есть сейчас и появятся в будущем) и с возможностью сортировки по любым полям этой таблицы?

Это то, что можно сделать в MorphX за несколько минут, сколько времени у вас это займет в SSRS

[fed]

Цитата:

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

Так это программисты сделали, без запроса от руководства проекта внедрить цепочку утверждений? Они, видимо, по ночам работали и потом тайком перенесли на рабочую версию?
Или это все-таки было бизнес-требование от ЛПР. Если это было бизнес-требование, то насколько проще, дешевле и безглюкавее это было бы сделать без встроенного workflow в AX?

Workflow сделали естественно по просьбам ЛПР. Счас клиент понимает что сделать без встроенного workflow было бы проще дешевле и безглюкавее.
Но это понимание пришло только после того как клиент сначала показал workflow пользователям, потом (после того как выяснилось что встроенный workflow мало что может) потратил кучу средств на изучение способов доработки workflow в .net, а потом при старте системы выяснилось что при реальном количестве пользователей, групп и прав, функция securityKeySet.loadUserRights() может отработать за 0.2 секунды, а может и за 45. Соответственно - стандартное ядро WorkFlow и системы обработки Eventов постоянно ждало завершения этой функции и события в очереди стояли по 5-6 часов.

Цитата:

Возвращаясь к дискуссии про SSRS. Ничего, кроме отвращения не могу вспомнить о собственном dev experience создания более-менее сложных отчетов в MorphX.
Этот движок хорош только для создания автоотчетов
Если считать за аксиому, что среда разработки ERP-системы должна позволять создавать сложные отчеты, включая графику, то тут есть два пути развития:
1. Изобрести велосипед, т.е. разработать новый движок внутри MorphX
2. Сделать хорошую интеграцию с уже имеющимся движком того же вендора, реализовав возможность создавать автоотчеты и обращаться к метаданным AX
В AX6 сейчас активно ведутся работы по направлению 2. Что в этом плохого - непонятно. Да, старым аксаптоведам (вроде меня) придется немного подучиться. И все.

Просто отчеты на SSRS выпустили еще в версии 4.0. Похоже что до более или менее работоспособного состояния их доведут в версии 6.0
Именно это-то и пугает. Вот сделают счас компиляцию в .net на лету. Дык страшно подумать что будет, если первые пару версий это будет работать так же стабильно как SSRS или WF в версиях 4.0 и 2009. И если проблемы с отчетами или WF еще можно как-то обойти, то проблемы с ядром системы исполнения - явно нет...

[mifi]

Цитата:

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

Workflow сделали естественно по просьбам ЛПР. Счас клиент понимает что сделать без встроенного workflow было бы проще дешевле и безглюкавее.
Но это понимание пришло только после того как клиент сначала показал workflow пользователям, потом (после того как выяснилось что встроенный workflow мало что может) потратил кучу средств на изучение способов доработки workflow в .net, а потом при старте системы выяснилось что при реальном количестве пользователей, групп и прав, функция securityKeySet.loadUserRights() может отработать за 0.2 секунды, а может и за 45. Соответственно - стандартное ядро WorkFlow и системы обработки Eventов постоянно ждало завершения этой функции и события в очереди стояли по 5-6 часов.


Просто отчеты на SSRS выпустили еще в версии 4.0. Похоже что до более или менее работоспособного состояния их доведут в версии 6.0
Именно это-то и пугает. Вот сделают счас компиляцию в .net на лету. Дык страшно подумать что будет, если первые пару версий это будет работать так же стабильно как SSRS или WF в версиях 4.0 и 2009. И если проблемы с отчетами или WF еще можно как-то обойти, то проблемы с ядром системы исполнения - явно нет...

Было бы очень хорошо, если бы все программное обеспечение работало бы как надо с версии 1.0 и не содержало багов. Если знаешь пример такого ПО - поделись, пожалуйста. Еще хорошо если был бы мир во всем мире, вечная весна и деньги никогда не кончались..

Цитата:

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

....
Но это понимание пришло только после того как клиент сначала показал workflow пользователям, потом (после того как выяснилось что встроенный workflow мало что может) потратил кучу средств на изучение способов доработки workflow в .net, а потом при старте системы выяснилось что при реальном количестве пользователей, групп и прав, функция securityKeySet.loadUserRights() может отработать за 0.2 секунды, а может и за 45. Соответственно - стандартное ядро WorkFlow и системы обработки Eventов постоянно ждало завершения этой функции и события в очереди стояли по 5-6 часов.

И чего? Побороли проблему?

[fed]

Цитата:

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

И чего? Побороли проблему?

Я же написал уже - просто тупо отрубили проверки прав доступа в workflow и eventах...

[EVGL]

Цитата:

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

Меньше глюков ? Я две недели назад как с одного проекта. Дык вот там программисты из лучших побуждений сделали так, чтобы закупку нельзя было разнести пока она не пройдет большую цепочку утверждений. Однако выяснилось, что из за уникальной глючности ядра workflow в Аксапте, этот самый workflow не может пройти быстрее чем за 4-5 часов. После почти месяца общения с саппортом, удалось решить эту проблему, только закомментировав большую часть проверок security и прав доступа в workflow. Похоже что разработчики не тестировали свой код при числе пользователей больше 50 и числе групп больше 1.

Да, workflow - это фантастическая история успеха. Я, кажется, уже рассказывал, что наш "отдел новых технологий" пару лет назад получил заказ оценить WF, сравнив ее с примитивной разработкой нашей компании (да чего уж там, с моей примитивной разработкой). Вердикт был однозначен: руки прочь от того, что сделано в AX, оставаться на том, что сделал Глазов.

У примитивной разработки Глазова образца 2004 года было одно и решающее преимущество: ничего не надо было программировать и не надо было подключать никаких сторонних систем.

Мне кажется, WF постигла судьба фичей, отданных на откуп программистам без конкретного технического задания. Т.е. фиче было суждено была делать не то, что нужно, а то, что можно. Такая же судьба постигла Commerce Gateway: после 4 лет и полной переработки получили более-мене удобоваримый продукт под названием AIF.