Пример сериализации объектов в 1С 8.3 и их восстановления из сериализованных данных

16.05.2017 29 Comments

Математика и алгоритмы, Разработка

, ,

    Обработка1.jpg
Простейшая обработка, демонстрирующая принципы сериализации выбранного Объекта 1С (Справочника, Документа и еще некоторых), с возможностью восстановления Объекта из сериализованного значения.

    Разбираясь с версионированием объектов в Бухгалтерии предприятия 3.0, я понял, что оно устроено весьма просто.

    В определенный момент (запись справочника, проведение документа…) объект сериализуется в формат FastInfoSet (по сути являющимся просто сжатым XML) и записывается в реквизит регистра сведений с типом «ХранилищеЗначения».

    При возврате к предыдущей версии, из хранилища извлекается сериализованное значение, производится его преобразование в объект, и объект записывается. При записи на сервере текущий объект заменяется извлеченным из хранилища.

    Всё.

    В данной обработке на совсем простом уровне проиллюстрирован этот механизм. Можно выбрать Объект (документ, справочник и некоторые другие) сериализовать его в XML и FastInfoSet.

    Сериализованные данные можно выгрузить в файл или создать новый, не записанный в базу Объект.

    Я не стал делать косвенно опасный механизм перезаписи существующего объекта, а просто создаю форму нового объекта, хранящегося в реквизите обработки «Сериализуемый объект» и затем в нее копируются данные восстановленного объекта. При этом создается новый объект с теми же реквизитами. Идею по открытию формы созданного на сервере из сериализованных данных Объекта я позаимствовал из статьи lobster‘а «Открытие формы еще незаписанного документа 1С 8.2 Управляемое приложение».

Related Posts

29 Comments

  1. spezc

    Я бы на вашем месте дополнил статью материалом, который бы объяснил, как восстановить версию объекта (например справочинка Номенклатура), если между версиями были изменены метаданные (например добавлен или удален реквизит).

    Reply ↓
  2. spezc

    ну может кому-то будет интересно:

    Функция Десериализовать(XMLСтруктураСериализованногоОбъекта) Экспорт
ЧтениеXMLДанных = Новый ЧтениеXML;
ЧтениеXMLДанных.УстановитьСтроку(XMLСтруктураСериализованногоОбъекта);
ТЗ = СериализаторXDTO.ПрочитатьXML(ЧтениеXMLДанных);
ЧтениеXMLДанных.Закрыть();
Возврат ТЗ;
КонецФункции

Функция Сериализовать(ОбъектСериализации) Экспорт
ДеревоВОбъектеXDTO = СериализаторXDTO.ЗаписатьXDTO(ОбъектСериализации);
МойXML = Новый ЗаписьXML;
МойXML.УстановитьСтроку();
ФабрикаXDTO.ЗаписатьXML(МойXML, ДеревоВОбъектеXDTO);
Возврат МойXML.Закрыть();
КонецФункции

Функция ПолучитьСтрокуДляПередачи(Значение) Экспорт

ХранилищеДляПередачи = Новый ХранилищеЗначения(Значение, Новый СжатиеДанных(9));
СтрокаДляПередачи = Сериализовать(ХранилищеДляПередачи);

Возврат СтрокаДляПередачи;

КонецФункции

Функция ПолучитьДанныеИзСтроки(ДанныеСтрокой) Экспорт

Хранилище = Десериализовать(ДанныеСтрокой);
Значение = Хранилище.Получить();

Возврат Значение;

КонецФункции

    Показать

    Reply ↓
  3. katkov_a

    (1) spezc, Достаточно записать прямо в серверной процедуре восстановленный из сериализованных данных объект, и он заместит собой существующую версию, т.к. он имеет тот же Идентификатор и следовательно для Программы он является тем же объектом.

    Reply ↓
  4. katkov_a

    (2) spezc, Сериализация объекта «СериализуемыйОбъект»:

    &НаСервере
Процедура СериализоватьОбъектНаСервере()

ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.УстановитьСтроку();
ЗаписьXML.ЗаписатьОбъявлениеXML();
ЗаписатьXML(ЗаписьXML, СериализуемыйОбъект, НазначениеТипаXML.Явное);
СтрокаXML = ЗаписьXML.Закрыть();

КонецПроцедуры

    Показать

    Восстановление объекта из Строки XML:

    &НаСервере
Функция СоздатьОбъектИзXMLНаСервере()

ЧтениеXML = Новый ЧтениеXML;
ЧтениеXML.УстановитьСтроку(СтрокаXML);
ВосстановленныйОбъект = ПрочитатьXML(ЧтениеXML);
// Для замещения ныне существующего объекта в базе достаточно записать Восстановленный объект
ВосстановленныйОбъект.Записать();

