Распределенка

[George Nordic]

Приветствую всех!
Никто не мог бы подсказать, возможно ли на распределенной базе (Все таблицы общие, кроме SequenceNumber и SystemSequence) разделить RecId и часть номерных серий... т.е. что бы каждая база "думала", что она работает только в своем диапазоне, что бы при репликации данные не наслаивались друг на друга...
И вообще, кто-нибудь распределенку делал?? Поделитесь опытом плиз-з-з!
С Уважением,
Георгий.

[Андре]

Цитата:

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

А ты думаешь, recid - это единственная проблема при реализации репликации в Аксапте ?

[George Nordic]

Не думаю, Андрей. Боюсь я. Но, видимо, нет другого пути Пинг за 1200мс - каково?? Вы же пробовали рапределенку... не поделитесь ли опытом?

С Уважением,
Георгий

[mazzy]

Здесь уже неоднократно обсуждался этот вопрос.
Поищите.

[Андре]

Цитата:

Вы же пробовали рапределенку...

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

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

[George Nordic]

Искал, Сергей. Просто хочу получить совет от того, кто уже наладил данное решение.

С Уважением,
Георгий

[mazzy]

понял, хорошо.

Знаю, что репликацией на Оракле занимался БелСофт.
Там реплицировался журнал откатов.

Можно попробовать поговорить с Андреем Кацемба
http://www.belerp.com/forum/profile....ewprofile&u=14

Но лично мне этот способ не понравился.

На этом форуме хорошие результаты дает поиск по ключевому слову "репликация"

[George Nordic]

Спасибо за контакт, Сергей!

Кстати,

Цитата:

На этом форуме хорошие результаты дает поиск по ключевому слову "репликация"

- немного не верно... все уже было прочитано ранее. Поэтому к Андрею и обращался Печально, что он отговаривает от этого решения

Тогда немного модифицируем задачу:
Есть ряд общих справочников типа LeadgerTable, InventTable, Route..., Opr.., Bom.. etc. Их мы можем безболзненно реплицировать на удаленное предприятие, т.к. изменения могут происходить только в центральном офисе. Хорошо. Далее уже на удаленном предприятии просходит оценка-запуск-приемка пр. заказа + ввод выработки. Причем номерные серии у них тоже отдельно настроенные, не пересекаются с основными (сериями документов в центр. офисе). Можно ли "закачать" в центральную базу эти пр. заказы и выработку? Можно ли настроить отдельный RecId (допустим, на удаленной он начинается с 1млрд) и как он будет жить при закачке в основную базу? (Т.е. получается разрыв между нумерациями RecId в одной базе. Это её обманет, но как это будет жить? ) Как быть с потребление материалов? Если склад будет отдельный и центр. офис не обязан еговидеть? Или тоже заводить в центральном и периодически синхронизировать, но теперь уже из удаленного офиса? Вопросы, вопросы...

Таким образом речь сводиться к частичноми реплицированию отдельных справочников. Поэтому и был задан вопрос по recId. У кого есть просто соображения по данному вопросу - буду рад выслушать.

С Уважением,
Георгий

[Андре]

Цитата:

Можно ли "закачать" в центральную базу эти пр. заказы и выработку?

Пока Вы не все рассказываете

Для чего нужно их туда закачивать ? Распишите задачу ?
Может достаточно реплицировать их в отдельную БД ? Стандартной SQL-ой репликацией. Если Вам нужна общая отчетность - то этого будет достаточно. Собирайте отчетность с помощью внешнего генератора отчетов. На 2 БД можно настроить OLAP - в конце-концов он для этого и предназначен

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

[George Nordic]

Спасибо за советы, Андрей! Olap мы рассматриваем, как вариант... ну, что бы в центральном офисе посмотреть состояние склада и т.п. Буду думать. Буду формулировать. Буду пробовать. Надеюсь, вскоре подниму эту ветку...

