Легальность и судьба наших интеграций как непрямого доступа.

[ax_mct]

Имеем судебное решение SAP UK v Diageo Great Britain поднятое в теме
"SAP засудил клиента на £60,000,000. Неплохо бы разобраться."
SAP засудил клиента на £60,000,000. Неплохо бы разобраться.
в которой выясняем что клиента SAP засудили за обмен сообщениями с SAP во время работы третьего приложения.

Имеем тему
"Кстати, BASIC LICENSING REQUIREMENTS: All Microsoft Dynamics AX 2012 R3 customers need to license..."
Кстати, BASIC LICENSING REQUIREMENTS: All Microsoft Dynamics AX 2012 R3 customers need to license...
в которой выясняем что разницы в лицензионном подходе SAP и Microsoft - нет.

Имеем все основания полагать что Microsoft рано или поздно последует примеру SAP так или иначе.

Встает вопрос изменения рынка и подходов к интеграции вообще и дизайна конкретной интеграций в частности. То есть "что можно", и "что нельзя", и "как".

Полагаю что вопрос актуальный для ISV, партнеров, клиентов и даже для программистов которые хотят долгой жизни клиентам и нашему рынку.

[ax_mct]

Цитата:

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

Вопрос в трактовке непрямого доступа. Допустим обмен между AX и внешней WMS сделан не через web-сервисы, а через EDI (файловый обмен). И что в этом случае считать, что кладовщик завершивший сборку в WMS должен иметь и лицензию для AX? Выглядит совсем не логично.

Цитата:

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

...
В том решении суда было замечание о том что момент обращения (timing) не имеет значения в случае асинхронного обмена, а важен сам факт использования SAP. Но основной кейс там на обмене сообщениями во время сессии пользователя.

Притянуть сложнее но можно. Как минимум если данная операция в бизнес-смысле не самодостаточна в WMS и требует для ее завершения обращение к AX. Если данные берутся (время от времени) из AX как из центральной базы бизнеса.

Про синхронность/асинхронность лицензионное соглашение ничего не говорит. А абсурдности в случае внешних покупателей больше чем с внутренним кладовщиком.
....
В принципе, есть только один вариант- для каждой интеграции иметь письменный ответ вендора. А иначе практически все интеграции - тикающая бомба, причем чем позднее рванет - тем больнее.
Обращение в AX за проверкой наличия товара в интернет-магазине, создание складского перемещения в AX по результатам сборки во внешней WMS и до-свидания бизнес.

Цитата:

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

Это также ненадежный вариант. Тогда уж надо делать протокол разногласий к договору или подписывать доп. соглашение, где давать точную формулировку непрямого доступа.
Кроме того, и с термином "интеграция" не всё прозрачно. Если считать EDI обмен с внешними поставщиками и клиентами - интеграцией, то получается, что сотрудники контрагентов также получают непрямой доступ к нашей системе, и для них можно требовать лицензию...

Как программист в настоящем и юрист в прошлом, проживающий в англоязычной стране, на среднем уровне погружения в термины и логику, лично я понимаю это так:

Case 1: Типичный EDI обмен с внешними поставщиками и клиентами - это OK.

Case 2: Кладовщик во внешней WMS которая по факту внешний модуль AX - это $$$$. Даже если асинхронная связь через IDE.

Case 3: Сторонний E-commerce когда во время сессии пользователя идет обращение к AX - это $$$$.

Case 4: Самодостаточное и способное работать без связи с AX но для работы которой нужны данные введенные через AX - ???? Надо подумать. Но риск уже есть.

[ax_mct]

Замечу что бояться нам рано, вопрос больше академический. Но обязательный к изучению.

Как я понимаю такого аудита как в SAP у Microsoft - нет. Но скажем пошла такая тема внутри Microsoft и скажем сотрудники Microsoft участвуют в проекте внедрения новой версии на клиенте где интеграций много и разных. И может быть больно всем и клиенту, и партнеру, и подрядчикам.

Практические точки тоже есть. Раньше я рассматривал создание интеграционных адаптеров как направление бизнеса, теперь это уже не выглядит разумным.

Или скажем я делал интеграцию через AIF c самописным .NET приложением чтобы часть сотрудников работала через него. Крупный серьезный клиент. Таких проектов уже скорее всего не будет именно потому что все по идее должны проснуться и начать вникать в этот indirect access. То есть на существование проектов интеграции это не может не влиять.

Но все же существенная часть из нас выполняет роль архитекторов и консультантов по интеграции. Крайне непрофессионально не понимать лицензирование в интеграции и как дизайн с этим связан. Поэтому для меня вопрос очень даже практический.

