AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.04.2018, 12:50   #21  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,228 / 2421 (89) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
ERP система - это мозг, а персонал и оборудование – всё остальное. Человечество хорошо научилось менять устаревшие/износившиеся персонал и оборудование.
Таим образом аналогия ERP это живое, живое не имеет интерфейсов признана неверной. Давайте согласимся на этом.

Раскройте, пожалуйста, эту аналогию. Внутри могзга нет интерфейсов? ERP система работает как нейросеть?

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

Можно как-то перейти от неясных аналогий к логическим построениям?
__________________
https://axcoder.github.io
Старый 02.04.2018, 11:42   #22  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
271 / 262 (9) ++++++
Регистрация: 27.02.2006
Адрес: Дания
Не могу сказать, что внутри мозга есть интерфейсы. Внутри мозга есть множество взаимосвязанных отделов. К примеру, вот так связаны 215 областей мозга мыши:



Если взять все объекты (или группы объектов с одинаковым префиксом) из АОТ и так же расположить по кругу, а потом нарисовать связи в соответствии с перекрестными ссылками, то должна получиться сходная картина.

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



Насколько я знаю. для запуска AOS достаточно модели Application Platform. Очень напоминает рептильный мозг, работающий даже когда хозяин в коме. Application Foundation -- это как лимбический мозг. И, наконец, все остальные модели -- это неокортекс. Всё условно, конечно.

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

Что касается интерфейсов между отделами. Я бы сказал, это довольно условно. Однажды попросили меня дать права доступа к оплате кредитной картой простому складскому рабочему. Я, конечно, поинтересовался у консультанта, не попутал ли он чего, ведь рабочий на складе обычно переставляет ящики. На что мне ответили, что в их бизнес-сценарии рабочий на складе должен брать в руки ящик только после того, как поступит оплата кредитной картой.
За это сообщение автора поблагодарили: belugin (5).
Старый 02.04.2018, 13:17   #23  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,228 / 2421 (89) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
Если взять все объекты (или группы объектов с одинаковым префиксом) из АОТ и так же расположить по кругу, а потом нарисовать связи в соответствии с перекрестными ссылками, то должна получиться сходная картина.
Надо попробовать. Только я бы не рисовал по кругу, а кластеризовал бы. Вопрос, хорошо это или плохо - такая связанность.

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

Цитата:
Что касается интерфейсов между отделами. Я бы сказал, это довольно условно. Однажды попросили меня дать права доступа к оплате кредитной картой простому складскому рабочему. Я, конечно, поинтересовался у консультанта, не попутал ли он чего, ведь рабочий на складе обычно переставляет ящики. На что мне ответили, что в их бизнес-сценарии рабочий на складе должен брать в руки ящик только после того, как поступит оплата кредитной картой.
Это правило или исключение? В софте можно было бы не описать отдельно правило подтверждения операции "брать в руки ящик" и рабочий бы спрашивал у кого-то "могу я взять в руки ящик или нет". Мне кажется тут скорее не логическая надобность а физическое ограничение.

Вообще у меня в голове вертится абстрактная идея разделить сущности - типа проводки - и бизнес-процессы. Сущности давать только расширять и создавать новые, бизнес-процессы можно менять (условно, разрешить оверлееринг на некотром подмножестве моделей, которые описывают бизнес правила) но это потребовал бы адского рефакторинга.
__________________
https://axcoder.github.io
Старый 02.04.2018, 14:27   #24  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,152 / 832 (32) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от belugin Посмотреть сообщение
Там написано "allows" a не "guarantees" .
Для меня это все звучит издевательством над здравым смыслом.
Измененять код через расширение это все равно его менять. Только опосредованно.

Риск же коллизий в непрямом способе только увеличивается. Единственный же вариант избегать столкновений и наложений это не программировать и не менять определенный функционал.

В случае же фунционального сбоку уже все равно overlayering или extensions.
А в случае наложения фунционала - extensions это минное поле.

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

