Не управляемые формы, Толстый клиент
В процессе обслуживания клиентов нашей организацией было принято решение о выборе стратегии минимального вмешательства в код и объекты конфигурации. И следствием явилась необходимость постоянного написания и доработок огромного количества внешних обработок и отчетов. Со временем росло количество этих дополнений и штат сотрудников работающих с (над) ними. В какой-то момент уже было тяжело найти актуальную версию того или иного дополнения, а, с увеличением количества клиентов, требовало больших усилий и затрат времени по их обновлению на рабочих местах. Так появилась идея написания данной обработки.
Суть ее проста — анализируется состав дополнительных отчетов и обработок клиента, сравнивается с содержимым определенной папки на ftp — сервере, и предоставляется возможность заменить или добавить любую из списка на сервере.
Разработка и обновление таких дополнений так же автоматически превращается в понятную и определенную. Любой сотрудник перед началом изменений получает себе последнюю копию с ftp-сервера, производит изменения, меняет версию и записывает ее на сервер. Хотя и без внесения информации об изменении версии будет видно, что дополнение было изменено, но без автоматической установки галочки в состояние «необходимо обновление».
Немного о реализации. По непонятным уже сейчас причинам было принято решение хранить служебную (и прочую) информацио о дополнении в макте табличного документа с зарезервированным названием «ПараметрыОбработки»
Значения для определения параметров берутся из столбца №1 начиная с первой строки
- Версия обработки;
- Тип обработки;
- Описание обработки;
- e-mail адрес разработчика/ответственного для уведомления об ошибках (не используется);
- Раздел учета;
- «тип форм» — управляемые/неуправляемые (не используется);
Стандартное описание обработки выглядит следующим образом:
Сама обработка по обновлению так же содержит этот макет. Он будет служить шаблоном для новых обработок.
Код обработки, правда, нарочно не оптимизировался. Много раз дописывался «набегами», посему — прошу сильно не кидать тапками.
При первом чтении содержимого папки ftp обработкой создается в этой же папке файл, в который который пишется описание каждого дополнения — своеобразное кэширование, чтобы каждый раз не перетаскивать на клиента все обработки. Принудительного обновления этого файла не требуется. Обработка анализирует дату изменения обработок на фтп и в файле описания и если находит отличия — переписывает файл-описания сама.
Для пользователя, под которым обработка обращается к ftp, необходимо разрешение на запись в эту папку.
Вроде все. Вероятно, текст будет дополняться описаниями, если будет много вопросов. Больших изменений менно этой версии не будет. В данный момент происходит активный перевод/перевод все и вся на УФ и готовится соответсвующая версия этой обработки.
Немного лирики.
При больших объемах и медленном соединении интернета обработка может не отрабатывать, но это должно быть понятно тем, кто часто имеет дело с протоколом ftp.
Надеюсь, кому-нибудь пригодится.
странно каммент не добавился . Ftp — не всегда открыт раз . 80 почти всегда открыт — два.
можно проверить регистрацию клиента — на этапе получения информации и разделять по версиям и вариациям отчетов.
(1) iov,
1с-ными средствами открываю соединение. От меня оно не зависит. Хотя в работе реальных проблем не встречал. У меня в 99% все отрабатывает без проблем. 1% — низкая скорость и не стабильность интернета.
Можно много чего сделать. Но делать на клиенте (в обработке) какую-то проверку бессмысленно. Можно на фтп создать нужное количество учет, заходить в каждой конторе под своей и в нужный момент блочить, если я правильно понял вопрос
(1) iov, туплю. Понял первую часть вашего «предложения» с 5го прочтения :). Сделать работу не через фтп. а через хттп — можно, но у меня вебсервер не прикручен к фтп. Да и скрипты всякие вешать надо. Хотелось максимально просто. Выложил на фтп, запустил обработку 🙂
Реальных ошибок никто не находил? Хотя, скачало-то 2 человека