Репликации в Axapte

[drFAD]

Всем привет!
У моего руководства есть большое желание внедрить Axapty. Но есть одно "НО".
Хочется иметь единую базу данных по всем филиалам Их достаточно много и они распределены по всей стране. Большинство филиалов имеют выделенные каналы (~2 Mbit/s) в интернет и объеденины в корпоративную сеть по VPN.
Желание в общем следующее:
что бы если в одном филиале на складе не оказалось нужного товара, то можно было бы без труда заказать со склада ругого филиала.

А так же что бы можно было без проблем смотреть бухгалтерские, финансовые и другие отчеты по отдельным филиалам и по всем сразу.

Отсюда вопрос:
Кто нибудь внедрял распределенную базу Axapta с репликациями межде базами данных (может даже на уровне самих баз данных). Если да то в двух словах архитектуру такой базы.

А если нет, то как кто-нибудь решал подобные проблемы. Если можно то поподробнее. Можно на мыло afedorov@dek.ru.

Буду очень признателен за подробные ответы т.к. рассматриваем вариант внедрения axaptы очень серьезно.

С уважением, Александр.

[Peter Savintsev]

Думаю, при наличие такой достаточно неплохой связи между филиалами можно обойтись одной централизованной БД. Использовать лучше всего трехуровневую кофигурацию, возможно, с несколькими серверами приложений. В этом случае никаких проблем репликацией не будет по причине отсутствия оной.

[Андре]

Цитата:

Думаю, при наличие такой достаточно неплохой связи между филиалами можно обойтись одной централизованной БД.

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

[Andrew Besedin]

Скорее всего, подойдет "частая" (транзакционная) репликация БД
Каждый филиал работает в своей компании Аксапта.
Справочники общие, все движение - раздельное.
Проблема при разрыве связи, таким образом, сводится к корректной состыковке справочников.
Тут предлагается сделать следующим образом. Напр, клиенты. Коды клиентов в разных филиалах различаются префиксом. Завести доп. поле: "код клиента в филиале1". Запускать периодич. операцию по состыковке одного клиента и другого, которые заведенны в разных филиалах (напр, по ИНН или др. признакам).
Придется дорабатывать алгоритмы получения сальдо, список сч/фактур и пр. документов по клиенту и т.п.

[drFAD]

Уважаемый Андрей Беседин!
Вы как раз абсолютно правильно поняли нашу проблему. Хотелось бы знать кто-нибудь подобное уже делал? Или может есть кто из интеграторов кто может такое сделать? Если найдется системный интегратор, который сможет такое обеспечить. Мы воспользуемся ЕГО услугой.

Но не хотелось бы всетаки чувствовать себя один на один с подобной проблемой. Если у кого действует хоть что нибудь подобное, поделитесь опытом.

С уважением, Александр Федоров.

[Pavel]

Цитата:

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

Какой народ продвинутый пошел. Все хотят узнать наперед.

"Интеграторы" при продаже системы поступают очень просто (далее пример из жизни):
Клиент:
- А ваша система будет делать репликацию данных между нашим офисом и складом
Продавец:
- Конечно. Она же работает на SQL сервере. Посмотрите, там (в SQL) даже такая функция есть - "Репликация".
Ха-ха-ха...

Главное продать, а там видно будет.

[komar]

Может, так у нас любят репликацию проводить потому, что в старых системах это был единственный вариант, и просто ничего другого себе вообразить не могут.
Репликация поднимает больше проблем, чем может решить, и тоже требует каналов связи. Особенно, если репликация двухсторонняя.
Кстати, в Вашем примере при заказе товара с чужого склада репликационный вариант явно не самый лучший - что будете делать, если товара на складе реально уже нет, а в отреплицированной базе в силу периодичности самой репликации он еще есть?
Или это вариант, когда "надо все" и при этом "все как в старой системе"?
Мой Вам совет, подумайте про единую базу....

[Pavel]

Цитата:

Изначально опубликовано drFAD
Кто нибудь внедрял распределенную базу Axapta с репликациями межде базами данных (может даже на уровне самих баз данных). Если да то в двух словах архитектуру такой базы.

А если нет, то как кто-нибудь решал подобные проблемы. Если можно то поподробнее. Можно на мыло afedorov@dek.ru.

Действительно без репликации все проще и примеров немало. Например, распределенное решение такого рода в "Киев Стар GSM" (Конкорд). Филиалы компании в разных городах Украины используют каждый свою базу. Система и базы данных в Киеве. Филиалы имеют удаленный доступ. Сводная информация получается путем консолидации данных. Есть и другие примеры Техносила - Аксапта, AVON - Конкорд и пр.

[Alex_K]

Цитата:

Изначально опубликовано Andrew Besedin
Скорее всего, подойдет "частая" (транзакционная) репликация БД
Каждый филиал работает в своей компании Аксапта.
Справочники общие, все движение - раздельное.
Проблема при разрыве связи, таким образом, сводится к корректной состыковке справочников.
Тут предлагается сделать следующим образом. Напр, клиенты. Коды клиентов в разных филиалах различаются префиксом. Завести доп. поле: "код клиента в филиале1". Запускать периодич. операцию по состыковке одного клиента и другого, которые заведенны в разных филиалах (напр, по ИНН или др. признакам).
Придется дорабатывать алгоритмы получения сальдо, список сч/фактур и пр. документов по клиенту и т.п.

