Партнерка на США и Канаду по недвижимости, выплаты в крипто
- 30% recurring commission
- Выплаты в USDT
- Вывод каждую неделю
- Комиссия до 5 лет за каждого referral
Глобальный ID должен быть и на получателе и на отправителе одинаковым (так же как другие настройки комплекса).
Глобальный ID должен быть уникален в рамках одной системы (это значит, что он должен быть уникален в системе АСФК в целом, т. е. больше ни в одном СУФД не должно быть такого же комплекса).
В данном примере Глобальный ID записывается в виде подчиненности организаций к вышестоящим с указанием наименования организаций:
Пример:
ЦАФК –9500 - вышестоящая организация для УФК
УФК – 9500.4800 – домашняя организация
Поле «Локальный ID»
В поле указывается наименование самой организации без подчиненности к вышестоящей организации (т. е. Локальный ID это окончание Глобального ID без указания всей ветки подчинения):
Пример:
ЦАФК – 9500
УФК – 4800
Поле «Наименование»
В поле указывается наименование, которое может выступать наименованием самой организации (если она одна в комплексе) или наименование оперзала, в котором эти организации обслуживаются, или как в примере заполнения Глобального ID (желательно писать такое же как в ГлобалИД)
Пример:
ЦАФК – 9500
УФК – 9500.4800
Внимание! Стоит придерживаться вышеописанных рекомендаций по настройкам, т. к. в выгруженных пакетах идет описание комплекса с которого пакет вышел и описание комплекса на который пакет пришел. В случае отличия значения этих полей даже на один символ, пакет не будет принят принимающей стороной (перейдет на ошибочный статус).
Поле «Описание».
В этом поле дается описание комплекса. Поле может не заполняться или заполняться произвольным текстом.
В поле «Описание» можно записать Глобальный ID, можно написать наименование организации. Если она единственная для этого настраиваемого комплекса, можно наименование оперзала.
Пример:
ЦАФК – CAFK9500
Поле «Активный адрес».
В этом поле указывается транспортный адрес, который система использует для осуществления транспортного обмена. Для привязки адреса к создаваемому комплексу необходимо:
1. Сначала сохранить комплекс.
2. Затем перейти по пути «Транспорт - Транспортные адреса» и создать там адрес. Возможно после этого, для появления в выпадающем списке нового адреса привязанному к этому комплексу, понадобится перезапуск сервера (или достаточно будет только перезапуска самого администратора).
Поле «Родительский комплекс».
Родительский комплекс – это комплекс, который является для настраиваемого комплекса – вышестоящей организацией (в которой он обслуживается).
Для заполнения поля «Родительский комплекс» необходимо нажать на кнопку 
, расположенную справа от поля, и из появившегося выпадающего списка уже созданных комплексов, выбрать родительский (см. рисунок).
Пример:
Для ЦАФК – нет
Для УФК – ЦАФК
Для ОФК – УФК
ПБС/РБС – ОФК или УФК (в зависимости, где обслуживается)
Пункт «Домашний комплекс».
Домашний комплекс - комплекс (узел) обслуживающий данного клиента (организацию), который при транспортных операциях является отправителем для настраиваемого стенда.
Список «Рядом расположенные комплексы».
Список заполняется в том случае, если у данного комплекса имеется еще и секретный комплекс. Или если настраивается секретный комплекс, тогда рядом расположенным выбирается открытый комплекс. Для добавления комплекса нужно выбрать его из списка, который вызывается нажатием на кнопку 
, и затем нажать кнопку «Добавить»(комплекс должен быть создан до его выбора из списка).
Пример:
У УФК есть закрытый контур и открытый. Настройки открытого контура:
У открытого УФК есть вышестоящий ЦАФК(9500) как показано на рисунке и так же присоединен закрытый контур своего УФК(9500s.6000s).
В свою очередь, настройки закрытого УФК строятся по тому же принципу. Вышестоящим будет ЦАФК закрытого контура, радом расположенный – УФК открытый.
Список «Организаций».
При заполнении списка выбирается сама организация. Для добавления организации к комплексу нужно сохранить комплекс, затем перейти в «Администрирование – Управление клиентами – Организации» и как показано на рисунке. Открыть организацию на редактирование, определить нужный комплекс. После чего нажать кнопку «Сохранить» 
, организация будет привязана к комплексу.
Перечень организаций комплекса можно увидеть на вкладке «Организации» в разделе «Администрирование – Транспорт – Транспортные комплексы»:
Настройка транспортных адресов
Каждый транспортный комплекс имеет набор транспортных адресов и один адрес из данного набора является текущим активным адресом.
По активному адресу производится отправка документов, а прием может осуществляться по остальным адресам настраиваемого комплекса. (При получении данных, текущий комплекс проверяет все свои адреса, а при отправке – отправляет на указанный активный адрес получателя).
Для доступа к настройкам транспортных адресов необходимо в СУФД перейти по следующему пути «Администрирование – Транспорт – Транспортные адреса» (см. рисунок).
Для добавления нового транспортного адреса требуется выполнить следующую последовательность действий:
1. На панели инструментов нажать кнопку «Добавить» 
. После этого в нижней части окна появятся поля для заполнения параметров создаваемого комплекса (см. рисунок).
Поле «Комплекс».
Для заполнения этого поля необходимо нажать на кнопку , расположенную справа от поля и выбрать из появившегося списка нужный комплекс
Поле «Указатель».
В поле «Указатель» требуется прописать адрес папки, через которую будет осуществляться транспорт между комплексами. Адрес указывается с использованием одного из трех шлюзов:
a) file://
b) ftp://
c) http://
a.В случае использования шлюза file:// необходимо для работы транспорта по сети сделать директорию транспорта доступной в сети для чтения, записи и удаления из нее файлов. На получателе привязать ее как сетевой диск и в адресе указывать его.
Примеры адресов:
file://D:/folder
file://./folder
file:///folder
file:///folder1/folder2
Адрес file:// указывается с учетом общей папки транспорта для всего АСФК и указанием конкретной директории для пакетов каждого комплекса.
Например:
file://D:/Transport/ Общей директорией здесь является Transport. В ней СУФД сам создаст директории для конкретного комплекса, из Глобал ID комплекса к которому будет привязан данный адрес. В нашем случае для УФК (9500.4800) адресе file://D:/Transport/была бы создана директория 9500.4800, в которой бы складывались пакеты УФК.
b.В случае использовании FTP необходимо определить машину на которой будет развернут и настроен FTP-сервер с соответствующим размером выделенной под документооборот памяти физической и оперативной. Примеры FTP адреса:
ftp://user:password@host:port/folder1/folder2
В указанном нами примере для УФК адрес используется ftp://test:[email protected], далее используется тот же принцип для директории конкретного комплекса, формировавшегося из Глобал ID.
c.Для создания протокола http:// достаточно на машине конкретного домашнего комплекса зарезервировать порт для обмена указав его в адресе домашнего комплекса с указанием хост(или IP) данной машины. Примером может служить вышестоящая организация для нашего УФК – это ЦАФК(9500) у которого адрес установлен http://172.17.1.39:18881 – где IP=172.17.1.39 это адрес машины на которой стоит СУФД ЦАФК, а 18881 это свободный порт, зарезервированный СУФДом при запуске сервера для обмена пакетами. Разделение пакетов так же проходит по Глобал IP
Внимание! Необходимо после внесения всех транспортных настроек, перезапустить СУФД.
Транспортная Карта.
С помощью СУФД документы могут ходить не только в свой вышестоящий и обратно, но так же предусмотрено хождение документов из одно АРМ в другой в независимости от его местонахождения и подчиненности ФК. Для пересылки документов, таким образом, получателю и отправителю необходимо знать только лишь транспортные данные комплекса получателя. В стандартной ситуации ОФК всегда будет являться транзитным комплексом, через которого документы будут пересылаться в OeBS УФК. Такой пример изображен на рисунке ниже:
В данном примере РБС отсылает документ в УФК. Таким образом, ему необходимо знать настройки: ОФК через которого пойдет документ, вышестоящий комплекс для этого ОФК, конечного получателя (в данном случае комплекс вышестоящий для ОФК и комплекс конечный получатель документа – один и тот же), и должен знать вышестоящего для комплекса конечного получателя. Т. е должна быть известна транспортная карта комплексов которые пересечет документ и все вышестоящие этих комплексов. Тоже самое в обратном порядке:
УФК для того что бы отослать ответ о получении и обработке документа в РБС должен знать конечного получателя, вышестоящего для конечного получателя. В результате как изображено на рисунке ниже, получается, что УФК будет знать обо всех своих ОФК, и обо всех АРМах имеющимся в подчинении как у себя так и у своих ОФК. И должен знать о своем вышестоящем – ЦАФК.
Заполнением транспортных карт занимается АП Параметров маршрутизации.
Мониторинг транспортных и документарных очередей
Для просмотра входящих исходящих документов в очереди документов используется «Монитор и транспортной документарной очереди». Для того, чтобы им воспользоваться необходимо зайти в пункт меню «Администрирование - Монитор транспортной очереди – Документарная очередь».
Для просмотра входящих исходящих пакетов в очереди пакетов используется «Монитор транспортной пакетоной очереди». Для того, чтобы им воспользоваться необходимо зайти в пункт меню «Администрирование - Монитор транспортной очереди – Пакетная очередь».
В вышеуказанных мониторах можно просматривать очереди, время отправки/получения документа/пакета, его статус. Существует возможность Скачать объект или Обработать его повторно:
Описанные мониторы позволяют искать/фильтровать пакеты и документы по интересующим критериям. Позволяют искать документы по гуидам и времени отправки/приема, и т. д
Настройка «Справочника связок для ОрФК»
Для работы транспорта так же используется настройки в «Справочнике связок для ОрФК», в котором записываются транспортные адреса (транспортная маска) для каждой организации.
Для настройки необходимо запустить ДТВ по ссылке вида:
http://<host name/ip>:<X>8080/docapp-3/ app. jnlp
(например: http://l3.ru. :28080/docapp-3/app. jnlp).
Или по ссылке тонкого клиента вида http://<host name/ip>:<X>8080 например: http://l3.ru. :28080).
В «Справочники / Справочник связок для ОрФК» настройки должны быть соответственны настройкам Комплекса, т. е. все организации, участвующие в транспортном обмене, должны быть приписаны в справочнике.
Поле «Организация» заполняется путем выбора по кнопке из справочника органций.
В списке «Роль организации» указывается роль, которая предназначается для организации выбранной выше.
Поля «Наименование» будут подтягиваться, в случае если вводимые коды организаций есть в справочнике Органов ФК.
В поле адреса указывается маска данной организации, в соответствии ее подчиненности вышестоящим ТОФК и уровню секретности.
Список «Признак контура» определяет контур, к которому относится организация.
Список «Программа» определяет к какому типу относится организация:
· Программный сегмент "S" – Тип СУФД
· Программный сегмент "E" – Тип OeBS
· Программный сегмент "С" – тип СЭД
· Программный сегмент "*" – все типы
Справочник связок должен строиться по тому же принципу, что и транспортная карта, т. е. все организации, через которые пакет у будет проходить, а так же их вышестоящие.
Пример заполненного справочника:
Различные виды транспортных адресов их значение и структура описаны в «Приложение 1. Формат транспортного адреса».
Справочник может заполняться вручную, но также может заполняться при помощи «АП заполнения параметров маршрутизации».
В ранних версиях 5-го ядра (5.0, 5.1) пересылка документов в ОЕБС выполнялась через транспорт при помощи системной организации с systemName = «OEBS».
Данная организация добавлялась в БД автоматически при старте сервера СУФД. Начиная с версии ядра 5.2 созданием данной организации и остальных ее параметров маршрутизации занимается АП заполнения параметров маршрутизации. АП добавляет системную организацию с systemName = 9500.6000...N. UFK-OEBS. Связывает ее с адресной маской, которая имеет программный сегмент = "E" (например, 9500.6000...N. E). Также АП привязывает системную организацию 9500.6000...N. UFK-OEBS к комплексу с globalID = "OEBS".
Чтобы при обновлении СУФД в регионах не поломать выгрузку документов в ОЕБС нужно выполнить АП заполнения параметров маршрутизации. АП должна быть запущена со следующими параметрами:
CLEAR_DICT = AUTOPROC
DIGEST = указать значение по умолчанию для создаваемых транспортных адресов
TYPE_OFK = допустимые значения данного параметра ON-LINE и OFF-LINE. Если будет указано значение:
· ON-LINE – при запуске на УФК, будут создаваться записи для ОФК СЭД
· OFF-LINE – при запуске на УФК, будут создаваться записи для ОФК СУФД
После выполнения АП маршрутизации необходимо проверить следующие настройки справочника связок:
1. Адресные маски УБП, ОФК и рядом расположенных УФК должны иметь только программный сегмент = «*».
2. При заполнении параметров маршрутизации на уровне УФК для домашней организации УФК создаются только 3 адресные маски:
a. адресная маска с программным сегментом "S"
b. адресная маска с программным сегментом "E"
c. адресная маска с программным сегментом "С"
Для текущего УФКа не должно быть адресной маски с программным сегментом «*». Если после отработки АП Маршрутизации в спр. Связок все-таки была найдена запись для текущего УФК с программным сегментом «*», то необходимо удалить ее вручную.
3. На уровне УФК для ЦАФК создаются только 2 адресные маски:
a. с программным сегментом "С" - ЦАФК СЭД
b. с программным сегментом "S" - ЦАФК Технологический
Для ЦАФКа не должно быть адресной маски с программным сегментом «*».
Например, для текущей организации УФК 6000 в открытом контуре в справочнике связок будет присутствовать 3 маски:
1. 9500.6000...N. E привязана к системной организации 9500.6000..--.N. UFK-OEBS
2. 9500.6000...N. S привязана к системной организации 9500.6000..--.N. UFK
3. 9500.6000...N. C привязана к системной организации 9500.6000..--.N. UFK-SED
Для текущей организации УФК в закрытом контуре ситуация аналогичная
1. 9500.6000...S. E привязана к системной организации 9500.6000..--.S. UFK-OEBS
2. 9500.6000...S. S привязана к системной организации 9500.6000..--.S. UFK
3. 9500.6000...S. C привязана к системной организации 9500.6000..--.S. UFK-SED
Таким образом, справочник связок должен содержать следующие адреса:
· Уровень ЦАФК
o Организации ЦАФК (домашняя) ставится программный сегмент «S», «E», «C»
o Всем остальным организациям ставится программный сегмент «*»
· Уровень УФК
o Организации УФК (домашняя) ставится программный сегмент «S», «E», «C»
o Организации ЦАФК (родительская) ставится программный сегмент «S», «C»
o Всем остальным организациям ставится программный сегмент «*»
· Уровень ОФК
o Организации ОФК (домашняя) ставится программный сегмент «S», «C»
o Всем остальным организациям ставится программный сегмент «*»
· Уровень ДУБП
o Всем организациям ставится программный сегмент «*»
Настройка системных констант
Теперь в рамках одного комплекса один и тот же пользователь сможет работать с правами разного уровня (например, ПБС и ОФК). Существует несколько уровней констант.
Типы констант - Задается имя константы и ее значение, которое будет по умолчанию.
Константы организации – задаются значения констант, уникальные только для конкретной организации, а не комплекса в целом и перекрывают типы констант, название которых совпадает с названием констант организации. Организация задается для пользователя. Если пользователь ассоциирован с несколькими организациями, то при создании документа ему предлагается выбрать организацию, в рамках которой создается документ. В момент выбора организации список системных констант будет перезагружен для выбранной организации.
Примечание:
Таким образом, сначала загружаются Типовые константы. Если определены константы для организаций, то они перезатирают типовые константы.
Пример.
АРМ одновременно является ПБС, РБС, ТОАП, ФО и ОФК, поэтому у него есть документы как уровня ПБС, так и уровня ТОАП, и уровня ОФК, и т. д. Есть сотрудник, который одновременно может работать с документами ПБС, ТОАП, РБС, ФО и ОФК.
Уровень ПБС определен в Типовых константах (см. Рисунок ниже). Для остальных организаций необходимо константы переопределить.
Эти константы будут использоваться в том случае, если их значения не указаны в Константах организации.
Далее необходимо открыть «Системные константы / Системные константы организации» для настройки констант других организаций, которые отличаются от базовой.
Необходимо нажать кнопку 
(1), выбрать тип константы (2), далее ввести ее новое значение, и, наконец, выбрать организацию (3).
В итоге получаем следующий список:
РБС имеет тереториальный орган, бюджет и главу аналогичные базовому ПБС, поэтому ему необходимо переопределить константы «Текущий уровня» и «Код Собственного БУ» (см. рисунок выше – организация ta12u).
ТОАП имеет тереториальный орган и бюджет аналогичные базовому ПБС, а глава у него отличается. Поэтому ему надо переопределить константы «Код ППП», «Текущий уровня» и «Код Собственного БУ» (см. рисунок выше – организация ta13u).
Финансовый орган имеет тереториальный орган аналогичный базовому ПБС, а Глава, бюджет, код БУ у него отличны, поэтому ему надо переопределить константы «Код бюджета», «Код ППП», «Текущий уровня» и «Код Собственного БУ» (см. рисунок выше – организация ta14u). И т. д.
При запуске документарной точки входа, в зависимости от того какой CurrentLevel (текущий уровень) подтянется при входе в систему, меню документарной точки входя будет различным. Т. е. будет соответствовать списку только тех документов которые создаются (принимаются) для того или иного уровня (например, у ЦАФК и УФК в ДТВ не будет документов вообще, или невозможно будет их создать в связи с тем что документы приходят к ним для бизнес обработки, т. е. для обработки в OeBS или передачи как транзита).
В Документарной точке входа доступен список организаций, с которыми может работать пользователь. При выборе организации переформируется дерево навигации.
Константа UserRole (по умолчанию = User). Необходима для справочника "Шаблоны назначений". Возможные значения : Admin, User – константа позволяет под admin редактировать записи справочника, кроме системных.
Консатнта «Признак секретности» SecurityLevel использует 2 значения: N - не секретная организация, S-секретная организация.
Формат РУБП может быть следующий для всех организаций: (x - буква, y - цифра)
Примеры:
1. хуууу
2. ххууу
3. хххуу
4. хххху
5. ххххх
6. ухууу
7. уххуу
8. уххху
9. ухххх
10. уухуу
11. уууху
12. уууух
13. ухуху
14. хухух
15. уухху
16. ххуух
17. хууух
18. уххху
19. ххуух
20. уухху
21. уххуу
22. хуухх
Внимание! При определении адреса получателя, и при создании документов, Системные константы играют первостепенную роль. Следовательно, ошибка в их настройке грозит неверной работой транспорта.
Полный перечень системных констант с их описанием и областью применимости приведен в разделе «Приложение 6. Перечень используемых системных констант»
Синхронизация OeBS и СУФД
Изменение синонима и исправление ошибок
Необходимо проверить, что синоним TB_MESSAGE в схеме APPS, настроен на таблицу TB_MESSAGE схемы SUFD2, чтобы выгрузка осуществлялась именно в таблицу схемы SUFD2 (Только для СУФД уровня ЦАФК и УФК).
Ниже приведён пример схемы размещения компонент, при которой необходимо изменение синонима.
Примечание:
Перед развертыванием БД требуется проследить за тем, чтобы параметр NLS_LANG клиента Oracle соответствовал кодировке файлов со скриптами создания БД.
Т. к. стандартно в поставке идут скрипты в кодировке Win1251, то параметр NLS_LANG должен быть равен RUSSIAN_RUSSIA. CL8MSWIN1251.
В ОС Windows параметр находится в ветке реестра "HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\<соответствующий раздел Oracle home>".
Его так же можно задать командой cmd-оболочки SET NLS_LANG=RUSSIAN_RUSSIA. CL8MSWIN1251.
В Unix системах параметр задается командой shell-оболочки setenv NLS_LANG RUSSIAN_RUSSIA. CL8MSWIN1251.
Данные параметры не важны для нормального функционирования БД, а имеют значение только на этапе развертывания.
В данном разделе будет рассмотрена выгрузка справочника ведомств из подсистемы OEBS и загрузка данного справочника в СУФД.
Обмен данными между системами OeBS и СУФД осуществляется через таблицу TB_MESSAGE и TB_MESSAGE_BIG_ATTRIBUTES. В каждой схеме СУФД присутствует таблица TB_MESSAGE и TB_MESSAGE_BIG_ATTRIBUTES, однако используются именно те которые находятся в OeBS.
Для рассматриваемого нами примера SQL инструкция синонима будет иметь следующий вид:
-- Create the synonym
create or replace synonym APPS. TB_MESSAGE
for SUFD2.TB_MESSAGE;
В случае не установки значения по умолчанию, при выгрузке данных из OEBS в схему СУФД возможны следующие ошибки:
Непредвиденная ошибка программного кода XXT_BS_XBR_SUFD. SET_OUTBOUND_XML
Причина: ORA-22275: задан неверный указатель LOB
ORA-06512: на "SYS. DBMS_LOB", line 533
ORA-06512: на "APPS. XXT_BS_XBR_SUFD", line 434
ORA-20001: Непредвиденная ошибка программного кода XXT_BS_XBR_SUFD. transport
Причина: Непредвиденная ошибка программного кода XXT_BS_XBR_SUFD. set_xml_to_sufd
…
После выполнения данных действий, OEBS будет настроен на взаимодействие с нужной базой СУФД.
Настройка связи с backoffice (взяаимодействие СУФД – OeBS)
В файл конфигурации СУФД, в …/STAND/etc/ backOffice.xml внести изменения Данная настройка необходима только для ЦАФК и УФК поскольку только в них происходит обработка бизнес-данных.
Обмен данными между OeBS и СУФД происходит в виде XML файлов через таблицу TB_MESSAGE и TB_MESSAGE_BIG_ATTRIBUTES находящуюся в OeBS. (Пример части XML и описание адрреса см. в Приложение 1. Формат транспортного адреса).
В случае копирования стенда из другого, т. е без установки инсталлятором, необходимо для настроек связи с OeBS зайти в STAND/etc/backOffice.xml и внести соответствующие поправки в обзац #Backoffice database. Подробное описание настройки переменных sufd. properties см. в разделе «Настройка конфигурационных файлов.»
Пример взаимодействия с OeBS см. в Приложение 3. Выгрузка данных из OEBS в СУФД.
После заведения организации, привязки к ней домашнего транспортного комплекса, определения активного транспортного адреса, настройки системных констант и заполнения Справочника связок для ОрФК (в части домашней организации), необходимо выгрузить из OeBS для СУФД следующие справочники:
· Справочник ведомств
· Реестр участников бюджетного процесса
· Справочник бюджетов
· Справочник лицевых счетов
· Справочник статусов документов
Теперь для заполнения справочника организаций, транспортных комплексов, адресов и справочника связок для ОрФК необходимо запустить автопроцедуру “Автопроцедура заполнения параметров маршрутизации” (Подробное описание см. в разделах «Приложение 5. Перечень используемых авто-процедур» и «Настройка «Справочника связок для ОрФК»»).
Настройка репликаций
Репликация – пересылка справочной информации от вышестоящего к нижестоящему комплексу.
Настройка проходит в администраторе СУФД «Администрирование комплекса – Репликация».
Фиксация изменений:
Изменения фиксируются с помощью сквозной нумерации по всем записям всех справочников (аналог Generation) – в поле LocalRplVersion таблицы DICT. Таблица DICT_LOG отныне не используется.
Объектная модель:
Основные таблицы настройки:
· RPL_OBJECT – репликационные объекты
· RPL_SUBSCRIPTION – подписки на репликацию
· RPL_RECEIVER – получатели репликации
· RPL_SENT_OBJECT – данные об отправленных объектах
Связочные таблицы:
· RPL_RECEIVER_SUBSCRIPTION – привязка подписок на репликацию к получателям
· RPL_SUBSCRIPTION_OBJECT – привязка репликационных объектов к подпискам
Настройка репликации:
Настройка репликаций на отправителе:
1. Зарегистрировать репликационные объекты. Указывается наименование (это имя в дальнейшем используется в настройке подписок) и выбирается справочник из перечня справочников.
2. Зарегистрировать подписки на репликацию и привязать к ней репликационные объекты. Создается подписка, указывается наименование (это имя используется в дальнейшем в настройке получателей) и признак активности.
Далее осуществляется подкрепление к подписке новых репликационных обхектов (созданный в пункте «Репликационные объекты»)
3. Зарегистрировать получателей и привязать к ним подписки. После того, как созданы подписки их надо привязать к получателям. Создается получатель (выбирается из списка комплексов):
К получателю привязываются подписки, созданные на предыдущих шагах:
4. Зарегистрировать автопроцедуру «Рассылка репликационных пакетов». Данная АП не имеет параметров и просто добавляется в расписание
Настройка репликаций на получателе:
1. Зарегистрировать автопроцедуру «Обработка репликационных пакетов». Данная АП не имеет параметров и просто добавляется в расписание
Алгоритмы отправки и обработки репликации:
Отправка:
Автопроцедура отправки выбирает всех активных получателей и их активные объекты из активных подписок и по очереди обрабатывает. Обработка заключается в следующем: для репликационного объекта строится запрос, включающий условие LocalRplVersion > :MaxVersion, где MaxVersion – значение поля LocalRplVersion из таблицы RPL_SENT_OBJECT с соответствующим комплексом-получателем и типом справочника. Записи, попадающие под условия запроса, отдаются процедуре формирования репликационных пакетов (в этом качестве используется существующий документ типа DocSysRpl) пачками по 20 записей. Эти записи сериализуются в единый XML и кладутся вложением в репликационный пакет. После этого в таблице RPL_SENT_OBJECT сохраняется новое значение LocalRplVersion для соответствующего получателя-справочника.
Загрузка отправляемых по репликации записей справочников, формирование репликационного пакета и фиксация версии отправленных объектов в таблице RPL_SENT_OBJECT делается в отдельной транзакции, поэтому :
- в случае ошибок пакетирования не будет проблем с некорректной фиксацией отправленной версии
- не будет проблем с памятью, т. к. отправляемые записи загружаются порциями.
Принятие:
Автопроцедура принятия выбирает все репликационные пакеты (документы DocSysRpl), находящиеся на статусе 10. Вложения распаковываются в список записей справочников. Далее идёт проверка, есть ли запись с соответствующим GUID в БД получателя. Если нет, запись вставляется. Если есть, сравниваются значения поля OuterRplVersion существующей записи и поля LocalRplVersion записи, пришедшей по репликации. Если OuterRplVersion в существующей записи больше или равна чем LocalRplVersion в пришедшей, то пришедшая игнорируется (т. к. предполагается, что более свежее репликационное изменение пришло раньше). В противном случае пришедшая запись сохраняется, обновляя существующую. В случае успешной обработки вложений репликационному документу выставляется статус 28, в случае ошибки статус 36.
Для обработки ситуации, когда источником репликации являются более одного комплекса, в таблицу Dict было введено поле OuterRplComplexId. Это поле хранит id комплекса, с которого была получена по репликации эта запись. Нужно оно в дальнейшем в следующей ситуации: когда запись пришла с одного комплекса, а потом пришла с другого, принимать решение о том, какая запись новее – существующая или пришедшая, на основании OuterRplVersion некорректно. В таких случаях будет делаться вызов в прикладной код, который и будет принимать это решение. Пока поле OuterRplComplexId заполняется, но не используется.
Отличия от старого механизма репликации:
1. Проще настраивать.
- нет необходимости указывать GUID подписки на отправителе и получателе
- настройка на получателе – только включить АП
2. Данные об отправленных репликационных записях хранятся в разрезе получатель – репликационный объект, что избавляет от проблемы, когда в существующую подписку добавляется новый справочник и не идёт по репликации, т. к. generation его записей меньше чем зафиксированный для этой подписки
3. Потеря одного репликационного документа не затыкает обработку всей очереди
4. Гораздо быстрее работает
Выгрузка справочников из BackOffice (OeBS)
Для возможности выгрузки справочников из OeBS необходимо обладать полномочиями «АСФК: Администрирование справочников».
Далее необходимо выбрать интересующий справочник на WEB-странице. Откроется форма справочника.
В случае, если необходимо выгрузить отдельные записи справочника. На форме справочника необходимо отметить записи, которые будут выгружаться. Далее нажать кнопку «Выполнить». В появившемся списке выбрать действие «Выгрузка текущей строки … в СУФД».
В случае, если необходимо выгрузить справочник целиком. На форме справочника необходимо отметить одну (любую) запись. Далее нажать кнопку «Выполнить». В появившемся списке выбрать действие «Выгрузка всех данных текущего справочника/ассоциатора СУФД».
Выгружать в СУФД имеет смысл только Актуальные записи (записи со статусом 801). Для отбора актуальных записей необходимо нажать «F11», далее в поле статус ввести «801», и завершить выбор записей сочетанием «CTRL+F11». Можно в данном запросе при необходимостиыыы использовать и другие критерии отбора.
Синхронизация OeBS и СУФД
Изменение синонима и исправление ошибок
Необходимо проверить, что синоним TB_MESSAGE в схеме APPS, настроен на таблицу TB_MESSAGE схемы SUFD2, чтобы выгрузка осуществлялась именно в таблицу схемы SUFD2.
Ниже приведён пример схемы размещения компонент, при которой необходимо изменение синонима.
Примечание:
Перед развертыванием БД требуется проследить за тем, чтобы параметр NLS_LANG клиента Oracle соответствовал кодировке файлов со скриптами создания БД.
Т. к. стандартно в поставке идут скрипты в кодировке Win1251, то параметр NLS_LANG должен быть равен RUSSIAN_RUSSIA. CL8MSWIN1251.
В ОС Windows параметр находится в ветке реестра "HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\<соответствующий раздел Oracle home>".
Его так же можно задать командой cmd-оболочки SET NLS_LANG=RUSSIAN_RUSSIA. CL8MSWIN1251.
В Unix системах параметр задается командой shell-оболочки setenv NLS_LANG RUSSIAN_RUSSIA. CL8MSWIN1251.
Данные параметры не важны для нормального функционирования БД, а имеют значение только на этапе развертывания.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 |
Проекты по теме:
Основные порталы (построено редакторами)