Репликация таблиц двух приложений AX 2009

[rootx]

Здравствуйте! Вопрос к знатокам!

Имеется система в организации AX 2009, в ней все основные модули, плюс расчеты с персоналом, которые включают себя, кадровый учет, учет рабочего времени, штатное расписание и сама зарплата.

Руководство решило, вынести зарплату в отдельное приложение с отдельной базой. А все остальное: кадры, табеля, ШР, оставить в основной системе.

Теперь встает вопрос, для расчета ЗП нужны, данные по табелям, приказам, отпускам, больничным.

Какими средствами можно реплицировать данные из основной системы в в другую где только будут работать расчетчицы.
Есть таблицы которые должны будут синхронизироваться в обе стороны, это только видимо средствами самой аксапты нужно делать, разрабатывать импорт, и запуск его через пакетник..
А по таблицам, которые только в одну сторону, можно ли как то настроить синхронизацию, средствами самого SQL сервера?

[sukhanchik]

Добрый день!
Короткий ответ: Простых средств реплицирования данных нет.
Средствами репликации SQL Server добиться чего-то можно, но 2 разных независимых канала передачи данных гарантированно дадут рассинхронизацию и возможную несогласованность в данных. Скажется ли она на системе или нет - это уже другой вопрос, но дополнительных проблем добавит.

Если более подробно - то при неограниченном времени и бюджете возможно сделать всё.
Здесь придётся описывать и продумывать. Думаю, что задача где-то не меньше, чем на 3-4 человеко-месяца (был аналогичный опыт. Пока всё описал - руководство приняло решение свернуть задачу, т.к. из долгого описания следует долгая разработка и не менее долгое тестирование. Плюс чем сложнее задача - тем сложнее последующая поддержка. После того, как это сложили и перевели в деньги - руководство сказало "ну нах").

[TasmanianDevil]

Цитата:

Сообщение от rootx

Руководство решило вынести зарплату в отдельное приложение с отдельной базой.

Смысл?

[oip]

Когда-то у нас на одном из проектов тоже было две Аксапты, во второую из которых был вынесенен один относительно независимый модуль. Связь между системами была односторонняя, на уровне десятка справочников. Реализованное решение - во втором приложении в АОТе эти справочники являются обычными таблицами, а на уровне SQL вместо этого они подменены вьюшами, "смотрящими" на первое приложение. Справочники на втором приложении read only, селектам все равно откуда селектить, все работает уже больше десятка лет. Есть, разумеется, небольшие нюансы с синхронизацией БД на этом приложении, но и все.

[mazzy]

Цитата:

Сообщение от rootx

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

репликация - это слишком требовательный термин.

можно ли свести к загрузке данных из другой Аксапты?
можно ли двухстороннюю репликацию свести к загрузке некоторых таблиц в одну сторону, а некоторых - в другую?

если да, то загружайте из другой базы при помощи штатного Statement+ResultSet
(или расширенного https://github.com/mazzy-ax/SysResultSet)

или (если сильны в администрировании SQL) попробуйте:

Цитата:

Сообщение от oip

Реализованное решение - во втором приложении в АОТе эти справочники являются обычными таблицами, а на уровне SQL вместо этого они подменены вьюшами, "смотрящими" на первое приложение. Справочники на втором приложении read only, селектам все равно откуда селектить, все работает уже больше десятка лет. Есть, разумеется, небольшие нюансы с синхронизацией БД на этом приложении, но и все.

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

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

[trud]

Цитата:

Сообщение от sukhanchik

Здесь придётся описывать и продумывать. Думаю, что задача где-то не меньше, чем на 3-4 человеко-месяца (был аналогичный опыт. Пока всё описал - руководство приняло решение свернуть задачу, т.к. из долгого описания следует долгая разработка и не менее долгое тестирование. Плюс чем сложнее задача - тем сложнее последующая поддержка. После того, как это сложили и перевели в деньги - руководство сказало "ну нах").

Кстати тут еще стоит учесть изменение стоимости лицензий(если все делать правильно ). Т.е. на фоне стоимости лицензий для АХ, SQL 3-4 месяца работы это довольно маленький процент

[rootx]

Цитата:

Сообщение от TasmanianDevil

Смысл?

Смысл сего действия понятен только руководству видимо.

[rootx]

Спасибо, за мысли, идеи. Стало примерно понятно, что нужно делать.

[sukhanchik]

Цитата:

Сообщение от rootx

Смысл сего действия понятен только руководству видимо.

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

Цитата:

Сообщение от trud

Т.е. на фоне стоимости лицензий для АХ, SQL 3-4 месяца работы это довольно маленький процент

Обычно об этом не задумываются, когда мысли рождаются из идеи безопасности ("мягкое место" жжёт в другом месте)

Просто когда до руководства доходит цена такого решения - то приходит понимание, что "овчинка" не стоит "выделки"

[rootx]

Цитата:

Сообщение от sukhanchik

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

Обычно об этом не задумываются, когда мысли рождаются из идеи безопасности ("мягкое место" жжёт в другом месте)

Просто когда до руководства доходит цена такого решения - то приходит понимание, что "овчинка" не стоит "выделки"

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

[rootx]

Такой еще вопрос возник при репликации средствами самого MS SQL сервера, на таблицах обаятельно должен быть первичный ключ.

Если поставить первичным ключем recid например через сервер, то после синхронизации таблицы в аоте он слетает.

Можно ли как-то поставить его через саму аксапту?

[George Nordic]

Цитата:

Сообщение от mazzy

если жеж нужна именно репликация,

Если нужна репликация, то гуглите Change Data Capture.

Так получилось, что сейчас в частности, я и CDC занимают. Но это - очень дорогие решения. Да, есть и 2х сторонняя репликация.
Вопрос, имеет ли смысл из пушки по SQL?

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

[rootx]

Цитата:

Сообщение от rootx

Такой еще вопрос возник при репликации средствами самого MS SQL сервера, на таблицах обаятельно должен быть первичный ключ.

Если поставить первичным ключем recid например через сервер, то после синхронизации таблицы в аоте он слетает.

Можно ли как-то поставить его через саму аксапту?

Нашел все делается через свойство таблицы, такие как ClusterIndex, PrimaryIndex, CreateRecIdIndex

[vmoskalenko]

Не делайте РЕПЛИКАЦИЮ таблиц. Делайте ИНТЕГРАЦИЮ двух систем!