Не забудьте еще и про синхронизацию приложения Аксапта на разных серверах. Тоже задачка нетривиальная. А модифицировать код все равно придется...
Так что, если есть возможность создать резервные каналы связи, IMHO, лучше тонкие клиенты и одна база.

[Andrew Besedin]

Всем привет!

Само собой, постоянная связь НАМНОГО лучше! Тонкий клиент - это здорово.
Но, как я вижу задачу, нужно продолжать работать филиалам при разрыве связи. А если эти разрывы - скорее правило, чем исключение, то нужно что-то думать.
Резервные каналы - это хорошо, но если и они порвутся? Работать-то надо продолжать...

Цитата:

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

Согласен. Тут продумать нужно разделение таблиц на комании. Каждый филиал - независимый склад(ы). Т.о. репликация не напортачит остатки.
При отсутствии связи запретить выписывать товар с других складов. Нормально так?

Цитата:

Не забудьте еще и про синхронизацию приложения Аксапта на разных серверах. Тоже задачка нетривиальная. А модифицировать код все равно придется...

И опять согласен. Это скорее организационный вопрос. Модификации, не касающиеся структуры данных, выполняются в "сводобном режиме". Все, что меняет данные хоть как-то, закачивается "по команде" (это особенно хорошо, если филиалы далеко друг от друга - конец раб. дня у одного == началу у другого (Хабаровск-Калининград))

[Alex_K]

Цитата:

Изначально опубликовано Andrew Besedin
Всем привет!

Само собой, постоянная связь НАМНОГО лучше! Тонкий клиент - это здорово.
Но, как я вижу задачу, нужно продолжать работать филиалам при разрыве связи. А если эти разрывы - скорее правило, чем исключение, то нужно что-то думать.
Резервные каналы - это хорошо, но если и они порвутся? Работать-то надо продолжать...

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

Цитата:

Согласен. Тут продумать нужно разделение таблиц на комании. Каждый филиал - независимый склад(ы). Т.о. репликация не напортачит остатки.
При отсутствии связи запретить выписывать товар с других складов. Нормально так?

На первый взгляд, да...

Цитата:

И опять согласен. Это скорее организационный вопрос. Модификации, не касающиеся структуры данных, выполняются в "сводобном режиме". Все, что меняет данные хоть как-то, закачивается "по команде" (это особенно хорошо, если филиалы далеко друг от друга - конец раб. дня у одного == началу у другого (Хабаровск-Калининград))

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

[komar]

Цитата:

Изначально опубликовано Andrew Besedin
Всем привет!

Само собой, постоянная связь НАМНОГО лучше! Тонкий клиент - это здорово.
Но, как я вижу задачу, нужно продолжать работать филиалам при разрыве связи. А если эти разрывы - скорее правило, чем исключение, то нужно что-то думать.
Резервные каналы - это хорошо, но если и они порвутся? Работать-то надо продолжать...

Согласен. Тут продумать нужно разделение таблиц на комании. Каждый филиал - независимый склад(ы). Т.о. репликация не напортачит остатки.
При отсутствии связи запретить выписывать товар с других складов. Нормально так?


И опять согласен. Это скорее организационный вопрос. Модификации, не касающиеся структуры данных, выполняются в "сводобном режиме". Все, что меняет данные хоть как-то, закачивается "по команде" (это особенно хорошо, если филиалы далеко друг от друга - конец раб. дня у одного == началу у другого (Хабаровск-Калининград))

1. Попадание на лицензии уже упоминалось. Репликация, кроме того, тоже требует каналов (вариант с посылкой диска на оленях рассматривать надо?). При разрыве связи работайте через модем.
2. При отсутствии связи запретить - Вы это программно будете реализовывать? В Аксапте? Или как?
3. А что не меняет данные?

[ans]

Цитата:

Изначально опубликовано drFAD

Желание в общем следующее:
что бы если в одном филиале на складе не оказалось нужного товара, то можно было бы без труда заказать со склада ругого филиала.
С уважением, Александр.

Добрый день!
Собственно это обсуждалось тут
http://www.axforum.info/forums/showt...?threadid=1651

Вам нужно решить насколько вам нужна консолидация склада - то есть вам нужен склад один на все подразделения в режиме онлайн или подойдет его консолидация за какой-то отрезок времени.
Репликация - это хорошо, однако ее реализация займет немало человеко-часов.
Самый сложный для реализации момент - если одну и ту же запись которая есть в подразделении и уже реплицировалась в главный офис отредактировали и тут и там но с разными значениями. И вот наступает момент очередной репликации, SQL (либо то, чем вы собираетесь реплицировать) сравнивает две записи....Какую из них ему считать правильной, а какую игнорировать и изменить? Причем и в подразделении и в главном офисе по этой записе уже прошли реальные физические операции (ну типа товар отгрузили)..........
Вобщем согласен я с Komar...