10.04.2018, 21:16 | #61 |
Banned
|
Кстати о древнем SAP и к вопросу о туториале сравнить трудоемкость в D365FO и где-то еще.
Полазил по CDX и посмотрел что они там делают и предлагают. Так вот SAP в Cloud он не хуже AX7 с точки зрения front-end расширений. Вот практически туториал, сомневаюсь что трудозатраты выше чем в D365FO. https://experience.sap.com/fiori-design-web/grid-table/ https://experience.sap.com/fiori-design-web/sap-fiori/ https://www.sap.com/uk/developer/top...velopment.html https://www.sap.com/uk/products/fior...t-capabilities SAP Fiori, SAP Web IDE. Насчет расширяемости back-end не знаю. Не вижу смысла рыть так как у меня нет сомнений в том что X++ самый расширяемый язык в мире. Но мне почему то кажется что стоимость back-end изменений не сильно отличается для обоих web вариантов ERP. |
|
|
За это сообщение автора поблагодарили: trud (5). |
10.04.2018, 21:26 | #62 |
Участник
|
Я, честно, не понял, о каком сценарии идет речь. Что значит раширяемость фронтенда без бекенда и как это происодит в SAP. Вы можете пример привести? User story? Конерктная задача и как она решается в вашем любимом интрументе одним фронтендом?
|
|
10.04.2018, 23:12 | #63 |
Banned
|
Цитата:
В качестве примера. Есть у нас ввод заказа. Есть операторы telesales. По сути для них D365FO не ERP, а рабочее место telesales. У них требования одно-оконное приложение, максимальная скорость ввода заказа в целом, подтягивание всевозможной информации по клиенту и его предыдущим заказам. И все это в том UI к которому они привыкли в другом приложении. Весь back-end должен быть в кнопке "Submit" и может быть 1-2 быстрых запросов сервера перед этим. Цитата:
Сообщение от belugin
Скажите мне, как веб-эксперт: если взять и плюхнуть грид на аксаптовскую форму и соединить с датасурсом. Запустить. Сколько времени надо чтобы в вашем любимом веб фреморке получить ту же самую фнукциональность включая:
Хотелось бы ссылку на туториал. |
|
10.04.2018, 23:58 | #64 |
Участник
|
Цитата:
Первое что я нашел содержит кучу сведений по специфическому саповскому бекэнду. https://www.tutorialspoint.com/sap_fiori Prerequisites to Learn SAP Fiori The following are the requirements for learning SAP Fiori − ABAP program and objects HTML5 JavaScript SAP UI5 ERP Implementation experience OData and SAP NetWeaver Gateway SAP HANA Я так понял, что это некая пришлепка сбоку к сапу. А грид это пришлепка сбоку к той пришлепке сбоку. Судя по коду, который я нашел, простая форма делается сложнее чем в AX Цитата:
В качестве примера. Есть у нас ввод заказа. Есть операторы telesales. По сути для них D365FO не ERP, а рабочее место telesales. У них требования одно-оконное приложение, максимальная скорость ввода заказа в целом, подтягивание всевозможной информации по клиенту и его предыдущим заказам. И все это в том UI к которому они привыкли в другом приложении. Весь back-end должен быть в кнопке "Submit" и может быть 1-2 быстрых запросов сервера перед этим.
Вебсервисы присутствуют в AX7 - если вам не нужен стандартный интерфейс в AX, что мешает просто написать сбоку на любом фреймворке фронтэнд, дергающй сервис? Если нужен стандартный, можно, наверное, всю нестандартную форму целиком запихать в один контрол и использовать его. |
|
11.04.2018, 01:39 | #65 |
Banned
|
Цитата:
Сообщение от belugin
Не с каким-либо другим фреймфорком, а с веб вей. И получился не туториал. Под тториалом я понимаю степ бай степ
Первое что я нашел содержит кучу сведений по специфическому саповскому бекэнду. https://www.tutorialspoint.com/sap_fiori Я так понял, что это некая пришлепка сбоку к сапу. А грид это пришлепка сбоку к той пришлепке сбоку. Судя по коду, который я нашел[/URL], простая форма делается сложнее чем в AX https://wiki.scn.sap.com/wiki/displa...E+-+Quickstart https://www.youtube.com/watch?v=STUrK2185s8 В нем все выглядит проще чем в Java EE. Если по конкретному вопросу то я согласен что в D365FO данная задача добавления грида с плюшками будет быстрее для программиста. Но вряд ли дешевле для клиента. Пришлепка эта по ходу как EP для AX2012 что было бы идеальным вариантом и для AX вместо превращения в один EP. Но судя по тому как CDX за 8 месяцев перевел SAP в Cloud, там как то все более вариативно и один web интерфейс возможен. Цитата:
Сообщение от belugin
А что именно требуется от расширяемости фронтенда а не от написания фронтенда с нуля к существующему бекэнду?
Вебсервисы присутствуют в AX7 - если вам не нужен стандартный интерфейс в AX, что мешает просто написать сбоку на любом фреймворке фронтэнд, дергающй сервис? Если нужен стандартный, можно, наверное, всю нестандартную форму целиком запихать в один контрол и использовать его. А типичному AX/D365FO программисту не нужна расширяемость front-end. Ему расширяемости X++ для полноты жизни и так хватить. Согласен что от добавления front-end расширяемости в текущий "web" фрэймворк D365FO ни жарко ни холодно. Она этому фрэймворку не нужна. Но в то же время думаю что использование какого-то общего и более стандартного web-framework было бы более разумно, с разделением front-end и back-end программирования. Если бы с самого начала развития AX7 типичный MS CRM программист мог делать front-end, а типичный AX программист back-end программирование то это было бы более дальновидно. P.S. Но тогда не было бы смысла обьявлять новую версию (AX7) целиком web, а имел бы смысл просто расширять EP. На что они конечно же пойти не могли. Практически все альтернативные решения используют отдельные MVC web-фрэймворки для которых проще найти специалистов. Последний раз редактировалось ax_mct; 11.04.2018 в 01:47. Причина: P.S. |
|
11.04.2018, 03:48 | #66 |
Участник
|
Цитата:
т.е. те кто хотят по старинке сложным языком кодят в X++ а новый подход успешных людей - это мышкой создавать Power apps, из AX брать только данные https://dynamics.microsoft.com/en-us...#release-notes Последний раз редактировалось trud; 11.04.2018 в 04:25. |
|
|
За это сообщение автора поблагодарили: ax_mct (5). |
12.04.2018, 09:37 | #67 |
Участник
|
Цитата:
Причем даже отладчик есть в веб-версии. Цитата:
Пришлепка эта по ходу как EP для AX2012 что было бы идеальным вариантом и для AX вместо превращения в один EP. Но судя по тому как CDX за 8 месяцев перевел SAP в Cloud, там как то все более вариативно и один web интерфейс возможен.
Цитата:
Тут вопрос кому. Пришедший со стороны web-программист посмотрит на все это дело и сделает все сбоку на каком либо варианте ASP.NET. Просто потому что иначе карму себе испортит.
Цитата:
А типичному AX/D365FO программисту не нужна расширяемость front-end. Ему расширяемости X++ для полноты жизни и так хватить.
Цитата:
Согласен что от добавления front-end расширяемости в текущий "web" фрэймворк D365FO ни жарко ни холодно. Она этому фрэймворку не нужна.
Цитата:
Но в то же время думаю что использование какого-то общего и более стандартного web-framework было бы более разумно, с разделением front-end и back-end программирования. Если бы с самого начала развития AX7 типичный MS CRM программист мог делать front-end, а типичный AX программист back-end программирование то это было бы более дальновидно.
Фронтендовской логики в типичном случае не очень много. Для того сценария, что вы приводили, можно написать фронтэнд сбоку. Если бы с самого начала был стандартный веб фреймворк, мы бы заставили X++ кодеров заниматься дизайном или нанимать дополнительных фронтэндщиков а для типичной задачи это оверкилл. |
|
12.04.2018, 18:32 | #68 |
Banned
|
Цитата:
Сообщение от belugin
...
Клауд != веб интерфейс. Отдельный дополнительный web-native интерфейс нужен для ограниченного количества сценариев. ... Он не сможет это сделать. Для большинства разработок нужно что-то менять в бекенде. Как и в SAP, я думаю. ... Фронтендовской логики в типичном случае не очень много. ... Для того сценария, что вы приводили, можно написать фронтэнд сбоку. ... Если бы с самого начала был стандартный веб фреймворк, мы бы заставили X++ кодеров заниматься дизайном или нанимать дополнительных фронтэндщиков а для типичной задачи это оверкилл. Просто странно что D365FO пошел по пути нестандартного веб фреймворк в то время как все аналогичные системы конкурентов постарались сделать их максимально стандартными для web программистов и отделили front-end от back-end. Странно что MFP упоминает в этой статье X++ в отрыве от front-end. Такое впечатление что все еще где-то там, в AX. Полность игнорируя тот факт что D365FO это web. Цитата:
Клауд != веб интерфейс. Отдельный дополнительный web-native интерфейс нужен для ограниченного количества сценариев.
Но у Sharepoint в корпоративной сети Windows не было конкурентов которые привлекают именно web-native. Насколько значимо наличие этого web-native или нет, я не знаю. Но то что на круто расширяемый X++ 8.0 никто не делает стойку кроме самих программистов X++ - уверен. Новым программистам он не интересен, а старые все бегут куда могут. P.S. Что кстати непонятно хорошо или плохо, вдруг за такими спецами скоро будут частные самолеты высылать или рабочие визы делать влет, все может быть. Последний раз редактировалось ax_mct; 12.04.2018 в 18:36. Причина: P.S. |
|
|
За это сообщение автора поблагодарили: Link (3). |
Теги |
ax8, dyn365fo, extensions, mfp |
|
|