AX2012 services - async. HTTP

[hardcore]

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

Я правильно понимаю, что у вас проблема с обработкой реквестов на стороне аксапты, т.е кол-во реквестов в единицу времени не слишком большое но каждый реквест выполняется очень долго? И судя по вопросу вы готовы вкладываться в разработку которая позволит клиенту отложено понимать что запрос на сервере выполнен.
Если да то можете рассмотреть следующий варианты (я привел все пару самых незамысловатых хотя на практике их гораздо больше) раз аксапта разработчики начинают активно использовать дот.нет.
Если нет то поясните в чем у вас техническая трудность?
Как говорил Alex_KD тут нужно использовать промежуточный WCF, так как сервисы акспаты несколько урезаны с точки зрения технической функциональности.

1. Взаимодействия в 2 стороны если клиентом является другая система например сайт и такое взаимодействие вообще разрешено административной политикой (наверно это как-то отвечает на ваш пункт с XMLHTTPRequest):
   а) Развернуть wcf сервис над ах, развернуть wcf сервис на клиенте. Клиент вызывает сервис над ах, асинхронно (имеется ввиду стандартный для .net подход
   ) запускает операцию в ах и возвращает управление, когда операция завершается, она вызывает сервис клиента передавая результат. На клиенте лежит логика по корреляции запроса с ответом.
   б) Также более красивый вариант, но не всегда реализуемый из-за ограничений со стороны админов. Реализовать сервис с CallbackContract так называемые дуплексные службы. С технической точки зрения это также вызов в 2 стороны, только коррелировать на клиенте ничего не надо, вы сделаете вызов клиентом вам вернется управления сразу, а когда сервер закончит выполнять запрос на клиенте сработает обработчик.
   
   
2. Если схема предусматривает только вызов со стороны клиента на сервер, а так обычно бывает если системы находятся «далеко друг от друга» и в компании сильна административная политика или взаимодействие между системами в разных компаниях:
   а) Способ в лоб: То вы можете также вызвать клиентом сервис над ах из него запустить операцию в ах асинхронно, по завершении выполнения просто сохранять результат в сериализованнов виде например в базе. А клиент должен периодически опрашивать сервер. Минусы подхода со стороны клиента, что придется писать логику повторного забора результата.
   
   б) Этот вариант вряд ли сходу может быть рабочий, указал только для полноты картины:
   В настройках своего wcf сервиса вы можете задать параметры InstanceContextMode= PerSession
   По умолчанию этот параметр равен perCall, то есть каждый раз когда вы делаете вызов операции на сервисе у вас создается новый экземпляр класса сервиса, если же вы поставите параметр persession то при вызове с одного клиента экземпляр класса будет один, это позволит вам также как и в первом случае вызвать код в ах и вернуть управление, а клиент должен периодически опрашивать сервис. Минусы этого подхода со стороны клиента очевидны, со стороны сервера можно напортачить с доступом к одним и тем же данным в разных потоках, т.к. wcf вам гарантирует только что для одного клиента будет работать экземпляр одного и того же сервиса но вот что вызов операций в этом экземпляре будет проходить из одно и того же потока не гарантируется.
   с) Есть еще совсем новый вариант работы через websockets но для этого нужно использовать windows server 2012 или windows 8 (сейчас только на них iis поддерживает эту технологию). Логика как и в пункте 1б + PerSession из пункта 2б, да и код похожий, и с точки зрения http взаимодействия администраторам глаза не мазолит т.к. вызовы все технически происходят со стороны клиента, такая надстройка над http вообщем.

p.s.
Вообще http устроен как протокол без состояний это дает наибольшую производительность, т.е. сервер не хранит состояние в памяти между вызовами клиента, а практически любая вещь (не считая кода 100 Continue) связанная с сессией (о том что сервер как бы помнит что это за клиент, храня его состояние в памяти постоянно) уже строится поверх http и снижает производительность.
Что касается «асинхронных http» запросов, которые вы можете делать через .net это конечно асинхронно только со стороны клиента. Клиент, делая вызов асинхронно может не ждать ответа от сервера, а продолжать исполнять код текущего потока, а ответ, который сервер обработал синхронно, приходит в другой поток клиента, после чего он становиться доступен в пользовательском обработчике. В общих чертах это можно найти здесь