[mazzy]

Цитата:

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

Как программист в настоящем и юрист в прошлом, проживающий в англоязычной стране, на среднем уровне погружения в термины и логику, лично я понимаю это так:

Case 1: Типичный EDI обмен с внешними поставщиками и клиентами - это OK.

Case 2: Кладовщик во внешней WMS которая по факту внешний модуль AX - это $$$$. Даже если асинхронная связь через IDE.

Case 3: Сторонний E-commerce когда во время сессии пользователя идет обращение к AX - это $$$$.

Case 4: Самодостаточное и способное работать без связи с AX но для работы которой нужны данные введенные через AX - ???? Надо подумать. Но риск уже есть.

текущие колебания линии партии и правительства задают столбовую дорогу к именованным пользователям.
это раньше, до победы единственно правильного и верного учения, лицензии делились по функционалу. Сейчас - праздник именованных пользователей и 4 источников и составных частей ролей.

Поэтому, с точки зрения лицензирования Майкрософт, классификация выглядит следующим образом:

• неименованный доступ к информации, не зависящей от пользователя
• именованный доступ пользователя к информации о себе
• именованный доступ пользователя к информации, которая создана другими пользователями за исключением функционала главной книги (роли task & functional - в рамках одного подразделения и в нескольких подразделениях соответственно)
• именованный доступ пользователя ко всем функциям, включая функционал главной книги (включая разноску документов)

причем безопасно считать, что доступ как при помощи самой аксапты, так и посредством сторонних программ. Там есть исключения, связанные с историческим развитием аксапты и назначением не той роли в стандартной аксапте. но общий подход такой. для доступа из внешних программ - именно такой.

есть еще один аспект:
лицензирование пользователя или лицензирование устройства - Device CAL.

для внешней программы (которая работает на каком-то оборудовании) можно купить лицензию на устройство.
тогда запросы с этого устройства не требуют лицензирования по пользователям.

поэтому для Microsoft Dynamics:

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

а вообще говоря, для Dynamics есть License Guide:

Цитата:

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

Какие-то городские легенды, чесслово
Вот на официальном сайте официальный документ Microsoft Dynamics AX 2012 R3 Retail and E-commerce Licensing Guide, там английским по белому на 8-й странице написано: External users (customers) do not require CALs.

по SAP'у я не знаю.

[ax_mct]

Цитата:

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

...
а вообще говоря, для Dynamics есть License Guide:
External users (customers) do not require CALs.

Пока нет времени прочитать ответить полностью, но выделенное не относится к третьим приложениям, а только к коробочным решениям MS как то e-commerce на базе SharePoint.

[ax_mct]

Цитата:

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

...
лицензирование пользователя или лицензирование устройства - Device CAL.

для внешней программы (которая работает на каком-то оборудовании) можно купить лицензию на устройство.
тогда запросы с этого устройства не требуют лицензирования по пользователям.
...

Тут интересно обсудить. И конкретизировать.

Уверен что

1. Фраза "External users (customers) do not require CALs." относится только к описанному сценарию
SCENARIO 3: E-COMMERCE когда Microsoft Dynamics e-commerce is a joint solution between Microsoft SharePoint and Microsoft Dynamics.

Считаю что для всего остального применяется следующее
" Direct or Indirect Access to the Microsoft Dynamics AX 2012 R3 solution functionality by users or devices is licensed through CALs. Every user or device accessing the solution functionality—whether directly or indirectly—must be covered by a CAL."

Уверен что
2. Лицензирование устройства - Device CAL должно быть на конечных устройствах как например мобильные терминалы, POS - для одного пользователя в момент времени. Но это никак не может быть сервер обрабатывающий запросы множества сессий пользователей и обеспечивающий обмен сообщениями с AX.

Тут еще интересно то что Diageo считал что если категория покупателя не подпадает ни под одну классификацию в лицензионном соглашении, то на нет и суда нет. Однако суд обоснованно и логично заключил что отсутствие описания роли/классификации не влияет на общее требование что за каждого пользователя нужно платить.

То есть пользователи e-commerce или WMS, где реализована интеграция с AX, в подавляющем большинстве типичных интеграций, - нелегальные пользователи AX.
Даже если они не попадают под существующую классификацию или рассматриваемые сценарии. "Можно только то что явно разрешено".

Цитата:

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

Не факт что правила лицензирования Retail Module, разработанного в Микрософте для Dynamics AX применяются для вообще любой абстрактной самописки или веб-сайта, которая либо через .net BC или через Web Service что-то почитывает и пописывает в аксапту.