А вот это вот "самый ширяемый язык, колбась не хочу" вызывает у меня фрустрацию. Это вообще для каких адресатов?
Старый 02.04.2018, 14:58   #25  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,152 / 832 (32) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от belugin Посмотреть сообщение
Вообще у меня в голове вертится абстрактная идея разделить сущности - типа проводки - и бизнес-процессы. Сущности давать только расширять и создавать новые, бизнес-процессы можно менять (условно, разрешить оверлееринг на некотром подмножестве моделей, которые описывают бизнес правила) но это потребовал бы адского рефакторинга.
А что даст и кому?
Старый 02.04.2018, 15:16   #26  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,228 / 2421 (89) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
А что даст и кому?
Вся эта штука с экстеншенами - фактически, как я понял, для облегчения обновления. Например, как сейчас можно получить новую платформу без апгрейда кода - потому что есть инетрфейсы и она обратно совместима - кастомеры смогут получить. Новую функциональность не вкладывая большие ресурсы в апгрейд кода. Примерно как сейчас апгрейд винды.
__________________
https://axcoder.github.io
Старый 02.04.2018, 17:21   #27  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,152 / 832 (32) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от belugin Посмотреть сообщение
Вся эта штука с экстеншенами - фактически, как я понял, для облегчения обновления. Например, как сейчас можно получить новую платформу без апгрейда кода - потому что есть инетрфейсы и она обратно совместима - кастомеры смогут получить. Новую функциональность не вкладывая большие ресурсы в апгрейд кода. Примерно как сейчас апгрейд винды.
Если я буду изменять фунциональность Windows OS, пусть даже как бы и сбоку, через крючки и дырки, то жизнь моя будет крайне нескучней при апгрейдах. Программа установки при этом ничего не заметит, это да.

Те же Netsuite, SalesForce предоставляют API к транформаторной будке и это намного честнее. В чем крутизна хитро-изогнутых инструментов X++ если нельзя ими лазить - непонятно.

Поэтому лучше бы MFP посыпал голову пеплом. Мальчишки-живодеры.

Я кстати написал там у него вежливый но саркастичный комментарий два дня назад, но полагаю что его не пропустят. Например я задал вопрос как много сейчас программистов X++ v.7-8 во всем мире вне стен Microsoft. И пожалел что пока еще нет лямбд и шаблонов на уровне языка.
Старый 02.04.2018, 17:27   #28  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,228 / 2421 (89) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Если я буду изменять фунциональность Windows OS, пусть даже как бы и сбоку, через крючки и дырки, то жизнь моя будет крайне нескучней при апгрейдах. Программа установки при этом ничего не заметит, это да.
Зависит от того, что значит "изменять функциональность". В разрешенных местах можно вроде. Драйвера поддерживаются в рамках одного поколения API.

Цитата:
Те же Netsuite, SalesForce предоставляют API к транформаторной будке и это намного честнее.
Это что значит?

Цитата:
В чем крутизна хитро-изогнутых инструментов X++ если нельзя ими лазить - непонятно.
Как это нельзя? Можно но не всюду. Невозможно сделать обратно совместимое API, где можно вообще все.

Нет ли мест, где изменения особо никому не нужны? Типа менять поведение бухгалтерской проводки как сущности нельзя, но менять процессы порождающие проводки можно?
__________________
https://axcoder.github.io
Старый 02.04.2018, 19:26   #29  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,152 / 832 (32) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от belugin Посмотреть сообщение
Зависит от того, что значит "изменять функциональность". В разрешенных местах можно вроде. Драйвера поддерживаются в рамках одного поколения API.
..
Это что значит?
..
Как это нельзя? Можно но не всюду. Невозможно сделать обратно совместимое API, где можно вообще все.

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

Самый расширяемый язык X++ (читай D365FO) не имеет таких интерфейсов, а предлагает сверлить и подвешиваться где только сможешь.
При этом нигде не говорится о концепции и границах дозволенного. Все рассматривается только со стороны технических возможности.

Опытные программисты AX по инерции используют те же границы дозволенного к которым они привыкли. Клиенты по инерции рассматривают как ту же платформу разработки которая переехала в web. И данная инерция движения и мысли провоцируется и поощряется вот такими вот статьями.

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

Но это же не так. Дымовая завеса с этим X++. Нельзя программировать так как было как раньше. Не с технической стороны, а с точки зрения функционала.
И кто об этом и где говорит?