Ксати, один из вопросов - можно ли надеяться на стандартную репликацию (даже отдельных таблиц)? не поедет ли при этом RecId - не будет ли дублирования? Може, развести их "вручную"?

С Уважением,
Георгий.

[mazzy]

Цитата:

Изначально опубликовано George Nordic
не поедет ли при этом RecId - не будет ли дублирования?

Поедет. Будет.

[Lazy_Tiger]

У нас распределенка. Если ввести некоторые ограничения, то не вижу особых технических проблем.
1) справочники редактируются только в центральном офисе и спускаются в филиалы
2) документы из офисов поднимаются в центр, тут я тоже не вижу проблемы. Не нужно RecID поля поднимать и все. тогда и конфликтов по RecId не будет

Или я не понимаю проблематику?

[Андре]

Цитата:

1) справочники редактируются только в центральном офисе и спускаются в филиалы
2) документы из офисов поднимаются в центр, тут я тоже не вижу проблемы. Не нужно RecID поля поднимать и все. тогда и конфликтов по RecId не будет

Или я не понимаю проблематику?

Ок. Допустим нам удалось сформулировать задачу именно таким, достаточно узким способом:

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

Таким образом, мы избегаем коллизий.

Теперь о ограничениях такого варианта, то, что сразу бросается в глаза:

1) Изменения в функционале должны одновременно происходить и в центре и в филиалах. Иначе возможен вариант, когда в центре добавили поле в табличку, а в одном из филиалов еще нет. -> Реплицироваться данная табличка не сможет.

2) Сопоставления, накладные расходы и т.д. - то есть, те таблицы, где связка происходит по recId. Либо мы реплицируем с recId, таким какой он был в филиале. Либо сопоставляем и т.д. повторно в центре (это уже совсем теоритический вариант . А теперь представим такую, вполне реальную ситуацию - в филиале провели сопоставление, реплицировались, а затем, откатили сопосталение, что то поравили и опять сопоставили. Будет очень здорово, если за следующей репликацией что-то не придется подчищать ручками

3) А вы уверены, что организационно сможете выполнить обозначенный пункт: "справочники передаются из центра в филиалы". Ведь это означает, что для того, чтобы поставить какую-нибудь галочку в настройках в филиале, Вы должны поставить ее в центре и провести сеанс репликации. А готов ли клиент и его бизнес ждать ? А Вы уверены, что однажды, under pressure of time, Вы не выдержите и не поставите эту галочку сразу в филиале ? А не проще через терминалку вносить настройки во все базы ? А не проще создать группу определений "Настройки" и осуществлять ее экспорт в центре и импорт в филиалах ?

Это так, что сразу бросается в глаза. Уверен, что в ходе эксплуатации этих пунктов будет гораздо больше.

[Андре]

Цитата:

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

Хочу подчеркнуть - я не говорю, что репликацию в Аксапте сделать нельзя. Можно Говорят, что и зайца на дуде играть можно научить. Вот только надо оценивать, что выгоды от репликации и затраты ресурсов, на реализацию и поддержку этой репликации.

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

1. А Вам действительно нужны в офисе все документы? Или все-таки не все ? Может составить перечень информации, которая действительно необходима в центре. А затем рассмотреть различные варианты доставки этой информации в центр.
2. Для чего Вам нужна эта информация ? Для получения консолидированной отчетности - тогда посмотрите Olap. Для получения каких-то отчетов ? Тогда может стоит взглянуть на MS Reporting Services ? В центре нужна копия базы филиала - тогда може подойдет стандартная односторонняя MS SQL репликация ?

Lazy_Tiger, вопросы скорее не к Вам, а к тем, кто только принимает решение о реализации репликации.

[mazzy]

согласен.

[Lazy_Tiger]

много чего понаписал и ... стер

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


P.S. открытым остался вопрос что делать компании у которой юр. лицо одно, а филиалов (даже по городу) несколько. Реализовывать онлайн? Не всегда это возмжно. Я, как CIO , представляю себе затраты по такому проекту. Они сопоставимы со стоимостью лицензий на Axapta
P.P.S. Кстати, про сопоставления и накладные расходы... А кто сказал что сопоставление НЕЛЬЗЯ сделать программно при импорте? Тогда не нужно реплицировать RecId