КонецФункции

    Показать

    Reply ↓
  5. DitriX

    (3) вы так и не ответили на вопрос (1) 🙂

    Попробуйте изменить тип данных или же добавить/удалить метаданные, некий реквизит, к примеру. И увидите — как 1С не восстановит вам старую версию а напишет ошибку десериализации 🙂

    Reply ↓
  6. katkov_a

    (5) DitriX, Ах пардон, просто не правильно прочитал. Ответ — не прокатит, при создании объекта возникнет ошибка.

    Reply ↓
  7. V.Nikonov

    (6) Придется сериализовать Новый (Пустой) объект, а затем сверять структуру xml , восстанавливаемой и текущей структуры… Вылавливать добавленные и лишние реквизиты структуры с корректировкой текстового представления…

    Reply ↓
  8. katkov_a

    (7) V.Nikonov, А как это сделать, если сериализованный объект хранится в FastInfoSet?

    Reply ↓
  9. kasper076

    (8) может по мимо сериализованных данных самого объекта хранить еще схему этого объекта? В таком случае можно будет сравнить сохраненную схему со схемой полученной из БД, если они идентичны, то просто десериализовать объект, а если нет, то создать XDTO-объект по сохраненной схеме, десериализовать в него данные сохраненного объекта и затем уже обрабатывать их.

    Reply ↓
  10. katkov_a

    (9) kasper076, Использование FastInfoSet применяется для уменьшения объема записываемых данных.

    А так, на здоровье, можно хранить в XML. Его получать из хранилища и не мудрствовать лукаво.

    Если хранить в базе еще и схему, то выигрыша в объеме не будет. Мне так кажется.

    Но, конечно, зависит от количества вводимых документов.

    Можно просто сделать хранение во внешних файлах XML «снимков» критичного документа.

    Reply ↓
  11. AlexO

    (10)

    Можно просто сделать хранение во внешних файлах XML «снимков» критичного документа.

    Вы хоть представляете, во что это выльется? Даже если вы корректно напишите подобную систему версионирования.

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

    Reply ↓
  12. AlexO

    (0)

    Идею по открытию формы созданного на сервере из сериализованных данных Объекта я позаимствовал

    Это какую вы там идею позаимствовали — что нужно заполнить форму перед её открытием?

    Reply ↓
  13. katkov_a

    (12) AlexO, Да. А как бы вы сделали это иначе, интересно, если не хотите перезаписывать документ старой версией? А открыть надо старую?

    Reply ↓
  14. katkov_a

    (11) AlexO, Да, представляю. Тысяча доков — тысяча файлов. 🙂

    Reply ↓
  15. kasper076

    (10) эт все понятно. Но как я понял после изменении структуры ранее сериализованного объекта десериализовать его уже не удастся. И тогда можно будет лишь считать его через ЧтениеХМЛ, а затем парсить.А вот если вместе с данными объекта сохранять еще и его схему, то объект можно будет получить в виде объекта ХДТО, что значительно упрощает работу с его свойствами. Схему можно хранить не в каждом элементе, а сводно. Т.е. будет некая история схем для объекта метаданных в виде структуры. Ключом будет ИД конфигурации, а значением ХМЛ представление схемы.

    Reply ↓
  16. AlexO

    (14)

    Да, представляю

    Да нет, не до конца ))

    А размер всей этой фейерии?

    Reply ↓
  17. AlexO

    (13)

    А как бы вы сделали это иначе, интересно, если не хотите перезаписывать документ старой версией?

    Да без разницы, как — тут и «идеи» нет никакой. Чистая реализация.

    Или создать «болванку» документа, и его заполнить, или создавать «имитацию» документа (как Франкенштейна — отдельно ТЧ, отдельно шапка, поля там…), и тоже их заполнить данными объекта.

    А идеи нет никакой ))

    Reply ↓
  18. AlexO

    (15) kasper076,

    Но как я понял после изменении структуры ранее сериализованного объекта

    Если меняете стурктуру исходного дока, а «слепок» в виде сериализации — остается прежним, то это и понятно, что «обратно» вы его не восстановите с прежней структурой.

    Это проблема 1С, аналогичная, как если сохранить «объект» в «ХранилищеЗначения», поменять его, а в Хранилище — останется старая не измененная копия.

    то объект можно будет получить в виде объекта ХДТО

    Со схемой — вы просто создаете новый объект как «объект XDTO», который, естесственно, не связан с предыдущим никак и ничем.

    Reply ↓
  19. katkov_a

    (17) AlexO, Да, чистая реализация.

    (16) AlexO, Идея раздувать базу тоже — так себе, а если записывать внешне, получится некая отдаленная аналогия Журнала регистрации. 🙂

    Reply ↓
  20. katkov_a

    (15) kasper076, «Считать» объект не удастся. Если он хранится в XML, то можно просмотреть его структуру, что бы понять, что изменилось.

    А если он хранится в FastInfoSet формате, то я даже не знаю, что можно сделать. А по стандартной методе из БСП он хранится в нем.

    Reply ↓
  21. AlexO

    (19)

    Идея раздувать базу тоже — так себе

    Да оно знаете (или нет?), как — у 1С что «в лоб» (писать и раздувать базу), что «полбу» (хранить тысячи файлов на диске) — все едино неоптимально.

    Тут — база раздувается, снижается производительность, там — диски «горят», медленно файлы читает и обрабатывает, снижается производительность…

    Если интересно — могу рассказать, что предпочитаю я. Совсем другие варианты. Не тру-одноэсовые )))

    Reply ↓
  22. katkov_a

    (21) AlexO, Раскажите.

    Reply ↓
  23. AlexO

    (22)

    Если данные «на посмотреть» — всякие там «временные» файлы, которые через полгода никому не нужны (уже отработаны), логи изменений из систем версионирования и прочее, что не нужно спустя какое-то время — то однозначно хранить в базе и периодически автоматически чистить, чтобы «не росло». Также — даже если «будет нужнО», всегда можно восстановить в архиве (например, цепочки изменений из системы версионирования).

    Если данные какие «нужные всегда» (картинки там, файлы, документы, которые и через 10 лет нужны будут) — то хранить в смежной базе (хоть SQL, хоть еще какой, какая понравится), и сделать ссылкообмен между ними. Ссылки, естественно, в формате ссылок 1С.

    Оба эти варианта покрывают 99,99999% всех потребностей в таких хранилищах, и обеспечивают оптимальную производительность.

    А также — архивирование, переносы (баз и данных), оптимизацию дискового пространства, контроль, управление и т.д и т.п.

    Потому что идеальны — в данных случаях и условиях.

    А 1С-у давно пора забубенить конфу «Хранилище данных» как болванку-шаблон для хранилищ из 2-го варианта. Но нет же, у них более возвышенные цели, чем какие-то приземленные потребности обработки данных ))

    Reply ↓
  24. katkov_a

    (23) AlexO, Хммм… А со внешним источником данных не получится?

    Ну т.е. другой базой SQL.

    Reply ↓
  25. katkov_a

    (24) У меня получилось подключиться к другой базе и записать туда текст!

    Создал в другой базе регистр сведений по названию «РегистрСедений» с одним текстовым полем.

    Создал в первой базе Внешний источник данных. Настроил подключение к SQL. Добавил найденую таблицу регистра сведений во ВнешнийИсточник. Вуаля. Могу в ней писать.

    Reply ↓
  26. AlexO

    (24)

    А со внешним источником данных не получится?

    (25)

    У меня получилось подключиться к другой базе и записать туда текст!

    Ничего не понял.

    Вы подключили таблицу другой базы SQL через «технологию» ВнешниеДанные? Или вы просто подключились к другой базе SQL и сумели записать туда данные?

    Создал в другой базе регистр сведений по названию «РегистрСедений» с одним текстовым полем.

    Если вы про другую базу 1С — то никакой «регистр сведений» вы не заполнили: вы заполнили лишь поле таблицы SQL, которую использует также и РС той базы 1С. «та» 1С никакой «записи» не получит — ей «плевать» на ваши «прямые» записи в SQL, там более сложная схема связки таблиц. Попробуйте записать что-то более сложное, чем примитивные типы данных, которые вам доступны по COM.

    Reply ↓
  27. katkov_a

    (26) AlexO, Мы говорили о сохранении версий документов. Дескать, базу «раздувать» плохо, но и во внешние файлы сохранять тоже плохо.

    Независимый непериодический регистр сведений 1С — обычная таблица в SQL. Я создал его в одной базе.

    И подключился к нему из другой через объект Внешний источник данных. И мне удалось писать в регистр сведений в той первой базе. (Я, просто, раньше никогда с объектом Внешний источник дел не имел)

    Это означает: можно версии объектов в виде XML писать через внешний источник данных в другую базу. И наша боевая база не будет «раздуваться» и объект мы сможем проанализировать в случае необходимости восстановления, т.к. они будут записаны в несжатом виде.

    Reply ↓
  28. AlexO

    (27)

    Это означает: можно версии объектов в виде XML писать через внешний источник данных в другую базу.

    Я, может, и не понимаю, о чем вы, но ощущение — что вы постоянно пересчитываете одни и те же три сосны ))

    (23) цитата «Если данные какие «нужные всегда» (картинки там, файлы, документы, которые и через 10 лет нужны будут) — то хранить в смежной базе (хоть SQL, хоть еще какой, какая понравится)»

    Текст также можно хранить аналогичным образом.

    Reply ↓
  29. sir

    (26) Все 1С «Получит» если корректно сделать запись в таблицу sql.

    У меня был реализован целый обмен между БД посредством записи напрямую в SQL другой БД 1С.

    Причем создавались новые документы, справочники и пр., И все это работало за доли секунд (и работает до сих пор)

    Но обращался я к другой БД не через внешнее соединение а через ADO.

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *