Вот мы и нашли этих 43 AX7 клиентов? Или это не AX7/D365?

[ax_mct]

Цитата:

Сообщение от Vadik;394953 А по существу - у нас [B

запущено два проекта[/B]. Один - дистрибьюция, ритейл + CRM. Второй - дистрибьюция (из плюшек - новомодное управление складом с мобильными сканерами). Ну и еще несколько в работе. По работе (кратко) общался с людьми поработавшими на паре-тройке проектов запущенных с другими партнерами. И это у меня круг общения в AX среде достаточно узкий

И, кстати - в обоих запущенных проектах клиент или ЛПР ранее уже работали с AX и "облако" выбирали целенаправленно и осознанно

Узкое не узкое общение, а десятая часть проектов в мире

Коль есть опыт по двум проектам на AX7, то какие все таки впечатления с полей?
Понятно что ручей не пересох, но очень интересует стоит ли становится в очередь за водой? При условии что рядом теплое море с PHP

[Vadik]

Цитата:

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

Узкое не узкое общение, а десятая часть проектов в мире
Коль есть опыт по двум проектам на AX7, то какие все таки впечатления с полей?

Лично у меня проект только один, но достаточно интенсивный - запустились за три месяца. С точки зрения организации процесса разработки и облуживания - все устроено достаточно разумно. Новых фич столько, что не знаешь за что хвататься. Возможно, в будущем понятие "универсального консультанта" и "универсального разработчика" просто отомрут - правило 10000 часов при таком разнообразии просто перестает работать. В общем, не соскучишься

Цитата:

Понятно что ручей не пересох, но очень интересует стоит ли становится в очередь за водой? При условии что рядом теплое море с PHP

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

[gl00mie]

Есть, к примеру, Technical Concepts Guide по 7-ке, там много интересного описано.

[DAX.Company]

Спасибо, коллеги, за позитивную информацию! успокоили. Будем работать и надеяться на лучшее!

[ax_mct]

Есть однако интересные проекты на AX7. Там где есть готовое нишевое решение.

Annata Dynamics DMS
http://annata.co.uk/solutions/dms/

Их проект
https://customers.microsoft.com/en-U...ud-erp-service

По ходу, список доступных клиентов AX7:
https://customers.microsoft.com/en-U...mics%20365&p=0

Если они умудрились сделать решение полностью сбоку, без overlayering, то они в шоколаде.

Зы: Как бы позитивная информация от противника AX7. Но я пока лучше LESS и СSS дальше точить буду в качестве попкорна.

Где бы еще найти как HTML5 движок в AX7 устроен?

[skuull]

Цитата:

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

Annata Dynamics DMS
http://annata.co.uk/solutions/dms/

Мы сейчас начинаем проект с IDMS от annata и глядя на код этого нишевого решения хочеться плакать и смеяться

[ax_mct]

Цитата:

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

Мы сейчас начинаем проект с IDMS от annata и глядя на код этого нишевого решения хочеться плакать и смеяться

Эмо-программирование? Главный вопрос - у них получилось сделать без overlayering "SYS" кода? Просто интересна судьба таких решений если overlayering системного кода сойдет полностью на нет как планируется MS.

[skuull]

Цитата:

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

Эмо-программирование? Главный вопрос - у них получилось сделать без overlayering "SYS" кода? Просто интересна судьба таких решений если overlayering системного кода сойдет полностью на нет как планируется MS.

Не получилось. Совсем. 90% кода ушло в оверлей App Suite. Очень грустно.

[Logger]

Цитата:

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

Не получилось. Совсем. 90% кода ушло в оверлей App Suite. Очень грустно.

Ээээ.
А как же проекты то делать ?
Заворачиваемся в простыню и тихо ползем на кладбище ?

[skuull]

Цитата:

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

Не получилось. Совсем. 90% кода ушло в оверлей App Suite. Очень грустно.

Пообщался я с этими ребятами и они говорят что МС поставил перед ними срок 12 месяцев чтобы переделать свой ISV на 100% экстеншен. Интересно это для всех ISV так или только для "избранных".

[belugin]

Цитата:

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

Где бы еще найти как HTML5 движок в AX7 устроен?

https://ax.help.dynamics.com/en/wiki...ing-reference/

[fed]

Предположу, что очень скоро, чуваки которые придумали extensions и model lock с удивлением узнают что попытка залочить прикладные модели выносит с рынка 90% вертикальных решений и 99% внедрений.
Ну то есть - это они в правильную сторону двигаются, только им надо было СНАЧАЛА очень капитально подумать на тему какого фундаментального функционала не хватает в прикладном ядре (ну например - absorption costing, или какого-то расширяемого API для распределения себестоимости сопродуктов), потом этот функционал написать, потом поставить там в правильных местах возможность расширений и только потом уже двигать в народные массы свою extension story. Но похоже что команда, которая за ядро и среду разработки отвечает - она совсем не в курсе состояния дел в прикладном функционале и вообще практик внедрения...

[mazzy]

Цитата:

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

Предположу, что очень скоро, чуваки которые придумали extensions и model lock с удивлением узнают что попытка залочить прикладные модели выносит с рынка 90% вертикальных решений и 99% внедрений.

нет, конечно.

extensions = plugins. подход отлично работает в огромном числе продуктов.
этот форум работает с плагинами, far, notepad++, vim, visual studio и т.п...

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

[gl00mie]

Цитата:

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

extensions = plugins. подход отлично работает в огромном числе продуктов.
этот форум работает с плагинами, far, notepad++, vim, visual studio и т.п...

Подход отлично работает в тех продуктах, которые изначально разрабатывались с учетом использования плагинов, и то... Какой-нить ePOS в R2 из-за своих зацементированных в ядре интерфейсов для простейших случаев позволяет писать плагины, а чуть что сложнее - уже всё: либо отказывайся от своей затеи, либо декомпилируй и пересобирай ядро.

Цитата:

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

Цитата:

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

они в правильную сторону двигаются, только им надо было СНАЧАЛА очень капитально подумать на тему какого фундаментального функционала не хватает в прикладном ядре, потом этот функционал написать, потом поставить там в правильных местах возможность расширений и только потом уже двигать в народные массы свою extension story.

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

У меня лично ощущение, что эти два сообщения - об одном и том же.

Цитата:

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

Цитата:

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

Предположу, что очень скоро, чуваки которые придумали extensions и model lock с удивлением узнают что попытка залочить прикладные модели выносит с рынка 90% вертикальных решений и 99% внедрений.

нет, конечно.

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

[fed]

Цитата:

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

нет, конечно.

extensions = plugins. подход отлично работает в огромном числе продуктов.
этот форум работает с плагинами, far, notepad++, vim, visual studio и т.п...

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

Да - какая-то часть вертикальных решений на рынке - это по факту плагины. Живет себе какое-то решение для рисования диаграм ганта или архива документов, живет в отдельных классах и со всем остальным интегрируется на уровне 10-20-30 строчек, вставленных в какие-то стандартные методы и опять-таки - 10-20-30 новых полей, вставленных в стандартные таблицы. Вполне могу поверить, что такие решения можно перевести на механизм extensions.
Тем не менее - если мы говорим о рынке отраслевых вертикальных решений (независимо от того - это действительно отчуждаемые вертикальные решения или просто коллекции наработок) - большая часть из них была построена на идее перекрытия стандартной функциональности. Причем как ты очень хорошо понимаешь, делалось это не по злой воле внедренцев, а просто в связи с отсутствием в стандарте кучи функциональности, типичной для данной отрасли.
Теперь рассмотрим дальнейшие действия микрософт:
1. Они могут закрыть overlayering как класс (возможно - от балды навставлял точек расширения в стандартные прикладные классы). В этом случае, на первых же проектах, по итогам анализа партнеры начнут сообщать клиентам о том что в новой версии их бизнес-процессы не представляется возможным покрыть; Возможность серьезной доработки отрублена, а стандартной фунции для данного процесса - нету. После этого клиент с большой вероятностью бодро откажется от подписки на D365, спишет затраты на анализ в убытки и пойдет внедрять САП. Действительно - преимущество облачных технологий - можно в любой момент остановить проект, списав в убытки только небольшие понесенные затраты. Ну и партнеры само собой будут тоже плавно мигрировать в САП. Ведь если разработка по факту запрещена, то лучше использовать систему с более богатым базовым функционалом.
2. Они могут оставить overlayering. Но только в этом случае - у обычных партнеров (не тех кто плагины пишет), сразу возникнет вопрос: А зачем нам вообще париться с extensions ? Все равно большая часть нашего функционала в них не укладывается, и все равно после апгрейда приходится мерджится. А после этого встанет другой вопрос - а если все равно приходится мерджится, то зачем они платформенные модели заблокировали ? Зачем табу на overlayering объявляли ?

[mazzy]

Цитата:

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

///живет в отдельных классах и со всем остальным интегрируется на уровне 10-20-30 строчек, вставленных в какие-то стандартные методы и опять-таки - 10-20-30 новых полей, вставленных в стандартные таблицы...

ну... мне кажется, что ты упускаешь одну главную вещь:

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

и с точки зрения любого руководителя в Майкрософт, затраты на почти любое телодвижение в dynamics нужно тут же умножать минимум на 5.

собственно, как мне кажется, отсюда и растут всевозможные extensions и прочие микросервисы.

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

но я не вижу другого вменяемого способа эволюционно что-то сделать в этой ситуации.

опять же! вспомни изменения в интерфейсе. Для некоторых продуктов (в частности для Аксапты) новый интерфейс - дичайший даунгрейд. а для остальных - норм. Зато теперь без специальных усилий не отличить один продукт от другого по внешнему виду. См. Dynamics 365. Без суффикса.

и я полностью согласен с твоей мыслью:

Цитата:

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

только им надо было СНАЧАЛА очень капитально подумать

но также хотел бы вспомнить и процитировать (квадратик - ссылка на оригинальное сообщение):

Цитата:

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

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

Цитата:

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

Сейчас в Майкрософте тоже происходит переключение.
Они сами называют его "цифровой трансформацией"
а у всех остальных называется "переход от монолитного приложения к микросервисам".

Причем про переход от монолита к микросервисам написано очень много.
Майкрософт наступает почти на все грабли, описанные в методических материалах про этот переход.
Майкрософт наступает даже на грабли описанные Джоэлем Спольски в далекие времена зарождения МС Офиса и победы над Lotus 1-2-3...
типично: http://russian.joelonsoftware.com/Ar...LetterIII.html, только нужно перевести не с конкурирующего продукта как в статье, а со своего на свой.

и эта "цифровая трансформация" происходит не только в россии. а по всему миру. И не только с Dynamics продуктами.

Применительно к Dynamics, в принципе, они задумали очень правильные вещи:
= выделить в микросервис расчет потребностей в ТМЦ
= выделить в микросервис расчет денежного покрытия и оценку CashFlow
= выделить в микросервис расчет налогов по законодетельствам разных стран
= выделить в микросервис финансы так, чтобы можно было нанимать внешние компании, которые ведут бухучет
= конечно же выделить в отдельный сервис CRM
= и т.п.

[Logger]

Цитата:

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

Да - какая-то часть вертикальных решений на рынке - это по факту плагины. Живет себе какое-то решение для рисования диаграм ганта или архива документов, живет в отдельных классах и со всем остальным интегрируется на уровне 10-20-30 строчек, вставленных в какие-то стандартные методы и опять-таки - 10-20-30 новых полей, вставленных в стандартные таблицы. Вполне могу поверить, что такие решения можно перевести на механизм extensions.
Тем не менее - если мы говорим о рынке отраслевых вертикальных решений (независимо от того - это действительно отчуждаемые вертикальные решения или просто коллекции наработок) - большая часть из них была построена на идее перекрытия стандартной функциональности. Причем как ты очень хорошо понимаешь, делалось это не по злой воле внедренцев, а просто в связи с отсутствием в стандарте кучи функциональности, типичной для данной отрасли.
Теперь рассмотрим дальнейшие действия микрософт:
1. Они могут закрыть overlayering как класс (возможно - от балды навставлял точек расширения в стандартные прикладные классы). В этом случае, на первых же проектах, по итогам анализа партнеры начнут сообщать клиентам о том что в новой версии их бизнес-процессы не представляется возможным покрыть; Возможность серьезной доработки отрублена, а стандартной фунции для данного процесса - нету. После этого клиент с большой вероятностью бодро откажется от подписки на D365, спишет затраты на анализ в убытки и пойдет внедрять САП. Действительно - преимущество облачных технологий - можно в любой момент остановить проект, списав в убытки только небольшие понесенные затраты. Ну и партнеры само собой будут тоже плавно мигрировать в САП. Ведь если разработка по факту запрещена, то лучше использовать систему с более богатым базовым функционалом.
2. Они могут оставить overlayering. Но только в этом случае - у обычных партнеров (не тех кто плагины пишет), сразу возникнет вопрос: А зачем нам вообще париться с extensions ? Все равно большая часть нашего функционала в них не укладывается, и все равно после апгрейда приходится мерджится. А после этого встанет другой вопрос - а если все равно приходится мерджится, то зачем они платформенные модели заблокировали ? Зачем табу на overlayering объявляли ?

Цитата:

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

Ну похоже что все-таки MS продавили на выпуск чисто on-premise версии (даже не гибридной). И после того как ее продажи пойдут, MS с интересом обнаружит что Azure версия используется в основном для прототипирования и предпродаж (генеря жалкие единицы процентов от выручки). После этого им придется сильно откорректировать свои планы
Я в целом могу поверить что HTML-интерфейс они через пару релизов доведут. Но вот как внедряться, когда каждый разработчик должен кодить и отлаживаться в своей виртуалке и релиз требует остановки сервера - я пока не очень понимаю. (Хотя может народ и привыкнет).
Ну то есть - меня в ax7 напрягает две вещи:
1. Облако. Точнее не облако как таковое, а отсутствие у партнеров и клиентов доступа к инфраструктуре. Дайте мне терминальный доступ к Аксаптовскому серверу в Azure, дайте внедрить, и после того как все внедрено, я даже готов отдать это микрософтовской поддержке (если им так уж хочется).
2. Пугают попытки лочить модели. Причем пугает не то что уже сейчас залочили, а то что могут этот механизм использовать для блокирования прикладных объектов (как бы безумно это не звучало для любого внедренца).
С 1ым пунктом, похоже что микрософт уже понял что пролетел, теперь еще осталось помножить на ноль их блокировки моделей...

Вот недавно попалось интервью Джеффри Сновера
https://habrahabr.ru/article/318462/

Из него в очередной раз стало понятно, что все обсуждаемые изменения - это не придуманная архитекторами аксапты придурь, а следствие ухода в облака. Нечто подобное имеет место в мире windows. В общем, глобальная стратегия.

[fed]

Короче говоря Project Green II
Просто в этот раз не хватило мудрости удавить уродца до выхода на рынок.

[mazzy]

Цитата:

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

Короче говоря Project Green

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

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

[ax_mct]

Цитата:

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

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

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

Скрип - это звук разрываемого борта на уровне ватерлинии. Такие заплатки как добавление делегатов и разделение на микросервисы уже не помогут. Архитектура AX в принципе для этого не предназначена. Титаник тупо тонет без шансов.

Программирование в AX7 будет становиться еще дороже, и web-интерфейс AX7 еще медленнее или беднее. При больших сомнениях в надежности.

Единственный вариант это считать AX2012 последней версией и пусть AX7 останется отдельным форком для D365 больше для маркетинга. Особенно если использовать наработки AX7 и приделать EP на его основе к AX2012.

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