Comments 41
Я всё сделал примерно так же, выгружал из 1с в XLS, парсером-плагином для wordpress собирал его. Всё на виртуальном хостинге, прототип работает нормально.
На похапе есть PHPexcelReader2
* A class for reading Microsoft Excel (97/2003) Spreadsheets.
* Version 2.22
* Enhanced and maintained by Alex Frenkel < excell2@frenkel-online.com >
* Maintained at code.google.com/p/php-excel-reader2/
На похапе есть PHPexcelReader2
* A class for reading Microsoft Excel (97/2003) Spreadsheets.
* Version 2.22
* Enhanced and maintained by Alex Frenkel < excell2@frenkel-online.com >
* Maintained at code.google.com/p/php-excel-reader2/
Т.е. на стороне сайта парсится именно xls?
Ну да, эксель файл можно сразу класть как «Скачать прайс» или посмотреть что нужно онлайн. Объемы небольшие, время работы скрипта 0.1с для 100кб файла.
В моём случае в xls было не достаточно информации для обновления каталога, он вообще был лишь побочным продуктом и добавлялся уже после того как был разработан прототип.
И ещё такой недостаток: в xls отсутствовал уникальный код/идентификатор для каждого товара, а значит, что обновлять было бы уже нельзя. Как скрипту установить соответствие между товаром в каталоге и обновлённом xls? По названию? Ну, во-первых, название может вдруг оказаться не уникальным, а во-вторых, оно ведь может и измениться. Поэтому пришлось бы, разве что, каждый раз затирать весь каталог и писать его заново, что мне кажется, было бы не совсем гладким решением. Поэтому и выгружал всё именно xml.
И ещё такой недостаток: в xls отсутствовал уникальный код/идентификатор для каждого товара, а значит, что обновлять было бы уже нельзя. Как скрипту установить соответствие между товаром в каталоге и обновлённом xls? По названию? Ну, во-первых, название может вдруг оказаться не уникальным, а во-вторых, оно ведь может и измениться. Поэтому пришлось бы, разве что, каждый раз затирать весь каталог и писать его заново, что мне кажется, было бы не совсем гладким решением. Поэтому и выгружал всё именно xml.
если уж планы обмена, то надо бы сделать на сайте счетчик полученных сообщений и в ответ 1су класть файлик с номером последнего загруженного из 1 с сообщения (его, естесственно, в xml надо добавить). тогда если при загрузке скриптом на сервере произошла ошибка (мало ли, память кончилась, или еще чего) — 1с просто выгрузит эти данные еще раз + новые изменившиеся. Да и в таком случае видно будет, что загрузка не производилась долгое время — пора бить в бубен тревогу.
А вообще — для не онлайн обмена — вполне вариант. еще картинки можно (допустим) в base64 пихнуть внутрь XML, чтобы файл один был (меньше файлов — крепче спим ИМХО)
А вообще — для не онлайн обмена — вполне вариант. еще картинки можно (допустим) в base64 пихнуть внутрь XML, чтобы файл один был (меньше файлов — крепче спим ИМХО)
На сайте и есть счётчик сообщений, и в админке видна полная статистика, вплоть до того сколько и когда изменилось.
Если скрипт рухнет в момент обработки, то он не удалит архив с сообщением и при следующем запуске попробует вновь, т.е. данные утеряны не будут.
Складывать в xml картинки смысла было мало. Боюсь, что php-скрипт, который вытаскивает их из xml и сохраняет поштучно, будет работать медленнее, нежели вызываемая внешняя утиль, специально заточенная под подобные операции. Но соглашусь с вами, действительно как вариант это можно иметь ввиду. Спасибо.
Если скрипт рухнет в момент обработки, то он не удалит архив с сообщением и при следующем запуске попробует вновь, т.е. данные утеряны не будут.
Складывать в xml картинки смысла было мало. Боюсь, что php-скрипт, который вытаскивает их из xml и сохраняет поштучно, будет работать медленнее, нежели вызываемая внешняя утиль, специально заточенная под подобные операции. Но соглашусь с вами, действительно как вариант это можно иметь ввиду. Спасибо.
Я делал такой проект для знакомых.
Выгрузка в csv из 1C -> парсинг и заливка уже средствами PHP.
Экспорт в xls тоже уже на стороне сайта.
Наверное до сих пор работает (URL не даю — зачем хабраэффект маленькому вебмагазину?)
Выгрузка в csv из 1C -> парсинг и заливка уже средствами PHP.
Экспорт в xls тоже уже на стороне сайта.
Наверное до сих пор работает (URL не даю — зачем хабраэффект маленькому вебмагазину?)
Да, думаю URL нам знать не обязательно, а вот услышать рассказ о подробностях создания всего механизма было бы очень интересно ;)
схема была такая:
1. Программист 1С сделал выгрузку в определенную папку csv файла заранее определенного формата.
(выгрузка была не по расписанию, а по кнопке из программы- так просил заказчик)
Затем следом в эту же папку записывался другой файл с оговоренным именем.
2. Программка nnCron следила за появлением файла и запускала скрипт загружающий данные в базу на хостинге. Следом в конце записывалось в базу значение флага конца загрузки и текущую дату актуальности прайса.
3. Скрипт на стороне сервера смотрел в базу и если появлялись новые данные перемещал их из временной таблицы в действующую.
4. Из тонкостей было одно: данные в 1С хранились в виде древовидного массива с двумя ключами (parent_id и element_id).
Короче программу «слабал» за пару вечеров.
1. Программист 1С сделал выгрузку в определенную папку csv файла заранее определенного формата.
(выгрузка была не по расписанию, а по кнопке из программы- так просил заказчик)
Затем следом в эту же папку записывался другой файл с оговоренным именем.
2. Программка nnCron следила за появлением файла и запускала скрипт загружающий данные в базу на хостинге. Следом в конце записывалось в базу значение флага конца загрузки и текущую дату актуальности прайса.
3. Скрипт на стороне сервера смотрел в базу и если появлялись новые данные перемещал их из временной таблицы в действующую.
4. Из тонкостей было одно: данные в 1С хранились в виде древовидного массива с двумя ключами (parent_id и element_id).
Короче программу «слабал» за пару вечеров.
Чтобы сделать на сервере универсальное решение, не только под 1С, реализовывал чезе Soap (MSSoap.SoapClient30). Встроенные средства для работы с Soap в восьмерке глючили, поэтому не стал их использовать. Да и код получился почти одинаковый для 7.7 и 8.х.
так ведь выгрузка в XML тоже является «универсальным» решением — оговорен формат, можно дополнительно закрепить его в XSD. Нам не важно, что выгружеат данные с клиента, лишь бы в оговоренном формате, нам не важно, что загружает эти выгруженные данные — хоть 1с, хоть php, хоть аксапта с сапом.
А зачем усложнять то, что можно сделать проще?
Хорошая статья, а заказы как обратно? А зачем xls, если есть точный порядок, то можно в csv завернуть, имхо и в разы быстрее будет обрабатывать. Подход запуска из командной строки подойдет только для 1с 8, в 7 не будет работать. Для большей надежности советую еще делить транспортный файл на куски.
XML, а не эксель. да и задачи про обратную выгрузку может и нет — просто сайт-витрина.
Заказы обратно выгружать не захотел сам заказчик, по своим личным причинам. Но если бы уж и потребовалась обработка заказов, то её бы я реализовал наверное так:
1С стучится, по указанному URL, где выводится список новых, необработанных заказов. Далее парсим 1С'кой информацию о новых заказах, пишем её в базу, при успехе отправляем запрос на сайт, подтверждающий успешную обработку заказа. После чего данный заказ пропадает из списка необработанных.
1С стучится, по указанному URL, где выводится список новых, необработанных заказов. Далее парсим 1С'кой информацию о новых заказах, пишем её в базу, при успехе отправляем запрос на сайт, подтверждающий успешную обработку заказа. После чего данный заказ пропадает из списка необработанных.
Да, но по условию была именно 8-ка, поэтому можно было пользоваться всеми её преимуществами.
Да, сначала я тоже задумывался о делении на части, но потом несколько раз попробовал сделать полную, начальную выгрузку. Всё выгрузилось и обработалось на сервере без сбоев. А уж частичное обновление и подавно работает.
Но, да, при больших размерах обмена, действительно стоило бы делить данные на части. Спасибо, за замечание.
Да, сначала я тоже задумывался о делении на части, но потом несколько раз попробовал сделать полную, начальную выгрузку. Всё выгрузилось и обработалось на сервере без сбоев. А уж частичное обновление и подавно работает.
Но, да, при больших размерах обмена, действительно стоило бы делить данные на части. Спасибо, за замечание.
Тоже изобретаю под себя похожий велосипед. Т.к. в 1С ни бум-бум, строки "Создаём план обмена, настраиваем. Дальше модифицируем нашу выгрузку, теперь во время выгрузки создаём новое сообщение в плане обмена, выгружаем только изменённые с момента последнего сообщения единицы… " стали откровением. Теперь хоть знаю в какую сторону копать. Большое человеческое спасибо!
Попросить 1с-ника настроить планировщик выгрузок с удобным для тебя форматом и порядком данных.
Мне самому интересно научиться :-)
рекомендую начать с v8.1c.ru/metod/books/book.jsp?id=187
Оно понятно, что можно самому научиться, но невозможно охватить всё. Проще разделить труд.
ИМХО нужно добавлять? )
ИМХО нужно добавлять? )
Я готов сам подписаться под этими словами. Но такова ситуация на данный момент.
Знаете, вынужден с вами не согласиться. Да, хорошо огородиться и каждому барахтаться в своей песочнице. Но кто-то ведь должен всё это контролировать, искать правильные архитектурные решения, а для этого необходимо знать, как минимум основы всех частей системы.
> Первым делом, конечно, я стал смотреть в сторону CommerceML, но ознакомившись с документацией, стало ясно, что для нашей, достаточно элементарной выгрузки городить весь этот огород — слишком долго, а бюджет не резиновый.
Это оно в документации страшно выглядит, а на деле за полдня у меня получилось сделать полную синхронизацию — заказы в обе стороны, товары, картинки и характеристики товаров.
Плюс большие объёмы 1С раскидывает на части, так что не страшны ограничения сервера на время работы скрипта.
Это оно в документации страшно выглядит, а на деле за полдня у меня получилось сделать полную синхронизацию — заказы в обе стороны, товары, картинки и характеристики товаров.
Плюс большие объёмы 1С раскидывает на части, так что не страшны ограничения сервера на время работы скрипта.
CommerceML в 8.2 кроме УТ отсутствует в виде готовой обработки для связи с ИМ, счастливым владельцам придется писать велосиды или использовать другие форматы или готовые обработчики не от битрикса. Зачем так сделали не знаю, но есть и другие аналоги, не использующие этот формат, но поддерживающие такие конфигурации и локализации.
Думаю это далеко не последний проект. Так что ещё обязательно будет и близкое знакомство с CommerceML ;)
В общем, как обычно: «Посмотрел чужие костыли — не понравились — сделал свои, родные».
Теперь по-делу:
1. Скрипт генерации превьювок надо доработать. Я свой писал, проверяющим время изменения исходного файла картинки и срабатывающего, если превьювки ещё нет или её дата изменения меньше даты изменения исходного файла. Очень экономит ресурсы и нервы особенно для генерации превью для номенклатур OVER 9000 позиций. особенно в вашем случае, кгда это всё запускается на клиентской машине.
Пример скрипта на sh
1.1. Image Magic по мимо ресайза позволяет ещё накладывать водяные знаки.
2. Зачем запускать выгрузку на стороне 1С и на стороне хостинга по планировшику? Что мешает после окончания формирования файла выгрузки, генерации картинок и заливки по FTP дёрнуть CGI-скрипт на стороне хостинга, чтобы инициировать обработку? Сразу отпадут некоторые «подстилки», которые фиксят вопрос «А что если соединение разорвётся?». Если разорвётся — скрипт не будет вызван.
Теперь по-делу:
1. Скрипт генерации превьювок надо доработать. Я свой писал, проверяющим время изменения исходного файла картинки и срабатывающего, если превьювки ещё нет или её дата изменения меньше даты изменения исходного файла. Очень экономит ресурсы и нервы особенно для генерации превью для номенклатур OVER 9000 позиций. особенно в вашем случае, кгда это всё запускается на клиентской машине.
Пример скрипта на sh
#!/bin/sh
dir="/usr/home/www/site"
src="/upload/images"
prevDst="/httpdocs/catalog/prev"
imgDst="/httpdocs/catalog/img"
cmd="/usr/local/bin/convert"
preview(){
${cmd} ${dir}${src}/$1 -auto-level -resize 170x105 -quality 70 -background white -gravity center -extent 170x105 ${dir}${prevDst}/$1
${cmd} ${dir}${src}/$1 -auto-level -resize 280x180 -quality 90 ${dir}${imgDst}/$1
}
cd ${dir}${src}
for f in *.jpg
do
if test -f $dir$prevDst/$f
then
if test `stat -f %c $dir$src/$f` -gt `stat -f %c $dir$prevDst/$f`
then
preview $f
fi
else
preview $f
fi
done1.1. Image Magic по мимо ресайза позволяет ещё накладывать водяные знаки.
2. Зачем запускать выгрузку на стороне 1С и на стороне хостинга по планировшику? Что мешает после окончания формирования файла выгрузки, генерации картинок и заливки по FTP дёрнуть CGI-скрипт на стороне хостинга, чтобы инициировать обработку? Сразу отпадут некоторые «подстилки», которые фиксят вопрос «А что если соединение разорвётся?». Если разорвётся — скрипт не будет вызван.
dbfb
Sign up to leave a comment.
Простая интеграция сайта и 1С