Данная обработка предназначена для уменьшения размеров любых внешних отчетов/обработок (ERT), имеет режим пакетной обработки каталогов. В зависимости от первичной оптимизации обрабатываемого файла, степень сжатия может составлять от нескольких процентов до нескольких раз.
Файлы
ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
0% комиссии — оплата напрямую исполнителю;
Исполнители любого масштаба — от отдельных специалистов до команд под проект;
Прямой обмен контактами между заказчиком и исполнителем;
Безопасная сделка — при необходимости;
Рейтинги, кейсы и прозрачная система откликов.
ПРИНЦИП ДЕЙСТВИЯ:
На данный момент функционал обработки на порядок усложнен по сравнению с первичной версией, поэтому в подробности здесь я вдаваться не буду - если кого заинтересует, и если кто разбирается в структуре компаундов и потоков - спрашивайте в личку или в комментах.
Сжатие достигается за счет переформирования потока "Gallery" (в тех обработках, где используются картинки), а также за счет анализа диалоговых форм и уменьшения потока "Main MetaData Stream" с учетом только используемых в диалоге обработки/отчета типов метаданных.
В состав обработки входит библиотека "compound.dll" (автор Костя Волков (reminder@softhome.net)), она запакована в состав ERT-файла обработки и распаковывается по мере необходимости. С ее помощью происходит процесс разбора файла на потоки и последующий сбор результирующего файла. Метод хранения бинарных файлов внутри ERT описан мной здесь: //infostart.ru/profile/1782/projects/600/
Простецкий скрипт переименования файлов в папке в нижний регистр, будет полезен программистам и системным администраторам имеющим навыки програмирования в 1С. Можно легко настроить под себя, спасает мне периодически час времени, может, кому еще будет полезен.
Боремся с бардаком. Работы в прошлых датах запрещены. Непроведенные документы (по разным причинам) - автоматом переносятся в начало текущего дня при запуске любого первого сеанса 1С в текущем дне. Задержка старта 1С - практически незначима. Не требует настройки, не требует допрограммирования (исключая один оператор вставки в процедуру старта системы). Можно обработку выполнять вручную с любой периодичностью.
Рассмотрим систему на базе Elasticsearch, Logstash и Kibana (ELK Stack) для анализа логов 1С Предприятие 7.7 с целью визуализации и анализа событий 1С.
Скрипт позволяет выполнить объединение конфигураций и реструктуризацию из командной строки. Объединение выполняется штатными средствами конфигуратора 1С 7.7, взаимодействие с которым происходит путем посылки нажатий клавиш.
Пригодится, если есть необходимость обновить или постоянно обновлять множество ИБ.
Периодически сталкивался со следующими проблемами при печати в 1С: 7.7 работающей под терминалом:
1) После замены принтера на клиентской машине 1С пытается печатать на старый принтер.
2) Отсутствует предварительный просмотр при печати.
3) Не работает печать без предварительного просмотра (пакетная печать документов).
4) В некоторых формах печатает, в некоторых нет.
Часто бывает необходимо отслеживать состояние часто повторяющихся регламентных заданий. Например, синхронизация данных с IP-телефонией, которая может производиться каждую минуту, синхронизация с сайтами, синхронизация данных с различными системами.
Использовать для этих целей логирование 1С чрезвычайно неэффективно и не удобно.
В таких случаях удобно использовать подход, применяемый в Unix-системах: писать логи в обычные текстовые файлы, а потом делать их обработку через эффективно работающие Unix-команды: grep, tail, cat, less и т.п.
Решил пока не делать те вещи, которые описаны в посткриптуме к данной обработке. Если есть интерес - можно сделать, не проблема, но только под "личную ответственность" упаковывающего.
кста, как я упоминал в комментариях к твоему ной-хау - Абрахамс демонстрировал как внутрь обработки может быть зашита например ДЛЛ-ка и установлена для работы обработки...
(3) На слово не верю. Почему когда я это выкладывал на двух форумах, никто кроме тебя не обмолвился об аналогиях? Ты покажи: что, где, когда, а уж потом будем говорить о неоригинальности.
(10) Ты - бяка! абрахамс - реально крутой чел, я от его скриптов и подходов чисто прусь.. такое впечатление, что он может сделать почти все (5 9-ок после ЗПТ) без использования ВК... если нужен пример упомянутый в (3) - то отпишись в личку - а то забуду и не найду...
(0) Саш, насчет Main MetaData Stream и "даже предварительный анализ обработки не даст 100%-корректного результата" не прав. Если в Dialog Stream вообще нет ссылок на реквизиты типа Документ, Справочик, Журнал и т.д (в общем на метаданные) можно резать смело. Выигрыш в размере может составить до 10 (!) раз
К своему стыду, обработку Abadonna не видел, но как понял из комментариев, он не знал что можно обрезать поток Gallery, а именно из-за него размер файла растет наиболее значительно.
(6) У меня в основной задаче как раз стояло ВЫГРУЗИТЬ всю галерею, чтобы внутренние, превращенные во внешние, оказались со встроенными картинками. А какие потоки резать/не резать - это я уж на сто рядов изучил :))) И без compound.dll и g-comp
Компаунд, по большому счету - обычная файловая система, только внутри самого файла ;)
(7) В том-то и дело, что галлерею вообще выгружать не надо, а только сами картинки и пустой Gallery - работать будет на любой конфе - проверил. Насчет Compound - Abadonna, я еще не настолько опытен, без инструментов не умею, но буду учиться :)
(13) Возможно, мы по-разному пытались формировать пустой Gallery. У меня тоже далеко не с первой попытки получилось - то упакованный отчет вообще не открывался, то открывался но без картинок.
(17) Вот теперь мне всё ясно стало! Я при выгрузке ваще убивал поток Gallery.
Забавно, что пустой Meta таки надо подсунуть сообразил, а что пустой (как ты делаешь) Gallery - нет. И на старуху бывает проруха ;)
(19) Лана, как-нить доберусь я до галереи ;) На том этапе меня это не сильно колыхало и я не стал особо заморачиваться. Но одно знаю точно: когда ThunderRep выгружает внутренний отчет во внешний и забирает только нужные картинки и всю галерею - оно потом работает корректно в любой конфе. Поэтому на том этапе я и плюнул слюной на размер галереи.
Оказалось, что принцип формирования "Picture->Gallery" сложнее, чем я предполагал. Просто тупо записывать один и тот же поток в обработки неверно, так как Gallery формируется динамически согласно количеству картинок и их идентификаторов (и размер потока тоже не постоянный). На данный момент обработка переделана с учетом этих особенностей - то есть каждый раз формирует поток "Picture->Gallery" с учетом особенностей конкретной обработки/отчета.
Для тех, кто уже упаковывал ERT с помощью моей обработки, желательно перепаковать их еще раз новой версией (если есть проблемы или желаете их избежать). Возможные проблемы при упаковке старой версией:
1) При количестве картинок более 22 старшие картинки не отображаются.
2) Некоторые картинки (даже до 22) могут не отображаться по причине несоответствия их идентификаторов предполагаемым.
3) При вставке упакованного отчета/обработки в конфигурацию вставляется всегда 22 картинки (скажем 5 реально существующих и 17 пустых).
Ну наконец-то я доделал то что давно хотел - сделал упаковку Main MetaData Stream. И притом не просто заменой, а путем анализа диалоговых форм и исключением из Main MetaData Stream тех объектов метаданных, которые не используются в реквизитах диалогов. На данный момент, с учетом "умной" упаковки Main MetaData Stream и Gallery, по степени сжатия моя обработка превосходит аналоги от Абадонны и G-Comp. Но пока еще возможны глюки (хотя сам не видел), пользуйтесь осторожно, об ошибках сообщайте.
