Pull to refresh

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/
Т.е. на стороне сайта парсится именно xls?
Ну да, эксель файл можно сразу класть как «Скачать прайс» или посмотреть что нужно онлайн. Объемы небольшие, время работы скрипта 0.1с для 100кб файла.
В моём случае в xls было не достаточно информации для обновления каталога, он вообще был лишь побочным продуктом и добавлялся уже после того как был разработан прототип.
И ещё такой недостаток: в xls отсутствовал уникальный код/идентификатор для каждого товара, а значит, что обновлять было бы уже нельзя. Как скрипту установить соответствие между товаром в каталоге и обновлённом xls? По названию? Ну, во-первых, название может вдруг оказаться не уникальным, а во-вторых, оно ведь может и измениться. Поэтому пришлось бы, разве что, каждый раз затирать весь каталог и писать его заново, что мне кажется, было бы не совсем гладким решением. Поэтому и выгружал всё именно xml.
Я не спорю. В эксель выгружается название, количество и цена. Номенклатура небольшая.
Сам буду на xml переделывать, если прототип одобрят.
А почему сразу не сделать с использованием xml?
Начал путь по другому, попросил сделать мне выгрузку остатков из 1с для тестов. Получил xls файл, полез в гугл, нашел phpexcelreader, сделал такой вариант. Затем узнал что 1с умеет делать выгрузки в другие форматы, задумался :)
Весь процесс был для души побыдлокодить на похапе.
если уж планы обмена, то надо бы сделать на сайте счетчик полученных сообщений и в ответ 1су класть файлик с номером последнего загруженного из 1 с сообщения (его, естесственно, в xml надо добавить). тогда если при загрузке скриптом на сервере произошла ошибка (мало ли, память кончилась, или еще чего) — 1с просто выгрузит эти данные еще раз + новые изменившиеся. Да и в таком случае видно будет, что загрузка не производилась долгое время — пора бить в бубен тревогу.

А вообще — для не онлайн обмена — вполне вариант. еще картинки можно (допустим) в base64 пихнуть внутрь XML, чтобы файл один был (меньше файлов — крепче спим ИМХО)
На сайте и есть счётчик сообщений, и в админке видна полная статистика, вплоть до того сколько и когда изменилось.
Если скрипт рухнет в момент обработки, то он не удалит архив с сообщением и при следующем запуске попробует вновь, т.е. данные утеряны не будут.
Складывать в xml картинки смысла было мало. Боюсь, что php-скрипт, который вытаскивает их из xml и сохраняет поштучно, будет работать медленнее, нежели вызываемая внешняя утиль, специально заточенная под подобные операции. Но соглашусь с вами, действительно как вариант это можно иметь ввиду. Спасибо.
Я делал такой проект для знакомых.
Выгрузка в csv из 1C -> парсинг и заливка уже средствами PHP.
Экспорт в xls тоже уже на стороне сайта.
Наверное до сих пор работает (URL не даю — зачем хабраэффект маленькому вебмагазину?)
Да, думаю URL нам знать не обязательно, а вот услышать рассказ о подробностях создания всего механизма было бы очень интересно ;)
схема была такая:
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, а не эксель. да и задачи про обратную выгрузку может и нет — просто сайт-витрина.
Ага xml, меджиком можно еще ватермарк на изображения наложить для красоты. 5000 товаров это приличный магазин, руками заказы обрабатывать уже напряжно. Так же можно выгрузить характеристики, если они есть. Синхронизировать покупателей и т.д. Всегда будет хотеться большего :)
Да, ImageMagick вообще очень мощная библиотека, которая уже выручала не раз, да и сколько ещё раз выручит!

