Документација за кутијата верзија на Bitrix24. Завршување на волшебникот за инсталација

Рамка Битрикс - технолошко јадро (платформа) за креирање и управување со проекти (веб-страници и корпоративни портали). Платформата ви овозможува да креирате неограничен број проекти користејќи една копија (лиценца) на производот, ставајќи ја јадрото и базата на податоци на системот во една копија на серверот.

На овој моментне се дуплираат сите можности на стариот кернел во D7. Но, новото јадро D7 Рамка Битрикспостепено заменувајќи го стариот. Ако користењето на старо јадро резултирало со предупредување од IDE: Методот/класата е застарена, тогаш треба да користите методи.

Од повеќе причини, документацијата API може да не ги опфаќа сите методи. За да разберете како функционира, понекогаш е подобро да го погледнете вистинскиот програмски код. За ова можете да користите бесплатен модулод Marketplace:.

Забелешка: со додавање #examples на адресата на која било страница, можете брзо да отидете на пример, ако има таков. (Ова не работи во датотеките со документација со формат CHM.)


Верзии на ентитети

Рамка Битрикспостојано се развива. Се појавуваат нови функции, некои застаруваат, а во функциите се појавуваат нови параметри. Сепак, прилично голем број проекти не се ажурирани. За да се олесни работата на програмирањето, документацијата покажува со која верзија на производот постоела (постоела) класата, методот, параметарот, настанот.

Верзиите се наведени на две места: во насловот и во табелите. Ако методот е валиден, тогаш насловот ќе го содржи само бројот на верзијата со кој се појавил во производот. Ако методот е застарен, тогаш ќе биде наведен и опсегот на верзии каде што важел.

Табелите ја означуваат верзијата со која ентитетот се појавил во производот само ако неговиот изглед не се совпаѓа со моментот на појавување на класата, самиот метод итн. На илустрацијата подолу: параметарот COURSE_ID се појави заедно со методот (односно од 5.1.0), а параметарот CHAPTER_ID само од верзијата 9.5.4.

Ако некој параметар (обично ова се однесува на параметри) се промени со развојот на производот, ќе има соодветна забелешка во неговиот опис. (На пример: пред верзијата x.x.x параметарот беше наречен *****).

Пример

Белешки:

  • Означи Застареназа метод, параметар или клуч значи дека не се препорачува да се користи бидејќи нема да има наставки или поправки.
  • Инсталирањето на верзиите не е целосно завршено, работата во оваа насока моментално е во тек.

„Битрикс“, 2001-2019 година, „1Ц-Битрикс“, 2019 година

Интеграцијата на онлајн продавница на 1C-Bitrix со системот може да се направи со помош на системскиот модул во Bitrix.Marketplace.

За време на инсталацијата, модулот ќе ви помогне да прикачите постоечки нарачки во системот.

По инсталацијата, модулот ќе:

  • вчитајте нови нарачки од 1C-Bitrix во системот;
  • ажурирање на податоците за постоечките нарачки земајќи ги предвид промените направени на 1C-Bitrix;
  • испраќајте нови нарачки и клиенти од системот на 1C-Bitrix;
  • ажурирајте ги податоците за постоечките нарачки земајќи ги предвид промените направени во системот (на пример, статусот на нарачката е променет во системот, бројот на стоки во нарачката итн., овие промени ќе се одразат и во 1C-Bitrix) ;
  • испрати информации за онлајн плаќање на нарачка од страна на корисникот до системот.

Исто така, можно е да се приспособат класите на приклучоци без да се изгуби изменетиот код при ажурирањето. За да го имплементирате изменетиот код, треба да поставите копија од датотеката со потребната класа во директориумот bitrix/php_interface/retailcrm.

Приклучокот има можност да ги приспособи следниве датотеки:

RestNormalizer.php
Logger.php
Клиент.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, модулот ќе користи прилагодена класа; можете да направите промени во неговите методи.

Регистрација на онлајн продавница во системот

Пред инсталацијата, регистрирајте ја вашата онлајн продавница во вашиот пример на системот (дел Администрација > Продавници, на пример, во демо верзијата):

Инсталирање на растворот во 1C-Bitrix

  • Кликнете на „Инсталирај“ на страницата со решение на пазарот и внесете ја адресата на вашата онлајн продавница:

  • Преземете го модулот преку системот за ажурирање 1C-Bitrix:

  • Започнете со инсталирање на модулот:

Ќе се стартува волшебникот за инсталација.

Волшебник за инсталација. Чекор 1

