<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
(0) Добрый день, есть несколько вопросов
1. Есть ли групповой режим или режим командной строки;
2. Возможно ли обработку адаптировать чтобы она стала как библиотека в onescript;
3. Какие условия распространения в дальнейшем планируются по данному инструментарию, если свободно возможно ли проект выложить в git для доработки сообществом;
(1)
Добрый день,
1. «Есть ли групповой режим или режим командной строки» — я так понимаю, речь только про обработку тестирования, а не про редактор правил? Нет, таких режимов нет. Можете пояснить, как вы видите работу обработки в этих режимах?
2. «Возможно ли обработку адаптировать чтобы она стала как библиотека в onescript»
С onescript не знаком. Опять же, можете пояснить, как вы это видите в общих чертах?
3. «Какие условия распространения в дальнейшем планируются по данному инструментарию, если свободно возможно ли проект выложить в git для доработки сообществом»
Обработка «Редактор правил проверки» распространяется через эту публикацию за стартмани.
Обработка «Тестирование конфигурации» и функции проверки свободны для распространения (планировал их выложить бесплатно, но правила инфостарта не позволяют). Если нужно, могу выслать. Обработку «Тестирование конфигурации» разработчики могут прикреплять к своим публикациям.
Про git пока не думал, но вообще да, идея интересная. По крайней мере, можно выложить обработку тестирования и функции проверки для совместной доработки.
Интересная разработка, всё, бы «ничего», НО
1. Всё равно над знать структуру метаданных другой конфигурации
4. Например, рассмотрим простейший случай
В конфигурациях УТ 11.4 и УНФ 1.6 есть справочник Номенклатура.
В УТ у номенклатуры есть реквизит «ВидНоменклатуры», в УНФ – «КатегорияНоменклатуры».
Изначально решение было разработано для УТ, для этой же конфигурации были подготовлены правила проверки — выполнялась проверка существование справочника Номенклатура с реквизитом ВидНоменклатуры.
Клиент протестировал его на УНФ и получил ошибку «Отсутствует реквизит ВидНоменклатуры».
Разработчик внёс изменение в решение. Теперь оно в зависимости от конфигурации использует тот или иной реквизит.
Показать
Разработчик, не зная (не имея) структуру метаданных (причём, порой, достаточно подробно углубляясь в особенности работы) никак не узнает, что вместо реквизита «ВидНоменклатуры» нужно использовать реквизит «КатегорияНоменклатуры» в этотм же справочнике. А ведь он хранение в иной версии конфигурации может быть и в другом месте организовано (например в регистре сведений). При этом в конфигурациях может быть и так, что актуальное хранение переместится в другое место с какой-то версии (в т.ч. в результате персональных доработок у пользователя), но старое место ещё останется (не которое время) в составе конфигурации — тогда проверка найдёт реквизит, который уже не используется — конечно тут всё можно понять при детальном изучении даже успешного отчета (самим пользователем, если он продвинутый). Но разработчик порой не сможет понят, что ему нужно и как доработать. Это касается не только реквизитов и элементов хранения данных, это касается любых метаданных.
2. Отсутствие различных элементов метаданных
Так же частенько какие-то элементы метаданных могут присутствовать не во всех поставках конфигураций даже одной версии (я про поставки разного уровня наполнения: проф, корп…) или же попросту быть включены/исключены с разных версий. Зачастую в этих случаях эти метаданные могут быть просто не использованы и в самом устанавливаемом решении. Но опять таки, анализировать как это всё должно быть учтено — по таким отчетам почти не реально. Нужно всю конфигурацию иметь и на ней тестировать.
(3)
Да, предполагается, что при обнаружении ошибок разработчик:
— либо отказывается от поддержки какого-то вида или версии конфигурации
— либо изучает конфигурацию, вносит изменения в свою разработку и исправляет правила проверки — добавляет туда новую ветку, относящуюся к новой конфигурации
По поводу этого: «При этом в конфигурациях может быть и так, что актуальное хранение переместится в другое место с какой-то версии»
Насколько я знаю, в типовых конфигурациях в этом случае к устаревшему объекту добавляют префикс «Удалить», так что проверка обнаружит ошибку. Но в случае «персональных доработок у пользователя» действительно могут быть проблемы.
Вообще идея обработок родилась в результате опыта, полученного при адаптации одного решения под конфигурации УТ 11.1-11.4, УНФ 1.6, Розница 2.2. Оглядываясь назад, могу сказать, что мне бы эти обработки тестирования помогли бы в своё время.
Я вижу такие возможные случаи использования обработок:
— конечный клиент может самостоятельно протестировать некоторое решение перед покупкой. Я часто вижу комментарии пользователей инфостарта типа «а ваша обработка будет работать под моей конфигурацией?»
— при выходе новой версии конфигурации разработчик может сам протестировать, будет ли его решение совместимо с ней. Например, если разработчик в своей публикации заявляет о совместимости с УТ, то при выходе УТ 11.4 он может увидеть, что в новой версии поменялся механизм хранения присоединённых файлов
— можно применять этот метод и для случая, когда вы, например, сопровождаете какого-то клиента, дорабатываете его конфигурацию, обновляете её. При очередном обновлении вы можете заранее протестировать, будут ли конфликты у ваших доработок с обновлённой конфигурацией.
Поздравляю!
Вы изобрели механизм заимствования и проверки расширений (ровно то, что делает платформа при проверке применимости расширения, только нативно).
(5)
Да, есть некоторые пересечения, только тут речь не только про расширения, плюс можно создавать собственные программные проверки.
(6) Ну так а в чем мотивация писать правила в сторонке от решения для УТ, например, если можно все решение и проверки сделать в расширении и использовать механику проверки платформы?
.
(7)
Как минимум:
— есть отдельная обработка тестирования, которую можно скинуть клиенту (вместе с правилами проверки), не скидывая свою разработку. Смысл в том, чтобы не предоставляя клиенту решение позволить ему проверить совместимость.
— есть редактор правил, который заточен под решение этой задачи. Плюс редактор правил уже в текущей версии позволяет строить правила проверки автоматически, в дальнейшем, если обработка будет пользоваться спросом, мы планируем совершенствовать механизм автоматического построения правил
— речь не только про расширения, но и про обработки, отчёты и т.д.
(9) Сценарий с проверкой совместимости без передачи решения интересный.
Но я не очень понимаю какой процесс общения с клиентом надо для этого использовать. Это только для аутсорсинга?
На отчеты и обработки не рекомендую сильно вкладываться, т.к. сейчас рекомендуется все делать расширениями.
(10)
По поводу этого:
«Но я не очень понимаю какой процесс общения с клиентом надо для этого использовать»
Если речь про Инфостарт, то я вижу это так:
— если решение на Инфостарте за рубли, то к нему можно прикреплять бесплатные файлы. Это значит, что можно прикрепить бесплатную обработку «Тестирование конфигурации» и правила проверки. Клиент сам сможет их скачать и протестировать.
— если решение за стартмани, то бесплатные файлы прикреплять нельзя, поэтому разработчик может в публикации написать о том, что готов предоставить средство тестирования. Клиент может написать разработчику запрос в личные сообщения, разработчик скинет ему обработку тестирования и правила проверки.
Клиент выполняет тестирование по правилам, если результаты содержат ошибки, скидывает результаты разработчику.