Думаю, что скоро будет проект, где как раз и будет синхронизация покупателей, выгрузка скидок, заказов, детали обработки заказов и тд.
Заказы обратно выгружать не захотел сам заказчик, по своим личным причинам. Но если бы уж и потребовалась обработка заказов, то её бы я реализовал наверное так:
1С стучится, по указанному URL, где выводится список новых, необработанных заказов. Далее парсим 1С'кой информацию о новых заказах, пишем её в базу, при успехе отправляем запрос на сайт, подтверждающий успешную обработку заказа. После чего данный заказ пропадает из списка необработанных.
А почему бы тогда уж не использовать планы обмена полностью? тогда и получение заказов с ответным пакетом и обновление статусов в выгрузке на сайт — всё в одном месте
Да, но по условию была именно 8-ка, поэтому можно было пользоваться всеми её преимуществами.

Да, сначала я тоже задумывался о делении на части, но потом несколько раз попробовал сделать полную, начальную выгрузку. Всё выгрузилось и обработалось на сервере без сбоев. А уж частичное обновление и подавно работает.
Но, да, при больших размерах обмена, действительно стоило бы делить данные на части. Спасибо, за замечание.
Тоже изобретаю под себя похожий велосипед. Т.к. в 1С ни бум-бум, строки "Создаём план обмена, настраиваем. Дальше модифицируем нашу выгрузку, теперь во время выгрузки создаём новое сообщение в плане обмена, выгружаем только изменённые с момента последнего сообщения единицы… " стали откровением. Теперь хоть знаю в какую сторону копать. Большое человеческое спасибо!
Попросить 1с-ника настроить планировщик выгрузок с удобным для тебя форматом и порядком данных.
Мне самому интересно научиться :-)
Спасибо, книжками уже затарился
Оно понятно, что можно самому научиться, но невозможно охватить всё. Проще разделить труд.
ИМХО нужно добавлять? )
Я готов сам подписаться под этими словами. Но такова ситуация на данный момент.
Понятно, сам занимался всем. Утомляет.
Утомляет, очень, но зато позволяет узнать все тонкости и потенциально узкие места системы.
Знаете, вынужден с вами не согласиться. Да, хорошо огородиться и каждому барахтаться в своей песочнице. Но кто-то ведь должен всё это контролировать, искать правильные архитектурные решения, а для этого необходимо знать, как минимум основы всех частей системы.
Так я первым комментарием написал, что недавно делал всё то же самое, но только чтобы побыдлокодить.
> Первым делом, конечно, я стал смотреть в сторону CommerceML, но ознакомившись с документацией, стало ясно, что для нашей, достаточно элементарной выгрузки городить весь этот огород — слишком долго, а бюджет не резиновый.

Это оно в документации страшно выглядит, а на деле за полдня у меня получилось сделать полную синхронизацию — заказы в обе стороны, товары, картинки и характеристики товаров.
Плюс большие объёмы 1С раскидывает на части, так что не страшны ограничения сервера на время работы скрипта.
CommerceML в 8.2 кроме УТ отсутствует в виде готовой обработки для связи с ИМ, счастливым владельцам придется писать велосиды или использовать другие форматы или готовые обработчики не от битрикса. Зачем так сделали не знаю, но есть и другие аналоги, не использующие этот формат, но поддерживающие такие конфигурации и локализации.
Думаю это далеко не последний проект. Так что ещё обязательно будет и близкое знакомство с CommerceML ;)
В общем, как обычно: «Посмотрел чужие костыли — не понравились — сделал свои, родные».

Теперь по-делу:
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

done


1.1. Image Magic по мимо ресайза позволяет ещё накладывать водяные знаки.

2. Зачем запускать выгрузку на стороне 1С и на стороне хостинга по планировшику? Что мешает после окончания формирования файла выгрузки, генерации картинок и заливки по FTP дёрнуть CGI-скрипт на стороне хостинга, чтобы инициировать обработку? Сразу отпадут некоторые «подстилки», которые фиксят вопрос «А что если соединение разорвётся?». Если разорвётся — скрипт не будет вызван.
Sign up to leave a comment.

Articles