[ax_mct]

Microsoft Dynamics AX Licensing Guide August 2016
http://download.microsoft.com/downlo...%20Edition.pdf

Use this guide to improve your understanding of how to license Microsoft Dynamics AX, Microsoft’s new cloud ERP service, built on and for Microsoft Azure.

То есть AX7.

Однако вот что я накопал для AX7:
_Subscription Licensing Requirements
__Internal and External Users
___With Microsoft Dynamics AX you must license each internal user who will access the service. However, access by external users is included with the subscription and do not require subscription licenses (“SLs”). External users are users that are not an employee, onsite contractor, or onsite agent of the customer or its affiliates.
In other words, end customers (customers of the Microsoft Dynamics AX customer) do not require a SL to access Microsoft Dynamics AX to manage their accounts and orders. However, end customers may not use Microsoft Dynamics AX to manage any portions of their business. In this sense, the definition of external users does not extend to onsite contractors or vendors. External user licenses cannot be used to provide business processes on the customer’s behalf.
Note: Offsite vendors are considered external users only when their time is shared in between multiple customer organizations (for example, IT support service vendors serving multiple customer organizations) and they are not in an employee-like relationship.

И для AX2012:
Microsoft Dynamics AX 2012 R3 Licensing Guide | 2016
https://www.google.co.uk/url?sa=t&rc...UcR5W9JGQhl0-Q

ACCESS BY EXTERNAL USERS
Your or your affiliates’ employees, agents, or contractors require a CAL to access your Microsoft Dynamics AX 2012 solution. Your customers do not require a CAL to access your Microsoft Dynamics AX 2012 solution to manage their accounts and orders. However, your customers may not use your software to manage any portions of their business.

Интересно. Но надо помнить что "не разрешено то что явно не разрешено". То есть одно дело когда клиент через стандартный EP, и другое когда покупатели создают заказ в e-commerce. Но мне думается что случайно или нет, но сценарий с e-commerce вполне подходит под "access your Microsoft Dynamics AX 2012 solution to manage their accounts and orders", хотя явно писали под EP сценарий. Ура

[ax_mct]

Хотелось бы добавить что расположение формулировки в документе критично.
Если "Внешние пользователи не требуют лицензирования" находится в разделе e-commerce c конкретным сценарием как использование e-commerce на SharePoint, то оно относится только к конкретному этому сценарию.

Все косвенные пользователи подлежат лицензированию за исключением явно прописанных исключений. В самостоятельном разделе "Внешние пользователи" описано такое исключение как "Ваши покупатели не требуют лицензировании если управляют своим профилем и заказами".

Это означает зелёный свет для e-commerce с АХ, при том что для SAP по сути неродной e-commerce стал невозможен. Это очень серьёзный аргумент при продажах.

Но это не делает легальными все интеграции с АХ. Исключение только для покупателей.
Наполовину то решение по SAP было бы верным и к АХ - менеджеры на web-интерфейсе запрашивающем информацию из базы АХ/SAP - должны быть заплаченными пользователями основной системы. И вариант лицензирования этого web-сервера как device не прокатит.

[Diman]

Цитата:

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

Раньше я рассматривал создание интеграционных адаптеров как направление бизнеса, теперь это уже не выглядит разумным.

Что так-то?

Тут везде в выдержках и лицензионных соглашений пишут про доступ к "functionality", а если интеграция напрямую лазить в БД будет, интересно как такой случай трактовал бы SAP и MS.
Вот если SAP или AX наружу сервис публикуют, это как раз подпдадает под условия лицензии и вроде как не криминально.

[ax_mct]

Цитата:

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

Что так-то?

Тут везде в выдержках и лицензионных соглашений пишут про доступ к "functionality", а если интеграция напрямую лазить в БД будет, интересно как такой случай трактовал бы SAP и MS.
Вот если SAP или AX наружу сервис публикуют, это как раз подпдадает под условия лицензии и вроде как не криминально.

Если о рынке адаптеров для АХ то страшно уже наполовину из-за исключения покупателей из лицензирования. Но до этого суда с SAP я вообще не задумывался и не знал о вопросе непрямого доступа, поэтому и забурлил. Для меня существование этого фактора делает рынок адаптеров проблематичным.

Интеграция через прямой доступ к базе как способ снижения лицензий - для меня минное поле. То есть для отдельного клиента и можно сделать, но инвестировать и продавать как продукт - уже рискованная инвестиция не только с точки зрения спроса, но и последствий.

