Цитата:
Сообщение от
Logger
Решил подобным образом связать две ax2012R3
Не работает.
А стоит ли две ax2012R3 связывать через BC?..
Помнится, у BC есть одна нехорошая особенность, из-за чего его нежелательно использовать в интеграциях двух систем, где нужна отказоустойчивость и масштабируемость: после первого входа он привязывается к определенному AOS-у и потом ни в какую на другие AOS-ы заходить не хочет. Из-за этой особенности летит вся (ожидаемая) отказоустойчивость, когда, скажем, некий Retail Transaction Server (RTS) подключается через BC.NET к AOS-ам для выполнения online-запросов с розничных касс (AX POS). Вот если с тем AOS-ом, куда подключился в первый раз экземпляр RTS, что-то случится, то к другому AOS-у он без собственного перезапуска не подключится и нагрузку между разными AOS-ами распределять не будет. С COM BC в AX2009, помнится, была такая же проблема, и связано это, судя по всему, с тем, что обычный сценарий использования BC "вход/короткий запрос/выход" плохо сочетается с тем обстоятельством, что новая всамделешная сессия на AOS-е создается довольно долго. Из-за этого BC кэширует свое соединение с AOS-ом и не разрывает его по Logoff - только если какой-нить Shutdown вызвать.
Цитата:
Сообщение от
Logger
Причем если использовать бизнесконнектор из консольного приложения или из вебсервиса написанного на .net то все работает. А из под аксапты не хочет ни в какую.
Может, это потому, что у консольного приложения еще нет соединений ни с одним AOS-ом? Сможет ли консольное приложение через .NET BC подключиться последовательно к двум разным AOS-ам?..
Мне лично думается, что для онлайн-интеграции двух разных инсталляций AX2012 лучше использовать AIF-сервисы, работающие через WCF. Там не нужно ставить локально никакие .NET BC, там поддерживается масштабируемость и отказоустойчивость, потому что каждый вызов AIF-сервиса может реально попадать на разные AOS-ы (если
использовать соотв. балансировку нагрузки), там за счет контрактов сервисов более явно определяются действия, доступные для выполнения извне, а не устраивается BC-анархия "подключился - и выполняй какой хочешь код", из-за которой появились все эти серверные методы, запросы разрешений на сервере и прочая...
Здесь мы, конечно, не рассматриваем интеграции, допускающие
асинхронную обработку сообщений, - для них вообще не обязательно использовать подключения к другой инсталляции AX2012, вместо этого можно через очереди сообщений связываться и прочие подобные механизмы.