[Андре]

Цитата:

да, серебрянной пули нет

Вот и я про то же

Цитата:

В основном организационные, а не технические

Именно !

Реализация репликации требует наличия некого выработанного порядка на проекте, стандартизованных процедур по решению проблем, возникающих в ходе эксплуатации.
Она не предусматривает того, что каждый день меняется функционал. Она не предусматривает того, что люди правят данные прямо в базе . Она не предусматривает того, что заказы/закупки и журналы сторнируются каждый день в массовом количестве
Может быть, стоит попробовать сделать репликацию, когда все остальные задачи на проекте уже решены. Тогда можно не спеша каждый день разгребать ошибки ночной репликации и принимать решение об их устранении.
Но не стоит начинать проект с репликаци.... .....есть вероятность, что репликацией все и закончится.

[Андре]

Цитата:

А кто сказал что сопоставление НЕЛЬЗЯ сделать программно при импорте? Тогда не нужно реплицировать RecId

Можно. Но тогда смотри описанный выше мною сценарий.

1) Есть филиал. В нем работает Аксапта. В нем провели сопоставление.
2) Есть центр. офис. В него филиал реплицировал данные. При импорте в центральном офисе все сопоставили заново.
3) После этого филиал вспоминает, что забыл про что-то. Он откатывает сопоставление, добавляет пару документов и сопоставляет заново.
4) Очередной сеанс репликации.

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

[George Nordic]

Попробую уточнить.

В общих чертах. Есть Основное Производство (ОП). Там сидят технологи (Ввод новой номенклатуры, конфигураций, спецификаций, операций, маршрутов, рабочих центров и т.п.), отдел закупок (склад, закупки, потребнось в материалах и т.п.), Плановый отдел (ввод производственных заказов) Фининсофый (расчет себестоимости изделий)... для простоты скажем, что руководство тоже там, т.е. необходима все отчетность. Для простоты будем считать, что бухгалтерской отчетности нет и финансовых проводок нет
Теперь запускается Удаленное Производство (УП)
1) Мы можем перенести работу технологов в ОП и запретить им там править маршруты етс. все будет вноситься в центральном офисе и перекачиваться им. Но на самом деле это не есть хорошо... Все-таки, потом они и сами должны начать работать... Вносить оперативные изменения.. И все это, разумеется, должно попадать обратно в ОП.
Таким образом, передаем ConfigTable, ConfigChoise, InventTable, InventDim, BOM, BOMTable, OptTable, RouteTable etc.. штук 40 таблиц.
2) Финансовый тоже можно задействовать в ОП, т.к. все основные таблицы для расчета с/с одинаковые.
3) Плановый отдел... Ну, они могут вносить только часть заказов. По-хорошему, УП само должно решать, что он и когда начинает. Т.е ввод производственных заказов, оценка, запуск - как из Основного, так и из Удаленного производств, приемка - только из удаленного. Ввод выработки - тоже только из удаленного. Делим ProdTable, ProdJournalTable.... etc.
4) Отдел закупок. У них - свой склад. Если ОП просто необходимо посмотреть наличие материалов в УП и еще пару отчетиков - то можно и OLAP прикрутить, разделить склады и не париться. А если перемещать со склада на склад? Очень неохота лезть в InventTrans сотоварищи...

Таким образом, есть часть таблиц, которые можно просто периодически (допустим, раз в день) принудительно заливать из Основного Производства в Удаленное (Номенклатура, Маршруты и т.п.), еще часть - которые можно просто загружать из Удаленного (тоже раз в день.. ввод выработки, например - не очень критично, когда центр её увидит), и часть таблиц, которые хотелось бы использовать более-менее одновремено. (Производственные заказы)

Вроде все, для начала...

[George Nordic]

Цитата:

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

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