Вход | Регистрация



Как присвоить номер сообщения изменениям в плане обмена без записи файла?

Как присвоить номер сообщения изменениям в плане обмена без записи файла?
Я
   toypaul
 
20.09.18 - 14:20
Есть план обмена, который нужен только для регистрации.

Задача. Выбрать изменения, присвоить им новый номер (скажем 1), выгрузить эти изменения (в файл), очистить изменения.

Как это можно сделать без использования ЗаписьСообщенияОбмена?
 
 
   Фрэнки
 
1 - 20.09.18 - 14:46
Странно... А для чего еще нужен план обмена, если сам по себе в нем больше ничего не происходит, а всего лишь только регистрация объектов?
   Фрэнки
 
2 - 20.09.18 - 14:47
т.е. в планах обмена в реальности ничего более нет - только регистрация
   Serg_1960
 
3 - 20.09.18 - 14:57
(0) Погугли когда именно номер присваивается зарегистрированным изменениям.
   Вафель
 
4 - 20.09.18 - 15:09
а почему бы просто не удалить регистрацию?
   toypaul
 
5 - 20.09.18 - 15:12
сделал без записи в файл. точнее нужно только НачатьЗапись и ВыбратьИзменения. Первое присваивает номер, второе этот номер проставляет всем пустыми записям. Дальше просто записывем пустой файл.

(3) именно это и нашел и Чистова
   toypaul
 
6 - 20.09.18 - 15:13
(4) просто удалить нельзя. надо сначала выбрать с присвоенными номером. именно с присвоенным. хотя по идее можно было бы просто взять все изменения в запросе ...

фиг его знает. так как-то кажется надежнее.
   timurhv
 
7 - 20.09.18 - 15:13
(1) Сторонняя программа\сервис забирает из базы измененные данные (например, кадровые документы).
Документы могут проводить задним числом в 1С, плюс нужны изменения записей в регистрах сведений.
   toypaul
 
8 - 20.09.18 - 15:14
(1) нужен только для регистрации. дальше формируется xml произвольного формата. изменения сразу удаляются. предлагал сделать регистр сведений, сказали делать ПО. ну ПО так ПО.
   Вафель
 
9 - 20.09.18 - 15:14
(7) проще удалять регистрацию по объектно
   Михаил Козлов
 
10 - 20.09.18 - 15:14
(6) Если нужно получить изменения, записать в файл и удалить, тогда зачем номер?
 
 Рекламное место пустует
   toypaul
 
11 - 20.09.18 - 15:19
мысль была такая что выгружаем изменения только на момент старта обработки. если в процессе появляются новые их не выгружаем.

чтобы затем удалить только то, что выгрузили по этому номеру.
   Фрэнки
 
12 - 20.09.18 - 15:20
(8) короче говоря, совершенно бесполезно рассчитывать, что номер регистрации в этой схеме сможет как-то адекватно работать. В регистрах сведений можешь сделать так, как тебе нужно. А вот на регистрации в планах обмена именно с учетом номера - будет все ломаться. Номера у записей регистрации в таблицах объектов платформа отслеживает очень ненадежно. Может это зависит от платформы, но... вообщем, я не советую такой подход
   Cyberhawk
 
13 - 20.09.18 - 15:20
(4) Даже если "изменения сразу удаляются" как в (8), то смысл в номере все равно есть, чтобы после окончания выгрузки объектов удалить регистрацию только по тем объектам, которые были выгружены (и не изменены за время выгрузки). По этому номеру это и определяется.
Т.к. за время выгрузки не только могли добавиться к обмену новые объекты (без номера), но и сам это объект мог перезаписаться (стать тоже без номера).
   Cyberhawk
 
14 - 20.09.18 - 15:20
(11) Повторил )
   Cyberhawk
 
15 - 20.09.18 - 15:21
(12) Номер выступает маркером, что объект попал в очередную обработку выгрузки
   Фрэнки
 
16 - 20.09.18 - 15:22
(15) Задумка была хорошая, но...
   Вафель
 
17 - 20.09.18 - 15:23
(15) что это нам дает?
   Cyberhawk
 
18 - 20.09.18 - 15:23
(17) Что нужно удалить такой объект после выгрузки, чтоб он не попал в следующую
   Cyberhawk
 
19 - 20.09.18 - 15:23
*удалить его регистрацию
   Фрэнки
 
20 - 20.09.18 - 15:32
(19) я несколько раз видел готовые решение по подобной схеме - номера не использовались.
   Serg_1960
 
21 - 20.09.18 - 15:44
(20) Это неверный подход, который не учитывает многопользовательский режим работы.
   Фрэнки
 
22 - 20.09.18 - 15:51
(21) выше я уже заметил, что сам считаю такие действия вынужденными тем, что платформа не обеспечивает надежного использования назначаемых в записях регистрации изменений номеров.

