Мобильное приложение для Dynamics AX

В нашей организации мы пытаемся разработать мобильное приложение / веб-сайт в качестве внешнего интерфейса для Dynamics AX 2012. Мы следуем архитектуре, предложенной MICROSOFT ( https://technet.microsoft.com/en-us/library/dn155874.aspx).

Несмотря на то, что ACS теперь не поддерживается в AZURE, архитектура, предложенная Microsoft, вынудила нас использовать ACS, который я создал после запроса команды Azure.

Архитектура Dynamics AX, предложенная Microsoft

Шаги следуют согласно документу:

Мы настроили следующие пункты, и в настоящее время мы застряли в одном месте:

  1. Настройте три сервера windows 2012 R2, работающие в одном домене - первый для AX и DC, второй для сервера ADFS и третий для службы WCF среднего уровня - выполнено и протестировано индивидуально

  2. Настройка сервера Dynamics AX 2012 со службой AIF, доступной в портах Inboud. - Готово. Установите сервер ADFS и создайте несколько пользователей. - Готово, прослушивание служебной шины в соответствии с журналами событий и проверенная проверка подлинности с помощью консоли powershell.

  3. Создайте пример консольного приложения для вызова ADFS для получения токена и передачи его на шину службы Azure - ADFS возвращает токен, а ACS возвращает токен

  4. Настройте службу среднего уровня, которая будет находиться между AX 2012 и мобильным клиентом - Настройка завершена и ошибка 404 выброса служебной шины

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

Почтовый звонок в сервисный автобус:

URL сообщения:

https://xxxxx.servicebus.windows.net/ExpenseRest/Expense?Action=Create

Заголовки:

Content-Type: application/json; charset=utf-8
Authorization: WRAP access_token="net.windows.servicebus.action=Send&http%3a%2f%2fschemas.microsoft.com%2faccesscontrolservice%2f2010%2f07%2fclaims%2fidentityprovider=http%3a%2f%2fFQDN.COM%2fadfs%2fservices%2ftrust&Audience=http%3a%2f%2finvmobile.servicebus.windows.net%2f&ExpiresOn=1503321191&Issuer=https%3a%2f%2fxxxxxxx-sb.accesscontrol.windows.net%2f&HMACSHA256=SS%SSS%SSSS%3d&wrap_access_token"
Host: xxxxxx.servicebus.windows.net
Content-Length: 4382
Expect: 100-continue

Тело:

{"adfstoken":"adfs_encoded_token","expenseData":{"Amount":"100","Comments":"Expense of 100 INR","CurrenyCode":"EUR","Date":"08/18/2017"}

Ошибка:

404, по указанному адресу сервис не размещен

Источник

1 ответ

Поэтому, если вы хотите использовать ACS, вам, по сути, нужно добавить этот список в белый список через запрос в службу поддержки. Новый рекомендуемый способ подключения - через SAS. Теперь документ, на который вы ссылаетесь выше, также рекомендует создавать службу WCF и / или прослушиватель служебной шины, который по сути является кодом.Net. Есть несколько диаграмм, но то, что я имею в виду, особенно на странице 27 или около того.

Поэтому, если вы работаете в.Net-коде, вы можете сразу же внедрить SAS, что более перспективно, чем пытаться заставить ACS работать.

Некоторые интересные дополнительные данные о SAS, как его реализовать, какие порты открывать через брандмауэр и т. Д.

Порты, которые вам нужно открыть, зависят от того, используете ли вы какой-либо из клиентов или apis rest SB. Из документации видно, что эти порты необходимы: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide

Сервисная шина Azure всегда требует использования TLS. Он поддерживает соединения через TCP-порт 5671, в результате чего TCP-соединение сначала накладывается на TLS, прежде чем войти в квитирование протокола AMQP, а также поддерживает соединения через TCP-порт 5672, в результате чего сервер немедленно предлагает обязательное обновление соединения до TLS с использованием модели, предписанной AMQP., Привязка AMQP WebSockets создает туннель через TCP-порт 443, который затем эквивалентен соединениям AMQP 5671.

Оба современных клиента должны использовать AMQP. Существует более старая версия клиента, которая вряд ли будет использоваться Accenture: более старая библиотека.NET, используемая в какой-то момент, имела собственный протокол на основе WCF, в котором использовался протокол TCP через 9354 (называемый SBMP, протокол обмена сообщениями SB) и иногда может использовали более старую технологию под названием WebStreams

Если вы используете исключительно, будет использовать наши остальные API, они могут использовать только 443. Немного больше данных на SAS https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas

Источник
Другие вопросы по тегам