Цитата:
менять процессы порождающие проводки можно
Уверены? По идее все от зависит от нюансов. Что-то можно, а что-то нельзя, но кто это будет оценивать и на какой стадии?
Старый 02.04.2018, 19:58   #30  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
271 / 262 (9) ++++++
Регистрация: 27.02.2006
Адрес: Дания
Вы таки будете смеяться, но мне вся эта история с запретом оверлеинга и введением хардлока напоминает историю с лоботомией как методом лечения. Вы почитайте про нее в Википедии, очень интересно. Сто лет назад один товарищ выяснил, что пересечение волокон в лобных долях делает из буйного пациента (читай, любителя всё оверлеить) спокойного и послушного (согласного подогнать бизнес процессы под стандарт). Были написаны многие статьи и проведены десятки тысяч операций. Были и критики, но их до поры до времени никто из приверженцев нового метода не слушал. Они даже обосновали экономическую целесообразность такого лечения:
Цитата:
... В начале 1940-х годов лоботомия уже широко применялась в США. Во время Второй мировой войны психиатрические отделения госпиталей Управления по делам ветеранов были заполнены множеством солдат, возвращавшихся с фронта и испытавших тяжёлое душевное потрясение. Эти пациенты часто оказывались в состоянии возбуждения, и чтобы осуществлять контроль над ними, требовалось множество медсестёр и другого вспомогательного медперсонала, что приводило к необходимости больших расходов. Таким образом, одной из главных причин широкого распространения лоботомии стало стремление снизить расходы на содержание обслуживающего персонала...
Обратите внимание: «... стремление снизить расходы на содержание обслуживающего персонала» ... Ничего не напоминает? В итоге лоботомию запретили, и сейчас мы о ней знаем из книг и фильмов.
За это сообщение автора поблагодарили: fed (3), Logger (5), NetBus (3).
Старый 02.04.2018, 21:19   #31  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,228 / 2421 (89) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
API означает более или менее неизменный интерфейс и определяет границы дозволенного.

Самый расширяемый язык X++ (читай D365FO) не имеет таких интерфейсов, а предлагает сверлить и подвешиваться где только сможешь.
При этом нигде не говорится о концепции и границах дозволенного. Все рассматривается только со стороны технических возможности.
Я думаю на эту тему в терминах design-by-contract, ковариантности, контравариантности и обратной совместимости.

Цитата:
Уверены? По идее все от зависит от нюансов. Что-то можно, а что-то нельзя, но кто это будет оценивать и на какой стадии?
Я имею ввиду гипотетичекскую альтернативную реальность в которой разделяем приложение разделено на две части - в одном модули которые можно легко обновить на новую версию с продуманным интерфейсом расширения, а в другой - "скрипты", которые можно править, но при этом новая версия не является обратно совместимой. То есть возможен ли некий компромисс. Условно говоря, как в линуксе - можно написать приложение, используя API, а можно поменять исходный код ОС. Или как в игровых движках (тут я не специалист но вроде там так) ядро .из основных понятий и скрипты (насколько я знаю, там даже другие языки для них используют чем для ядра - типа lua).
__________________
https://axcoder.github.io
Старый 02.04.2018, 22:48   #32  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,152 / 832 (32) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от belugin Посмотреть сообщение
Я думаю на эту тему в терминах design-by-contract, ковариантности, контравариантности и обратной совместимости.
...
Я имею ввиду гипотетичекскую альтернативную реальность в которой разделяем приложение разделено на две части - в одном модули которые можно легко обновить на новую версию с продуманным интерфейсом расширения, а в другой - "скрипты", которые можно править, но при этом новая версия не является обратно совместимой. То есть возможен ли некий компромисс. Условно говоря, как в линуксе - можно написать приложение, используя API, а можно поменять исходный код ОС. Или как в игровых движках (тут я не специалист но вроде там так) ядро .из основных понятий и скрипты (насколько я знаю, там даже другие языки для них используют чем для ядра - типа lua).
А я в терминах бизнеса. Самое важное в этом бизнесе правильно оценить возможность и трудоемкость задачи. Вовремя при этом сделать. Какое-то расхождение до 20% считается приемлимым. С новыми лабиринтами браться за программисткие задачи - это неприемлимый риск уже на стадии оценки.

