01.04.2018, 12:50 | #21 |
Участник
|
Цитата:
Раскройте, пожалуйста, эту аналогию. Внутри могзга нет интерфейсов? ERP система работает как нейросеть? Мне вот кажется, что как раз персонал выполняет функцию ERP системы там, где их нет. Есть ли интерфейсы между отделами? Можно как-то перейти от неясных аналогий к логическим построениям? |
|
02.04.2018, 11:42 | #22 |
Участник
|
Не могу сказать, что внутри мозга есть интерфейсы. Внутри мозга есть множество взаимосвязанных отделов. К примеру, вот так связаны 215 областей мозга мыши:
Если взять все объекты (или группы объектов с одинаковым префиксом) из АОТ и так же расположить по кругу, а потом нарисовать связи в соответствии с перекрестными ссылками, то должна получиться сходная картина. Кроме того, принято условно делить мозг на 3 отдела, рептильный, лимбический и неокортекс. Рептильный мозг, самый древний и глубокий, отвечает за базовые инстинкты, лимбический (мозг птиц и низших млекопетающих) отвечает за эмоции. Неокортекс позволяет нам вести вот эту дискуссию. Насколько я знаю. для запуска AOS достаточно модели Application Platform. Очень напоминает рептильный мозг, работающий даже когда хозяин в коме. Application Foundation -- это как лимбический мозг. И, наконец, все остальные модели -- это неокортекс. Всё условно, конечно. Персонал действительно выполняет функцию ERP системы, но не там, где ее нет (она везде есть, пусть даже в виде скоросшивателя, никто не держит все проводки в голове), а где ее функциональности не хватает. Если полностью заменить персонал и оборудование, включая директора и калькулятор, но оставить скоросшиватель, новый персонал вполне сможет продолжить с работу в этой системе. Что касается интерфейсов между отделами. Я бы сказал, это довольно условно. Однажды попросили меня дать права доступа к оплате кредитной картой простому складскому рабочему. Я, конечно, поинтересовался у консультанта, не попутал ли он чего, ведь рабочий на складе обычно переставляет ящики. На что мне ответили, что в их бизнес-сценарии рабочий на складе должен брать в руки ящик только после того, как поступит оплата кредитной картой. |
|
|
За это сообщение автора поблагодарили: belugin (5). |
02.04.2018, 13:17 | #23 |
Участник
|
Цитата:
Цитата:
Персонал действительно выполняет функцию ERP системы, но не там, где ее нет (она везде есть, пусть даже в виде скоросшивателя, никто не держит все проводки в голове), а где ее функциональности не хватает. Если полностью заменить персонал и оборудование, включая директора и калькулятор, но оставить скоросшиватель, новый персонал вполне сможет продолжить с работу в этой системе.
Цитата:
Что касается интерфейсов между отделами. Я бы сказал, это довольно условно. Однажды попросили меня дать права доступа к оплате кредитной картой простому складскому рабочему. Я, конечно, поинтересовался у консультанта, не попутал ли он чего, ведь рабочий на складе обычно переставляет ящики. На что мне ответили, что в их бизнес-сценарии рабочий на складе должен брать в руки ящик только после того, как поступит оплата кредитной картой.
Вообще у меня в голове вертится абстрактная идея разделить сущности - типа проводки - и бизнес-процессы. Сущности давать только расширять и создавать новые, бизнес-процессы можно менять (условно, разрешить оверлееринг на некотром подмножестве моделей, которые описывают бизнес правила) но это потребовал бы адского рефакторинга. |
|
02.04.2018, 14:27 | #24 |
Banned
|
Для меня это все звучит издевательством над здравым смыслом.
Измененять код через расширение это все равно его менять. Только опосредованно. Риск же коллизий в непрямом способе только увеличивается. Единственный же вариант избегать столкновений и наложений это не программировать и не менять определенный функционал. В случае же фунционального сбоку уже все равно overlayering или extensions. А в случае наложения фунционала - extensions это минное поле. Запрет обязан быть не на техническом поле, а на фунциональном. Например, что нельзя изменять бизнес-процессы, можно только их расширять своими собственными процессами. А вот это вот "самый ширяемый язык, колбась не хочу" вызывает у меня фрустрацию. Это вообще для каких адресатов? |
|
02.04.2018, 14:58 | #25 |
Banned
|
Цитата:
Сообщение от belugin
Вообще у меня в голове вертится абстрактная идея разделить сущности - типа проводки - и бизнес-процессы. Сущности давать только расширять и создавать новые, бизнес-процессы можно менять (условно, разрешить оверлееринг на некотром подмножестве моделей, которые описывают бизнес правила) но это потребовал бы адского рефакторинга.
|
|
02.04.2018, 15:16 | #26 |
Участник
|
Вся эта штука с экстеншенами - фактически, как я понял, для облегчения обновления. Например, как сейчас можно получить новую платформу без апгрейда кода - потому что есть инетрфейсы и она обратно совместима - кастомеры смогут получить. Новую функциональность не вкладывая большие ресурсы в апгрейд кода. Примерно как сейчас апгрейд винды.
|
|
02.04.2018, 17:21 | #27 |
Banned
|
Цитата:
Сообщение от belugin
Вся эта штука с экстеншенами - фактически, как я понял, для облегчения обновления. Например, как сейчас можно получить новую платформу без апгрейда кода - потому что есть инетрфейсы и она обратно совместима - кастомеры смогут получить. Новую функциональность не вкладывая большие ресурсы в апгрейд кода. Примерно как сейчас апгрейд винды.
Те же Netsuite, SalesForce предоставляют API к транформаторной будке и это намного честнее. В чем крутизна хитро-изогнутых инструментов X++ если нельзя ими лазить - непонятно. Поэтому лучше бы MFP посыпал голову пеплом. Мальчишки-живодеры. Я кстати написал там у него вежливый но саркастичный комментарий два дня назад, но полагаю что его не пропустят. Например я задал вопрос как много сейчас программистов X++ v.7-8 во всем мире вне стен Microsoft. И пожалел что пока еще нет лямбд и шаблонов на уровне языка. |
|
02.04.2018, 17:27 | #28 |
Участник
|
Цитата:
Цитата:
Те же Netsuite, SalesForce предоставляют API к транформаторной будке и это намного честнее.
Цитата:
В чем крутизна хитро-изогнутых инструментов X++ если нельзя ими лазить - непонятно.
Нет ли мест, где изменения особо никому не нужны? Типа менять поведение бухгалтерской проводки как сущности нельзя, но менять процессы порождающие проводки можно? |
|
02.04.2018, 19:26 | #29 |
Banned
|
Цитата:
Сообщение от belugin
Зависит от того, что значит "изменять функциональность". В разрешенных местах можно вроде. Драйвера поддерживаются в рамках одного поколения API.
.. Это что значит? .. Как это нельзя? Можно но не всюду. Невозможно сделать обратно совместимое API, где можно вообще все. Нет ли мест, где изменения особо никому не нужны? Типа менять поведение бухгалтерской проводки как сущности нельзя, но менять процессы порождающие проводки можно? Самый расширяемый язык X++ (читай D365FO) не имеет таких интерфейсов, а предлагает сверлить и подвешиваться где только сможешь. При этом нигде не говорится о концепции и границах дозволенного. Все рассматривается только со стороны технических возможности. Опытные программисты AX по инерции используют те же границы дозволенного к которым они привыкли. Клиенты по инерции рассматривают как ту же платформу разработки которая переехала в web. И данная инерция движения и мысли провоцируется и поощряется вот такими вот статьями. Новые программисты, скорее всего c .NET, вообще не имеют опыта чтобы понимать что можно, а что нельзя. И понимание у них скорее всего такое что можно все если дают такие широкие возможности. Но это же не так. Дымовая завеса с этим X++. Нельзя программировать так как было как раньше. Не с технической стороны, а с точки зрения функционала. И кто об этом и где говорит? Цитата:
менять процессы порождающие проводки можно
|
|
02.04.2018, 19:58 | #30 |
Участник
|
Вы таки будете смеяться, но мне вся эта история с запретом оверлеинга и введением хардлока напоминает историю с лоботомией как методом лечения. Вы почитайте про нее в Википедии, очень интересно. Сто лет назад один товарищ выяснил, что пересечение волокон в лобных долях делает из буйного пациента (читай, любителя всё оверлеить) спокойного и послушного (согласного подогнать бизнес процессы под стандарт). Были написаны многие статьи и проведены десятки тысяч операций. Были и критики, но их до поры до времени никто из приверженцев нового метода не слушал. Они даже обосновали экономическую целесообразность такого лечения:
Цитата:
... В начале 1940-х годов лоботомия уже широко применялась в США. Во время Второй мировой войны психиатрические отделения госпиталей Управления по делам ветеранов были заполнены множеством солдат, возвращавшихся с фронта и испытавших тяжёлое душевное потрясение. Эти пациенты часто оказывались в состоянии возбуждения, и чтобы осуществлять контроль над ними, требовалось множество медсестёр и другого вспомогательного медперсонала, что приводило к необходимости больших расходов. Таким образом, одной из главных причин широкого распространения лоботомии стало стремление снизить расходы на содержание обслуживающего персонала...
|
|
|
За это сообщение автора поблагодарили: fed (3), Logger (5), NetBus (3). |
02.04.2018, 21:19 | #31 |
Участник
|
Цитата:
Сообщение от ax_mct
API означает более или менее неизменный интерфейс и определяет границы дозволенного.
Самый расширяемый язык X++ (читай D365FO) не имеет таких интерфейсов, а предлагает сверлить и подвешиваться где только сможешь. При этом нигде не говорится о концепции и границах дозволенного. Все рассматривается только со стороны технических возможности. Цитата:
Уверены? По идее все от зависит от нюансов. Что-то можно, а что-то нельзя, но кто это будет оценивать и на какой стадии?
|
|
02.04.2018, 22:48 | #32 |
Banned
|
Цитата:
Сообщение от belugin
Я думаю на эту тему в терминах design-by-contract, ковариантности, контравариантности и обратной совместимости.
... Я имею ввиду гипотетичекскую альтернативную реальность в которой разделяем приложение разделено на две части - в одном модули которые можно легко обновить на новую версию с продуманным интерфейсом расширения, а в другой - "скрипты", которые можно править, но при этом новая версия не является обратно совместимой. То есть возможен ли некий компромисс. Условно говоря, как в линуксе - можно написать приложение, используя API, а можно поменять исходный код ОС. Или как в игровых движках (тут я не специалист но вроде там так) ядро .из основных понятий и скрипты (насколько я знаю, там даже другие языки для них используют чем для ядра - типа lua). Все уже придумано. Легион продуктов и фрэймоворков. Наиболее популярный подход с использованием предопределенной файловой структруры. Когда мы просто создаем директории и файлы которые подхватываются системой. При этом базовый код не редактируется. Это уже даже некий стандарт. В облачных ERP типа SalesForce и NetSuite это API. Так как падение wordpress, Yii и прочих web сайтов это не то же самое как падение ERP. (Хотя для онлайн-магазин это тоже больно, но грабли уже всем известные и потому комфортные). Цитата:
Пишите код на языке программирования Apex для добавления бизнес-логики или на языке разметки Visualforce (для
создания пользовательского интерфейса). Интегрируйте свое приложение с помощью API-интерфейсов и проводите проверку подлинности своих внешних приложений. Теорeтечески ISV решения для D365FO имеют потенциал. Но они опять таки разумны если делать боковой или паралельный фунционал, не меняя сами существующие процессы. Но с таким сбоку не важно чем, слоями, расширениями или API, снижение рисков за счет функциональной отвязанности. У меня есть несколько своих вертикальных решений которые я бы в других условиях сделал бы для AppStore D365FO. Но я даже не в состоянии оценить ровно ничего. А на оценке строится бизнес. Поэтому и раздражаюсь на подобные статьи по сути заманивающие в охотничью яму. В яме тоже конечно можно найти косточку погрызть |
|
03.04.2018, 09:50 | #33 |
Moderator
|
Я просто замечу, что микрософт вложился в 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 |
Участник
|
Цитата:
Драйверы в виндах были, думаю, изначально, однако, я не видел живьем версии до 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 |
Banned
|
Прокрастинируя перед задачей которую неоценил раза в три, поинтересовался как у других.
Опять таки язык 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 |
MCT
|
Цитата:
Сообщение от ax_mct
Прокрастинируя перед задачей которую неоценил раза в три, поинтересовался как у других.
Опять таки язык Apex. Хотелось бы чтобы MFP сравнивал с ним и другими, прежде чем заявлять что X++ самый самый. Особенно если речь о лидерах рынка за которыми идет гонка и которых в то же время как бы не существует..... Сидят такие индо менеджеры и меряются у кого платформа по круче будет. Ну как это в D365 нет современных форков! ... А на всех остальных на@рать. Привыкнут. Главное, что бы либидо индо менеджера было удовлетворено.
__________________
Axapta book for developer |
|
04.04.2018, 07:58 | #37 |
Участник
|
Кстати по поводу обновлений - незаметно так вышла АХ8, обратите внимание на срок поддержки(на 1.5 года меньше чем АХ7.3)
вообще у них Whats new забавный получился закрыли разработку, поддержка меньше, до кучи надо чтоб еще работало медленнее https://docs.microsoft.com/en-us/dyn...tform-releases |
|
|
За это сообщение автора поблагодарили: Logger (1), ax_mct (3). |
04.04.2018, 09:59 | #38 |
Участник
|
|
|
04.04.2018, 10:25 | #39 |
северный Будда
|
Бешеный принтер какой-то(((((((( Ну разве можно менять версии ERP-системы раз в два-три года?????
__________________
С уважением, Вячеслав |
|
04.04.2018, 10:28 | #40 |
Участник
|
Stitch_MS, так все, теперь официально не нужно добавлять Ent edition. И аналог NAV получил свое отдельное название Business Central.
__________________
Ivanhoe as is.. Последний раз редактировалось Ivanhoe; 04.04.2018 в 11:24. |
|
|
За это сообщение автора поблагодарили: Stitch_MS (1). |
Теги |
ax8, dyn365fo, extensions, mfp |
|
|