Распределенное решение

[Urch]

Здравствуйте.

У меня вопрос: сталкивался ли кто-нибудь с реально распределенным решением на MS Navision Axapta?

Дело в том, что у нашей компании более 15 региональных подразделений. Из них 5 БОЛЬШИХ заводов.

Доступные каналы связи с заводами вряд ли смогут превысить 128 Кб/с (по крайней мере в обозримом будущем).

При этом желательно получить максимально интегрированное решение.

Буду благодарен за любую информацию.

[mazzy]

Этим активно занимались в Минске.
Результаты не очень ободряющие но опыт у них есть.

Попробуй выйти на Евгения Куликова в Навижине.
Он курирует партнеров и, думаю, поможет узнать делати и состыкует с авторами методики.

[ldv]

Подходов к построению распределенного решения может быть несколько.
В Аксапта реализованы следующие подходы:

1. Консолидация на уровне главной книги - т.е. консолидация финансовой отчетности.
2. Интеграция посредством Commerce Gateway через MS BizTalk Server.

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

Интеграция через Commerce Gateway - это интеграция на уровне документов. Причем также здесь можно использовать единую БД. Т.е. может быть реализована следующая схема: одно из ваших подразделений вводит Заказ - автоматически формируется Закупка у другого подразделения, а по событию Закупки в свою очередь у третьего подразделения создается производственный заказ. Но здесь надо помнить, что любую схему надо будет программировать. Из стандартных схем реализована схема Заказ - Закупка.

Т.е. при использовании первого подхода и второго - в зависимости от потребностей - можно построить необходимое решение.

[Urch]

1. Консолидация на уровне главной книги - т.е. консолидация финансовой отчетности.

К сожалению данный вариант вряд ли сможет устроить.

Удаленные подразделения являются участниками единых бизнес-процессов, действующих практически (допустимое отставание - 1 час) в реальном режиме времени.
С каналом тоже сложность: 20-30 рабочих мест - это МИНИМУМ, который нужен заводу. Кроме того, вешать судьбу завода на канал... Сомнительно...

2. Интеграция посредством Commerce Gateway через MS BizTalk Server.

Это уже более интересно, но...

Проблема №1. Обмен документами, как я понимаю, происходит через XML схемы. Но как быть, если у меня в одной из баз происходит необходимость изменить структуру документа, а как следствие, и XML схему. Смогут ли два aXAPTA-СЕРВЕРА ПОНЯТЬ ДРУГУ ДРУГА ПОСЛЕ ЭТОГО.

Проблема №2. Если у меня системы начинают работать в режиме офф-лайна (по-моему эта схема подразумевает именно это), то как решить проблему с "двойниками". Т.е. если у меня на двух серверах завели один и тот же объект одновременно (например, контрагента), то при "синхронизации" двух баз будут обоюдно созданы "двойники". Понятно, что в этом конкретном случае можно вешать какой-либо анализ на поля ИНН, например, но как быть с другими документами...

Проблема №3. Если рассмотреть Ваш пример: "одно из ваших подразделений вводит Заказ - автоматически формируется Закупка у другого подразделения, а по событию Закупки в свою очередь у третьего подразделения создается производственный заказ. ". А как быть с откатом Заказа, если уже пошли дальнейшие процессы.

Проблема №4 Опять же для Вашего примера. А если мне необходимо знать финансовые взаимоотношения (состояние взаиморасчетов) между заказчиком и поставщиком перед заключением сделки? А если эта информация находится на центральном "сервере"? А клиент седит перед региональным диллером на стульчике и ждет оформление заказа?

И много-много других проблем.

Возникает вопрос: есть ли для распределенных решений КОНКРЕТНАЯ методология с соответствующим ПОЛНОФУНКЦИОНАЛЬНЫМ инструментарием, предусматривающим все возможные аспекты, возникающие при взаимодействии двух (или более) серверов.

[ldv]

Цитата:

Возникает вопрос: есть ли для распределенных решений КОНКРЕТНАЯ методология с соответствующим ПОЛНОФУНКЦИОНАЛЬНЫМ инструментарием, предусматривающим все возможные аспекты, возникающие при взаимодействии двух (или более) серверов.