Все уже придумано. Легион продуктов и фрэймоворков. Наиболее популярный подход с использованием предопределенной файловой структруры. Когда мы просто создаем директории и файлы которые подхватываются системой. При этом базовый код не редактируется. Это уже даже некий стандарт.

В облачных ERP типа SalesForce и NetSuite это API. Так как падение wordpress, Yii и прочих web сайтов это не то же самое как падение ERP. (Хотя для онлайн-магазин это тоже больно, но грабли уже всем известные и потому комфортные).

Цитата:
Пишите код на языке программирования Apex для добавления бизнес-логики или на языке разметки Visualforce (для
создания пользовательского интерфейса). Интегрируйте свое приложение с помощью API-интерфейсов и проводите
проверку подлинности своих внешних приложений.
https://resources.docs.salesforce.co...xtend_code.pdf

Теорeтечески ISV решения для D365FO имеют потенциал. Но они опять таки разумны если делать боковой или паралельный фунционал, не меняя сами существующие процессы. Но с таким сбоку не важно чем, слоями, расширениями или API, снижение рисков за счет функциональной отвязанности.

У меня есть несколько своих вертикальных решений которые я бы в других условиях сделал бы для AppStore D365FO. Но я даже не в состоянии оценить ровно ничего. А на оценке строится бизнес.

Поэтому и раздражаюсь на подобные статьи по сути заманивающие в охотничью яму. В яме тоже конечно можно найти косточку погрызть
Старый 03.04.2018, 09:50   #33  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,353 / 4413 (152) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Я просто замечу, что микрософт вложился в Extensions model в надежде на то что клиенты будут более регулярно обновлятся на свежие версии, а микрософт сможет снизить затраты на поддержку. Опыт показывает, что снижение трудозатрат либо пренебрежимо мало, либо вообще отрицательное.
Просто мне пришлось на одно из наших достаточно сильно кастомизированное приложение на Dax2012R2 устанавливать аж 3 CU (CU5, CU7, CU12). Средние мои (то есть - технического консультанта/разработчика) трудозатраты на обновление всех трех окружений (DEV,TEST,PROD), составляли, наверное, около 5-6 человеко-дней. Собственно мерджинг кода в DEV составлял порядка 8-12 часов. Остальное уходило на обновление данных и всякие другие технические мероприятия.
При обновлении D365 с extensions, трудозатрат на мерджинг нет. Однако же трудозартаты на то чтобы забэкапить данные из всех окружений, удалить все виртуальные машины, восстановить данные, проапгрейдить данные в режиме командной строки (со всеми трудностями сопутствующей диагностики) - заметно больше чем трудозатраты на мерджинг.
Кроме того, поскольку без слоев значительно тяжелее найти конфликты в логике, затраты на тестирование возрастают. Аналогично - если клиент требовал более или менее существенных кастомизаций, то заметная часть доработок была сделана по модели copy-on-write. Без технологии слоев, мерджинг микрософтовских изменений в копии микрософтовских классов занимает на порядок дольше.
Не имел пока опыта обновления реального продуктивного приложения в D365, но очень подозреваю что из за необходимости взаимодействовать с DSE (которые работают по крайне примитивному алгоритму), времени на это уйдет заметно поболее чем при старом подходе (когда я все сам мог сделать).
Ну и наконец - модель extensions никак не влияет на время собственно тестирования нового приложения пользователями. (А скорее оно опять таки малость выростет, поскольку шансы на не пойманные конфликты в логике - выше).

Соответственно, я очень подозреваю, что большая часть клиентов просто не будет обновляться вообще. Тяжело будет оправдать достаточно заметные вложения в обновление, если это обновление ничего кроме косметических правок не привносит.
Собственно - вопрос в том, что будет MS делать с теми клиентами, которые не хотят обновляться (Ну то есть - за подписку платят, но тратить свое время на установку обновлений не хотят). Попытки просто кинуть клиентов и прекратить контракты чреваты очень серьезными репутационными потерями (а может даже судебными исками). А если MS сдастся и будет поддерживать клиентов со старыми версиями, то в общем-то смысл extensions model просто пропадет....

