Интеграция - использовать стандарт или писать на коленке ?

[trud]

Цитата:

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

А вот как стучаться в D365 из .NET сборки на том же сервере? ODATA если вставка записей или custom service JSON/SOAP если обращение к коду? То есть только через Active Directory и IIS?

Это вроде описано в документации. есть даже пример с открытым кодом
https://github.com/Microsoft/Recurri...ions-Scheduler

[ax_mct]

Цитата:

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

А вот как стучаться в D365 из .NET сборки на том же сервере? ODATA если вставка записей или custom service JSON/SOAP если обращение к коду? То есть только через Active Directory и IIS?

Цитата:

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

Это вроде описано в документации. есть даже пример с открытым кодом
https://github.com/Microsoft/Recurri...ions-Scheduler

Пример классный спасибо. Интересно и очень в тему. Там сервис который перемещает файлы c данными и умеет это делать в частности в Azure BLOB.

Но это не совсем "то". Хотя я уже все понял. Martin Dráb сказал что можно все что можно в .NET и я призадумался. И обнаружил что в современном .NET можно сделать гораздо меньше чем в мое время.

То есть .NET Remoting (https://en.wikipedia.org/wiki/.NET_Remoting) в D365FO не применим. Это конечно вопрос к .NET.
То есть .NET Business Connector уже не часть D365FO и варианты вызова кода это только веб-сервисы. Через AAD и IIS и никак иначе. И тут я всплакнул за Business Connector.

[belugin]

Цитата:

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

То есть .NET Business Connector уже не часть D365FO и варианты вызова кода это только веб-сервисы..

Если сборка уже загружена в процесс dyn365fo и вызвана оттуда, то из нее можно вызывать X++ классы https://docs.microsoft.com/en-us/dyn...business-logic

[ax_mct]

Цитата:

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

Если сборка уже загружена в процесс dyn365fo и вызвана оттуда, то из нее можно вызывать X++ классы https://docs.microsoft.com/en-us/dyn...business-logic

Классный пример в копилку. Спасибо.
В приведенном примере AXQueryProvider (LINQ) и подписка на AX событие из C#.
Вызова X++ класса в примере нет.

Кстати жалуются что данный пример не рабочий из-за binding errors.
"12 Sep 2018 Bug 246523 has been logged to track this issue." и до сих пор.
https://github.com/MicrosoftDocs/dyn...lic/issues/326

Но идея интересная сама по себе. Только мне кажется что это даже чинить не будут, закроют такую фичу как ненужную. Оставив замечательную статью о возможностях

И будет сакральное знание о том что так делать не стоит уделом экспертов которым платят за то что они знают чему верить, а чему нет. Я например из этого понял что AX из C# это плохой и проблемный дизайн в данном контексте. Так как то же самое можно сделать с C# из X++ и спокойнее спать.

Или таки есть опыт вызовов X++ классов из C#?

[ax_mct]

Цитата:

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

к сожалению .NET Remoting прибили для кросс-платформенности.
...
Martin Dráb сказал что можно все что можно в .NET и я призадумался. И обнаружил что в современном .NET можно сделать гораздо меньше чем в мое время.

Что интересно Java RMI так и осталось. Те же удаленные вызовы кода на уровне сокетов по внутреннему протоколу.
https://en.wikipedia.org/wiki/Java_r...hod_invocation
https://docs.oracle.com/javase/1.5.0...llo-world.html

При этом да, судя по всему Java RMI сейчас используют намного меньше чем раньше, все делают REST. Как бы общий тренд вообще.
P.S. По сути формально оставшись Java RMI тоже с рынка ушла.

Но добавляя (интеграционный) компонент на ту же машину (в виде DLL в случае .NET) и использовать
web-средства коммуникации, это странно.
Даже в on-premise это сборка (подписанная причем) должна быть зарегистрирована как приложение в Azure AD и ходить TCP через IIS (в AX).

[skuull]

С помощью BYOD можно экспортировать в SQL Server, проблема только в том чтобы наклепать дата энтитей, но они вам все равно нужны только на чтение и не для всех таблиц, так что давно можно было сделать. Экспортите себе инкрементео хоть каждую минуту, в чем проблема?

Data Lake можно пощупать уже сейчас, это как раз горячо любимые многими файлы в Azure Storage Account, но пока это только aggregated measurements которые мало кто и так использует.

[fed]

Цитата:

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

С помощью BYOD можно экспортировать в SQL Server, проблема только в том чтобы наклепать дата энтитей, но они вам все равно нужны только на чтение и не для всех таблиц, так что давно можно было сделать. Экспортите себе инкрементео хоть каждую минуту, в чем проблема?

Можно, но:

1. Почему бы просто не дать клиентам read-only доступ к основной БД ? Зачем умножать сущности сверх необходимости ? Также стоит вспомнить про классический "принцип биплана": Самолет с двумя парами крыльев ломается в два раза чаще чем с одной.
2. Entity для транзакционных сущностей надо еще разработать.
3. Инкрементальный экспорт работает не очень устойчиво.Если бы он устойчиво работал, вряд ли бы пришлось Микрософту писать толстый батч для перекачки из основной БД в Data Warehouse, который каждый раз с ноля данные перезаливает .
4. Клиенту надо платить за еще один Azure SQL инстанц, который реально нужен только для того чтобы перекачать данные в его собственную локальную БД. При этом - эта Azure SQL БД, это уже не второе крыло, а третье, поскольку по дороге из нее в локальную базу данных тоже что-то отсохнуть может.

Ну то есть - я могу согласиться что Power BI полезен для не очень больших клиентов (в пределах 40 рабочих мест на круг - не только для D365). Но если клиент большой, то у него наверняка стоят какие-то другие системы (типа MES или систем бюджетирование или еще чего-то подобного), наверняка есть какой-то тул для бизнес-аналитики, которому надо данные и из этих систем качать и из аксапты. Так вот - зачем заставлять клиента так мучаться,если достаточно было просто открыть R/O доступ к основной базе данных ?

[skuull]

Цитата:

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

[*]Клиенту надо платить за еще один Azure SQL инстанц, который реально нужен только для того чтобы перекачать данные в его собственную локальную БД. При этом - эта Azure SQL БД, это уже не второе крыло, а третье, поскольку по дороге из нее в локальную базу данных тоже что-то отсохнуть может.

Я писал об экспорте в SQL Sever, а не Azure SQL, т.е.напрямую, зачем вам прослойка?

Нет смысла спорить, что с доступом в базу было бы проще, но его нет. entity надо разработать, но за 2 года любой партнёр уже мог их наразрабатывать и продавать пачкой. Список будет примерно одинаковый.

Итак у вас есть entities и выгрузка в локальный SQL, что вам ещё не хватает ?

[fed]

Цитата:

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

Я писал об экспорте в SQL Sever, а не Azure SQL, т.е.напрямую, зачем вам прослойка?

Может быть он напрямую и работает (не пробовал), но поддерживается ли он ? Во вторых - не факт что клиент захочет свой основной Data Warehouse в интернет открывать, так что скорее всего придется отдельный сервер БД ставить (и лицензию покупать), через который все равно придется данные протягивать.
Я пожалуй добавлю, что я это все написал просто по мотивам вопросов пары клиентов. То есть - можно мне долго чего-то доказывать, но клиенты просто спрашивают - почему им надо платить дополнительные деньги, за что-то заведомо менее надежное чем был бы простой прямой доступ к БД? И я в общем не могу ничего другого ответить кроме как "Потому что это - Microsoft". Вопрос - хорошо ли это для самого Микрософта в долгосрочной перспективе?

[ax_mct]

Цитата:

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

Почему бы просто не дать клиентам read-only доступ к основной БД ?

Самое базовая причина полагаю это сдвинутость на защите информации клиента ото всех включая клиента как sales point (security compliance certifications, HIPAA etc )
https://docs.microsoft.com/en-us/azu...urity-overview

Думаю что варианты с тем же ODBC тоже можно реализовать с этим всем compliance но оно им зачем. То есть для них одни минусы.

[skuull]

Цитата:

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

Самое базовая причина полагаю это сдвинутость на защите информации клиента ото всех включая клиента как sales point (security compliance certifications, HIPAA etc ).

MS говорит, что это производительность, типа не надо отчёты гонять по продакшен базе, а потом говорить что все медленно.

[ax_mct]

Цитата:

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

MS говорит, что это производительность, типа не надо отчёты гонять по продакшен базе, а потом говорить что все медленно.

Очень может быть так как статистика использования портится. Да и тот же ODBC в целом к Azure SQL не запрещен и это только особенность D365FO. Скорее всего производительность настолько больное место у продукта что не хотят хоть как-то еще ухудшать.

[fed]

Цитата:

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

MS говорит, что это производительность, типа не надо отчёты гонять по продакшен базе, а потом говорить что все медленно.

Гм. Насколько я помню, у микрософта нету никаких SLA по производительности D365FO. То есть - даже если у клиента медленно, им сейчас в целом - все равно. Соответственно - не понятно почему их в таком случае производительность беспокоит...

[lvan]

сюда напшите, или в яммер https://experience.dynamics.com/idea...d%20Operations

[Maxim Gorbunov]

Цитата:

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

А какой бюджет и по какой ставке?

Оцените в часах. Бюджет заранее неизвестен. Предположим, что вы отвечаете на RFQ.