Администрирование DICS. Часть 2. Как узнать, что объект пришел в другую систему и как его там найти

В предыдущем материале были рассмотрены объекты администрирования DICS. В этом будет дан ответ на самый распространенный вопрос пользователей администратору.

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

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

Итак, любому объекту системы, который отправляется через DICS, в момент отправки присваивается GUID. Этот GUID не изменяется и является сквозным для всех систем, участвующих в обмене.

Шаг 1. Определение GUID объекта. Для этого нужно получить данные из таблицы SCGlobalIDCorrespondence. В ней хранятся соответствия GUID и локальных идентификаторов  объектов. Получение GUID документа будет выглядеть следующим образом:

select GlobalID
from SCGlobalIDCorrespondence
where ComponentType = 1 and LocalID = 106694

Где 106694 – ИД документа в DIRECTUM. Если вернулась пустая строка, значит документ вообще не выходил из системы и надо искать причину. Если GUID найден, то нужно найти пакет, в котором передан этот объект

Шаг 2. Поиск пакета. Что в GUID хорошо, так это количество комбинаций, фактически обспечивающее его уникальность. Поэтому если найти пакет, в котором содержится GUID – это и есть то, что нам надо. Идем в папку Buffers агента и ищем файлы по маске *.xml с текстом, совпадающим с GUID. В итоге находим искомый пакет. Сразу скажу, что для нормального администрирования DICS возможностей Windows Explorer маловато (получится как игра в Doom на тачпаде), поэтому сразу обзаведитесь файловым менеджером. Теперь, если пакет находится в папке SentBuffer – значит все хорошо и он успешно передан на контроллер. Если же он в TransferBuffer – значит, в другой системе смотреть еще нечего – пакет на данный момент не передался. Пакет имеет свой GUID (в имени файла) – по нему его можно найти на контроллере и на других агентах. Если пакета нет ни в TransferBuffer, ни в SentBuffer, но он есть в CommunicationLog – это тоже значит, что пакет успешно передался. Про подробную маршрутизацию пакетов будет другой материал. При поиске пакетов надо смотреть на их время создания, т.к. один объект может быть отправлен несколько раз и поэтому входить в разные пакеты. Нам нужен тот, который по времени максимально совпадает с временем формирования задания удаленному пользователю. Если все равно пакетов находится несколько, то можно заглянуть внутрь и посмотреть что там – к какому конкретно заданию (с каким GUID) относится пакет.

Шаг 3. Поиск объекта в другой системе. Если объект когда-либо принимался в другую систему, то в этой системе он оставит свой след в таблице SCGlobalIDCorrespondence. Поэтому, зная GUID, мы легко сможем найти – чему он соответствует, открыть этот объект и получить всю интересующую пользователя информацию (например, у кого сейчас документ).

Важные уточнения

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

Во-первых, идентификация объектов по GUID заложена в архитектуре DICS по умолчанию, но ее можно изменить на прикладном уровне. Т.е. разработчик может настроить соответствие, скажем, записей справочников друг другу не по GUID, а по наименованию (или по любому другому признаку). В этом случае поиск пакета по GUID будет работать так же как описано, но вот GUIDы в разных системах для такого объекта могут быть разные.

Во-вторых, нужно понимать соответствие типов объектов в системе-приемнике и системе источнике.

Заключение

Как видно из вышеописанного, многие из шагов вполне автоматизируемы. Причем некоторые очень просто (например, можно добавить на карточку документа автоматически подгружаемый GUID или сделать кнопку для его получения). Архитектура управления пакетами DICS достаточно открыта для того, чтобы любые разработчики смогли написать свои менеджеры пакетов и прочие хорошие вещи, которые будут востребованы администраторами. Конечно, менеджер пакетов должен появиться рано или поздно в стандартной поставке DICS. Но вряд ли кто-то сейчас скажет когда точно это произойдет.