Документація за коробковою версією «Бітрікс24. Завершення майстра установки

Bitrix Framework - технологічне ядро ​​(платформа) для створення та управління проектами (веб-сайтами та корпоративними порталами). Платформа дозволяє створювати необмежену кількість проектів із застосуванням однієї копії (ліцензії) продукту, розміщуючи ядро ​​та базу даних системи в єдиному екземплярі на сервері.

на Наразіне всі можливості старого ядра продубльовані в D7. Але нове ядро ​​D7 в Bitrix Frameworkпоступово заміняє старе. Якщо використання старого ядра призвело до запобігання IDE: Method/class is deprecated , то потрібно використовувати методи .

Через ряд причин API документація може охоплювати всі методи. Для розуміння роботи іноді краще переглянути програмний код. Для цього можна використати безкоштовний модульз Маркетплейсу: .

Примітка: додавши до адреси будь-якої сторінки #examples, можна швидко перейти до прикладу, якщо він на ній є. (У файлах документації формату CHM це не працює.)

Версії сутностей

Bitrix Frameworkпостійно розвивається. З'являються нові функції, деякі старіють, у функціях з'являються нові параметри. Проте досить багато проектів не оновлюються. Для полегшення програмістської праці в документації проставлено з якою і за якою версією продукту клас, метод, параметр, подія існували (існують).

Версії проставляються у двох місцях: у назві та у таблицях. Якщо метод діє, то в заголовку стоятиме лише номер версії, з якої він з'явився в продукті. Якщо метод застарів, то там буде вказаний діапазон версій, де він був діючий.

У таблицях вказується версія, з якою сутність виникла продукті, лише тому випадку, якщо її поява не збігається з моментом появи самого класу, методу тощо. На ілюстрації нижче: параметр COURSE_ID з'явився разом із методом (тобто з 5.1.0), а параметр CHAPTER_ID лише з версії 9.5.4.

Якщо з розвитком продукту параметр (зазвичай це стосується параметрів) змінювався, буде відповідне примітка у його описі. (Наприклад: до версії х.х.х параметр називався *****).

приклад

Примітки:

• Позначка Застарівметод, параметр, ключ означає, що його не рекомендується використовувати так як розширень і виправлень не буде.
• Простановка версій виконана в повному обсязі, роботи у цьому напрямі ведуться на даний момент.

"Бітрікс", 2001-2019, "1С-Бітрікс", 2019

Інтеграцію інтернет-магазину на 1С-Бітрікс із системою можна провести за допомогою модуля системи у Bitrix.Marketplace.

Під час встановлення модуль допоможе вивантажити існуючі замовлення в систему.

Після встановлення модуль буде:

• проводити вивантаження нових замовлень з 1С-Бітрікс у систему;
• проводити оновлення даних за існуючими замовленнями з урахуванням змін, внесених до 1С-Бітріксу;
• проводити вивантаження нових замовлень та клієнтів із системи в 1С-Бітрікс;
• проводити оновлення даних за існуючими замовленнями з урахуванням змін, внесених до системи (наприклад, у системі було змінено статус замовлення, кількість товарів у замовленні та ін., у 1С-Бітрікс ці зміни також будуть відображені);
• надсилати в систему інформацію про онлайн-оплату замовлення користувачем.

Також існує можливість кастомізації класів плагіна без втрати модифікованого коду при оновленні. Щоб впровадити модифікований код, необхідно розмістити копію файлу з потрібним класом у директорії bitrix/php_interface/retailcrm .

У плагіні є можливість кастомізації наступних файлів:

RestNormalizer.php
Logger.php
Client.php
RCrmActions.php
RetailCrmUser.php
RetailCrmICML.php
RetailCrmInventories.php
RetailCrmPrices.php
RetailCrmCollector.php
RetailCrmUa.php
RetailCrmEvent.php
RetailCrmHistory_v4.php
RetailCrmHistory_v5.php
RetailCrmOrder_v4.php
RetailCrmOrder_v5.php
ApiClient_v4.php
ApiClient_v5.php

Для кастомізації файлів, в назві яких є версія API, створюються файли з назвою без вказівки версії, наприклад - RetailCrmHistory.php .

Після створення копії файлу з класом у директорії bitrix/php_interface/retailcrm модуль буде використовувати кастомізований клас, можете вносити зміни до його методів.

Реєстрація інтернет-магазину в системі

Перед встановленням зареєструйте Ваш інтернет-магазин у Вашому екземплярі системи (розділ Адміністрування > Магазини, наприклад, демо-версії):

Встановлення рішення в 1С-Бітрікс

• Натисніть «Встановити» на сторінці рішення у Marketplace та вкажіть адресу Вашого інтернет-магазину:

• Завантажте модуль через Систему оновлень 1С-Бітрікс:

• Почніть встановлення модуля:

Запуститься майстер установки.

Майстер установки. Крок 1