[EVGL]

Благодарю за глубокий ответ.

Цитата:

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

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

Совершенно верно. Опыт на моем компьютере показал, что доставка сообщения через все уровни абстракции занимает 30 мс, тогда как полная обработка простейшего запроса требует 2 с. Клиент требует ответ <1с.

Цитата:

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

Развернуть wcf сервис над ах, развернуть wcf сервис на клиенте. Клиент вызывает сервис над ах, асинхронно (имеется ввиду стандартный для .net подход

Этого хотелось бы избежать, поскольку надстройка неминуемо скроет WSDL-описание, а клиент предъявляет высокие требования к администрированию и контролю версий схем и моделей данных. В противном случае можно сразу брать MSMQ-адаптор и не мучиться.

Цитата:

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

Способ в лоб: То вы можете также вызвать клиентом сервис над ах из него запустить операцию в ах асинхронно, по завершении выполнения просто сохранять результат в сериализованнов виде например в базе. А клиент должен периодически опрашивать сервер. Минусы подхода со стороны клиента, что придется писать логику повторного забора результата.

Этот способ я пробовал с той разницей, что вызывался стандартный сервис в AX. Минус в том, что WCF-клиент все равно проходит по всем методам, и приходится сериализовывать уже де-сериализованный XML-объект, теряя производительность. Кроме того, придется менять сигнатуры и возвращаемые значения всех update-, create- и прочих методов.

Цитата:

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

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

Да, я догадался, что т.н. асинхронный вызов в .NET работает именно так, и это - не более чем программное ухищрение.

[Vadik]

А на Azure Service Bus adapter не смотрели еще? Там вроде и Service reference при разработке клиента, и реальная асинхронность. Я не агитирую, просто интересно (возможно сами скоро будем тестировать)

[EVGL]

Цитата:

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

А на Azure Service Bus adapter не смотрели еще? Там вроде и Service reference при разработке клиента, и реальная асинхронность. Я не агитирую, просто интересно (возможно сами скоро будем тестировать)

Асинхронности, похоже, нет: http://blogs.msdn.com/b/aif/archive/...s-adapter.aspx

[Alex_KD]

Цитата:

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

Минусы этого подхода со стороны клиента очевидны, со стороны сервера можно напортачить с доступом к одним и тем же данным в разных потоках

Чтобы не напортачить есть _DocumentHash в документ сервисах, который можно взять в read и дальше использовать в update.

Цитата:

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)]

Может есть какой метод с помощью которого можно прописать этот (или любой) аттрибут для AX сервиса?

Цитата:

Этого хотелось бы избежать, поскольку надстройка неминуемо скроет WSDL-описание

Новый WCF опубликует свой WSDL-описание, если указать это в web.config.

Цитата:

Совершенно верно. Опыт на моем компьютере показал, что доставка сообщения через все уровни абстракции занимает 30 мс, тогда как полная обработка простейшего запроса требует 2 с. Клиент требует ответ <1с.

Документ сервисы не знаю насколько шустрые, т.к. пока не тестировал. Простейший сервис (не документ) отвечает практически мгновенно (~100мс). С документ сервисом я бы смотрел в стороны уменьшения передаваемых данных. Наверняка тащите кучу ненужных/не используемых/пустых полей туда-сюда.

Евгений, а в вашем примере с 1000 паралельными запросами все ли запросы действительно выполнились паралельно? Все ли запросы выполнились в примерно одинаковый промежуток времени? Что-то мне подсказывает, что первые 200 прошли на ура, а дальше пошел беспредел...

[Vadik]

Цитата:

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

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

Случайно забрел сюда повторно. Понимаю что Евгению не сильно актуально, но вдруг кому-то пригодится.. Для "тяжелых" в плане количества участвующих таблиц и полей документов (типа клиента, поставщика, продукта) использование data policies с отключением ненужных (неиспользуемых) полей снижает время отклика как раз где-то раза в два-три