PHP и Битрикс: Пошаговое выполнение процесса

Насколько нам известно, выполнение любого действия несколько тысяч раз может занимать приличное время.
1. пользователь любит прогресс-бары и счётчики
2. пользователь не любит, когда ничего не происходит
3. пользователь любит возможность остановить происходящее
4. времени на выполнение браузеру может тупо не хватить

Примеры таких задач в битриксе - импорт разнообразных типов, или, как это было у меня - удаление задач в КП по определённому условию. Запускаются такие процессы из браузера по желанию юзверя и должны выполняться, показывая текущий статус обработки.

Оставим оформительскую красоту для дизайнеров и реализуем счётчик и простенький прогресс-бар.

Сначала понимаем, что надо сделать на первом шаге, затем что на втором, и что на шаге n-1 и n. Находим точку повторения и точку окончания. Итого:

1. на странице есть кнопка запуска, информационный блок со статистикой и js-обработчики: запуска процесса и обработки результата
2. по клику на кнопке передаём номер шага (и/или другие необходимые параметры)
3. ajax-приёмник обрабатывает шаг, формирует json с необходимой информацией для статуса и возвращает его вызывающей функции.
4. функция обработки результата парсит инфу, выводит статус, решает, надо ли запускать следующий шаг и, соответственно, запускает следующий шаг или заканчивает работу процесса

Прогресс бар реализую с помощью тега progress. Управлять им очень просто:
* максимальное значение задаётся атрибутом max
* текущее значение задаётся атрибутом value
* можно управлять внешним видом с помощью стилей
* минус у него один - это HTML5 и не всеми он поддерживается. Но я показываю его для примера, так что можете реализовать прогресс-бар по старинке - на дивах =)

Json легко парсит функция JSON.parse, превращающая его в объект, с которым уже можно работать дальше.


Пошаговая заготовка из статьи

Дока по тегу progress
Дока по объекту JSON
И ещё про JSON для тех, кому совсем интересно

Битрикс. Похожие товары.

Как известно, формулировка "похожести" у каждого заказчика своя. В данном варианте от меня требовалось создать компонент, возвращающий айдишки продуктов, "похожих" по следующим условиям:

1. цена хотя бы одного торгового предложения искомого продукта не должна отличаться более чем PRICE_INTERVAL от цены исходного продукта
2. искомый продукт должен лежать в той же секции, что и исходный продукт

Битрикс и Инстаграм. Собираем фотки по хештегу для конкурса.

Устраивать конкурсы в инстаграме сейчас модно. И удобно. Инстаграм предоставляет достаточно обширный API, который позволяет делать практически всё, что может сделать обычный пользователь ручками.

Составляем в мозгу логику действий
1. Создание ИБ Конкурсов и ИБ Фоток для конкурсов.
2. Конкурсы создаются ручками операторов. Свойствами конкурсов являются Название, Активность, Время начала действия, Время окончания действия, Хештег, Описание, Результат, Разрешение работы скрипта.
3. Фотки получаются скриптом для конкурса методом обращения к Инстаграм API и сохраняются в базе (ссылки на фотки).


И если с первым и вторым пунктом справятся контент-менеджеры, то с третьим пунктом у них возникнут сложности. И тут на сцену выходит разработчик.

Битрикс КП. Импорт задач из XLSX файла.

Ранее в одном из наших КП добавление задач обрабатывалось бизнес-процессами, сейчас задач стало столько, что бизнес-процессы стали неуместны, и понадобился инструмент для массовой заливки задач на КП.

Итак, есть xlsx файл со списком задач. Из него можно узнать

• TITLE
• DESCRIPTION
• RESPONSIBLE_ID
• CREATED_BY
• START_DATE_PLAN
• END_DATE_PLAN

а также можно вычислить GROUP_ID и несколько свойств, которые были добавлены к задачам.

Сегодня:

• загружаем файл без перезагрузки страницы
• обрабатываем xlsx файл с помощью сторонней библиотеки
• добавляем свои свойства к задачам
• добавляем задачи в базу КП по конкретным группам

Битрикс. Раздаём заказы нескольким операторам.

Пришла задача написать системку распределения заказов для операторов. Первоначальное задание:
1. Нужна страничка с одной кнопкой. Оператор нажимает эту кнопочку и получает заказ на обработку.
2. Оператор может:

• Отказаться от заказа (например, не дозвонились пользователю). В этом случае заказ спит некоторое время, а потом возвращается.
• Отменить заказ штатной кнопочкой Отменить - у нас это равносильно по смыслу удалению заказа (удалять заказы операторам нельзя)
• Изменить статус заказа, чем снимает с себя обязательства по обработке заказа, закрывает заказ.
• И пограничный случай - если заказ заблокирован кем-то ещё, то оператор может снять с себя этот заказ. Пример - создание тестовых заказов, которые обрабатываются непосредственно теми, кто тестирует. В этом случае заказ оператору может попасть, но будет перехвачен из реального списка тестировщиком.

После некоторых дебатов, было решено делать это всё отдельным модулем, чтобы удобнее дополнять, внедрять и весь код был в одном месте.

Версия модуля предварительная, доработок там требуется ещё с тонну. Код - жестокая смесь двух стилей - стандартного битриксового и D7. Где получалось - исправила на D7. Вообще, возможностей нового ядра пока чуток не хватает (про документацию лучше помолчу).
Итак, сегодня в статье микс из описаний использованных решений и самой схемы работы модуля.