› › Dokumentacija za škatlasto različico Bitrix24. Dokončanje čarovnika za namestitev

Dokumentacija za škatlasto različico Bitrix24. Dokončanje čarovnika za namestitev

Bitrix Framework - tehnološko jedro (platforma) za izdelavo in vodenje projektov (spletne strani in korporativni portali). Platforma vam omogoča ustvarjanje neomejenega števila projektov z uporabo ene kopije (licence) izdelka, pri čemer jedro in bazo podatkov sistema postavite v eno kopijo na strežnik.

Vklopljeno ta trenutek v D7 niso podvojene vse funkcije starega jedra. Toda novo jedro D7 Bitrix Framework postopoma nadomešča staro. Če je uporaba starega jedra povzročila opozorilo IDE: Method/class is deprecated , potem morate uporabiti .

Zaradi več razlogov dokumentacija API morda ne zajema vseh metod. Za razumevanje delovanja je včasih bolje pogledati dejansko programsko kodo. Za to lahko uporabite brezplačen modul iz tržnice: .

Opomba: če naslovu katere koli strani dodate #examples, lahko hitro skočite na primer, če je na njej. (To ne deluje v dokumentacijskih datotekah, oblikovanih v CHM.)


Različice entitet

Bitrix Framework nenehno razvijajo. Pojavijo se nove funkcije, nekatere postanejo zastarele, v funkcijah se pojavijo novi parametri. Vendar pa precej veliko število projektov ni posodobljenih. Za olajšanje dela programerja je v dokumentaciji navedeno, iz katere in za katero različico izdelka je obstajal (obstaja) razred, metoda, parameter, dogodek.

Različice so pritrjene na dveh mestih: v naslovu in v tabelah. Če je metoda veljavna, bo naslov vseboval samo številko različice, s katero se je pojavil v izdelku. Če je metoda zastarela, bo tam naveden obseg različic, kjer je bila veljavna.

V tabelah je navedena različica, s katero se je entiteta pojavila v izdelku, le če njen videz ne sovpada s trenutkom pojava samega razreda, metode itd. Na spodnji sliki: parameter COURSE_ID se je pojavil skupaj z metodo (torej od 5.1.0), parameter CHAPTER_ID pa šele od različice 9.5.4.

Če se je z razvojem izdelka parameter (običajno se to nanaša na parametre) spremenil, potem bo v njegovem opisu ustrezna opomba. (Na primer: pred različico x.x.x se je parameter imenoval *****).

Primer

Opombe:

  • označiti Zastarelo za metodo, parameter, ključ pomeni, da ga ni priporočljivo uporabljati, saj ne bo nobenih razširitev in popravkov.
  • Namestitev različic še ni v celoti zaključena, delo v tej smeri trenutno poteka.

Bitrix, 2001-2019, 1C-Bitrix, 2019

Integracijo spletne trgovine na 1C-Bitrix s sistemom lahko izvedete s pomočjo sistemskega modula v Bitrix.Marketplace.

Ko je nameščen, bo modul pomagal pri nalaganju obstoječih naročil v sistem.

Po namestitvi bo modul:

  • naložite nova naročila iz 1C-Bitrix v sistem;
  • posodobite podatke o obstoječih naročilih ob upoštevanju sprememb v 1C-Bitrix;
  • naložite nova naročila in stranke iz sistema v 1C-Bitrix;
  • posodobite podatke o obstoječih naročilih ob upoštevanju sprememb v sistemu (v sistemu je bilo na primer spremenjeno stanje naročila, število blaga v naročilu itd., te spremembe se bodo odražale tudi v 1C-Bitrixu );
  • v sistem pošlje informacije o spletnem plačilu naročila s strani uporabnika.

Možno je tudi prilagoditi razrede vtičnikov, ne da bi pri posodabljanju izgubili spremenjeno kodo. Za implementacijo spremenjene kode morate v imenik bitrix/php_interface/retailcrm postaviti kopijo datoteke z zahtevanim razredom.

Vtičnik ima možnost prilagajanja naslednjih datotek:

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

Za prilagajanje datotek, katerih imena vsebujejo uporabljeno različico API-ja, se datoteke ustvarijo z imenom brez navedbe različice, na primer - RetailCrmHistory.php.

Ko ustvarite kopijo datoteke z razredom v imeniku bitrix/php_interface/retailcrm, bo modul uporabljal prilagojeni razred, lahko spremenite njegove metode.

Registracija spletne trgovine v sistem

Pred namestitvijo registrirajte svojo spletno trgovino v svoji sistemski instanci (razdelek Administracija > Trgovine, npr. v demo verziji):

Namestitev rešitve v 1C-Bitrix

  • Kliknite »Namesti« na strani rešitve v tržnici in vnesite naslov vaše spletne trgovine:

  • Prenesite modul prek sistema posodobitev 1C-Bitrix:

  • Začnite nameščati modul:

Zagnal se bo čarovnik za namestitev.

Čarovnik za namestitev. Korak 1

