Правильно настроенная репликация довольно полезная штука, если Ваша система Service Desk 4.5 будет синхронизироваться в течение дня с кадровой системой, то можно успевать реагировать на изменение прав доступа. – Что парой бывает очень полезная вещь, если блокировка доступа может быть произведена автоматически. Как говориться тут уже будут другие проблемы.
Все ново испеченные пользователи, будут автоматически появляется в системе. Перечислять все плюсы не стану их очень много.
Проверенный и надежный способ репликации. «SQL + XML»

Давайте рассмотрим несколько ходов развития системы.

Но прежде чем мы начнем рассматривать развитие системы, давайте взглянем на текущую структуру Вашей системы. Скорее всего, у большинства из Вас используются штатные механизмы. То есть, как систему установили, так ее и эксплуатируете. Service Desk 4.5 можно довести до ума, при этом потребуется не так уж и много сил, главное знать, что Вы хотите увидеть на выходе.

Приступим: Первый, назовем его «Системное изменение», второй, назовем «Правила системы».

Системные изменения: меняем штатный механизм работы системы на тот, что необходим Вам. Сюда мы отнесем «Принцип работы правил. Изменение штатного функционала на нештатный».
Думаю, лучше привести пример: Скажем у Вас 12 app серверов, каждый из которых работает по своим направлениям, кто-то почту разбирает, кто-то с пользователями работает, web-приклад, агент-сервер и т.п. Главное, что их объединяет - это «scheduled tasks», у каждого сервера он свой. На самом деле, это плохо, обратите внимание: каждый сервер занимается свои делом, а тут выходит, что у них есть что-то общее. Изменив системную логику, можно отобрать у каждого сервера данный функционал и направить его на отдельный сервер, который будет работать только с этими объектами.

Вы спросите, зачем это нужно? Ситуация такова, допустим, в Вашей системе включена возможность групповой правки. И есть правила, которые каким-то действием генерируют scheduled tasks, но создание данного scheduled происходит на том сервере, на котором производили изменения. А теперь представьте себе ситуацию, что проверка данного события совпадет с максимальной нагрузкой на систему. Как правило, это утро, если взглянуть на схему изнутри, то можно представить, как плохо становиться серверу, которому нужно обрабатывать не только запросы специалистов, но еще и запросы Scheduled, исполняя при этом еще и правила системы. Т.е нагрузка увеличивается в два раза. Отсюда могут рождаться новые проблемы. Замедление или зависание приклада, повышенная нагрузка на базу данных, ошибки java. Казалось, одна мелочь, а может столько проблем создавать.

Читать подробнее...

Начнем с того, что у нас есть Active Directory и кадровая система постоянная на платформе SAP. Все это дело нужно скрестить с Service Desk 4.5.
Поделим все на этапы.

•Получение данных из SAP.
•Написание DTS пакета на SQL.
•Загрузка данных в SQL полученных из SAP «Средствами DTS».
•Выгрузка данных из Active Directory «Средствами DTS».
•Выгрузка данных из Active Directory с удалением двойников по ФИО «Средствами DTS».
•Выгрузка данных из Service Desk «Средствами DTS».
•Первичная загрузка данных в Service Desk.
•Финальная загрузка данных в Service Desk.

Теперь все по порядку.
Получение данных из SAP

Предположим, что данные из кадров мы можем получать только раз в сутки (Ночью), в определенном формате «Фалы TXT».

Описываем файл schema.ini

Читать подробнее...