Enterprise Portal + AOS + Web

[linney]

Уважаемые участники форума!

Еще один животрепещущий вопрос...

Решили покупать Enterprise Portal и Web-пользователей т.е
конфигурация будет такая:
В штаб-квартире СУБД, AOS, портал, пользователи как web,
так и обычные.
НО есть еще удаленные офисы...
что ставить туда? Еще по одному порталу? Еще по одному AOSу?
(там тоже будут web пользователи...)

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

Короче, вопросы:
1. может ли портал работать через AOS?
2. можно ли каскадировать AOS?
3. ......

Что посоветуете?

[vleg]

В филиалы не нужно ставить ничего. Закупите только нужное количество одновременно подключенных web-пользователей.

Развертывание Корпоративного портала, как и любого другого веб-приложения Аксапты, осуществляется прямо из нее. В параметрах веб-приложения вы указываете с какой именно конфигурацией будет осуществляться работа данного приложения (в конфигурации определяются параметры подключения - база данных \ сервер приложения \ компания). Если учет по всем компаниям ведется в одной базе данных, видимо, каждое юр. лицо работает со своей компанией в Аксапте. Сколько компаний, столько веб-узлов и должно быть развернуто (каждый узел - в виртуальном каталоге или подкаталоге inetpub\wwwroot). Остается настроить права доступа и сообщить в каждый офис, с каким именно сайтом им работать.

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

[linney]

Спасибо за ответ!

скорее всего будет так:
один удаленый офис - одна компания

>Сколько компаний, столько веб-узлов и должно быть развернуто (каждый узел - в >виртуальном каталоге или подкаталоге inetpub\wwwroot).

хотелось бы уточнить, что это означает приминительно к лицензиям Enterprise Portal?
нужно ли столько порталов сколько есть офисов?

Т.е. хотелось чтобы пользователи филиалов не ломились напрямую в центральный
офис, а чтобы они сначала попадали на сервер-портал-что-то еще, что ФИЗИЧЕСКИ стоит в филиале, а этот сервер уже отвечал за связь и транзакции с центром

---------------
Спасибо

[vleg]

Для развертывания портала нужно, чтобы на сервере, на которым развернуто соответствующее веб-приложение, был также установлен Axapta Business Connector. Для того, чтобы все работало, ABC должен быть постоянно "на связи" с приложением (в трехзвенке - с AOS или или их кластером). Поэтому особого смысла разворачивать именно эти два компонента в удаленном офисе не вижу. Проще разместить их в демилитаризованной зоне в сети центрального офиса. Никаких дополнительных лицензий для этого не требуется - покупаете один Enterprise Portal Framework, нужные роли, нужное количество COM и Web пользователей.

Если же в удаленном офисе требуется разместить офф-лайновое решение, то нужна еще одна лицензия на все, что там будет использоваться. Ну и дополнительная ручная (экспорты-импорты) или автоматическая (к примеру XML) передача данных в центр.

[Lyas]

Коллеги.
А можно поподробней на счет DMZ и т.д.
Задача следующая. (Думаю, аналогичная задача возникала у каждого, использующего WEB-клиентов.)
В локальной сети имеется SQL сервер с Axapta. Там же расположен AOS.
IIS находится в DMZ.
Клиенты, соответственно, в интернете.
Правила доступа - обычные:
Inet -> DMZ - Да.
Inet -> Lan - Нет
DMZ -> Lan - Нет
DMZ -> Inet - Да
Lan -> Inet - Да
Lan-> DMZ - Да.
В случае баз данных я поступал бы так: установил в DMZ еще один SQL сервер и синхронизировал его с основным. Причем синхронизация инициировалась бы основным сервером. А IIS обращался бы к SQL, который находится в DMZ.
А как это решается в Аксапте?
Заранее спасибо.