Кстати совсем не 100% что прямой доступ к базе это индульгенция. Остаётся вероятность проблем.

P.S. Или лицензированный пользователь (при чем в случае device CAL- конечный девайс) или наличие явного и конкретного исключения из под лицензирования. Во всех остальных и прямо не указанных сценариев - риск, так как дух и буква лицензионных соглашений - "вы должны за все платить пока мы явно не разрешаем".

До тех пор пока не сказано что прямой доступ к базе допускается - даже для BI ситуация неоднозначная. Хотя я может что-то и пропустил насчет случаев аналитики в соглашениях.Но в любом случае я бы не стал стартовать и участвовать в интеграции которая основана на уходе от лицензий через прямой доступ к базе. Крайне сомнительный фундамент.

[Diman]

Цитата:

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

До тех пор пока не сказано что прямой доступ к базе допускается - даже для BI ситуация неоднозначная.

А это вообще ад, если так. Интересно тогда, какое соглашение будет иметь большую силу, для SQL или AX

[mazzy]

Цитата:

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

А это вообще ад, если так.

нет, не так.

Цитата:

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

Какие-то городские легенды, чесслово
Вот на официальном сайте официальный документ Microsoft Dynamics AX 2012 R3 Retail and E-commerce Licensing Guide

[ax_mct]

Цитата:

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

нет, не так.

mazzy, вы опять ссылаетесь на документ в котором

Direct or Indirect Access to the Microsoft Dynamics AX 2012 R3 solution functionality by users or devices is licensed through CALs. Every user or device accessing the solution functionality—whether directly or indirectly—must be covered by a CAL.

И в котором фраза "External users (customers) do not require CALs." относится только к описанному сценарию
SCENARIO 3: E-COMMERCE когда Microsoft Dynamics e-commerce is a joint solution between Microsoft SharePoint and Microsoft Dynamics.

До тех пора мы не нашли явного исключения из CAL (как это сделано для покупателей товаров) все кто имеет доступ к системе прямо или опосредованно - должны быть нормальными пользователями AX. Включая прямой доступ к базе для BI. Термин "the solution functionality", до тех пор пока не прямо не разьяснен в документе - неодназначен и легко может включать саму базу AX при грамотной подаче.

С другой стороны смысл нагнетать и фантазировать? Почему бы не спросить Microsoft

- "Требуют ли CAL внутренние пользователи (out-of-box | third-party) BI с данными из AX, как например менеджеры по продажам не являющиеся пользователями AX"?

- "Требуют ли CAL внешние пользователи BI с данными из AX, как например контрагенты не являющиеся пользователями AX"?

ну или похожее. Кто нибудь спрашивал?

[mazzy]

Цитата:

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

mazzy, вы опять ссылаетесь на документ

да, я опять ссылаюсь на официальный документ на официальном сайте.

Цитата:

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

в котором ... относится только

чтобы любой мог проверить ваши выводы и проследить ход ваших рассуждений. и сделать собственные выводы.

Цитата:

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

С другой стороны смысл нагнетать и фантазировать? Почему бы не спросить Microsoft

именно.

[ppson]

что такое indirect access?

[ax_mct]

Цитата:

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

что такое indirect access?

Любой косвенный, опосредованный доступ. К примеру использование стороннего продукта в котором есть обращение к AX.

В принципе цель моего бурления достигнута - мы знаем что есть такой доступ и что за него может быть больно. И что имеет смысл сомневаться и спрашивать тот же Microsoft. Или не спрашивать, но понимать риски.

[DAX.Company]

Цитата:

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

Любой косвенный, опосредованный доступ. К примеру использование стороннего продукта в котором есть обращение к AX.

Ну я так понимаю если обращение к функционалу - то да. Нарушение. А к данным (BI) кто ж вам запретит обращаться...

[Diman]

Цитата:

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

Любой косвенный, опосредованный доступ. К примеру использование стороннего продукта в котором есть обращение к AX.

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

[mazzy]

выделил трэш в отдельную ветку
А если линия партии заколеблется в другую сторону, что будет с теми, кто рассчитывал на нынешнюю интерпретацию?

[Vadik]

Не совсем про интеграцию, и скорее для себя закладочку оставить.. Клиентов используюших EP лицензировать не надо

Q: The created claims user was not marked as an external user in AX so it consumed one user license in the application. The claims users should be marked as external, is it right?
A: It is a known problem that external users are not marked as external in the users form, but external users assigned to customer role and associated with a customer does not require user licenses

Solution 1739121 Forms based authentication for Public EP template