Последний раз редактировалось fed; 03.04.2018 в 11:44.
За это сообщение автора поблагодарили: raz (1), DAX.Company (2), Logger (3), belugin (5), ax_mct (7), MikeR (6), AlexeyS (2), Stitch_MS (3), Vadik (1), Link (9), sukhanchik (6).
Старый 03.04.2018, 11:38   #34  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,559 / 5084 (177) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Цитата:
Сообщение от belugin Посмотреть сообщение
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Если я буду изменять фунциональность Windows OS, пусть даже как бы и сбоку, через крючки и дырки, то жизнь моя будет крайне нескучней при апгрейдах. Программа установки при этом ничего не заметит, это да.
Зависит от того, что значит "изменять функциональность". В разрешенных местах можно вроде. Драйвера поддерживаются в рамках одного поколения API.
Очень интересная аналогия с OS и драйверами. Обратимся к истории...
Драйверы в виндах были, думаю, изначально, однако, я не видел живьем версии до 3.1 - это 1992 год выпуска. Но там не то, что драйвер, а любое приложение могло поставить OS в колленно-локтевой упор. В качестве точки отсчета для корпоративного рынка я бы взял WinNT 4.0 - это 1996 год выпуска. Однако, и там с драйверами было не все хорошо, частенько приходилось видеть синий экран смерти, потому что IRQL not less or equal, кроме того, PnP-шность (аналог возможности установки разных расширений D365O сбоку без конфликтов) хромала на обе ноги. Как-то полегче стало в Win2000 (соответственно, 2000-й год выпуска) и совсем хорошо - в WinXP (2001-й год). Где-то тогда же пошла тема с подписанными Microsoft'ом драйверами, которые вместе с железом проходили сертификационное тестирование (аналог сертификации решений для AppStore).
Таким образом, флагманскому продукту Microsoft, над которым трудилось, думаю, куда больше народу, чем сейчас над D365O, понадобилось 4-5 лет (а то и 8-9, если считать с Win3.1), чтобы выкристализовалось API драйверов и подходы к их написанию, позволившие сторонним разработчикам начать клепать действительно совместимые между собой, устанавливаемые side-by-side драйверы сети, дисковых устройств, фильтры файловой системы, etc. И это при том, что архитектура OS была достаточно хорошо проработана уже во времена WinNT 4.0. Стоит ли тогда удивляться, что сейчас, спустя всего полтора года (с ноября 2016) после первого релиза AX7/D365O, с Extension'ами еще не всё так радужно, как пытается представить mfp?

Последний раз редактировалось gl00mie; 03.04.2018 в 11:43.
За это сообщение автора поблагодарили: Ivanhoe (2), belugin (5), ax_mct (7), MikeR (6), Vadik (1), S.Kuskov (5).
Старый 03.04.2018, 15:44   #35  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,152 / 832 (32) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
Прокрастинируя перед задачей которую неоценил раза в три, поинтересовался как у других.

Опять таки язык Apex. Хотелось бы чтобы MFP сравнивал с ним и другими, прежде чем заявлять что X++ самый самый. Особенно если речь о лидерах рынка за которыми идет гонка и которых в то же время как бы не существует.

https://developer.salesforce.com/pag...mming_Language

Apex Features and Functionality
In addition to the essential capabilities of running on demand in a multi-tenant environment, Apex Code brings a number of other features that greatly expand the power developers have in using the Force.com platform and in the range of applications they can build.

Apex Code and event model. Apex Code can be tied to the execution of the platform, enabling developers to exert fine-grain control over an application. When thinking about the Apex code, it’s useful to consider the analogy of stored procedures and triggers, since fundamentally the language is tied to behaviors on the data, as opposed to providing a higher level UI language or representation. Hence developers can tie Apex Code into almost every aspect of an application’s behavior: overriding the behavior in existing buttons, creating a new button, manipulating the control of a custom link, programming the control of an inline s-control, or even overriding the behaviors associated with a related list and data.

Consider an app that enables the user to create a new lead in Force.com by clicking the save button to commit that record to the database. With Apex code, developers can create and execute code residing on salesforce.com’s server to intercede just after the button is clicked. The code might check for any duplicate records, and if it finds any, implement a data quality scenario that notifies the user. Otherwise, the record commits to the database as is normally the case. (See Apex Code Example above.)

Transaction control. Because Apex Code is closely bound to Force.com data, developers can readily add transactional features to their applications. For example, if one user is referencing a field while somebody else is trying to delete it, the system is aware of the conflict. Apex Code also features data commits and rollbacks, which are especially important when working across multiple objects.