А многопользовательская там запись или нет... Алгоритм в целом там несложный и на первый взгляд вполне себе годный. Именно для целей регистрации новых изменений объектов... Не помню только включалась ли там блокировка записей новых хоть на какие-то транзакции или нет... Похоже что да - транзакции там тоже использовались в узких местах!
   Cyberhawk
 
23 - 20.09.18 - 15:54
(20) Ну значит вместо номера у каждого выгружаемого объекта был какой-то другой маркер. Не блокировать же его до конца успешной выгрузки? Иначе как узнавать, что объект уже можно удалить из очереди выгрузки?
   Serg_1960
 
24 - 20.09.18 - 16:05
(22) Да, разумеется, и блокировки, и транзакции - всё это используется. Но и этого - мало. Помимо этого, когда мы пишем типа "ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(Узел, Номер)", мы "фиксируем" состав зарегистрированных изменений текущего сенса обмена на неопределенное время без установки блокировки всей работы с базой всех. Несколько сложно сказал, надеюсь поймут.
   Фрэнки
 
25 - 20.09.18 - 16:11
(23) (24)
Пишется массив выгруженных объектов.
Перед окончанием обработки накладывается транзакция и делается чтение из регистрации всех изменений в массив
Узел очищается
Сравниваются два массива - новые записи отсеиваются и зарегиваются повторно.
Транзакция фиксируется
   Serg_1960
 
26 - 20.09.18 - 16:23
... и каждый остался при своём мнении.
   Cyberhawk
 
27 - 20.09.18 - 16:27
(25) При таком подходе объект, который был перезаписен (изменен) во время выгрузки, не будет ничем отличаться от объекта, который не был изменен за это время выгрузки. Ну т.е.  он будет сидеть и в том первом массиве выгруженных, и в массиве зарегистрированных. Но снимать его регистрацию-то нельзя
   Вафель
 
28 - 20.09.18 - 16:43
(27) поэтому нужно пообъектно. заблокировал - выгрузил объект - удалил запись
   Cyberhawk
 
29 - 20.09.18 - 16:46
(28) 1. Такой атомарный подход может не работать тогда, когда нужна логика выгрузки "все или ничего".
2. Зачем блокировать, когда можно не блокировать? В чем тебе кажется преимущество перед описанным в (13)?
   Вафель
 
30 - 20.09.18 - 16:48
(29) если все или ничего, то нужно подтверждение загрузки тогда
   Cyberhawk
 
31 - 20.09.18 - 16:52
(30) Вовсе нет. Просто внешней системе может быть не нужным какой-то один объект, если вместе с ним нет всего остального сопутствующего.
   Вафель
 
32 - 20.09.18 - 16:53
(31) если файл не загрузится (например некорректно сформировался файл) - то ты уже потеряешь инфу о том какие объекты нужно выгрузить.
   Фрэнки
 
33 - 20.09.18 - 16:59
(27) массив именно записей, а не самих объектов.
 
 
   Cyberhawk
 
34 - 20.09.18 - 17:01
(32) Вовсе нет. Что-то ты мешаешь в кучу.
Всякие системы есть, которым надо кормить пакеты (строки/файлы) и которые не умеют в обратку подтверждать.
Это конечно же не значит, что они умеют разбирать эти строки/файлы пообъектно и им можно выгружать пообъектно, ведь они могут быть рассчитаны всегда только на определенный состав объектов в прилетевшем пакете ("протокол обмена").
Так что ты что-то намешал.
   Фрэнки
 
35 - 20.09.18 - 17:02
(27) т.е. я выгрузил объект первый раз. Он после этого успел регнуться еще несколько раз. Поскольку выборка шла из массива записей - эти записи останутся в выборке невыгруженных, т.к. выборка выгруженных успеет очиститься при получении первой записи (ведущий цикл по массиву регистрации, а не массиву выгруженных)
   Вафель
 
36 - 20.09.18 - 17:04
(34) в данном случае пообъектно система умеет принимать. ибо в следующий заход прилетит 1 документ
   Cyberhawk
 
37 - 20.09.18 - 17:06
(35) Лучше б на одном простом (конкретном) примере.
Ну типа дано: на узле зарегистрировано два документа.
Далее начинается процесс выгрузки по твоему алгоритму и что там внутри происходит?
1. Получаем массив объектов к выгрузке (два документа?)
2. Крутим цикл, выгружаем каждый документ.
3. Пока выгружали второй, первый в базе поменяли.
4 ???
   Вафель
 
38 - 20.09.18 - 17:07
(37) это смотря когда очишать список регистрации
   Cyberhawk
 
39 - 20.09.18 - 17:08
(36) Хз о чем ты
   Вафель
 
40 - 20.09.18 - 17:10
(39) о том что пакет вполне может быть из 1 элемента, ибо в регистрации может быть только 1 элемент
   Фрэнки
 
41 - 20.09.18 - 17:12
(37) т.к. он был зареан лишний раз, то выборка записей зареганных будет больше, чем выгруженных.