На кроці 1.1 Вам необхідно вказати адресу Вашої системи (наприклад, https://test.retailcrm.ru) та API-ключ, який Ви згенерували раніше у системі:

Важливо! Якщо в бітріксі існує лише один магазин, крок 1.Сайти пропускається.

Майстер установки. Крок 1. Сайти

На кроці 1.Сайти необхідно задати відповідність між Вашими магазинами в 1С-Бітрікс та системою.

Важливо! У всіх Ваших магазинах у системі має бути спільний API-ключ.

Майстер установки. Крок 2

На другому етапі необхідно вказати відповідність значень довідників інтернет-магазину та системи. Модуль сам намагається встановити відповідність типових статусів. Там, де це не вдалося зробити модулю, потрібно вказати відповідність самостійно:

Перевірте, чи є у системі необхідні значення довідників, які відповідають довідникам інтернет-магазину. Якщо їх недостатньо, додайте їх у розділі Адміністрація, не закриваючи сторінку майстра установки:

Після цього оновіть сторінку майстра: нові значення довідників мають підвантажитись.

Майстер установки. Крок 3

На третьому кроці модуль дозволяє задати відповідність між полями 1С-Бітрікс та системи.

Важливо! Якщо є форма « зворотнього зв'язку» або замовлення «в 1 клік», і ці дані не потрапляють у стандартні замовлення бітрікс, то вони не підтягуються в систему.

Також, якщо ведеться робота з юридичними особами, необхідно заповнити всі поля, як зазначено на скріншоті нижче.

Майстер установки. Крок 4

На четвертому етапі модуль дозволяє Вам вивантажити оформлені раніше замовлення до системи. Вивантаження може тривати деякий час (1000 замовлень вивантажуються близько 5 хвилин). Хід процесу вивантаження показуватиме прогрес-бар.

За потреби Ви можете зупинити вивантаження та відновити знову через деякий час.

Вивантаживши раніше оформлені замовлення, Ви зможете побачити аналітичні звіти в Панелі KPI. Ми рекомендуємо виконувати цей крок.

Майстер установки. Крок 5

На п'ятому етапі налаштовується вивантаження каталогу товарів. Для цього потрібно виконати такі пункти.

1. Вибір інфоблоків та властивостей

Вибрані інфоблоки будуть вивантажені до системи. На вибір вам буде запропоновано лише ті інфоблоки, які містять товари або мають прив'язані інфоблоки з торговими пропозиціями. Паралельно з вибором інфоблоків можна вибрати такі властивості: артикул, виробник, колір, вага, розмір – для цього необхідно вказати властивість інфоблоку, яка відповідає за збереження відповідної властивості. Вибір якості не є обов'язковим.

2. Шлях до файлу

По вказаному шляху буде згенеровано файл у форматі , у якому буде структура каталогу. За замовчуванням встановлено шлях - "/bitrix/catalog_export/retailcrm.xml". У разі зміни шляху, потрібно виконання аналогічного налаштування в системі.

3. Налаштування кількості офферів в експорті

У налаштуваннях експорту каталогу є поле «Максимальна кількість торгових пропозицій у товару», де необхідно вводити максимальну кількість торгових пропозицій, які можуть бути в одного товару (якщо їх більше 50). За замовчуванням модуль розраховує максимум на 50 торгових пропозицій товару. Якщо торгових пропозицій у магазині менше 50 на товар, це можна ігнорувати. Якщо торгових пропозицій більше і налаштування вказується, рекомендується переводити агент на крон, якщо він працює на хітах.

4. Вибір періодичності розвантаження

На вибір буде дано три варіанти:

1. Ні- при виборі даного пункту автоматично не буде настроєно періодичне вивантаження каталогу, і Вам доведеться вивантажувати каталог щоразу самостійно.

Цей варіант може бути корисним, якщо каталог товарів Вашого інтернет-магазину змінюється дуже рідко, або Ви хочете налаштувати параметри розвантаження пізніше.

2. Cron- Вибір цього пункту призведе до автоматичного створення спеціального профілю, який буде прив'язаний до служби Cron сервера, на якому функціонує сайт інтернет-магазину.

Утиліта cron працює в фоновому режиміта виконує зазначені завдання у вказаний час.

Вибір цього пункту може бути корисним, якщо каталог містить дуже велику номенклатуру ( понад 10 000 товарів). Для цього пункту необхідно вказати назву спеціального профілю експорту.

3. Агент. В даному випадку також буде створено спеціальний профіль, який підключиться до технології «Агенти» в 1С-Бітрікс, і вивантаження буде відбуватися. автоматично раз на добу.

Агент – це php-функції, які запускаються з певною періодичністю. На початку завантаження кожної сторінки система автоматично перевіряє, чи є агент, який потребує запуску, та у разі потреби виконує його. Не рекомендується створювати агентів для тривалих вивантажень - краще використовувати cron.

Даний варіант найкращий, якщо каталог містить менше 10 000 товарівВивантаження відбувається досить швидко, і це ніяк не позначиться на швидкості роботи сайту інтернет-магазину.

У разі великої номенклатури ( понад 10 000 товарів), необхідна додаткове налаштуванняАгенти на Cron. Для цього пункту необхідно вказати ім'я спеціального профілю експорту.

4. Вказівка ​​моментального розвантаження

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

Після вивантаження каталогу в файл в системі необхідно зайти в розділ Адміністрування -> Магазин -> Назва магазину -> Вкладка "Каталог" і поставити галочку в полі "Завантажити каталог із ICML зараз". У цьому випадку завантаження файлу та його обробка починаються практично моментально.

5. Вказівка ​​ім'я профілю

Після коректного налаштування вивантаження каталогу товарів, у розділі Магазин > Установки > Експорт даних з'явиться новий вид експорту системи, у разі вказівки періодичного вивантаження при встановленні також з'явиться профіль експорту.

Примітка:
Для самостійного налаштуванняВивантаження є можливість створення власного профілю експорту.

Завершення майстра установки

В кінці установки буде створено 2 агенти: один агент вивантажує історію замовлень з Бітрікс в систему, другий агент генерує каталог. Якщо вивантаження замовлень налаштовано на агент, то замовлення вивантажуються в систему на момент виклику історії. В інших випадках замовлення вивантажуються за подією.

Вивантаження служби доставки під час обміну 1С-Бітрікс – система

Якщо у вас до 1С-Бітрікс підключені автоматизовані служби доставки, такі як eDost, які мають багато профілів: Пошта Росії, EMS, DHL та багато інших, то в системі Ви можете скористатися можливістю вивантаження такого роду служби доставки.

На боці системи мають бути налаштовані способи доставки. Якщо модуль системи був встановлений до підключення служби доставки до Бітрікс, то недостатні способи доставки потрібно буде завести в систему вручну. Якщо модуль встановлено після підключення служби доставки, то способи доставки встановляться автоматично, як і саме вивантаження служби. Тобто для кожного замовлення вивантажуватиметься вартість доставки.

На стороні 1С-Бітрікс необхідно зробити наступні налаштування, якщо модуль системи було встановлено після підключення служби доставки до системи 1С-Бітрікс:

Перейдіть до Адміністрація > Установки, перейдіть на вкладку "Установки довідників".

Налаштуйте відповідність способів доставки (попередньо налаштувавши на стороні системи). Далі натисніть кнопку "Вивантаження служб доставки".

Налаштування періодичності вивантаження 1С-Бітрікс – система

При оновленні каталогу товарів можна виділити два моменти:

Генерація каталогу (у форматі yml/icml) на стороні клієнта та

Система завантажує каталог разів на три години. Шлях до файлу, який необхідно вивантажити, задається в налаштуваннях магазину – потрібно зайти до розділу Адміністрація > Магазини > Вибрати магазин > Вкладка Каталог.

Після встановлення модуля системи в 1С-Бітрікс створюється профіль для розвантаження. Щоб подивитися, потрібно зайти в Робочий стіл > Магазин > Установки > Експорт даних. На скріншоті представлено два варіанти:

За замовчуванням,

Вивантаження каталогу системи.

Якщо вибрати другий варіант, натиснувши на нього, можна відкрити параметри вивантаження.

У випадку, якщо варіантом періодичності обраний Агент, щоб переглянути список Агентів, потрібно зайти в Робочий стіл > Установки > Установки продукту > Агенти.

Якщо натиснути "Редагувати" або "Додати новий", можна призначити або змінити періодичність запуску завдання на генерацію.

Періодичність синхронізації даних під час обміну 1С-Бітрікс – система

Модуль системи дозволяє вивантажувати каталог товарів у вашу систему, а також проводити регулярний двосторонній обмін замовленнями та клієнтами.

При своєчасному розвантаженні даних із каталогу менеджери вашої системи матимуть актуальну інформацію про наявність товару. Ситуація, коли товар замовлений, а через якийсь час з'ясовується, що його немає, не виникне.

Обмін замовленнями – це процес синхронізації даних, коли замовлення вивантажуються в обидві сторони:

З 1С-Бітрікс в систему:

• Якщо увімкнено вивантаження за подіями, при створенні або зміні замовлення в системі 1С-Бітрікс, він відразу ж вивантажиться в систему. Якщо вибрано агент вивантаження, то замовлення вивантажиться в систему протягом 15 хвилин (не рекомендується використовувати цей механізм без вагомих причин, тому що в цьому випадку замовлення приходять із затримкою та оновлення цих замовлень в систему не будуть передані).
• При зміні користувача основні дані також відразу вивантажаться в систему.

Із системи в 1С-Бітрікс:

• Якщо в системі створити замовлення для нового користувача, то в 1С-Бітрікс вивантажиться замовлення та створиться Новий користувачв інтервалі від 1 до 15 хвилин.
• Якщо в системі на сторінці замовлення змінити адресу, вартість доставки або статус, всі ці зміни вивантажаться в 1С-Бітрікс протягом 15 хвилин.
• Якщо в системі змінити знижки у товарів та змінити кількість товарів – це зміниться і в 1С-Бітрікс у проміжку від 1 до 15 хвилин.

Зміни у модулі інтеграції

Версія 2.0

• Модуль інтеграції версії V2.0 призначений для інтеграції 1C-Бітрікс із встановленим у ньому модулі "Інтернет-магазин (sale)" версії > 16.
• Тепер робота модуля здійснюється за допомогою API V4.
• У модулі інтеграції тепер використовується нове ядро ​​1С-Бітрікс D7.
• Тепер із системи на сайт також приходять зміни по клієнту (П.І.Б., email, телефон).
• У налаштуваннях модуля інтеграції в розділі "Інші налаштування" з'явилася можливість транслювати номери замовлень із системи в 1C-Бітрікс. Тобто, якщо в системі створити в ручному режимі замовлення з номером, наприклад, 12345R, то 1С-Бітрікс створиться замовлення з таким же номером.
• Так як у модулі "Інтернет магазин(sale)" версії > 16 розробники Бітрікс пішли від застосування знижок до всього замовлення і залишили знижки тільки у товарів, то в системі поки що також немає можливості використовувати знижки до всього замовлення. Можна задавати знижки лише до конкретних позицій замовлення.

Версія 2.1

• Додані одиниці виміру в експорті каталогу.

Версія 2.2

• Тепер модуль підтримує кілька версій API із можливістю вибору.
• Підтримка API V5.
• Додано можливість вивантаження залишків у розрізі складів.
• Додано можливість вивантаження типів цін.
• Додано базову інтеграцію Daemon Collector.
• Додано інтеграцію з Universal Analytics.
• Доопрацьовано логіку роботи вбудованих функцій для модифікації даних.
• Додана вбудована функція retailCrmApiResult.
• Додано тригерний варіант історії змін.

Версія 2.4

• Додано перевірку в обробнику збереження оплати на нове замовлення.
• Додано налаштування кількості торгових пропозицій в експорті.
• Додано конвертацію закупівельної ціни.
• Зміна файлів перекладів.
• Додано перевірку у вивантаженні змін із системи для властивостей замовлення.
• Додано вивантаження ПДВ.
• Виправлено одержання списку типів цін для розвантаження. Для вибору доступні всі типи, які є в Бітріксі.

Інші налаштування

Налаштування замовлень

Транслювати номери замовлень створених у ЦРМ до магазину

При створенні замовлення в системі у нього формується свій унікальний номер за заданими правилами. При виставленні цього параметра в модулі номер такого замовлення буде передано до магазину при зворотній синхронізації.

Вивантаження замовлень

• За подією- за збереження замовлення дані йдуть у систему;
• Агентом- виконується надсилання нових замовлень перед запитом історії змін із системи.

Версія API клієнта

Тепер можна вибирати вірю API, з якою працюватиме модуль. Можливість вибору залежить від системи. Рекомендується вибирати найновішу версію.

Включити вивантаження залишків у розрізі складів (доступно за наявності складів)

Тепер можна здійснювати періодичне вивантаження залишків зі складів сайту до складу системи. Для цього потрібно:

• зробити зіставлення складів сайту зі складами системи;
• вказати магазини системи, в які вантажитимуться залишки;
• вибрати інфоблоки з товарами, необхідних завантаження залишків (обирати необхідно ті, які вказані в експорті каталогу системи).

Вивантаження здійснюється агентом з періодичністю 1 годину (за замовчуванням).

Зверніть увагу, що для завантаження залишків у систему повинні бути включені опції .

Включити вивантаження типів цін для товарів (доступно лише за наявності кількох типів цін)

Тепер можна здійснювати періодичне вивантаження додаткових типів цін із магазину до системи. Для цього потрібно:

• зробити зіставлення типів цін сайту з типами цін системи;
• вказати магазини системи, в які будуть вантажитися додаткові типи цін;
• вибрати інфоблоки з товарами, для яких потрібно завантаження додаткових типів цін (вибирати потрібно ті, що вказані в експорті каталогу системи).

Вивантаження здійснюється агентом з періодичністю 24 години (за замовчуванням).

Активувати Демон Collector

Тепер з інтерфейсу налаштувань можна додати до сайту Демон Collector. Для цього потрібно зазначити відповідний ключ для потрібного сайту. Ключ можна знайти у системі.

Включити інтеграцію з UA

Тепер з інтерфейсу налаштувань можна увімкнути інтеграцію з Universal Analytics (коректно працює зі стандартним компонентом оформлення замовлень). Для кожного сайту, на який Ви хочете додати відстеження, потрібно заповнити Ідентифікатор відстеження та Індекс параметра користувача.

Де $order – сформований масив даних замовлення для відправки в систему, а $ arFields – масив полів замовлення на сайті. function retailCrmBeforeOrderSave($order) ( //Ваші зміни return $order; //або return false; і тоді зміни із системи на це замовлення будуть проігноровані )

Де $order - масив із зміненими даними замовлення, що прийшов із системи.

Функція retailCrmAfterOrderSave

retailCrmAfterOrderSave - функція виконується відразу після збереження на сайті змін даних замовлення, що прийшли з історії із системи.

function retailCrmAfterOrderSave($order) ( //Ваші зміни return; )

Де $order - масив із зміненими даними замовлення, що прийшли із системи.

Функція retailCrmApiResult

retailCrmApiResult - функція, що виконується відразу після отримання відповіді від API системи.

function retailCrmApiResult($methodApi, $res, $code) ( //Ваші зміни return; )

Де $methodApi - назва API методу, $res - результат запиту true / false (вдалий чи вдалий запит), $code - код статусу відповіді API.

Зверніть увагу, що помилки в коді під час використання цієї функції можуть порушити роботу синхронізації сайту та системи.

Якщо перерахованих вище інструментів з якоїсь причини недостатньо, можна внести необхідні зміни безпосередньо в код модуля без ризику втрати цих змін під час оновлення модуля. Для цього потрібно скопіювати файл з потрібним класом у директорію /bitrix/php_interface/retailcrm/ і вже в ньому робити модифікацію. Цей механізм підтримує зміну класів для роботи з клієнтами, замовленнями, подіями, експортом каталогу та іншими допоміжними механізмами.

Закладка Завдання користувачапризначена тим, хто безпосередньо працюватиме з продуктом, тобто для співробітників компаній, які використовують наш програмний продукт.

Закладка Адміністраторські завдання призначено тим, хто адмініструватиме коробкову версію «Бітрікс24».

Закладка Документаціяпризначена для розробників проектів на основі коробкової версії «Бітрікс24».

Завдання користувача

Завдання користувача	Інформація
Перед початком роботи. Як авторизуватися на порталі, інтерфейс корпоративного порталу та інструменти роботи з ним, пошук інформації та рівні доступу до інформації.	Основні відомості
Мої інструменти. Інструменти персональної роботи: Завдання, Календар, Повідомлення та інші.	Мої інструменти
Компанія. Все про компанію в якій ви працюєте: реквізити, новини, вакансії та інше	Компанія
Інші співробітники. Як знайти співробітника, як зрозуміти структуру компанії, як оцінити ефективність співробітника та дізнатися скільки він відпрацював? І такі питання, пов'язані з іншими співробітниками.	Співробітники
Робота з документами. Все про роботу з документами: як зберігати та редагувати, документообіг та бізнес-процеси з документами, як підключити зовнішні папки з документами.	Документи
Сервіси для зручності роботи. Інструменти для автоматизації рутинних операцій: від організації планерок та зборів до подання заявки на матеріали, від оформлення відрядження до отримання виписки по особовому рахунку.	Сервіси
Робочі групи. Інструменти групової роботи на вирішення виробничих завдань.	Групи
Робота з контрагентами. Клієнти, постачальники, ліди, угоди, контакти, вирви продажів та інше, інше. Коротше CRM.	CRM
Гості вашого порталу. Обмежений доступдо інформації на порталі для тих, хто не є співробітником компанії, але кому вам треба щось показати чи щось обговорити.	Екстранет
Приклади. Як саме побудувати роботу з допомогою інструментів корпоративного порталу? Декілька прикладів вирішення виробничих завдань.	Приклади використання
Відео урокиКраще один раз побачити, ніж сто разів почути. Відео з роботи з Бітрікс24	Відеоролики

Адміністраторські завдання

Адміністраторські завдання	Інформація
Перед початком роботи. Необхідний мінімум відомостей про систему: як працює, терміни, структура, довідкова система, типи адміністрування та їх можливості.	Основні відомості
Встановлення та налаштування. Як правильно встановити, оновити чи перенести портал. Як настроїти пошук. Можливі помилкицих процесів. Віртуальна машинадля коробкової версії «Бітрікс24».	Встановлення та налаштування
Основи адміністрування. Інтерфейс програми та як ним керувати. Види інформації на порталі та як їх використовувати. Принципи управління доступом до інформації та користувачами. Інструменти контролю за станом проекту та безпека доступу.	Основи адміністрування
Адміністратор КП. Інструменти та методи роботи з порталом для співробітника, який виконує поточне адміністрування. Налаштування модулів та зовнішнього виглядупорталу у межах його компетенції.	Адміністратор КП
Адміністратор системи. Максимальні можливості керування порталом. Принципи налаштування всіх модулів системи.	Адміністратор системи
Додатково. Як зв'язати портал та 1С.	Додатково

Розробникам

Документація для розробників – це опис API системи. Документація для користувачів – це опис компонентів та налаштувань системи.

Документація доступна як онлайн, так і у вигляді файлу у форматі chm. Рекомендується користуватися он-лайн версією як актуальнішою. Файли формату chm оновлюються періодично, в них може бути відсутня інформація за останніми версіями.

Увага! Якщо ви не бачите вміст файлу формату .chm, то причина - налаштування безпеки операційної системи. У властивостях файлу потрібно зняти блокування від перегляду. Детальніше читайте уFAQ.

Системи допомоги		.chm
Документація для розробників	Онлайн-версія	bsm_api.chm Версія документа від 26.10.2018
Документація з API D7	Онлайн-версія	api_d7.chm Версія документа від 29.05.2019
Документація для користувачів	Онлайн-версія	bsm_user.chm Версія документа від 29.11.2018

Документація – це довідкова інформація. Розробнику-початківцю її мало для роботи з системою. У освоєнні принципів програмування Bitrix Frameworkвам допоможе спеціальний курс:

Розробник Bitrix Framework	Розділи
Перед початком роботи. Що таке Bitrix Frameworkі що ця платформа відрізняється з інших систем. Спільнота розробників.	Попередні зауваження
Архітектура продукту. Структура продукту у термінах MVC, що таке сайту розумінні системи, права доступу.	Архітектура продукту
Як це працює?. Технології Bitrix Framework.	Технології
Дизайн сайту. "Перетворення" картинки на працюючий сайт. Власне це і є проектування сайту.	Інтеграція дизайну
Загальний порядок роботи над сайтом. Реалізація сайту Яким чином це робити? Простий приклад.	Як створити простий сайт
Інфоблокиз погляду розробника. Робота через API системи та штатними засобами.	Інформаційні блоки
Компоненти. Компоненти – це основний інструмент розробника під час роботи. Як і у яких випадках кастомізувати? Що кастомізувати: шаблон чи сам компонент? Файли result_modifierі component_epilog.
Проектування бізнес-процесів. Автоматизація поточної діяльності підприємства. Як зробити те, чого немає у продукті за замовчуванням?
D7. Нове ядро ​​системи. Принципи роботи.	D7
Доросли до своїх розробок. Створення своїх модулів та типових рішень, завантаження на Маркетплейс.
Доросли до власних розробок - 2 Технологія Композитний сайт
"Дорослий" проектЯк правильно розробити та експлуатувати складний чи високонавантажений проект на Bitrix Framework?	Розробка та експлуатація високонавантажених проектів

Нещодавно наша компанія отримала на супровід і доопрацювання досить великий інтернет-магазин на 1С-Бітрікс. Проект кілька місяців, як був запущений у промислову експлуатацію, але при цьому мав низку серйозних проблем. Крім того, замовник планував виконати завдання щодо доопрацювання нового функціоналу в максимально стислий термін. Переді мною було поставлено завдання організувати ефективну роботуза проектом з мінімальним часом простою сайту та максимальним задоволенням потреб замовника.

Вихідні дані:

• Є інтернет-магазин на 1С-Бітрікс
• Проекту кілька років, але лише кілька місяців тому сайт перевели на 1С-Бітрікс
• Відвідуваність 10-15 тис. осіб на день
• Каталог магазину містить близько 12 000 позицій товарів
• Простої та відключення сайту неприпустимі
• Проект протягом півроку розроблявся іншою компанією:
• 1. Є ТЗ приблизно на 100 аркушів, що відповідає виконаній роботі приблизно на 40%
  2. Жодної документації проекту
  3. Відсутність розуміння чому попередні розробники використовували саме такі архітектурні рішення.

Розробкою програмного забезпеченнязагалом, та web-проектів зокрема, займаюся близько 8 років. За цей час стикався з проектами різної складності і, на перший погляд, завдання не видалося мені надто важким. При виконанні проектів у нашій компанії зазвичай застосовується методологія SCRUM. Від неї я і почав відштовхуватися.

Насамперед, отримав доступ вихідного кодупроекту. Поверхнево проаналізував. Узгодив із замовником список першочергових завдань. Склав план розробки для трьох розробників і, як сказав Гагарін, поїхали!

Проблема №1 – у всьому винні розробники

Як це зазвичай і буває, у всьому винні всі, окрім замовника. Дизайнер зробив макет, який надто багато важить, хостер надав сервер, який повільно працює, розробники зробили сайт, який весь час глючить та ламається, менеджери виконали якісь завдання, які ми виконувати не просили, після переходу з старої версіїсайту на 1С-Бітрікс відбулося різке зниження пошукового трафіку тощо. Ситуація не є однозначною. З одного боку основна відповідальність, звичайно ж, повинна лежати на компанії розробнику. Потрібно було донести до замовника наслідки всіх дій із сайтом та підготувати до результату. За виконання роботи запропонувати цілісну архітектуру майбутньої системита план розробки, якого потрібно дотримуватись до завершення основних етапів. Провести ретельне тестування функціоналу та здати роботу. З іншого боку, не рідко стикаюся із ситуацією, коли замовник усе сам краще знає, бо в нього мама колись малювала, а тому є найкращим дизайнером, і його 7ми річний син чудово розуміється на SEO-оптимізації, тому що весь час проводить за комп'ютером, граючи в GTA.

Хто винен, хто має рацію судити не нам. У цьому випадку, попереднім підрядником була досить відома надійна компанія і нічого поганого про їхню розробку сказати не можу. Та й замовник об'єктивно переживає за свій продукт і намагається його покращити. Як воно було не знаю, для себе я виявив пояснення в недостатній кількості аналітики наданої виконавцем замовнику.

В результаті:

• Проект не доведено до логічного завершення. Багато завдань кинуті на середині шляху
• Проект не документований. Робота частини функціоналу не очевидна. При розробці нового функціоналу виявляється, що перестав працювати функціонал, який раніше працював та про існування якого новий розробник і не підозрював
• Частину написаного попереднім виконавцем коду доводиться переписувати з нуля
• Задумана архітектура проекту у перші тижні/місяць роботи новому підряднику не зрозуміла. Доопрацювання функціоналу одного модуля призводить до втрати працездатності функціоналу ніяк не пов'язаного з ним модуля
• Замовник нервує, виконавець нервує, відвідувачі незадоволені, відвідуваність зменшується, продажі падають

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

Проблема №2 – паралельна технологія.

Відповідно до ліцензійної політики 1С-Бітрікс, кожна ліцензія на сайт дозволяє використовувати дві копії системи. Одну, як продакшено сайт, другу – для розробки. Проблема полягає в тому, що технологія ведеться декількома, в моєму випадку, трьома, розробниками безперервно. У випадку із класичною розробкою все просто. Кожен розробник займається своїм модулем. Потім проводиться функціональне тестування кожного модуля, всі доробки зливаються в репозиторій якоїсь системи контролю версій, далі це тестується разом (інтеграційне тестування). Якщо результат нормальний – тестова версія презентується замовнику. Після ухвалення тестової версії відбувається оновлення продакшен-сервера. Відповідно до методології SCRUM я визначив, щоб викладатиму нові версії на бойовий сайт раз на тиждень. Відповідно є 3-4 дні на основну розробку. 1 день на тестування та виправлення помилок та пів дня на оновлення бойового сервера. Терміни звичайно вагаються, але правила «реліз щочетверга» намагався чітко дотримуватися.

Перше з чим зіткнувся, в 1С-Бітрікс є ситуації, в яких той самий файл одночасно задіяний у різному функціоналі в різних кінцях сайту. Найпростіше і очевидне рішення – використовувати систему контролю версій, у моєму випадку, SVN, яким користуюсь у всіх інших проектах. Для використання контролю версій потрібно, щоб у кожного розробника була своя власна версія коду, що він править і потім зливає загальний репозиторій.

Як же бути з ліцензією? Звернувся до технічну підтримку 1С-Бітрікс. Отримав пропозицію докупити дод. ліцензії на розробку. М'яко сказати, не зрадів, але інших пропозицій не отримав. Вихід знайшов досить швидко. Вирішив використовувати NFR-ключі. Добре, що партнерський статус дозволяє. В результаті створив 5 істаляцій інтернет-магазину:

• Продакшен-сервер
• Тестовий сервер
• 3 сервери розробки (по одному на розробника)

Згодом пішов ще далі. З'явилася окрема інсталяція для тестера. Виявилося, що із моїм везінням замовник завжди заходить на тестовий сервер у момент, коли там щось оновлюється. У багтреку виникає багато зайвих завдань, які вже й так виконані, а у замовника виникає враження, що ми погано робимо свою роботу.

Зараз використовую таку схему:

• Кожен розробник використовує для роботи лише свою локальну копію
• У обумовлений час усі завершені доопрацювання зливаються у загальну гілку у репозиторії.
• QA забирає собі «смержену» версію для тестування
• Після тестування та виправлення помилок відбувається оновлення демонстраційного сервера для замовника
• Після перевірки та акцепту замовником, доопрацювання переносяться на бойовий сервер.

З очевидних мінусів такого підходу хочу виділити низький рівень залучення замовника до розробки. Результат видно замовнику вже лише на фінальній стадії. Такий підхід застосовується якщо у вас є хороший аналітик, який рідко помиляється і знаходиться в постійному контакті із замовником. Інакше багато завдань доведеться переробляти з нуля.

У міру побудови схеми зіткнувся ще з однією проблемою. Проект займає на диску близько 80Гб. Без кешу та тимчасових файлів – близько 60. Намагався спочатку прибрати картинки та відео з контролю версій – не вийшло. Інформація на сайті постійно змінюється. Тестувати потрібно на актуальних даних. Перший коміт сайту в репозиторій у мене йшов шматками понад 2 доби. Перший чекають у папку для розробки проходить кілька годин (SVN сервер в локальної мережірозробки). Якщо, не дай Боже, випадково зробити повний апдейт папки проекту - можна йти курити, обідати, грати в пінг-понг або керлінг. Коміт лише вибраних файлів або папок проходить досить швидко. Рішення: виконав завдання – закомити одразу десяток змінених файлів.

Проблема №3 – оновлення продакшен-сервера та спільна робота із замовником

Проблема найважливіша, складна і до кінця не вирішена. Адже якщо інші проблеми відносяться до внутрішньої кухні проекту, то від роботи сайту залежить репутація та дохід замовника, а отже, і мій дохід.

Тут добре працюють закони Мерфі:

• Якщо щось погано працює на тестовому сервері – на бойовому сервері обов'язково зламається.
• Якщо щось добре працює на тестовому сервері – на бойовому сервері це все одно обов'язково зламається.
• Якщо баг на сайті існує всього 5 секунд, його обов'язково знайде хтось із відвідувачів і обов'язково напише про це у відгуках чи формі зворотного зв'язку.
• Якщо сайт не працює 1 хвилину під час оновлення, то саме в цю хвилину власник компанії показуватиме його своєму другові або конкуренту (і це не зважаючи на погодження часу та процедури оновлення).

Я, звичайно, утрирую, але в кожному жарті є частка жарту. Мінімальне навантаження на сайт із 4 до 6 ранку. Оновлювати в цей час звичайно краще, але дуже не хочеться.

У випадку більшості веб-застосунків є чітка структура поділу програми на шари і оновлення сайту можна розділити на 2 частини:

• Оновлення програмного коду
• Оновлення бази даних за допомогою SQL-скриптів

У випадку з 1С-Бітрікс дещо складніше. По-перше, файлів багато. У мене в проекті їх понад мільйон. Звичайний апдейт з репозиторію проходить не менше 20-30 хвилин. Можна звичайно апдейтувати тільки змінені файли, але тоді втрачається весь сенс репозиторію. По-друге, і це куди сумніше, часто при апдейті доводиться робити ручні зміни та налаштування через адмінку. А це завжди повільно, треба пам'ятати всі зміни, які необхідно виконати, велика ймовірність випадково помилитись. Можна, звичайно, написати SQL-скрипт, який сам внесе всі потрібні зміни в базу. У найпростіших випадках, певна річ, так і робимо. Але в більшості випадків написання та налагодження такого скрипту займає більше часу, ніж сама розробка і набагато більше часу, ніж виконання всіх дій вручну з подальшою перевіркою.

Хорошого вирішення проблеми поки що не знайшов. Наразі оновлюємо налаштування в базі вручну. Для мінімізації помилок складається чек-лист зі списком, що потрібно зробити при апдейті. Оновлення намагаємося робити максимально уважно та акуратно. Після оновлення всією командою перевіряємо основний функціонал продакшен сервера та проводимо додаткове тестування. Кількість помилок мінімізована, але повністю багів і простоїв при оновленні позбутися поки не вийшло.

Друге, з чим зіткнувся, це спільна роботаіз замовником. Т.к. проект великий, над ним постійно працює близько 30 чоловік. Контент-менеджери, менеджери з продажу, SEO-оптимізатори, маркетологи та багато ще кого. Звичайно, кожен вносить у сторінки сайту та налаштування модулів якісь зміни. Першим рішенням було забрати права у замовника на внесення змін до програмного коду сайту. Рішення абсолютно правильно, але стало лише гіршим. Якщо раніше замовник припускав, що він може зайти на сайт і випадково щось зламати, то тепер всі шишки стали сипатися тільки на нас. До чого. Навіть якщо контент-менеджер криво відредагував текст на сторінці та не закрив якийсь тег – все одно винен розробник. Рішення знайшлося досить просте. У маркетплейсі є безкоштовний модуль контролю версій сторінок. Проблему це не прибрало, все одно хтось час від часу щось та наплужить, зате тепер з'явилася можливість подивитися в будь-який момент часу хто змінював, що змінював і чому все зламалося. Результат, звичайно, не ice, але купу нервів мені заощаджує.

Додатково ухвалили рішення перед кожним оновленням тестового сервера, беремо на нього копію з бойового. На це теж витрачається багато часу. Заархівувати проект, перенести на інший сервер, розархівувати. Усе це триває кілька годин. Натомість нові доопрацювання перевіряються практично в бойових умовах. Якщо налаштування тестового та продакшеного сервера ідентичні, різниця в роботі буде мінімальна і кількість помилок суттєво скорочується. Як показав досвід, за тиждень продакшен сервер може змінитися настільки, що частина нового функціонала, який працює без проблем на копії тижневої давності, на свіжій копії може взагалі не заробити.

Проблема №4 – «зробіть мені терміново, це завдання на 5 хвилин»

Проблема відноситься не стільки до 1С-Бітрікс, скільки до доопрацювання та підтримки працюючих проектів. Часто у замовника виникає бажання зробити якусь дрібницю, але терміново та одразу на бойовому сайті. Результат завжди один – нічого хорошого із цього не виходить. У кращому випадку, про цю доробку просто забудуть при черговому релізі, в гіршому - сервер просто впаде і його доведеться відновлювати кілька годин з бекапа.

Рішення знайшло лише одне – ніколи не йти на поводу у замовника на шкоду надійності та безпеці. Як би замовник не просив, винний завжди буде розробник. Як казав мені мій колишній начальник: «Я тебе не просив зробити погано».

І якщо вже торкнулися теми бекапів, хочу помітити. Бекап засобами 1С-Бітрік це звичайно добре і зручно, але дуже повільно. Якщо терміново необхідно відновити 1-2 файли або кілька значень в базі, доводиться чекати поки розархівуються всі 60 Гб. Тут найефективнішою мені здається така схема:

• Повинен відбуватися щодобовий бекап файлів та бази даних у вигляді архіву на зовнішнє джерелоданих.
• Завжди робимо бекап безпосередньо перед оновленням в одному з двох варіантів:
• 1. Варіант light – Копіюємо всю папку проекту до сусідньої папки на сервері. Базу даних як дампа зберігаємо в окремий файл. Нічого не архівуємо. Якщо потрібно буде відновити якесь значення в базі або один із файлів, все буде під рукою і доступно
  2. Варіант strong – аналогічно до попереднього, тільки базу копіюємо в іншу базу даних MySQL. Це дозволить у разі повного краху за 1-2 хвилини виправити у файлі хостів кореневу папку сайту та проект почне працювати із сусідньої папки з копією бази.

Висновок

Дякую всім, хто дочитав до кінця. Сподіваюся, мій досвід буде вам корисним. Буду радий пропозиціям щодо більш вдалих способів вирішення озвучених проблем у коментарях або в особу. Зараз я постарався озвучити основні проблеми доопрацювання та підтримки вже запущених проектів із високими вимогами до надійності. Якщо матеріал виявиться цікавим, планую написати продовження про особливості архітектури 1С-Бітрікс, які відрізняють розробку сайту на Бітрікс від розробки інших веб-проектів.

Інформацію по роботі з можна знайти у навчальних курсах та в документації. Навчальні курси призначені для освоєння методів роботи в програмному продуктіа документація - для освоєння принципів кастомізації CMS.

При роботі з «1С-Бітрікс: Управління сайтом»Проблеми виникають у вигляді конкретних практичних завдань. Ми зібрали у профільні теми різні сторінкинавчальних курсів, щоб полегшити пошук відповідей на запитання.

Навчальні центри Задати питання Форум

Закладка Контент-менеджерампризначена для тих, хто безпосередньо працюватиме з продуктом, тобто для контент-менеджерів, що ведуть проекти, створені на нашому програмному продукті.

Закладка Адміністраторампризначена для тих, хто адмініструватиме «1С-Бітрікс: Управління сайтом».

Закладка Розробникампризначена для розробників проектів на основі «1С-Бітрікс: Управління сайтом».

Контент-менеджерам

Завдання по роботі із системою	Інформація
Перед початком роботи. Робота над контентом неможлива без авторизації. Як авторизуватись на сайті? Що таке одноразові паролі та як з ними працювати?	Авторизація
Інтерфейс програми. Працювати з будь-якою програмою неможливо, якщо не зрозуміло призначення тієї чи іншої кнопки чи команди. Як працювати з новим інтерфейсом Ермітаж? Як працювати з інтерфейсом у старих версіях програми?	Елементи керування
Як працювати з інформацією. Інформація буває різною: статичною та динамічною, текстовою та графічною. Як керувати тією чи іншою інформацією? Як розміщувати її на сторінках сайту? Як створити саму сторінку чи розділ і задати їх властивості?	Інформація на сайті та робота з нею
Структура сайту. Будь-який сайт складається з розділів та сторінок. Як легко і просто керувати структурою сайту поточній роботі? Прийом роботи. Медіабібліотека, як сховище відео, фото та аудіофайлів.	Управління структурою
Візуальний редактор - це основний інструмент контент-менеджера під час роботи з сайтом. Все про роботу з редактором: як вставляти текст, форматувати та редагувати його, роботу з графікою та таблицями. Сніпети та налаштування редактора «під себе». Відео по роботі з візредактором.	Візуальний редактор
Інформаційні блоки- основне місце зберігання динамічно виведеної інформації. Необхідний рівень знань для роботи із цим інструментом системи.	Інформаційні блоки
Компоненти. Будь-яка динамічна інформація виводиться сама по собі, а з допомогою спеціальних програмних інструментів - компонентів. Основні моменти роботи з цими інструментами: як додати компонент на сторінку, як налаштувати, як працювати з ним.	Компоненти
Практика. Теорія – це добре. Але спробувати «ручками» - це завжди краще. Допоможуть освоїти роботу численні приклади з описом, як виконувати типові, найчастіші завдання, що стоять перед контент-менеджером.	Приклади роботи із системою
Типові помилки. Допомогти в освоєнні системи допоможе і список найчастіших помилок та способів їх вирішення.	Типові помилки під час роботи з системою

Ви можете імпортувати на свій сайт курс Контент менеджерз цього архіву. Курс без запитань для тестів.
Версія курсу від 5.06.2015 року.

Адміністраторам

Адміністраторські завдання	Інформація
Перед початком роботи. Необхідний мінімум відомостей про систему як працює, терміни, структура.	Основні відомості
Встановлення та налаштування. Як правильно встановити, оновити чи перенести сайт. Можливі помилки цих процесів. Віртуальна машина для «1С-Бітрікс: Управління сайтом».	Встановлення та налаштування
Основи адміністрування. Основні принципи адміністрування в системі: керування сайтами, користувачами, доступом до модулів та інформації, налаштування інтерфейсу, робочі інструменти адміністратора, забезпечення безпеки.	Основи адміністрування
Пошук. Все про пошук інформації на сайті. Налаштування модуля Пошук, статистика, хмара теги та інші інструменти. Типові помилки.	Пошук
Інформаційні блоки. Докладно про найважливіший модуль системи. Експорт та імпорт, приклади роботи.	Інформаційні блоки
Приклади операцій. Декілька практичних прикладів по роботі з системою.	Приклади операцій
Модулі системи. У «1С-Бітрікс: Управління сайтом»більше 40 різних модулів, що дозволяють виконувати різні завдання: від проведення опитувань до AD/LDAP інтеграції та хмарних сховищ. Детальний описналаштування та роботи з модулями системи некомерційної спрямованості.	Адміністратор. Модулі
Інтернет-торгівля. Організація віртуального магазину та завдання, пов'язані з цим: робота з валютами, інтеграція з 1С, торговий каталог та налаштування інтернет-магазину. Приклад роботи.	Адміністратор. Бізнес

Розробникам

Документація для розробників – це опис API системи. Документація для користувачів – це опис компонентів та налаштувань системи.

Документація доступна як онлайн, так і у вигляді файлу у форматі chm. Рекомендується користуватися он-лайн версією як актуальнішою. Файли формату chm оновлюються періодично, в них може бути відсутня інформація по останнім змінаму довідковій системі.

Увага! Якщо ви не бачите вміст файлу формату .chm, то причина - налаштування безпеки операційної системи. У властивостях файлу потрібно зняти блокування від перегляду. Детальніше читайте уFAQ.

Системи допомоги		.chm
Документація для розробників	Онлайн-версія	bsm_api.chm Версія документа від 26.10.2018
Документація з API D7	Онлайн-версія	api_d7.chm Версія документа від 29.05.2019
Документація для користувачів	Онлайн-версія	bsm_user.chm Версія документа від 29.11.2018

Документація – це довідкова інформація. Розробнику-початківцю її мало для роботи з системою. У освоєнні принципів програмування Bitrix Frameworkвам допоможе спеціальний курс:

Розробник Bitrix Framework	Розділи
Перед початком роботи. Що таке Bitrix Frameworkі що ця платформа відрізняється з інших систем. Спільнота розробників.	Попередні зауваження
Архітектура продукту. Структура продукту у термінах MVC, що таке сайту розумінні системи, права доступу.	Архітектура продукту
Як це працює?. Технології Bitrix Framework.	Технології
Дизайн сайту. "Перетворення" картинки на працюючий сайт. Власне це і є проектування сайту.	Інтеграція дизайну
Загальний порядок роботи над сайтом. Реалізація сайту Яким чином це робити? Простий приклад.	Як створити простий сайт
Інфоблокиз погляду розробника. Робота через API системи та штатними засобами.	Інформаційні блоки
Компоненти. Компоненти – це основний інструмент розробника під час роботи. Як і у яких випадках кастомізувати? Що кастомізувати: шаблон чи сам компонент? Файли result_modifierі component_epilog.
Проектування бізнес-процесів. Автоматизація поточної діяльності підприємства. Як зробити те, чого немає у продукті за замовчуванням?
D7. Нове ядро ​​системи. Принципи роботи.	D7
Доросли до своїх розробок. Створення своїх модулів та типових рішень, завантаження на Маркетплейс.
Доросли до власних розробок - 2 Технологія Композитний сайт
"Дорослий" проектЯк правильно розробити та експлуатувати складний чи високонавантажений проект на Bitrix Framework?	Розробка та експлуатація високонавантажених проектів