В самой Аксапта такого интрумента нет, репликацию надо делать на уровне базы данных. Недостатков здесь также много. И я бы не сказал, что интеграция через BizTalk сильно хуже такого решения. Вернее, я уверен в обратном.

По проблеме №2:
Описанная проблема с двойниками при репликации также возникнет - и ее придется сидеть и разбирать в каждом конкретном случае вручную, либо программировать специальные алгоритмы, которые можно запрограммировать и для BizTalk.
Далее - двойники возникают и в единой БД - например всегда возникают двойники по клиентам, поставщикам, товарам - как этого избежать - вопрос скорее организационный.

По проблеме №3:
Откаты заказа - любое событие, которое завершается транзакцией - может быть передано через BizTalk - естественно схемы для каждой из них необходимо будет разрабатывать.

И по проблеме №1:
проблема после изменения структуры БД возникнет хоть после репликации, хоть при интеграции через BizTalk. Это также скорее организационная проблема.

И много-много других проблем можно решить. Главное чтобы их число было конечным.

А ответ на поставленный вопрос следующий: методологии предусматривающей все возможные аспекты взаимодействия двух серверов нет и быть не может. Нельзя объять необъятное - как замечательно сказал Козьма Прутков. Всегда необходимо учитывать бизнес-логику, которая может меняться, что должно приводить к изменению схемы взаимодействия.

[Urch]

А по проблеме №4?

[ldv]

Проблема №4:
т.е. необходимость поддерживать реальные сальдо по клиентам. Наиболее просто вести все продажи в одной базе. Доступ из филиалов к БД может быть обеспечен через WEB. Т.е. для региональных дилеров - все что нужно это рабочее место Customer Self Service. Доступ к состоянию стоков и задолженности клиентов в этом случае обеспечивается по-моему стандартной функциональностью. По моему там же реализована возможность проверки кредитного лимита. Но не ручаюсь. В любом случае это запрограммировать несложно.
Если с WEB доступом также совсем никак, можно создать в BizTalk схемы по передаче в том числе и платежных документов с последующей их автоматической разноской - я уже ранее писал - для любого события можно задать схему. Но это решение - хуже.
Лучше все же доступ через WEB по каналу 128 Кб/с.

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

[kroxa]

очень интересный вопрос, хотел узнать про решение "все филиалы на одной БД"

возможно сможете дать ссылку или кратко описать как происходит работа в случае расположения различных центров ответственности (к сожелению не знаю как в аксапте называется по русски ФИЛИАЛ) в одной БД:

1. как решается вопрос "бщих" справочников (на уровне отдельных записей или справочника целиком, наример справочник контрагентов и номенклатурных позиций)?

2. есть ли какая-то функциональность создания документов на основе документов из другого центра ответственности

3. может ли планирование (сбыта, финансовое, производсво) в типовой конфигурации обрабатывать корпоративную структуру, т.е. получать консолидированые планы и план-факторый анализ (аналогично про бюджеты) ?

[mad_pilot]

>"все филиалы на одной БД"
это разные компании сидящие в 1 вирт. компании


>как решается вопрос "бщих" справочников (на уровне отдельных записей или >справочника целиком, наример справочник контрагентов и номенклатурных >позиций)?

это через коллекции.
если интересует - есть куча готовых коллекций (в т-ч заказы с клиентами и номенклатура) , может что и подойдет...

[ldv]

Цитата:

1. как решается вопрос "бщих" справочников (на уровне отдельных записей или справочника целиком, наример справочник контрагентов и номенклатурных позиций)?

Для настройки общих справочников используется понятие таблицных коллекций. Кроме того здесь необходимо упомянуть о функциональности Домена компаний. Любую таблицу мы можем сделать общей для всех компаний одного домена. В рамках одной БД можно организовать необходимое количество доменов. Есть партнерское решение по разграничению доступа на уровне записи. Таким образом, при определении таблицы как общей, с помощью разграничения доступа на уровне записи по какому-либо критерию таблицы, мы можем сделать справочник условно "общим" - т.е. на уровне записей. На самом деле настройка табличных коллекций занятие довольно интересное. Например, я делал такую настройку, когда таблица товарных транзакций была общая, поддерживалась общая нумерация номенклатуры, а журналы ввода складских операций были раздельные и т.п.