На чекор 1.1, треба да ја наведете адресата на вашиот систем (на пример, https://test.retailcrm.ru) и клучот API што сте го генерирале порано во системот:

Важно! Ако има само една продавница во Bitrix, чекор 1. Сајтовите се прескокнуваат.

Волшебник за инсталација. Чекор 1. Веб-страници

На чекор 1.Sites, треба да ја поставите кореспонденцијата помеѓу вашите продавници во 1C-Bitrix и системот.

Важно! Сите ваши продавници во системот мора да имаат заеднички API клуч.

Волшебник за инсталација. Чекор 2

Во вториот чекор, треба да ја наведете кореспонденцијата помеѓу вредностите на онлајн продавницата и системските директориуми. Самиот модул се обидува да воспостави кореспонденција за типични статуси. Онаму каде што модулот не успеа да го стори тоа, треба сами да го наведете совпаѓањето:

Проверете дали системот ги има потребните вредности на директориумот што одговараат на директориумите на онлајн продавницата. Ако нема доволно, додајте ги во делот Администрација без да ја затворите страницата на волшебникот за инсталација:

После ова, освежете ја страницата на волшебникот: треба да се вчитаат новите вредности на директориумот.

Волшебник за инсталација. Чекор 3

Во третиот чекор, модулот ви овозможува да ја поставите кореспонденцијата помеѓу полињата на 1C-Bitrix и системот.

Важно! Ако има форма“ повратни информации„или нарачки „со 1 клик“, и овие податоци не спаѓаат во стандардните нарачки на Bitrix, тогаш тие не се влечат во системот.

Исто така, ако работите со правни лица, мора да ги пополните сите полиња како што е наведено на сликата од екранот подолу.

Волшебник за инсталација. Чекор 4

Во четвртиот чекор, модулот ви овозможува да прикачите претходно поставени нарачки во системот. Растоварувањето може да потрае некое време (1000 нарачки се истоваруваат за околу 5 минути). Напредокот на процесот на поставување ќе биде прикажан со лента за напредок.

Доколку е потребно, можете да го паузирате преземањето и да продолжите повторно по некое време.

Откако ќе ги поставите претходно поставените нарачки, ќе можете да гледате аналитички извештаи во панелот KPI. Препорачуваме да го извршите овој чекор.

Волшебник за инсталација. Чекор 5

Во петтиот чекор, поставувањето на каталогот на производи е конфигурирано. За да го направите ова, мора да ги завршите следните точки.

1. Избор на информативни блокови и својства

Избраните информативни блокови ќе бидат поставени на системот. Ќе ви биде понуден избор само од оние информативни блокови што содржат производи или имаат поврзани информативни блокови со трговски понуди. Паралелно со изборот на информативни блокови, можете да ги изберете следните својства: напис, производител, боја, тежина, големина - за ова треба да го наведете имотот на информативниот блок, кој е одговорен за складирање на соодветното својство. Изборот на имот е изборен.

2. Патека на датотеката

На наведената патека ќе се генерира датотека во формат, која ќе ја содржи структурата на директориумот. Стандардната патека е - "/bitrix/catalog_export/retailcrm.xml". Ако ја промените патеката, ќе треба да извршите слично поставување во системот.

3. Поставување на бројот на понуди при извоз

Во поставките за извоз на каталог, има поле „Максимален број на трговски понуди за производ“, каде што мора да го внесете максималниот број на трговски понуди што може да ги има еден производ (ако има повеќе од 50). Стандардно, модулот пресметува максимум 50 трговски понуди за производ. Ако има помалку од 50 трговски понуди по производ во продавницата, оваа поставка може да се игнорира. Ако има повеќе трговски понуди и поставката е одредена, се препорачува агентот да се префрли на круни ако работи на хитови.

4. Избор на фреквенција на истовар

Ќе има три опции за избор:

1. Бр- кога ќе ја изберете оваа ставка, периодичното поставување на каталогот нема автоматски да се конфигурира и секој пат ќе треба сами да го прикачувате каталогот.

Оваа опција може да биде корисна ако каталогот на производи на вашата онлајн продавница се менува многу ретко или ако сакате подоцна да ги конфигурирате параметрите за прикачување.

2. Крон- изборот на оваа ставка ќе доведе до автоматско креирање на посебен профил кој ќе биде поврзан со услугата Cron на серверот на кој работи веб-страницата на онлајн продавницата.

Вклучува алатката cron позадинаи извршува одредени задачи во одредено време.

Изборот на оваа ставка може да биде корисен ако каталогот содржи многу голема ставка ( повеќе од 10.000 производи). За оваа ставка, мора да го наведете името на специјалниот профил за извоз.

3. Агент. Во овој случај, ќе се создаде и посебен профил кој ќе се поврзе со технологијата „Агенти“ во 1C-Bitrix, а поставувањето ќе се изврши автоматски еднаш дневно.

Агентот е PHP функција која работи на одредена фреквенција. На почетокот на секое вчитување на страницата, системот автоматски проверува дали има агент што треба да се стартува и доколку е потребно, го извршува. Не е препорачливо да се создаваат агенти за поставувања кои одземаат многу време - подобро е да се користи cron.

Оваа опција е најпосакувана ако директориумот содржи помалку од 10.000 производи, тогаш поставувањето се случува доста брзо и тоа нема да влијае на брзината на веб-страницата на онлајн продавницата на кој било начин.

Во случај на голем опсег ( повеќе од 10.000 производи), неопходно е дополнително прилагодувањеАгент на Крон. За оваа ставка, исто така треба да го наведете името на специјалниот профил за извоз.

4. Индикација за моментално истоварување

Како резултат на поставувањето на знамето „Исклучи сега“, структурата на директориумот ќе се истовари во горната датотека, веднаш по инсталирањето на модулот.

Откако ќе го поставите каталогот во датотека во системот, треба да отидете во Администрација -> Продавница -> Име на продавница -> табот „Каталог“ и штиклирајте го полето „Преземи каталог од ICML сега“. Во овој случај, преземањето на датотеката и неговата обработка започнува речиси веднаш.

5. Одредување име на профилот

По правилно поставување на прикачувањето на каталогот на производи, ќе се појави нов тип на системски извоз во делот Продавница > Поставки > Извоз на податоци; ако е одредено периодично поставување при инсталацијата, ќе се појави и профил за извоз.

Забелешка:
За само-конфигурацијапри поставување, можно е да креирате сопствен профил за извоз.

Завршување на волшебникот за инсталација

На крајот од инсталацијата, ќе се создадат 2 агенти: еден агент ја поставува историјата на нарачки од Bitrix во системот, вториот агент генерира каталог. Ако поставувањето на нарачките е конфигурирано за агент, тогаш нарачките се поставуваат на системот во моментот кога се повикува историјата. Во други случаи, нарачките се истоваруваат врз основа на настан.

Растоварување на услугата за испорака за време на размената 1C-Bitrix - системот

Ако имате автоматизирани услуги за испорака поврзани на 1C-Bitrix, како што е eDost, кои имаат многу профили: Руска пошта, EMS, DHL и многу други, тогаш во системот можете да ја искористите можноста за прикачување на ваков вид услуга за испорака.

Методите за испорака мора да се конфигурираат на системската страна. Ако системскиот модул бил инсталиран пред да ја поврзете услугата за испорака со Bitrix, тогаш методите за испорака што недостасуваат ќе треба рачно да се внесат во системот. Ако модулот е инсталиран по поврзувањето на услугата за испорака, тогаш методите за испорака ќе се инсталираат автоматски, како и самата услуга што се истоварува. Односно, за секоја нарачка ќе се преземат трошоците за испорака.

На страната 1C-Bitrix, мора да ги направите следните поставки ако системскиот модул е ​​инсталиран по поврзувањето на услугата за испорака со системот 1C-Bitrix:

Оди до Администрација > Поставки, одете во табулаторот „Поставки на директориумот“.

Конфигурирајте ја кореспонденцијата на методите за испорака (прелиминарно конфигурирани на страната на системот). Следно, кликнете на копчето „Подигни услуги за испорака“.

Поставување на фреквенцијата на поставување 1C-Bitrix - систем

При ажурирање на каталогот на производи, може да се истакнат две точки:

Генерирање каталог (во формат yml/icml) на страната на клиентот и

Системот го презема каталогот еднаш на секои три часа. Патеката до датотеката што треба да се постави е поставена во поставките на продавницата - треба да отидете во делот Администрација > Продавници > Изберете продавница > картичката Каталог.

По инсталирањето на системскиот модул во 1C-Bitrix, се креира профил за поставување. За да видите, треба да отидете на Десктоп > Продавница > Поставки > Извоз на податоци. Сликата од екранот покажува две опции:

Стандардно,

Поставување на системскиот директориум.

Ако ја изберете втората опција, со кликнување на неа ќе се отворат опциите за поставување.

Ако Агентот е избран како опција за фреквенција, за да ја видите листата на агенти, треба да отидете до Десктоп > Поставки > Поставки за производи > Агенти.

Ако кликнете на „Промени“ или „Додај ново“, можете да ја доделите или промените фреквенцијата на извршување на задачата за генерирање.

Фреквенција на синхронизација на податоци за време на размената 1C-Bitrix - систем

Системскиот модул ви овозможува да поставите каталог на производи на вашиот систем, како и да вршите редовна двонасочна размена на нарачки и клиенти.

Со навремено поставување податоци од каталогот, вашите системски менаџери ќе имаат ажурирани информации за достапноста на производот. Нема да се појави ситуација кога некој производ е нарачан, а по одредено време ќе испадне дека е без залиха.

Размената на нарачки е процес на синхронизација на податоци кога нарачките се поставуваат во двете насоки:

Од 1C-Bitrix до системот:

  • Ако е овозможено поставување по настани, при креирање или менување на нарачка во системот 1C-Bitrix, таа веднаш ќе се постави во системот. Ако се избере агент за истовар, нарачката ќе биде поставена на системот во рок од 15 минути (не се препорачува да се користи овој механизам без убедливи причини, бидејќи во овој случај нарачките ќе пристигнат со задоцнување и ажурирањата на овие нарачки нема да се префрлаат на системот).
  • Кога корисникот ќе се промени, главните податоци исто така ќе бидат веднаш поставени на системот.

Од системот до 1C-Bitrix:

  • Ако креирате нарачка во системот за нов корисник, тогаш нарачката ќе биде поставена на 1C-Bitrix и креирана Нов корисникво опсег од 1 до 15 минути.
  • Ако ја промените адресата, цената на испораката или статусот во системот на страницата за нарачка, тогаш сите овие промени ќе бидат поставени на 1C-Bitrix во рок од 15 минути.
  • Ако ги промените попустите на производите во системот и ја промените количината на производи, тоа ќе се промени во 1C-Bitrix во интервалот од 1 до 15 минути.

Промени во модулот за интеграција

Верзија 2.0

  • Верзијата на модулот за интеграција V2.0 е дизајнирана да го интегрира 1C-Bitrix со верзијата на модулот „Онлајн продавница (продажба)“ > 16 инсталирана во него.
  • Сега модулот работи преку API V4.
  • Модулот за интеграција сега го користи новото јадро 1C-Bitrix D7.
  • Сега промените во однос на клиентот (полно име, е-пошта, телефон) се испраќаат и на веб-страницата од системот.
  • Во поставките на модулот за интеграција во делот „Други поставки“, стана можно да се преведат броевите на нарачките од системот на 1C-Bitrix. Тоа е, ако рачно креирате нарачка во системот со бројот, на пример, 12345R, тогаш ќе се креира нарачка со истиот број во 1C-Bitrix.
  • Бидејќи во верзијата на модулот „Онлајн продавница (продажба)“ > 16, програмерите на Bitrix се оддалечија од примената на попусти за целата нарачка и оставија попусти само за производите, системот, засега, исто така нема можност да користи попусти на целата нарачка. Можете да поставите попусти само за одредени ставки за нарачки.

Верзија 2.1

  • Додадени мерни единици во каталошкиот извоз.

Верзија 2.2

  • Модулот сега поддржува неколку верзии на API со избор.
  • Поддршка за API V5.
  • Додадена е можност за растоварање салда по складиште.
  • Додадена е можност за преземање типови на цени.
  • Додадена е основна интеграција на Daemon Collector.
  • Додадена е интеграција со Universal Analytics.
  • Логиката на вградените функции за модификација на податоците е подобрена.
  • Додадена е вградена функција retailCrmApiResult.
  • Додадена е верзија на активирањето на историјата на промени.

Верзија 2.4

  • Додадена е проверка во процесорот за заштеда на плаќање за нова нарачка.
  • Додадена е поставка за бројот на трговски понуди при извоз.
  • Додадена е конверзија на куповната цена.
  • Промена на датотеките за превод.
  • Додадена е проверка при растоварување на промените од системот за својствата на нарачката.
  • Додадено е подигнување на ДДВ.
  • Поправено е да се добие список со типови цени за прикачување. Сите видови достапни во Bitrix се достапни за избор.

Други поставки

Поставки за нарачка

Пренесете ги броевите на нарачките создадени во централниот центар за обработка до продавницата

Кога ќе се креира нарачка во системот, тој генерира свој единствен број според наведените правила. Кога оваа поставка е поставена во модулот, бројот на таквата нарачка ќе се пренесе во продавницата при обратна синхронизација.

Растовар на нарачки

  • По настан- кога ќе ја зачувате нарачката, податоците одат во системот;
  • Агент- новите нарачки се испраќаат пред да се побара историјата на промени од системот.

Верзија на API на клиентот

Сега можете да ја изберете верзијата на API со која ќе работи модулот. Изборот зависи од верзијата на системот. Се препорачува да се избере најновата верзија.

Овозможете растоварување на салда по складиште (достапно доколку постојат складишта)

Сега можете периодично да ги растоварате билансите од магацините на локацијата до системските магацини. За да го направите ова ви треба:

  • споредете ги магацините на локацијата со системските складишта;
  • наведете ги системските складишта во кои ќе се вчитаат салда;
  • изберете информативни блокови со стоки потребни за товарни салда (треба да ги изберете оние што се наведени во извозот на каталогот за системот).

Поставувањето го врши агентот со фреквенција од 1 час (стандардно).

Ве молиме имајте предвид дека за да се вчитаат салда во системот, опциите мора да бидат овозможени.

Овозможете поставување типови цени за производи (достапно само ако има неколку типови цени)

Сега можете периодично да испраќате дополнителни типови цени од продавницата во системот. За да го направите ова ви треба:

  • споредете ги типовите на цени на локацијата со типовите на системски цени;
  • наведете ги системските складишта во кои ќе се вчитаат дополнителни типови цени;
  • изберете информациски блокови со производи кои бараат вчитување дополнителни типови цени (треба да ги изберете оние што се наведени во извозот на каталогот за системот).

Поставувањето го врши агентот на секои 24 часа (стандардно).

Активирајте го собирачот на демони

Сега можете да го додадете колекторскиот демон на веб-страницата од интерфејсот за поставки. За да го направите ова, треба да го наведете соодветниот клуч за саканата локација. Клучот може да се најде во системот.

Овозможете интеграција на UA

Сега можете да овозможите интеграција со Universal Analytics од интерфејсот за поставки (функционира правилно со стандардната компонента за нарачка). За секоја локација на која сакате да додадете следење, треба да пополните ID за следење и Индекс на приспособени параметри.

Каде што $order е генерирана низа на податоци за нарачката што треба да се испратат до системот, а $arFields е низа полиња за нарачки на веб-локацијата. функцијата retailCrmBeforeOrderSave($rder) ( //Вашите промени враќаат $order; //или враќаат неточно; а потоа промените од системот за оваа нарачка ќе бидат игнорирани)

Каде што $order е низа со изменети податоци за нарачката добиени од системот.

функција retailCrmAfterOrderSave

retailCrmAfterOrderSave - функција која се извршува веднаш откако промените на податоците за нарачката добиени од системската историја се зачувани на веб-локацијата.

функција retailCrmAfterOrderSave($rder) ( //Вашите промени се враќаат; )

Каде што $order е низа со изменети податоци за нарачката добиени од системот.

Функција малопродажбаCrmApiResult

retailCrmApiResult - функција која се извршува веднаш по добивањето одговор од системот API.

функција retailCrmApiResult($methodApi, $res, $code) ( //Вашите промени се враќаат; )

Онаму каде што $methodApi е името на методот API, $res е резултат на точното / неточното барање (успешно или неуспешно барање), $code е статусен код за одговор на API.

Имајте предвид дека грешките во кодот при користење на оваа функција може да ја нарушат синхронизацијата на страницата и системот.

Ако алатките наведени погоре поради некоја причина не се доволни, можете да ги направите бараните промени директно во кодот на модулот без ризик да ги изгубите овие промени при ажурирање на модулот. За да го направите ова, треба да ја копирате датотеката со потребната класа во директориумот /bitrix/php_interface/retailcrm/ и да направите измени во неа. Овој механизам поддржува менување класи за работа со клиенти, нарачки, настани, извоз на каталог и други помошни механизми.


Обележете Прилагодени задачие наменет за оние кои директно ќе работат со производот, односно за вработените во компаниите кои го користат нашиот софтверски производ.

Јазичето Административни задачи е наменето за оние кои ќе ја администрираат верзијата во кутија „Битрикс24“.

Обележете Документацијанаменет за развивачи на проекти базирани на верзијата во кутии „Битрикс24“.

Прилагодени задачи

Административни задачи

За програмери

Програмерската документација е опис на системот API. Корисничката документација е опис на компонентите и поставките на системот.

Документацијата е достапна и онлајн и како датотека во формат chm. Се препорачува да се користи онлајн верзијата бидејќи е поажурирана. chm-датотеките периодично се ажурираат и може да не содржат информации за најновите верзии.

Внимание! Ако не ја гледате содржината на датотеката со формат .chm, тогаш причината се безбедносните поставки операционен систем. Во својствата на датотеката треба да ја одблокирате датотеката од гледање. Прочитајте повеќе воНајчесто поставувани прашања

Документацијата е референтна информација. Не е доволно за почетник програмер да работи со системот. Во совладувањето на принципите на програмирање во Рамка БитриксПосебен курс ќе ви помогне:

Не така одамна, нашата компанија доби прилично голема онлајн продавница на 1C-Bitrix за одржување и модификација. Проектот беше пуштен во комерцијална работа пред неколку месеци, но во исто време имаше голем број сериозни проблеми. Покрај тоа, клиентот планираше да ги заврши задачите за финализирање на новата функционалност што е можно побрзо. Добив задача да организирам ефикасна работаспоред проектот со минимално застој на локацијата и максимално задоволување на потребите на клиентите.

Првични податоци:

  • Постои онлајн продавница на 1C-Bitrix
  • Проектот е стар неколку години, но пред само неколку месеци локацијата беше префрлена на 1C-Bitrix
  • Посетеност 10-15 илјади луѓе дневно
  • Каталогот на продавници содржи околу 12.000 артикли на производи
  • Застојот и прекините на локацијата се неприфатливи
  • Проектот беше развиен од друга компанија во рок од шест месеци:
    1. Постои техничка спецификација за приближно 100 листови, што одговара на приближно 40% од завршената работа.
    2. Нема проектна документација
    3. Недостаток на разбирање зошто претходните програмери користеле специфични архитектонски решенија.

Развој софтверГенерално, а особено веб-проекти, работам на веб проекти околу 8 години. За тоа време наидов на проекти со различна сложеност и, на прв поглед, задачата не ми изгледаше премногу тешка. При спроведување на проекти во нашата компанија, по правило се користи методологијата SCRUM. Почнав да се туркам од неа.

Прво, добив пристап изворен кодпроект. Површно анализирано. Се договори со клиентот за листата на приоритетни задачи. Направив развоен план за 3 програмери и, како што рече Гагарин, одиме!

Проблем број 1 - програмерите се виновни за сè

Како што обично се случува, сите се виновни освен клиентот. Дизајнерот направи распоред кој тежи премногу, хостерот обезбеди сервер кој работи бавно, програмерите направија веб-локација која постојано е со кабриолет и расипана, менаџерите завршија некои задачи што не баравме да се извршат откако се префрливме од стара верзијастраницата на 1C-Bitrix имаше нагло намалување на сообраќајот за пребарување, итн. Ситуацијата не е јасна. Од една страна, главната одговорност, се разбира, треба да лежи на компанијата за програмери. Беше неопходно да се пренесат на клиентот последиците од сите дејства со страницата и да се подготвиме за резултатот. При изведување на работа, предложете холистичка архитектура иден системи развоен план што треба да следи додека не се завршат пресвртниците. Спроведете темелно тестирање на функционалноста и поднесете ја работата. Од друга страна, често наидувам на ситуација кога клиентот сам знае сè подобро, бидејќи неговата мајка некогаш сликала, па затоа е најдобар дизајнер, а неговиот 7-годишен син е добро упатен во SEO оптимизација, бидејќи целото време го поминува на компјутер играјќи GTA.

Не е наше да судиме кој е виновен, а кој е во право. Во овој случај, претходниот изведувач беше прилично добро позната, доверлива компанија и не можам да кажам ништо лошо за нивниот развој. А клиентот, објективно, се грижи за својот производ и се обидува да го подобри. Не знам како се случи, за себе најдов објаснување во недоволната количина на аналитика што ја дава изведувачот на клиентот.

Како резултат:

  • Проектот не е доведен до својот логичен заклучок. Многу задачи се напуштени на половина пат
  • Проектот не е документиран. Работата на дел од функционалноста не е очигледна. Кога развивате нова функционалност, излегува дека функционалноста што работела и за чие постоење не се сомневал новиот развивач престанала да работи
  • Дел од кодот напишан од претходниот изведувач треба да се препише од нула
  • Предвидената архитектура на проектот не му е јасна на новиот изведувач во првите недели/месеци на работа. Подобрувањето на функционалноста на еден модул доведува до губење на функционалноста на модулот кој во никој случај не е поврзан со него.
  • Клиентот е нервозен, изведувачот е нервозен, посетителите не се задоволни, посетеноста се намалува, продажбата паѓа

Гледам само едно решение за проблемот: постепено систематски исчистете ги сите модули на страницата еден по еден за да го доведете производот во потребната состојба. Некои грешки беа вклучени во посебни задачи и беа завршени веднаш, други беа поправени паралелно со развојот на новата функционалност. Резултатот е дека со секое ажурирање, по навремено отстранување на грешки, страницата станува подобра и постабилна.

Задача бр. 2 – паралелен развој.

Во согласност со политиката за лиценцирање 1C-Bitrix, секоја лиценца за веб-локација ви овозможува да користите 2 копии од системот. Едната како производствена локација, втората за развој. Проблемот е што развојот го спроведуваат неколку, во мојот случај тројца, програмери континуирано. Во случај на класичен развој, сè е едноставно. Секој развивач работи на свој модул. Потоа се врши функционално тестирање на секој модул, сите подобрувања се спојуваат во складиштето на некој систем за контрола на верзии, а потоа се тестира сите заедно (тестирање за интеграција). Ако резултатот е нормален, тест верзијата му се презентира на клиентот. Откако ќе се прифати тест верзијата, производствениот сервер се ажурира. Во согласност со методологијата SCRUM, решив дека ќе ставам нови верзии на местото за производство еднаш неделно. Според тоа, има 3-4 дена за основен развој. 1 ден за тестирање и поправки на грешки и половина ден за ажурирање на серверот за производство. Роковите, се разбира, варираат, но се обидов строго да се придржувам до правилото „ослободување секој четврток“.

Првото нешто што наидов е дека во 1C-Bitrix има ситуации во кои истата датотека истовремено се користи во различна функционалност на различни краеви на страницата. Наједноставното и најочигледно решение е да користам систем за контрола на верзијата, во мојот случај, SVN, кој го користам во сите други проекти. Но, за да се користи контролата на верзијата, неопходно е секој развивач да има своја верзија на кодот, која ја уредува и потоа се спојува во заедничкото складиште.

Што е со лиценцата? Контактиран техничка поддршка 1C-Битрикс. Добив понуда да купам дополнително. лиценци за развој. Најблаго кажано, не бев среќен, но не добив други понуди. Доволно брзо најдов решение. Решив да користам NFR клучеви. За среќа, партнерскиот статус го дозволува тоа. Како резултат на тоа, создадов 5 инсталации на онлајн продавница:

  • Сервер за производство
  • Тест сервер
  • 3 развојни сервери (еден по развивач)

Со текот на времето отидов уште подалеку. Има и посебна инсталација за тестерот. Се испостави дека со моја среќа, клиентот секогаш се најавува на тест-серверот во моментот кога нешто се ажурира таму. Патеката за грешки содржи многу непотребни задачи кои се веќе завршени, а клиентот добива впечаток дека лошо си ја вршиме работата.

Во моментов ја користам следнава шема:

  • Секој развивач ја користи само својата локална копија за работа
  • Во договореното време, сите завршени подобрувања се спојуваат во заедничка гранка во складиштето
  • QA ја зема споената верзија за тестирање
  • По тестирањето и поправањето на грешките, демо-серверот се ажурира за клиентот
  • По верификацијата и прифаќањето од страна на клиентот, подобрувањата се пренесуваат на серверот за производство.

Меѓу очигледните недостатоци на овој пристап, би сакал да го истакнам ниското ниво на вклученост на клиентите во развојот. Резултатот е видлив за клиентот само во последната фаза. Овој пристап е применлив доколку имате добар аналитичар кој ретко греши и е во постојан контакт со клиентот. Во спротивно, многу задачи ќе треба да се преработат од нула.

Додека го градев колото, наидов на друг проблем. Проектот зазема околу 80 GB простор на дискот. Без кеш и привремени датотеки - околу 60. Отпрвин се обидов да ги отстранам сликите и видеата од контролата на верзијата - не функционираше. Информациите на страницата постојано се менуваат. Треба да тестирате користејќи тековни податоци. Првото обврзување на страницата во складиштето ми требаше повеќе од 2 дена во парчиња. Првото плаќање во папката за развој трае неколку часа (влезен SVN сервер локална мрежаразвој). Ако, не дај Боже, случајно направиш целосно ажурирање на фолдерот на проектот, можеш да заминеш да пушиш, да ручаш, да играш пинг-понг или карлинг. Давањето само избрани датотеки или папки е доста брзо. Решение: Ја завршив задачата да преземам десетина променети датотеки одеднаш.

Проблем бр. 3 – ажурирање на серверот за производство и соработка со клиентот

Проблемот е најважен, комплексен и не е целосно решен. На крајот на краиштата, ако другите проблеми се однесуваат на внатрешната работа на проектот, тогаш угледот и приходот на клиентот, а со тоа и мојот приход, зависат од работата на страницата.

Законите на Марфи функционираат одлично овде:

  • Ако нешто не работи добро на серверот за тестирање, тоа дефинитивно ќе се скрши на серверот за производство.
  • Ако нешто работи совршено на серверот за тестирање, сепак ќе се скрши на серверот за производство.
  • Ако грешката на страницата постои само 5 секунди, еден од посетителите дефинитивно ќе ја најде и дефинитивно ќе напише за тоа во прегледи или во формуларот за повратни информации.
  • Ако страницата не работи 1 минута за време на ажурирањето, тогаш токму во овој момент сопственикот на компанијата ќе му ја покаже на својот пријател или конкурент (и тоа е и покрај договорот за времето и постапката за ажурирање).
Се разбира, претерувам, но секоја шега има некаков хумор во себе. Минималното оптоварување на локацијата е од 4 до 6 часот наутро. Се разбира, би било подобро да се ажурира во овој момент, но навистина не сакам.

Во случајот на повеќето веб-апликации, постои јасна структура за поделба на апликацијата во слоеви и ажурирањето на страницата може да се подели на 2 дела:

  • Ажурирање на кодот
  • Ажурирање на базата на податоци користејќи SQL скрипти

Во случајот со 1C-Bitrix, сè е малку покомплицирано. Прво, има многу датотеки. Имам повеќе од милион од нив во мојот проект. Типично ажурирање од складиштето трае не помалку од 20-30 минути. Се разбира, можете да ги ажурирате само променетите датотеки, но тогаш целата поента на складиштето е изгубена. Второ, и ова е многу потажно, често при ажурирањето треба да направите рачни промени и поставки преку административниот панел. И ова е секогаш бавно, треба да ги запомните сите промени што треба да се направат, постои голема веројатност случајно да направите грешка. Се разбира, можете да напишете SQL скрипта што ќе ги направи сите потребни промени во базата на податоци. Во наједноставните случаи, се разбира, го правиме токму тоа. Но, во повеќето случаи, пишувањето и дебагирањето на таква скрипта трае повеќе време отколку самиот развој и многу повеќе време отколку рачно извршување на сите дејства со последователно тестирање.

Сè уште не најдов добро решение за проблемот. Сега рачно ги ажурираме поставките во базата на податоци. За да се минимизираат грешките, се составува листа за проверка со листа на она што треба да се направи за време на ажурирањето. Се трудиме да го извршиме ажурирањето што е можно повнимателно и прецизно. По ажурирањето, целиот тим ја проверува главната функционалност на производствениот сервер и врши дополнително тестирање. Бројот на грешки е минимизиран, но сè уште не е можно целосно да се ослободите од грешките и времето на прекин за време на ажурирањето.

Втората работа на која наидов е соработкасо клиентот. Бидејќи Проектот е голем, на него постојано работат околу 30 луѓе. Менаџери со содржина, менаџери за продажба, оптимизатори на оптимизација, маркетери и многу други. Секако, секој прави некои промени на страниците на страницата и поставките на модулите. Првата одлука беше да му се одземат правата на клиентот да прави промени во програмскиот код на страницата. Одлуката беше апсолутно исправна, но само се влоши. Ако порано клиентот претпоставуваше дека и тој може да оди на страницата и случајно да скрши нешто, сега целата неволја почна да паѓа само врз нас. Каква врска има тоа. Дури и ако менаџерот на содржина криво го уредил текстот на страницата и не затворил некоја ознака, сепак виновен е развивачот. Се покажа дека решението е прилично едноставно. Пазарот има бесплатен модул за контрола на верзијата на страницата. Ова не го реши проблемот, некој сè уште ќе збрка нешто од време на време, но сега е можно во секое време да се види кој го променил она што го променил и зошто сè пукнало. Резултатот, се разбира, не е мраз, но ми заштедува многу нерви.

Дополнително, решивме пред секое ажурирање на серверот за тестирање, да носиме копија од серверот за производство на него. Ова исто така одзема многу време. Архивирајте го проектот, префрлете го на друг сервер, отпакувајте го. Сето ова трае неколку часа. Но, новите подобрувања се тестираат практично во борбени услови. Доколку поставките на серверите за тестирање и производство се идентични, разликата во работењето ќе биде минимална, а бројот на грешки значително ќе се намали. Искуството покажа дека за една недела серверот за производство може да се промени толку многу што некои од новите функционалности што работат без проблеми на една недела стара копија може воопшто да не работат на нова копија.

Проблем бр. 4 – „направи го тоа за мене итно, ова е задача од 5 минути“

Проблемот се однесува не толку на 1C-Bitrix, туку на префинетоста и поддршката на работните проекти. Често клиентот има желба да направи некоја ситница, но итно и веднаш на местото на производство. Резултатот е секогаш ист - ништо добро не излегува од тоа. Во најдобар случај, оваа модификација едноставно ќе биде заборавена за време на следното издание; во најлош случај, серверот едноставно ќе се сруши и ќе треба да се врати од резервната копија неколку часа.

Најдов само едно решение - никогаш не го следете водството на клиентот на сметка на сигурноста и безбедноста. Без разлика како бара клиентот, програмерот секогаш ќе биде виновен. Како што ми рече мојот поранешен шеф: „Не те замолив да направиш ништо лошо“.

И бидејќи ја допревме темата за резервни копии, сакам да забележам. Резервната копија со користење на 1C-Bitrick е секако добра и удобна, но многу бавна. Ако итно треба да вратите 1-2 датотеки или неколку вредности во базата на податоци, треба да почекате додека не се отпакуваат сите 60 GB. Следната шема ми се чини дека е најефикасна:

  • Треба да има дневна резервна копија на датотеки и бази на податоци во форма на архива надворешен изворподатоци.
  • Секогаш правиме резервна копија веднаш пред ажурирањето во една од 2-те опции:
    1. Светло за опции – Копирајте ја целата проектна папка во соседна папка на серверот. Ние ја зачувуваме базата на податоци како депонија во посебна датотека. Ништо не архивираме. Во случај да треба да вратите некоја вредност во базата на податоци или некоја од датотеките, сè ќе ви биде при рака и лесно достапно
    2. Опција силна - слична на претходната, само ние ја копираме базата на податоци во друга база на податоци MySQL податоци. Ова ќе овозможи, во случај на целосен пад, да се поправи основната папка на страницата во датотеката на домаќините за 1-2 минути, а проектот ќе започне да работи од соседна папка со копија од базата на податоци.

Заклучок

Благодарност до сите што прочитаа до крај. Се надевам дека моето искуство ќе ви биде корисно. Ќе ми биде драго да добијам предлози за подобри начини за решавање на проблемите покренати во коментарите или во лична порака. Сега се обидов да ги искажам главните проблеми за финализирање и поддршка на веќе започнатите проекти со високи барања за доверливост. Ако материјалот се покаже како интересен, планирам да напишам продолжение за карактеристиките на архитектурата 1C-Bitrix што го разликуваат развојот на страницата на Bitrix од развојот на други веб-проекти.

Информации за работа со може да се најдат во упатствата и документацијата. Курсевите за обука се дизајнирани да ги совладаат работните методи во софтверски производ, и документација - за совладување на принципите на CMS прилагодување.

Кога работите со „1C-Bitrix: Управување со локација“проблемите се јавуваат во форма на конкретни практични проблеми. Се собравме во специјализирани теми различни страницикурсеви за обука за да ви биде полесно да најдете одговори на вашите прашања.



Центри за обука Постави прашање Форум



Обележете Менаџери со содржинае наменет за оние кои директно ќе работат со производот, односно за менаџери со содржини кои водат проекти креирани на нашиот софтверски производ.

Обележете Администраторитенаменети за оние кои ќе администрираат „1C-Bitrix: Управување со локација“.

Обележете За програмеринаменета за развивачите на проекти врз основа на „1C-Bitrix: Управување со локација“.

Менаџери со содржина

Можете да го увезете курсот на вашата веб-страница Менаџер за содржинаод оваа архива. Курс без прашања за тестови.
Верзија на курсот од 5 јуни 2015 година.

Администраторите

За програмери

Програмерската документација е опис на системот API. Корисничката документација е опис на компонентите и поставките на системот.

Документацијата е достапна и онлајн и како датотека во формат chm. Се препорачува да се користи онлајн верзијата бидејќи е поажурирана. Датотеките со формат chm периодично се ажурираат и може да не содржат информации за најновите промениво системот за помош.

Внимание! Ако не ја гледате содржината на датотеката со формат .chm, тогаш причината се безбедносните поставки на оперативниот систем. Во својствата на датотеката треба да ја одблокирате датотеката од гледање. Прочитајте повеќе воНајчесто поставувани прашања

Документацијата е референтна информација. Не е доволно за почетник програмер да работи со системот. Во совладувањето на принципите на програмирање во Рамка БитриксПосебен курс ќе ви помогне:


Врв