30.01.2017, 21:05 | #21 |
Модератор
|
Да, WHS + WMDP. Клиента кстати уже выпустили в виде Windows mobile и Android приложений, но мы пока используем в браузере на сканерах
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: Ivanhoe (5). |
30.01.2017, 21:37 | #22 |
Модератор
|
Цитата:
Цитата:
Понятно что ручей не пересох, но очень интересует стоит ли становится в очередь за водой? При условии что рядом теплое море с PHP
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: Ace of Database (3). |
30.01.2017, 21:47 | #23 |
Banned
|
Цитата:
Сообщение от Vadik
Да, WHS + WMDP. Клиента кстати уже выпустили в виде Windows mobile и Android приложений, но мы пока используем в браузере на сканерах
Warehouse Mobile Devices Portal (WMDP) is a web application hosted in IIS. It uses ASP.NET MVC runtime. For the current version of Microsoft Dynamics 365 for Operations, WMDP is provided as a standalone component, meant for self-deployment on-premises. То есть WMDP хостится на локальном IIS и далее коннектится через web-services к приложению находящемуся в Azure? Как производительность? |
|
30.01.2017, 22:05 | #24 |
Banned
|
|
|
31.01.2017, 09:24 | #25 |
Участник
|
|
|
31.01.2017, 10:32 | #26 |
Участник
|
Есть, к примеру, Technical Concepts Guide по 7-ке, там много интересного описано.
|
|
|
За это сообщение автора поблагодарили: mazzy (2), Logger (5), Ace of Database (3), Ivanhoe (5), alex55 (1). |
31.01.2017, 17:24 | #27 |
Участник
|
Спасибо, коллеги, за позитивную информацию! успокоили. Будем работать и надеяться на лучшее!
|
|
31.01.2017, 23:15 | #28 |
Модератор
|
У нас не совсем стандартный сетап, мы WMDP портал не используем а запускаем через эмулятор (форма такая которая для отладки используется). Не так эстетично (CSS не поменять например), но дешево, надежно и практично. Производительность ? Ну, это же погрузчики и палеты с морожеными курями, а не контра или танчики. Производительность устраивает. Поотзывчивее чем Dynamics Anywhere (мир его праху), если кто сталкивался
__________________
-ТСЯ или -ТЬСЯ ? |
|
01.02.2017, 09:35 | #29 |
Участник
|
|
|
01.02.2017, 10:39 | #30 |
Участник
|
Цитата:
Сообщение от Vadik
Да, WHS + WMDP. Клиента кстати уже выпустили в виде Windows mobile и Android приложений, но мы пока используем в браузере на сканерах
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: gl00mie (1). |
07.02.2017, 16:45 | #31 |
Banned
|
Есть однако интересные проекты на 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 устроен? |
|
08.02.2017, 01:32 | #32 |
Участник
|
Цитата:
Сообщение от ax_mct
Annata Dynamics DMS
http://annata.co.uk/solutions/dms/ |
|
08.02.2017, 09:48 | #33 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: mazzy (2), Vadik (1), trud (1), ax_mct (7). |
08.02.2017, 14:04 | #34 |
Banned
|
Эмо-программирование? Главный вопрос - у них получилось сделать без overlayering "SYS" кода? Просто интересна судьба таких решений если overlayering системного кода сойдет полностью на нет как планируется MS.
|
|
10.02.2017, 11:00 | #35 |
Участник
|
Не получилось. Совсем. 90% кода ушло в оверлей App Suite. Очень грустно.
|
|
|
За это сообщение автора поблагодарили: fed (3). |
10.02.2017, 11:41 | #36 |
Участник
|
|
|
10.02.2017, 12:28 | #37 |
Moderator
|
Предположу, что очень скоро, чуваки которые придумали extensions и model lock с удивлением узнают что попытка залочить прикладные модели выносит с рынка 90% вертикальных решений и 99% внедрений.
Ну то есть - это они в правильную сторону двигаются, только им надо было СНАЧАЛА очень капитально подумать на тему какого фундаментального функционала не хватает в прикладном ядре (ну например - absorption costing, или какого-то расширяемого API для распределения себестоимости сопродуктов), потом этот функционал написать, потом поставить там в правильных местах возможность расширений и только потом уже двигать в народные массы свою extension story. Но похоже что команда, которая за ядро и среду разработки отвечает - она совсем не в курсе состояния дел в прикладном функционале и вообще практик внедрения... |
|
10.02.2017, 12:59 | #38 |
Участник
|
Цитата:
extensions = plugins. подход отлично работает в огромном числе продуктов. этот форум работает с плагинами, far, notepad++, vim, visual studio и т.п... проблема не в плагинах. проблема в переходе на плагины для унаследованного кода Аксапты, который подразумевал возможность модификации в любой момент и не подразумевал специальных точек расширения. Последний раз редактировалось mazzy; 10.02.2017 в 13:07. |
|
|
За это сообщение автора поблагодарили: trud (1), ax_mct (5). |
10.02.2017, 13:22 | #39 |
Участник
|
Цитата:
Цитата:
Сообщение от mazzy
Цитата:
Сообщение от fed
они в правильную сторону двигаются, только им надо было СНАЧАЛА очень капитально подумать на тему какого фундаментального функционала не хватает в прикладном ядре, потом этот функционал написать, потом поставить там в правильных местах возможность расширений и только потом уже двигать в народные массы свою extension story.
Если ставить телегу впереди лошади и закручивать гайки прежде, чем предусмотреть специальные точки расширения прикладной логики, то - да, конечно |
|
10.02.2017, 13:23 | #40 |
Moderator
|
Цитата:
Сообщение от mazzy
нет, конечно.
extensions = plugins. подход отлично работает в огромном числе продуктов. этот форум работает с плагинами, far, notepad++, vim, visual studio и т.п... проблема не в плагинах. проблема в переходе на плагины для унаследованного кода Аксапты, который подразумевал возможность модификации в любой момент и не подразумевал специальных точек расширения. Тем не менее - если мы говорим о рынке отраслевых вертикальных решений (независимо от того - это действительно отчуждаемые вертикальные решения или просто коллекции наработок) - большая часть из них была построена на идее перекрытия стандартной функциональности. Причем как ты очень хорошо понимаешь, делалось это не по злой воле внедренцев, а просто в связи с отсутствием в стандарте кучи функциональности, типичной для данной отрасли. Теперь рассмотрим дальнейшие действия микрософт: 1. Они могут закрыть overlayering как класс (возможно - от балды навставлял точек расширения в стандартные прикладные классы). В этом случае, на первых же проектах, по итогам анализа партнеры начнут сообщать клиентам о том что в новой версии их бизнес-процессы не представляется возможным покрыть; Возможность серьезной доработки отрублена, а стандартной фунции для данного процесса - нету. После этого клиент с большой вероятностью бодро откажется от подписки на D365, спишет затраты на анализ в убытки и пойдет внедрять САП. Действительно - преимущество облачных технологий - можно в любой момент остановить проект, списав в убытки только небольшие понесенные затраты. Ну и партнеры само собой будут тоже плавно мигрировать в САП. Ведь если разработка по факту запрещена, то лучше использовать систему с более богатым базовым функционалом. 2. Они могут оставить overlayering. Но только в этом случае - у обычных партнеров (не тех кто плагины пишет), сразу возникнет вопрос: А зачем нам вообще париться с extensions ? Все равно большая часть нашего функционала в них не укладывается, и все равно после апгрейда приходится мерджится. А после этого встанет другой вопрос - а если все равно приходится мерджится, то зачем они платформенные модели заблокировали ? Зачем табу на overlayering объявляли ? Последний раз редактировалось fed; 10.02.2017 в 13:36. |
|
|
За это сообщение автора поблагодарили: Dreadlock (1). |
Теги |
#многоходовочка, ax7, axanywhere, d365, toincrease, whs, wmdp |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|