Уже около года OCext оказывает услугу импорта из любого файла поставщика. Всё больше предпринимателей сталкиваются с проблемой невозможности или профессиональной сложности, когда возникает потребность заведения большого количества данных.
Стандартные модули, хотя и дают необходимый функционал, всё же еще до использования модулей, приходится много изучать, разбираться, и учитывать.
Мы помогаем сделать быстро, профессионально и делимся информацией о самом необходимом, что нужно для импорта или налаживания процессов обмена
Вначале немного о важности правильности импорта и обмена. Довольно много наших клиентов приходят за данной услугой тогда, когда неправильное заведение или ведение данных уже привело к убыткам или на многие недели отстрочило запуск магазина. Например, несколько клиентов торговали по не обновившимся ценам себе в убыток, и узнали об этом только после заказа поставщику. Были случаи, когда не обновились остатки и клиентам пошли телефонные звонки с претензиями по сроку доставки. У одного клиента случайно перепутались свойства товара, картинки, и его покупатель обосновано требовал бесплатный возврат или обмен (в другой регион). Также были случаи, когда практически не получалось решить задачу одинаковых артикулов и по этому пришлось отказаться от нового поставщика. Или сложности с большим размером файла, что также приводило к отсрочке введения товаров.
Теперь о хорошем
Применяя это к обмену данными, негативных событий можно избежать вообще. Если с самого начала сделать всё максимально правильно, если знать максимум того, что нужно знать для организации импорта или обмена данными.
Если на входе используется импорт XML – сначала следует ознакомиться с форматом XML. XML - это DOM-формат – достаточно простой для освоения. Такой же простой как HTML (еще одна разновидность формата DOM). Не редко встречается и комбинация форматов. Например, XML содержит в себе JSON, HTML или собственную микроразметку. Каждое такое включение в базовый формат, требует наличия парсеров этих включений в модулях импорта и обмена.
При использовании спецификации на базе XML (например, YML) необходимо почитать не только про XML, но и спецификацию YML – это примерно как выучить язык, но с небольшим числом слов – задача простая. На это понадобится время, но времени уйдет немного. YML – Yandex Market Language. Для чего это учить? Хотя бы для того, чтобы удостовериться, что перед Вами действительно YML. Или, как это часто бывает, на самом деле всего 60% от YML, а всё остальное - это теги и атрибуты, которые введены в документ разработчиком поставщика. Который применил собственный язык описания данных, но не предупредил Вас об этом. Вы ищете и покупаете парсеры YML, а у Вас не YML в принципе. Проверить схему YML, например, можно здесь
CSV – простой текстовый формат. Простота открывает огромное число возможностей для использования. Однако в этом состоит и главный нюанс формата. Упаковать в него можно всё, что угодно, и как угодно. Но правильно это сделать можно только, если иметь ввиду то, чем будет парситься данный документ в последствие. Далеко не всё можно извлечь, если оно сложено неверно или не под конкретный парсер.
Excel-файлы – не являются обменным форматом. Существуют расширения, которые умеют работать с XLS на стороне web-сервера, однако, фактически они работают с таблицей, которая остается после обработки XLS этими расширениями. С тем самым «CSV» (который и придуман в рамках Excel), и который образуется, уже как результат обработки excel-файла не путем экспорта в CSV из программы, а прямо на сервере. Тут кроется еще один нюанс. Визуальный (семантический и синтаксический) контроль формата XLS по содержимому файла осуществить невозможно. А гибкость excel, как программы, позволяет делать из содержимого красивые документы, но такие документы, которые в принципе невозможно использовать без существенной ручной дообработки. Даже, если нет желания, оплачивать специалиста, которые сделает качественную переупаковку данных из XLS и в CSV, всё равно её нужно будет делать. И делать с учетом требований средств импорта, и с учетом архитектуры данных, в рамках которой должны быть заведены эти данные. Это важно учитывать, потому что с XLS – это точно неизбежно
JSON, API – данные подходы, в принципе невозможно самостоятельно освоить, без разработчиков. Это сразу упустим.
При любом обмене данными нужно делать бекап базы данных. На эту тему отлично написано на нашем партнере – хостинге IHC.RU
«Говорят, что люди делятся на тех, кто не делает бэкапы, и на тех, кто уже делает :-)»
При любом обмене данными очень важно вести лог всех операций. Абсолютно всех. Лог нужен не только для ситуаций, чтобы убедиться, что всё прошло успешно. Но и чтобы вернуться к нему потом, если случайно выяснится, что на самом деле, были ошибки. Чтобы избежать этих ошибок в будущем. Лог позволяет найти, когда началась ошибка. Системная ли она, или ограничена чем-то незначительным, выяснить связана со сбоем сервера или сбоем удаленного сервера
Если при импорте устанавливались остатки, цены и тем более, если менялись эти значения. Все эти параметры, а также другие параметры, которые могут быть сверены по числовому значению, должны обязательно сверяться в начале и в конце. Часть из них проверяется выборочно. Достаточно проверить приблизительно 1-3%, чтобы экстраполировать успех или не успех на всю операцию в целом. Мы используем автоматизацию, чтобы проверять документы, но если автоматизации нет, то можно пользоваться простейшими редакторами, и через функцию «найти / заменить», или путем функций в ексель, делать проверочные расчеты.
Помните, когда Вы ставили CMS на сервер – сервер спрашивал Вас о кодировке? Зачем? Как только кодировка сайта установлена, с этого момента все потоки данных будут кодированы на её базе. По этому, если осуществляется импорт или обмен важно точно знать о кодировке входящих данных.
Кракозябры – это не ошибка – это вывод одной кодировки данных средствами другой. Ну, примерно, как говорить с акцентом, не будучи носителем языка. Можно что-то понять, но выглядит это забавно.
Также нужно учитывать, что php нет однозначных решений для перекодирования не латинских символов, без проблем и сразу. Поэтому на входе, чтобы исключить проблемы с кодированием, нужно подавать документы в той кодировке, в которой создана база данных, и в той, на базе которой созданы файлы сайта.
Форматы – это языки описания чего-либо. Как у любого языка, у формата есть правила. Что-то вроде «жи», «ши» - пиши с буквой «и». Есть и языки, которые образованы на других языках, где правил больше, но сохранена преемственность. Перед импортом, перед каждым импортом, в том числе, перед автоимпортом нужно смотреть документ и различными инструментами проверять синтаксис. Или на лету, при автооимпорте, или вручную.
Каждый документ нужно проверять визуально, человеком, который выборочно сможет отследить связи одних данных с другими. Почему это нужно делать, смотрите в разделе «у поставщика всё правильно»
Когда проводник Windows выбрасывает окно – «нет места на диске» – это означает корректную работу Проводника, и корректную работу жесткого диска. Смысл данной проблемы не в том, что нужен новый Проводник, а в том, что все данные – затрачивают ресурсы памяти физической, и оперативной, ресурсы времени. И это важно учитывать.
У каждого хостинга есть ограничения на использование времени, размера передаваемых файлов на сервер и многих других параметров – в совокупности только базовых настроек несколько десятков.
И если стоит задача импорта чего-то с числом более 1000, то могут возникнуть всякие интересные вещи. Упустим ситуацию, когда хостинг элементарно скрывает, и дает меньше ресурсов, чем сам же пишет. Это на грани, что называется… Самые распространённые ситуации, это параметры max_input_vars, max_execution_time, memory_limit и несколько других, которыми регулируется работа базы данных, и сервера, времени и объемов различной памяти
У поставщиков всё правильно – это так. Однако в своей работе мы обязательно проверяем правильность. И именно потому что мы это делаем, мы хорошо знаем, что не всегда это так.
Это связано не только с тем, что проверку нужно делать в принципе, с точки зрения технологии, но и с тем, что данные могут быть изменены случайно, или в результате сбоя сервера. По ходу импорта, или в ходе обмена. В последнее время также на хостингах всё чаще ставится защита от парсерсеров. Но владелец сайта может и не догадываться об этом. В итоге при импорте на определенном объеме данных происходит замедление или вообще остановка процесса импорта. Особенно, если речь идет о затягивании картинок со стороннего сервера.
Завершить хочется тем, что поставщики и владельцы магазина не обязаны знать всё досконально, чтобы сделать импорт, обмен данными. Эта профессиональная обязанность ложится на администраторов сайтов, разработчиков – вообщем всех тех, кто обслуживает сайты. И если Ваш разработчик говорит о невозможности импорта, то не всегда это не так.
Со своей стороны еще до услуги импорта, и обмена мы точно говорим будет результат или нет. Как правило на импорт одного документа уходит 1-2 дня.