Packaging, re-use and Web services. Apex Code uses a packaging model similar to that of Java, in which reusable packages of code can be invoked from each other or from within triggers. Unlike Java, however, Apex is not object oriented in the sense that those packages can be modified through inheritance. Significantly, any method defined in a package can optionally be automatically exposed as a Web service, and thus can be invoked via the SOAP API or directly through the AJAX toolkit.

Performance, scalability and upgrades. Because Apex Code runs on demand, scalability, compatibility and maintenance issues are salesforce.com’s responsibility, not yours. Apex-developed applications can scale indefinitely to support additional users, without your having to deploy additional servers. Applications potentially run faster because a single query can obtain information from multiple objects.

When newer versions of Force.com and the Apex code itself are introduced, your code is never rendered obsolete. Force.com ensures backward compatibility by maintaining processor-specific versions of Apex virtual machines, which in turn correspond to the API. As a result, your code continues to operate without modification.

Apex Code and the AppExchange. Apex Code can be packaged along side custom objects, S-controls and other platform features, allowing developers to redistribute their Apex Code-enhanced apps via the same AppExchange directory available today.
Старый 03.04.2018, 16:18   #36  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,592 / 661 (26) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Прокрастинируя перед задачей которую неоценил раза в три, поинтересовался как у других.

Опять таки язык Apex. Хотелось бы чтобы MFP сравнивал с ним и другими, прежде чем заявлять что X++ самый самый. Особенно если речь о лидерах рынка за которыми идет гонка и которых в то же время как бы не существует.....
Вот вот, именно. Я так это понимаю, что в следующей версии AX7-D365 уже добавят таки Node.js или хотя бы Angular. Так как у Salesforce это уже есть.
Сидят такие индо менеджеры и меряются у кого платформа по круче будет.
Ну как это в D365 нет современных форков!
...
А на всех остальных на@рать. Привыкнут.
Главное, что бы либидо индо менеджера было удовлетворено.
__________________
Axapta book for developer
Старый 04.04.2018, 07:58   #37  
trud is offline
trud
Участник
Лучший по профессии 2017
 
631 / 712 (25) +++++++
Регистрация: 07.06.2003
Кстати по поводу обновлений - незаметно так вышла АХ8, обратите внимание на срок поддержки(на 1.5 года меньше чем АХ7.3)
вообще у них Whats new забавный получился
закрыли разработку, поддержка меньше, до кучи надо чтоб еще работало медленнее

https://docs.microsoft.com/en-us/dyn...tform-releases

Нажмите на изображение для увеличения
Название: AX8.jpg
Просмотров: 165
Размер:	43.9 Кб
ID:	11876
За это сообщение автора поблагодарили: Logger (1), ax_mct (3).
Старый 04.04.2018, 10:25   #39  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,334 / 296 (12) ++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Бешеный принтер какой-то(((((((( Ну разве можно менять версии ERP-системы раз в два-три года?????
__________________
С уважением,
Вячеслав
Старый 04.04.2018, 10:28   #40  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
3,975 / 2048 (76) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Stitch_MS, так все, теперь официально не нужно добавлять Ent edition. И аналог NAV получил свое отдельное название Business Central.
__________________
Ivanhoe as is..

Последний раз редактировалось Ivanhoe; 04.04.2018 в 11:24.
За это сообщение автора поблагодарили: Stitch_MS (1).
Теги
ax8, dyn365fo, extensions, mfp

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
mfp: Extensible X++ – Method signatures Blog bot DAX Blogs 0 31.08.2017 18:11
mfp: Extensible Inventory Dimensions Blog bot DAX Blogs 0 10.08.2017 14:11
german_nav_developer: Dynamics NAV 2013 R2 multi-tenancy – Viele Mieterinnen ohne Stress und Neid Blog bot Dynamics CRM: Blogs 0 30.12.2013 19:00
german_nav_developer: Codepage und Multilinguale Dynamics NAV Installationen Blog bot Dynamics CRM: Blogs 0 05.06.2011 15:51
mfp: X++ - A mananged language Blog bot DAX Blogs 1 20.01.2011 00:51
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 13:35.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.