Цитата:

2. есть ли какая-то функциональность создания документов на основе документов из другого центра ответственности

Такая функциональность может быть реализована через Commerce Gateway. Кроме того, можно использовать механизм связанных компаний - в журналах всегда есть ссылка на связанную компанию, но эта технлогия кажется мне менее предпочтительной. Однако она и менее дорогая.

Цитата:

3. может ли планирование (сбыта, финансовое, производсво) в типовой конфигурации обрабатывать корпоративную структуру, т.е. получать консолидированые планы и план-факторый анализ (аналогично про бюджеты) ?

Можно проводить консолидацию финансовой информации - есть механизмы как он-лайн, так и офф-лайн консолидации. Функциональность работает как для плана, так и для факта.

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

[skof]

Цитата:

Изначально опубликовано mazzy
Этим активно занимались в Минске.
Результаты не очень ободряющие но опыт у них есть.

Попробуй выйти на Евгения Куликова в Навижине.
Он курирует партнеров и, думаю, поможет узнать делати и состыкует с авторами методики.

Результаты такие - Конкорд (не Аксапта правда, но сами знаете в каких они родственных отношениях) распределенно работает в организации со множеством филиалов, связанных по коммутируемым линиям (мдемы на 56К и качество связи не всегда на высоте), в каждом филиале свой сервер со своей базой и в центре сервер - собирающий всю информацию со всех филиалов. Наш продукт выполняет синхронизацию баз, работает это на уровне базы данных и Аксапта "не знает" о синхронизации. База данных Оракл. В принципе под MS SQL2000 можно переписать.

В прошлом году в августе мы возили все это под Аксапту и демонстрировали работоспособность синхронизации в Аксапте (проверяли путем выдергивания штекера локальной сети в момент сеанса синхронизации - ошибок не обнаружили).

Система документирована, есть руководство администратора - в общем пишите...

[komar]

Лицензия на каждую инсталляцию+расходы на администрирование нескольких баз+расходы на систему репликации+опять-таки каналы для передачи данных для репликации+издержки, связанные с недостаточной оперативностью обновления центральной базы. Добавить к этому практическую невозможность "двухсторонней" репликации и возможные глюки в системе репликации. Плюс оборудование (сервера и т.д.) для каждой инсталляции.
Это все против стоимости расширения каналов, которая позволяла бы работать удаленно с единой базой.
Так откуда такая зацикленность на распределенной базе данных? На это действительно есть разумные причины, или это просто привычка со времен 1С?

[Urch]

Ну, как сказать. Если говорить о Москве, то согласен. Канал если не дешевле, то точно проще в разработке и поддержке. Т.е. косвенно дешевле.

Но как быть с регионами. Если в Брянск идет всего 4 мб/с, а мы в 40 км. от Брянска? А на канале еще 200 клиентов? Оптика от Москвы до Брянска или Плесецка - это отнюдь не дешевле "распределенного" решения...

[ldv]

[QUOTE]Если в Брянск идет всего 4 мб/с, а мы в 40 км. от Брянска? А на канале еще 200 клиентов? Оптика от Москвы до Брянска или Плесецка - это отнюдь не дешевле "распределенного" решения...[/QUOTE

Распределенное решение тоже каналов требует между прочим - если на иных носителях с курьером информацию не возить - ).

А на самом деле - интеграция через BizTalk - это всего лишь более технологическая репликация. Она может быть реализована и не в on-line. В качестве транспорта может использоваться и HTTP, и файл. Т.е. решение не должно быть более трафикоемким, чем аналогичная репликация.

[Urch]

Цитата:

Распределенное решение тоже каналов требует между прочим - если на иных носителях с курьером информацию не возить - ).

Так я с этого и начал - максимум 128, реально - 64. (см. первое сообщение темы)

[komar]

Ну... а через модем?

[axot]

Советую посмотреть
http://www.erponline.ru/read/about/implemtrade

[komar]

Они изначально заказывали именно распределенную базу.