V koraku 1.1 morate določiti naslov vašega sistema (na primer https://test.retailcrm.ru) in ključ API, ki ste ga prej ustvarili v sistemu:

Pomembno! Če je v Bitrixu samo ena trgovina, je korak 1. Spletna mesta preskočen.

Čarovnik za namestitev. 1. korak. Spletna mesta

V koraku 1. Spletna mesta morate nastaviti korespondenco med svojimi trgovinami v 1C-Bitrix in sistemom.

Pomembno! Vse vaše trgovine v sistemu morajo imeti skupni ključ API.

Čarovnik za namestitev. 2. korak

V drugem koraku morate določiti ujemanje med vrednostmi spletne trgovine in sistemskih imenikov. Modul sam poskuša vzpostaviti korespondenco za tipična stanja. Če modul tega ni uspel, morate sami določiti ujemanje:

Preverite, ali ima sistem potrebne iskalne vrednosti, ki ustrezajo iskalnim poizvedbam spletne trgovine. Če niso dovolj, jih dodajte v razdelku Administracija, ne da bi zaprli stran čarovnika za namestitev:

Po tem osvežite stran čarovnika: naložiti je treba nove referenčne vrednosti.

Čarovnik za namestitev. 3. korak

V tretjem koraku vam modul omogoča nastavitev ujemanja med polji 1C-Bitrix in sistemom.

Pomembno! Če obstaja obrazec povratne informacije” ali naročila “v 1 kliku” in ti podatki ne spadajo v standardna naročila Bitrix, potem se ne potegnejo v sistem.

Tudi, če delate z pravne osebe, morate izpolniti vsa polja, kot je prikazano na spodnjem posnetku zaslona.

Čarovnik za namestitev. 4. korak

V četrtem koraku vam modul omogoča nalaganje predhodno oddanih naročil v sistem. Razkladanje lahko traja nekaj časa (1000 naročil se razloži v približno 5 minutah). Napredek postopka raztovarjanja bo pokazal vrstico napredka.

Po potrebi lahko nalaganje začasno ustavite in čez nekaj časa znova nadaljujete.

Z nalaganjem predhodno oddanih naročil si boste lahko ogledali analitična poročila na plošči KPI. Priporočamo, da naredite ta korak.

Čarovnik za namestitev. 5. korak

V petem koraku je konfigurirano razkladanje kataloga izdelkov. Če želite to narediti, sledite spodnjim korakom.

1. Izbira infoblokov in lastnosti

Izbrani infobloki bodo naloženi v sistem. Ponujeno vam bo, da izberete samo tiste infobloke, ki vsebujejo blago ali imajo povezane infobloke s trgovskimi ponudbami. Vzporedno z izbiro infoblokov lahko izberete naslednje lastnosti: izdelek, proizvajalec, barva, teža, velikost - za to morate določiti lastnost infobloka, ki je odgovorna za shranjevanje ustrezne lastnosti. Izbira lastnosti ni obvezna.

2. Pot datoteke

Na določeni poti bo ustvarjena datoteka v formatu, v kateri se bo nahajala struktura imenika. Privzeta pot je - "/bitrix/catalog_export/retailcrm.xml". Če spremenite pot, boste morali izvesti podobno konfiguracijo v sistemu.

3. Nastavitev števila ponudb v izvozu

V nastavitvah izvoza kataloga je polje »Maksimalno število trgovskih ponudb na izdelek«, kjer morate vnesti največje število trgovinskih ponudb, ki jih lahko ima en izdelek (če jih je več kot 50). Privzeto modul izračuna največ 50 trgovinskih ponudb za izdelek. Če je v trgovini manj kot 50 ponudb za izdelek, lahko to nastavitev prezrete. Če je ponudb za trgovanje več in je nastavitev določena, je priporočljivo, da posrednika prenesete v krone, če deluje na zadetkih.

4. Izbira pogostosti razkladanja

Na izbiro bodo tri možnosti:

1. št- ko je ta element izbran, občasno razkladanje kataloga ne bo samodejno konfigurirano, zato boste morali katalog vsakič razložiti sami.

Ta možnost je lahko uporabna, če se katalog izdelkov vaše spletne trgovine zelo redko spreminja ali če želite pozneje prilagoditi nastavitve nalaganja.

2. Cron- z izbiro te postavke se samodejno ustvari poseben profil, ki bo povezan s storitvijo Cron strežnika, na katerem deluje spletna stran spletne trgovine.

Zažene se pripomoček cron ozadje in opravlja določene naloge ob določenem času.

Izbira tega artikla je lahko koristna, če katalog vsebuje zelo obsežno nomenklaturo ( več kot 10.000 izdelkov). Za to postavko morate podati ime izvoznega profila po meri.

3. Agent. V tem primeru bo ustvarjen tudi poseben profil, ki se bo povezal s tehnologijo "Agenti" v 1C-Bitrixu in prišlo bo do nalaganja samodejno enkrat na dan.

Agent je funkcija php, ki se izvaja z določeno frekvenco. Na začetku nalaganja vsake strani sistem samodejno preveri, ali obstaja agent, ki ga je treba zagnati, in ga po potrebi izvede. Ni priporočljivo ustvarjati agentov za dolga nalaganja - bolje je uporabiti cron.

Ta možnost je najprimernejša, če imenik vsebuje manj kot 10.000 artiklov, potem je nalaganje precej hitro in to ne bo vplivalo na hitrost spletne strani spletne trgovine.

V primeru velike nomenklature ( več kot 10.000 izdelkov), je potrebna dodatna konfiguracija agenta na Cronu. Za to postavko morate podati tudi ime izvoznega profila po meri.

4. Indikacija takojšnjega razkladanja

Kot rezultat nastavitve zastavice »Razloži zdaj« bo struktura imenika razložena v zgornjo datoteko takoj po namestitvi modula.

Ko naložite katalog v datoteko v sistemu, pojdite na Administracija -> Trgovina -> Ime trgovine -> zavihek Katalog in označite polje »Prenesi katalog iz ICML zdaj«. V tem primeru se prenos datoteke in njena obdelava začneta skoraj takoj.

5. Določanje imena profila

Ko je nalaganje kataloga izdelkov pravilno konfigurirano, se v razdelku Trgovina > Nastavitve > Izvoz podatkov pojavi nova vrsta sistemskega izvoza, če med namestitvijo določite občasno nalaganje, se prikaže tudi izvozni profil.

Opomba:
Za samonastavitev Razkladanje ima možnost ustvarjanja lastnega izvoznega profila.

Dokončanje čarovnika za namestitev

Na koncu namestitve bosta ustvarjena 2 agenta: en agent naloži zgodovino naročil iz Bitrixa v sistem, drugi agent ustvari katalog. Če je za agenta konfigurirano nalaganje naročil, se naročila naložijo v sistem v trenutku, ko se prikliče zgodovina. V drugih primerih se naročila razbremenijo glede na dogodek.

Razkladanje dostavne službe med izmenjavo 1C-Bitrix - sistem

Če imate na 1C-Bitrix povezane avtomatizirane storitve dostave, kot je eDost, ki imajo veliko profilov: Ruska pošta, EMS, DHL in mnogi drugi, potem lahko v sistemu izkoristite možnost nalaganja te vrste dostavne službe.

Načini dostave morajo biti konfigurirani na strani sistema. Če je bil sistemski modul nameščen, preden je bila dostava povezana z Bitrixom, bo treba manjkajoče načine dostave v sistem vnesti ročno. Če je bil modul nameščen po povezavi dostavne službe, se samodejno namestijo načini dostave in razkladanje same storitve. To pomeni, da bo za vsako naročilo strošek pošiljanja razložen.

Na strani 1C-Bitrix je treba izvesti naslednje nastavitve, če je bil sistemski modul nameščen po povezavi dostavne službe s sistemom 1C-Bitrix:

Pojdi do Skrbništvo > Nastavitve, pojdite na zavihek "Nastavitve iskanja".

Nastavite ujemanje načinov dostave (predhodno konfigurirano na strani sistema). Nato kliknite gumb »Razloži storitve dostave«.

Nastavitev pogostosti nalaganja 1C-Bitrix - sistem

Pri posodabljanju kataloga izdelkov je mogoče razlikovati dve točki:

Generiranje imenika (v formatu yml/icml) na strani odjemalca in

Sistem naloži katalog vsake tri ure. Pot do datoteke, ki jo želite naložiti, je nastavljena v nastavitvah trgovine - odpreti morate razdelek Skrbnik > Trgovine > Izberite Trgovina > Zavihek Katalog.

Po namestitvi sistemskega modula v 1C-Bitrix se ustvari profil za nalaganje. Za ogled morate iti na Namizje > Trgovina > Nastavitve > Izvoz podatkov. Posnetek zaslona prikazuje dve možnosti:

privzeto,

Nalaganje sistemskega imenika.

Če izberete drugo možnost, s klikom nanjo odprete možnosti nalaganja.

Če je kot možnost periodičnosti izbran agent, morate za ogled seznama agentov iti na Namizje > Nastavitve > Nastavitve izdelka > Agenti.

Če kliknete »Spremeni« ali »Dodaj novo«, lahko dodelite ali spremenite pogostost zagona opravila za generiranje.

Pogostost sinhronizacije podatkov med izmenjavo 1C-Bitrix - sistem

Sistemski modul vam omogoča nalaganje kataloga blaga v vaš sistem, kot tudi redno dvosmerno izmenjavo naročil in strank.

S pravočasnim razkladanjem podatkov iz kataloga bodo imeli skrbniki vašega sistema ažurne informacije o razpoložljivosti blaga. Do situacije, ko je blago naročeno in se čez nekaj časa izkaže, da ga ni na zalogi, ne bo prišlo.

Izmenjava naročil je proces sinhronizacije podatkov, ko se naročila nalagajo v obe smeri:

Od 1C-Bitrix do sistema:

  • Če je omogočeno razkladanje po dogodkih, bo pri ustvarjanju ali spreminjanju naročila v sistemu 1C-Bitrix takoj razloženo v sistem. Če je izbran agent za raztovarjanje, bo naročilo razloženo v sistem v 15 minutah (ni priporočljivo uporabljati tega mehanizma brez utemeljenih razlogov, saj v tem primeru naročila prispejo z zamikom in posodobitve teh naročil ne bodo prenesene na sistem).
  • Ob menjavi uporabnika se v sistem takoj naložijo tudi glavni podatki.

Od sistema do 1C-Bitrix:

  • Če v sistemu ustvarite naročilo za novega uporabnika, bo naročilo naloženo v 1C-Bitrix in nov uporabnik bo ustvarjen v intervalu od 1 do 15 minut.
  • Če spremenite naslov, stroške dostave ali status v sistemu na strani naročila, bodo vse te spremembe naložene v 1C-Bitrix v 15 minutah.
  • Če v sistemu spremenite popuste za blago in spremenite količino blaga, se bo to spremenilo tudi v 1C-Bitrix v razponu od 1 do 15 minut.

Spremembe v integracijskem modulu

Različica 2.0

  • Integracijski modul V2.0 je namenjen integraciji 1C-Bitrix z nameščenim modulom »Spletna trgovina (prodaja)« različice > 16.
  • Zdaj delo modula poteka prek API-ja V4.
  • Integracijski modul sedaj uporablja novo jedro 1C-Bitrix D7.
  • Sedaj iz sistema stran prejme tudi spremembe za stranko (polno ime, e-pošta, telefon).
  • V nastavitvah integracijskega modula v razdelku »Druge nastavitve« je postalo mogoče oddajati številke naročil iz sistema v 1C-Bitrix. To pomeni, da če je naročilo s številko, na primer 12345R, ustvarjeno v sistemu ročno, bo naročilo z isto številko ustvarjeno v 1C-Bitrix.
  • Ker so razvijalci Bitrixa v modulu "Spletna trgovina (odprodaja)" verzija > 16 pustili uporabo popustov za celotno naročilo in pustili popuste le za blago, sistem zaenkrat tudi nima možnosti koriščenja popustov za celotno naročilo. Popuste lahko nastavite samo za določene artikle naročila.

Različica 2.1

  • Dodane merske enote pri izvozu kataloga.

Različica 2.2

  • Modul zdaj podpira več različic API z izbiro.
  • Podpora za API V5.
  • Dodana možnost raztovarjanja ostankov v okviru skladišč.
  • Dodana možnost prenosa tipov cen.
  • Dodana osnovna integracija Daemon Collector.
  • Dodana integracija z Universal Analytics.
  • Izboljšana je logika vgrajenih funkcij za spreminjanje podatkov.
  • Dodana vgrajena funkcija retailCrmApiResult.
  • Dodana sprožilna različica zgodovine sprememb.

Različica 2.4

  • Dodano preverjanje v upravljalniku za shranjevanje plačila za novo naročilo.
  • Dodana nastavitev števila trgovinskih ponudb v izvozu.
  • Dodana je konverzija nabavne cene.
  • Spreminjanje prevodnih datotek.
  • Dodano preverjanje pri razlaganju sprememb iz sistema za lastnosti naročila.
  • Dodan DDV nalaganje.
  • Popravljeno pridobivanje seznama vrst cen za razkladanje. Za izbiro so na voljo vse vrste, ki so na voljo v Bitrixu.

Druge nastavitve

Nastavitve naročila

Oddajte številke naročil, ustvarjenih v CRM, v trgovino

Pri ustvarjanju naročila v sistemu ima le-to svojo unikatno številko po določenih pravilih. Ko je ta nastavitev nastavljena v modulu, se številka takega naročila med povratno sinhronizacijo prenese v trgovino.

Raztovarjanje naročil

  • Po dogodku- pri shranjevanju naročila gredo podatki v sistem;
  • Agent- nova naročila se pošljejo pred zahtevanjem zgodovine sprememb iz sistema.

Različica API-ja odjemalca

Zdaj lahko izberete različico API-ja, s katero bo modul deloval. Izbira je odvisna od različice sistema. Priporočljivo je, da izberete najnovejšo različico.

Omogoči razkladanje stanja v kontekstu skladišč (na voljo, če obstajajo skladišča)

Zdaj lahko občasno raztovorite ostanke iz skladišč na lokaciji v sistemska skladišča. Za to potrebujete:

  • primerjati skladišča mesta s skladišči sistema;
  • določite shrambe sistema, v katere bodo naložena stanja;
  • izberite infobloke z blagom, potrebnim za nakladanje ostankov (morate izbrati tiste, ki so navedeni v izvozu kataloga za sistem).

Raztovarjanje izvaja agent s frekvenco 1 ure (privzeto).

Upoštevajte, da morajo biti možnosti omogočene, če želite naložiti ostanke v sistem.

Omogoči nalaganje vrst cen za izdelke (na voljo samo, če obstaja več vrst cen)

Zdaj lahko občasno naložite dodatne vrste cen iz trgovine v sistem. Za to potrebujete:

  • primerjajte tipe cen spletnega mesta s tipi cen sistema;
  • določite trgovine sistema, v katere bodo naložene dodatne vrste cen;
  • izberite infobloke z izdelki, ki zahtevajo nalaganje dodatnih tipov cen (izbrati morate tiste, ki so navedeni v izvozu kataloga za sistem).

Raztovarjanje izvaja agent s frekvenco 24 ur (privzeto).

Aktivirajte Daemon Collector

Zdaj lahko dodate Collector Daemon na svoje spletno mesto iz vmesnika za nastavitve. Če želite to narediti, morate določiti ustrezen ključ za želeno spletno mesto. Ključ najdete v sistemu.

Omogoči integracijo UA

Zdaj lahko omogočite integracijo z Universal Analytics v vmesniku za nastavitve (pravilno deluje s standardno komponento za preverjanje). Za vsako spletno mesto, ki mu želite dodati sledenje, boste morali izpolniti ID sledenja in indeks razsežnosti po meri.

Kjer je $order niz podatkov o naročilu, ki se pošljejo sistemu, $arFields pa je niz polj naročila na spletnem mestu. funkcija retailCrmBeforeOrderSave($order) ( //Vaše spremembe vrnejo $order; //ali vrnejo false; nato bodo spremembe sistema za to naročilo prezrte)

Kjer je $order matrika s spremenjenimi podatki o naročilu, ki prihajajo iz sistema.

funkcija retailCrmAfterOrderSave

retailCrmAfterOrderSave - funkcija, ki se izvede takoj po shranjevanju na spletnem mestu sprememb podatkov o naročilu, ki izvirajo iz zgodovine sistema.

funkcija retailCrmAfterOrderSave($order) ( //Vaše spremembe se vrnejo; )

Kjer je $order matrika s spremenjenimi podatki o naročilu, ki prihajajo iz sistema.

funkcija retailCrmApiResult

retailCrmApiResult - funkcija, ki se izvede takoj po prejemu odgovora sistemskega API-ja.

funkcija retailCrmApiResult($methodApi, $res, $code) ( //Vaše spremembe vrnejo; )

Kjer je $methodApi ime metode API, $res je rezultat prave/napačne zahteve (uspešna ali neuspešna zahteva), $code je statusna koda odgovora API.

Upoštevajte, da lahko napake v kodi pri uporabi te funkcije motijo ​​sinhronizacijo spletnega mesta in sistema.

Če zgoraj navedena orodja iz nekega razloga ne zadoščajo, lahko zahtevane spremembe naredite neposredno v kodi modula, ne da bi pri posodabljanju modula izgubili te spremembe. Če želite to narediti, morate kopirati datoteko z zahtevanim razredom v imenik /bitrix/php_interface/retailcrm/ in ga že v njem spremeniti. Ta mehanizem podpira spreminjanje razredov za delo s strankami, naročili, dogodki, izvozom kataloga in drugimi pomožnimi mehanizmi.


Zaznamek Naloge po meri je namenjen tistim, ki bodo neposredno delali s produktom, torej zaposlenim v podjetjih, ki uporabljajo naš programski produkt.

Zavihek Skrbniške naloge je namenjen tistim, ki bodo skrbeli za škatlasto različico Bitrix24.

Zaznamek Dokumentacija zasnovan za razvijalce projektov, ki temeljijo na različici v škatli Bitrix24.

Naloge po meri

Skrbniške naloge

Razvijalci

Dokumentacija za razvijalce je opis API-ja sistema. Uporabniška dokumentacija je opis komponent in nastavitev sistema.

Dokumentacija je na voljo na spletu in kot datoteka chm. Priporočljiva je uporaba spletne različice, saj je bolj ažurna. Datoteke chm se redno posodabljajo in morda ne vsebujejo informacij o najnovejših različicah.

Pozor! Če ne vidite vsebine formatne datoteke .chm, potem so razlog varnostne nastavitve operacijski sistem. V lastnostih datoteke morate odstraniti blokiranje ogleda datoteke. Preberite več vpogosta vprašanja

Dokumentacija je referenčna informacija. Ni dovolj, da razvijalec začetnik dela s sistemom. Pri obvladovanju principov programiranja v Bitrix Framework poseben tečaj vam bo pomagal:

Ne tako dolgo nazaj je naše podjetje prejelo precej veliko spletno trgovino na 1C-Bitrix za vzdrževanje in revizijo. Projekt je bil v komercialnem obratovanju že nekaj mesecev, hkrati pa je imel številne resne težave. Poleg tega je naročnik načrtoval čimprejšnje dokončanje nalog dokončanja nove funkcionalnosti. Dobil sem nalogo organiziranja učinkovito delo projekt z minimalnim časom izpada spletnega mesta in največjim zadovoljstvom strank.

Začetni podatki:

  • Na 1C-Bitrixu je spletna trgovina
  • Projekt je star nekaj let, a šele pred nekaj meseci je bilo spletno mesto preneseno na 1C-Bitrix
  • Obisk 10-15 tisoč ljudi na dan
  • Katalog trgovine vsebuje približno 12.000 artiklov blaga
  • Nedelovanja in izpadi spletnega mesta so nesprejemljivi
  • Projekt je šest mesecev razvijalo drugo podjetje:
    1. Obstaja TOR, približno 100 listov, kar ustreza opravljenemu delu za približno 40%
    2. Brez projektne dokumentacije
    3. Pomanjkanje razumevanja, zakaj so prejšnji razvijalci uporabljali takšne arhitekturne rešitve.

Razvoj programsko opremo na splošno in še posebej s spletnimi projekti se ukvarjam približno 8 let. V tem času sem se soočal s projekti različnih zahtevnosti in na prvi pogled se mi naloga ni zdela pretežka. Pri izvajanju projektov v našem podjetju se praviloma uporablja metodologija SCRUM. Začel sem se umikati stran od nje.

Najprej sem dobil dostop izvorna koda projekt. Površno analizirano. S stranko dogovorili seznam prednostnih nalog. Naredil sem razvojni načrt za 3 razvijalce in kot je rekel Gagarin, gremo!

Problem številka 1 - krivi so razvijalci

Kot se ponavadi zgodi, so za vse krivi vsi razen stranke. Oblikovalec je naredil pretežko postavitev, gostitelj je zagotovil počasen strežnik, razvijalci so naredili spletno stran, ki ima hrošče in se ves čas pokvari, upravitelji so opravili nekaj nalog, za katere nismo zahtevali, da jih opravimo po prehodu iz stara različica spletnem mestu na 1C-Bitrixu se je močno zmanjšal iskalni promet itd. Situacija ni jasna. Po eni strani bi morala biti glavna odgovornost seveda na strani razvijalca. Stranki je bilo treba posredovati posledice vseh dejanj s spletno stranjo in se pripraviti na rezultat. Pri izvajanju del ponudite celostno arhitekturo prihodnji sistem in razvojni načrt, ki mu je treba slediti, dokler mejniki niso dokončani. Izvedite temeljito testiranje funkcionalnosti in predajte delo. Po drugi strani pa velikokrat naletim na situacijo, ko kupec sam vse bolje pozna, ker je njegova mama nekoč slikala in je torej najboljši oblikovalec, njegov 7-letni sin pa dobro pozna SEO, saj ves čas preživi za računalnikom in igra GTA.

Kdo je kriv, kdo ima prav, ne sodimo mi. V tem primeru je bil prejšnji izvajalec dokaj znano zanesljivo podjetje in o njihovem razvoju ne morem reči nič slabega. In kupec objektivno skrbi za svoj izdelek in ga poskuša izboljšati. Ne vem, kako je bilo, zase sem našel razlago v nezadostni količini analitike, ki jo je izvajalec posredoval naročniku.

Kot rezultat:

  • Projekt ni bil pripeljan do logičnega konca. Veliko nalog je opuščenih na sredini poti
  • Projekt ni dokumentiran. Delo dela funkcionalnosti ni očitno. Pri razvoju nove funkcionalnosti se izkaže, da je prenehala delovati funkcionalnost, ki je prej delovala in o obstoju katere novi razvijalec ni slutil
  • Del kode, ki jo je napisal prejšnji izvajalec, je treba ponovno napisati iz nič
  • Predvidena arhitektura projekta v prvih tednih / mesecih dela novemu izvajalcu ni jasna. Izpopolnjevanje funkcionalnosti enega modula povzroči izgubo funkcionalnosti modula, ki z njim ni v nobeni povezavi.
  • Stranka nervozna, izvajalec nervozen, obiskovalci nezadovoljni, obisk vse manjši, prodaja pada

Vidim samo eno rešitev problema: postopoma sistematično očistite vse module spletnega mesta po vrsti, da izdelek pripeljete v zahtevano stanje. Nekatere napake so bile premaknjene v ločene naloge in izvedene takoj, nekatere so bile popravljene vzporedno z razvojem novih funkcionalnosti. Rezultat - z vsako posodobitvijo, po operativnem čiščenju hroščev, ki so se pojavili, je stran vedno boljša in stabilnejša.

Problem št. 2 je vzporedni razvoj.

V skladu z licenčno politiko 1C-Bitrix vam vsaka licenca spletnega mesta omogoča uporabo 2 kopij sistema. Ena kot proizvodna lokacija, druga - za razvoj. Težava je v tem, da razvoj nenehno izvaja več, v mojem primeru trije razvijalci. V primeru klasičnega razvoja je vse preprosto. Vsak razvijalec dela na svojem modulu. Nato se izvede funkcionalno testiranje vsakega modula, vse izboljšave se zlijejo v repozitorij nekega sistema za nadzor različic, nato se vse skupaj testira (integracijsko testiranje). Če je rezultat normalen, se kupcu predstavi preskusna različica. Ko je preskusna različica sprejeta, se produkcijski strežnik posodobi. V skladu z metodologijo SCRUM sem se odločil, da bom enkrat tedensko naložil nove različice na produkcijsko mesto. V skladu s tem je za glavni razvoj na voljo 3-4 dni. 1 dan za testiranje in odpravljanje napak in pol dneva za posodabljanje bojnega strežnika. Seveda roki nihajo, vendar sem se skušal striktno držati pravila »sproščanje vsak četrtek«.

Prva stvar, na katero sem naletel, je bila, da v 1C-Bitrixu obstajajo situacije, v katerih je ista datoteka hkrati vključena v različne funkcije na različnih koncih spletnega mesta. Najenostavnejša in najbolj očitna rešitev je uporaba sistema za nadzor različic, v mojem primeru SVN, ki ga uporabljam v vseh drugih projektih. Toda za uporabo nadzora različic je nujno, da ima vsak razvijalec svojo različico kode, ki jo ureja in nato združi skupni repozitorij.

Kaj pa licenca? Obrnil sem se na tehnično podporo 1C-Bitrix. Prejel ponudbo za dokup. razvojne licence. Milo rečeno nisem bil vesel, a drugih ponudb nisem dobil. Hitro sem našel izhod. Odločil sem se za uporabo ključev NFR. Na srečo partnerski status to omogoča. Kot rezultat sem ustvaril 5 instalacij spletne trgovine:

  • Produkcijski strežnik
  • Testni strežnik
  • 3 razvojni strežniki (eden na razvijalca)

Čez čas je šel še dlje. Obstajala je tudi ločena namestitev za tester. Izkazalo se je, da z mojo srečo stranka vedno vstopi na testni strežnik v trenutku, ko se tam nekaj posodablja. V bugtracku je veliko nepotrebnih nalog, ki so že opravljene, stranka pa dobi vtis, da svojega dela ne opravljamo dobro.

Trenutno uporabljam naslednjo shemo:

  • Vsak razvijalec za delo uporablja samo svojo lokalno kopijo
  • Ob dogovorjenem času se vse opravljene izboljšave združijo v skupno vejo v repozitoriju
  • QA vzame za testiranje "razmazano" različico
  • Po testiranju in odpravljanju napak se demo strežnik posodobi za stranko
  • Po preverjanju in sprejemu s strani stranke se izboljšave prenesejo na bojni strežnik.

Med očitnimi pomanjkljivostmi tega pristopa želim izpostaviti nizko stopnjo vključenosti strank v razvoj. Rezultat je stranki viden šele v končni fazi. Ta pristop je uporaben, če imate dobrega analitika, ki redko dela napake in je v stalnem stiku s stranko. V nasprotnem primeru bo treba veliko nalog ponoviti iz nič.

Med gradnjo vezja sem naletel na drugo težavo. Projekt zaseda okoli 80 GB na disku. Brez predpomnilnika in začasnih datotek - približno 60. Sprva sem poskušal odstraniti slike in videoposnetke iz nadzora različic - ni delovalo. Informacije na spletnem mestu se nenehno spreminjajo. Testirati morate na trenutnih podatkih. Prva objava spletnega mesta v repozitorij je pri meni šla v kosih več kot 2 dni. Prvo prevzemanje v razvojno mapo traja nekaj ur (strežnik SVN v lokalno omrežje razvoj). Če, bog ne daj, po nesreči naredite popolno posodobitev projektne mape, lahko greste kaditi, večerjati, igrati ping-pong ali curling. Posredovanje samo izbranih datotek ali map je dovolj hitro. Rešitev: opravil nalogo - izdati ducat spremenjenih datotek hkrati.

Problem #3 – Nadgradnja produkcijskega strežnika in sodelovanje s stranko

Problem je najpomembnejši, kompleksen in do konca nerešen. Konec koncev, če se preostale težave nanašajo na notranjo kuhinjo projekta, potem sta ugled in dohodek stranke ter posledično moj dohodek odvisen od dela spletnega mesta.

Tu pridejo v poštev Murphyjevi zakoni:

  • Če nekaj ne deluje dobro na testnem strežniku, se bo zagotovo pokvarilo na produkcijskem strežniku.
  • Če nekaj dobro deluje na testnem strežniku, se bo zagotovo pokvarilo na produkcijskem strežniku.
  • Če hrošč obstaja na spletnem mestu le 5 sekund, ga bo eden od obiskovalcev zagotovo našel in o tem zapisal v ocenah ali v obrazcu za povratne informacije.
  • Če spletno mesto med posodobitvijo ne deluje 1 minuto, ga bo lastnik podjetja v tej minuti pokazal svojemu prijatelju ali konkurentu (in to kljub usklajevanju časa in postopka posodabljanja).
Seveda pretiravam, a v vsaki šali je nekaj šale. Najmanjša obremenitev na mestu je od 4 do 6 zjutraj. Seveda bi bilo bolje posodobiti v tem trenutku, vendar tega res ne želim.

V primeru večine spletnih aplikacij obstaja jasna struktura za razdelitev aplikacije na plasti, posodabljanje spletnega mesta pa je mogoče razdeliti na 2 dela:

  • Posodobitev kode
  • Posodabljanje podatkovne baze s skripti SQL

V primeru 1C-Bitrix je vse nekoliko bolj zapleteno. Prvič, datotek je veliko. V svojem projektu jih imam več kot milijon. Običajna posodobitev iz repozitorija ne traja manj kot 20-30 minut. Seveda lahko posodobite le spremenjene datoteke, a potem se izgubi celoten smisel repozitorija. Drugič, in to je veliko bolj žalostno, pogosto morate pri posodabljanju narediti ročne spremembe in nastavitve prek skrbniške plošče. In to je vedno počasno, zapomniti si morate vse spremembe, ki jih je treba narediti, obstaja velika verjetnost, da se po nesreči zmotite. Seveda lahko napišete skript SQL, ki bo naredil vse potrebne spremembe v bazi podatkov. V najpreprostejših primerih seveda naredimo prav to. Toda v večini primerov pisanje in odpravljanje napak v takšnem skriptu traja več časa kot sam razvoj in veliko več časa kot ročno izvajanje vseh dejanj z naknadnim preverjanjem.

Nisem še našel dobre rešitve. Zdaj ročno posodobimo nastavitve v bazi. Za zmanjšanje napak je sestavljen kontrolni seznam s seznamom, kaj je treba narediti med posodobitvijo. Posodabljati se trudimo čim bolj skrbno in natančno. Po posodobitvi celotna ekipa preveri glavno funkcionalnost produkcijskega strežnika in izvede dodatna testiranja. Število napak je zmanjšano, vendar hrošči in izpadi med posodobitvami še niso popolnoma odpravljeni.

Druga stvar, s katero sem se srečal, je skupinsko delo s stranko. Ker projekt je velik, okoli 30 ljudi nenehno dela na njem. Upravljavci vsebine, vodje prodaje, SEO-optimizatorji, tržniki in mnogi drugi. Seveda vsak naredi nekaj sprememb na straneh spletnega mesta in nastavitvah modulov. Prva odločitev je bila, da se stranki odvzame pravica do spreminjanja programske kode strani. Odločitev je povsem pravilna, samo še slabše je bilo. Če je prej stranka domnevala, da lahko gre tudi na spletno stran in po nesreči kaj zlomi, so zdaj vsi udarci začeli padati samo na nas. Pri čem. Tudi če je upravitelj vsebine narobe uredil besedilo na strani in ni zaprl kakšne oznake, je še vedno kriv razvijalec. Rešitev se je izkazala za precej preprosto. Tržnica ima brezplačen modul za nadzor različic strani. Težave s tem ni bilo odpravljeno, vseeno bo občasno kdo kaj naredil, sedaj pa je mogoče v vsakem trenutku videti, kdo je spremenil, kaj se je spremenilo in zakaj se je vse pokvarilo. Rezultat seveda ni led, mi pa prihrani veliko živcev.

Dodatno smo se odločili, da pred vsako posodobitvijo testnega strežnika nanj prenesemo kopijo iz produkcijskega strežnika. Tudi to vzame veliko časa. Projekt arhivirajte, premaknite na drug strežnik, razpakirajte. Vse to traja več ur. Toda nove izboljšave so preizkušene skoraj v bojnih razmerah. Če so nastavitve testnega in produkcijskega strežnika enake, bo razlika v delovanju minimalna, število napak pa bistveno manjše. Kot so pokazale izkušnje, se lahko produkcijski strežnik v enem tednu toliko spremeni, da nekatere nove funkcionalnosti, ki brez težav delujejo na kopiji izpred enega tedna, morda sploh ne bodo delovale na novi kopiji.

Problem številka 4 - "naredi me nujno, to je naloga za 5 minut"

Težava se ne nanaša toliko na 1C-Bitrix, temveč na izboljšanje in podporo obstoječih projektov. Pogosto ima stranka željo izdelati kakšno malenkost, vendar nujno in takoj na mestu boja. Rezultat je vedno enak – nič dobrega ni. V najboljšem primeru bo ta izboljšava med naslednjo izdajo preprosto pozabljena, v najslabšem pa bo strežnik preprosto padel in bo trajalo več ur, da ga obnovimo iz varnostne kopije.

Našel sem le eno rešitev - nikoli ne sledite navodilom stranke na škodo zanesljivosti in varnosti. Ne glede na to, kako stranka zahteva, bo vedno kriv razvijalec. Kot mi je moj nekdanji šef rekel: "Nisem te prosil, da delaš slabe stvari."

In ker smo se dotaknili teme varnostnih kopij, želim opozoriti. Varnostno kopiranje z uporabo 1C-Bitrik je vsekakor dobro in priročno, vendar zelo počasno. Če morate nujno obnoviti 1-2 datoteki ali več vrednosti v bazi podatkov, morate počakati, da se razpakira vseh 60 GB. Tukaj se mi zdi najbolj učinkovita naslednja shema:

  • Obstajati mora dnevno varnostno kopiranje datotek in baze podatkov v obliki arhiva na zunanji vir podatke.
  • Varnostno kopijo vedno naredimo neposredno pred posodobitvijo v eni od dveh možnosti:
    1. Lučka možnosti – Kopirajte celotno mapo projekta v sosednjo mapo na strežniku. Baza podatkov v obliki izpisa se shrani v ločeno datoteko. Ničesar ne arhiviramo. V primeru, da boste morali obnoviti kakšno vrednost v bazi ali kateri od datotek, bo vse pri roki in lahko dostopno
    2. Močna možnost je podobna prejšnji, le da osnovo kopiramo v drugo osnovo Podatki MySQL. To bo omogočilo, da v primeru popolnega zrušitve v 1-2 minutah popravite korensko mapo spletnega mesta v datoteki gostiteljev in projekt bo začel delovati iz sosednje mape s kopijo baze podatkov.

Zaključek

Hvala vsem, ki ste prebrali do konca. Upam, da vam bo moja izkušnja koristila. Vesel bom predlogov o uspešnejših načinih reševanja težav, izraženih v komentarjih ali osebno. Zdaj sem poskušal izraziti glavne težave pri izpopolnjevanju in podpori že zagnanih projektov z visokimi zahtevami glede zanesljivosti. Če se bo gradivo izkazalo za zanimivo, nameravam napisati nadaljevanje o značilnostih arhitekture 1C-Bitrix, ki razlikujejo razvoj spletnega mesta na Bitrixu od razvoja drugih spletnih projektov.

Informacije o delu z lahko najdete v vadnicah in dokumentaciji. Tečaji usposabljanja so namenjeni obvladovanju metod dela v programski izdelek, in dokumentacija - za obvladovanje principov prilagajanja CMS.

Pri delu z "1C-Bitrix: Upravljanje spletnega mesta" problemi se pojavljajo v obliki posebnih praktičnih problemov. Različne strani izobraževalnih tečajev smo zbrali v teme profila, da boste lažje našli odgovore na svoja vprašanja.
Centri za usposabljanje Postavi vprašanje Forum



Zaznamek Upravljavci vsebine je namenjen tistim, ki bodo neposredno delali s produktom, torej vodjem vsebin, ki vodijo projekte, ustvarjene na našem programskem produktu.

Zaznamek Administratorji namenjeno tistim, ki bodo upravljali "1C-Bitrix: Upravljanje spletnega mesta".

Zaznamek Razvijalci namenjen razvijalcem projektov, ki temeljijo na "1C-Bitrix: Upravljanje spletnega mesta".

Upravljavci vsebine

Tečaj lahko uvozite na svoje spletno mesto Upravitelj vsebine iz tega arhiva. Tečaj brez vprašanj za teste.
Različica tečaja z dne 6. 5. 2015.

Administratorji

Razvijalci

Dokumentacija za razvijalce je opis API-ja sistema. Uporabniška dokumentacija je opis komponent in nastavitev sistema.

Dokumentacija je na voljo na spletu in kot datoteka chm. Priporočljiva je uporaba spletne različice, saj je bolj ažurna. chm se redno posodabljajo in morda manjkajo informacije o zadnje spremembe v sistemu pomoči.

Pozor! Če ne vidite vsebine formatne datoteke .chm, potem so razlog varnostne nastavitve operacijskega sistema. V lastnostih datoteke morate odstraniti blokiranje ogleda datoteke. Preberite več vpogosta vprašanja

Dokumentacija je referenčna informacija. Ni dovolj, da razvijalec začetnik dela s sistemom. Pri obvladovanju principov programiranja v Bitrix Framework poseben tečaj vam bo pomagal:

Priljubljeno v kategoriji:
Acoustic Energy AE1 MkIII: referenčni standardi za splošne zvočnike Pot do sebe
Acoustic Energy AE1 MkIII: referenčni standardi za splošne zvočnike...
prebrati
Kako namestiti CryptoPro - kako namestiti osebno potrdilo v CryptoPro z bliskovnega pogona?
Kako namestiti CryptoPro - kako namestiti osebni certifikat v ...
prebrati
Vdelana programska oprema za Alcatel van touch pixie
Vdelana programska oprema za Alcatel van touch pixie
prebrati
Animirana ozadja namizja
Animirana ozadja namizja
prebrati

Najnovejši članki
SIRI: kaj je to in kako ga uporabljati
prebrati
Zvočna kartica kot generator
prebrati
Kaj storiti, če "polja predmeta ni mogoče najti"
prebrati
Sistemske zahteve za Windows 7 Ultimate
prebrati
Samsung Galaxy Grand Prime: pregled, tehnični...
prebrati
Huawei HiSuite je program za sinhronizacijo z...
prebrati
Kako samodejno zagnati aplikacijo, ko ...
prebrati
Kako očistiti disk pred smeti
prebrati
Vrh