- Открываем транзакцию (новые записи от остальных сеансов блочатся)
3.1 Считываем зареганные по узлу в массив и чистим узел
4. Перебираем выборку зареганных
4.1 находим в списке Выгруженных объект - удаляем 
4.2 ищем далее - в выгруженных уже пусто - регаем объект по узлу
-- Фиксируем транзакцию (блокировка снимается)
   Cyberhawk
 
42 - 20.09.18 - 17:15
(41) 1. Почему зареганных будет больше, чем выгруженных?
Выгружено два (первый и второй документ), и зарегано на момент начала транзакции (до очистки регистрации на узле) тоже эти два документа.
2. По твоему пункту 4.1 первый документ будет найден в списке выгруженных и удален с узла.
   Cyberhawk
 
43 - 20.09.18 - 17:18
(40) Предположим, что:
- в каждом пакете должны быть обязательно все свежесозданные объекты (товары, например), которые в приемник еще не передавались, иначе приемник не сможет принять такой пакет
и
- все товары из каждого документа мы не передаем в пакете, если они не свежесозданные (не зарегистриованы на узле)
   Фрэнки
 
44 - 20.09.18 - 17:18
(42) когда у тебя идет изменений объекта в базе, то новая регистрация изменений ложится в таблицу регистраций с пустым номером, новой записью, а не затиранием старой. Выборка из таблы регистраций вернет записи с дублями без номеров пакета, но с такими же объектами. Не все будут с дублями - новые измененные будут "лишние"
   Cyberhawk
 
45 - 20.09.18 - 17:19
(44) Стоп, так ты же писал что не пользуешься номерами как маркерами?
   Фрэнки
 
46 - 20.09.18 - 17:20
(45) количество записей в выборках - там же номер пакета ключевое поле.
   Cyberhawk
 
47 - 20.09.18 - 17:20
А получается, что ты как раз пользуешься тем, что у выбранных объектов будут номера (в запомненном тобою первом массиве-срезе)
   Вафель
 
48 - 20.09.18 - 17:21
(43) товары передавай раньше документов и все
   Cyberhawk
 
49 - 20.09.18 - 17:21
(46) Так мы вроде (20) обсуждаем?
 
 Рекламное место пустует
   Фрэнки
 
50 - 20.09.18 - 17:22
(45) сами номера не нужны. Нужны именно массивы любых зареганных объектов в любом количестве записей. Можно не номера пакетов, а время. Не важно как, но важно, что они избыточны.
   Фрэнки
 
51 - 20.09.18 - 17:23
(47) я пользуюсь тем, что поле есть и оно может быть пусто или непусто. Но само значение номера пакета не определяется.
   Cyberhawk
 
52 - 20.09.18 - 17:25
(51) Ясно, спс. Мое "маркер" то же самое и означало (пох какой там номер отправленным присваивается).
   Cyberhawk
 
53 - 20.09.18 - 17:40
(48) 1. И все равно непонятно, зачем ты предлагаешь блокировать каждый объект, когда это можно не делать.
2. И при предлагаемом тобою пообъектном удалении регистрации информация о регистрации безвозвратно утеривается, если до завершения выгрузки возникает какая-нибудь невосстановимая ошибка - что с этим делать будем?
   Фрэнки
 
54 - 20.09.18 - 17:43
(53) Не блокировать объекты, нет.

Открыть транзакцию в момент чтения из таблиц регистрации изменений и очистки этих таблиц. Это автоматически, на уровне СУБД заблочит добавление новых регистраций до окончания транзакции. Вероятно, что длительность транзакции будет небольшой. Это минус у такого подхода. И я это видел в готовом виде в готовых решениях.
   Фрэнки
 
55 - 20.09.18 - 17:44
(53) не теряется ничего = если транзакция не зафиксилась - регистрация восстановится в полном объеме, даже того, чего можно и не восстанавливать
   Cyberhawk
 
56 - 20.09.18 - 17:53
(54) Это ты сейчас про какой подход отвечаешь? Я-то про (28)
   Вафель
 
57 - 20.09.18 - 17:57
(54) блокировка добавления регистрации - это равносильно блокировки записи
   Cyberhawk
 
58 - 20.09.18 - 18:06
(57) Но ты-то предлагаешь блокировать каждый объект на время его выгрузки, что куда дольше, чем то, что там Фрэнки описывал (у него однократная блокировка в конце и только на время чтения и очистки реги), так?
   Serg_1960
 
59 - 20.09.18 - 19:07
Продолжаете изобретать велосипед?

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

PS: у меня план обмена РИБ и мне все ваши пообъектные изыскания совсем не в тему.
   Фрэнки
 
60 - 20.09.18 - 19:41
(59) :-) В ентрерпраййз дата , если судить по отзывам - нет уже прежней халявы, к которым привыкли в РИБ обменах
   Cyberhawk
 
61 - 20.09.18 - 22:19
(59) "у меня план обмена РИБ и мне все ваши пообъектные изыскания совсем не в тему" // Так между идентичными-то конфами сам бог велел максимально атомарно (пообъектно) передавать


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует