› › Bitrix24:n laatikkoversion dokumentaatio. Ohjatun asennustoiminnon viimeistely

Bitrix24:n laatikkoversion dokumentaatio. Ohjatun asennustoiminnon viimeistely

Bitrix Framework - tekninen ydin (alusta) projektien luomiseen ja hallintaan (verkkosivustot ja yritysportaalit). Alustan avulla voit luoda rajoittamattoman määrän projekteja käyttämällä yhtä tuotteen kopiota (lisenssiä) ja sijoittamalla järjestelmän ytimen ja tietokannan yhteen kopioon palvelimelle.

Päällä Tämä hetki kaikkia vanhan ytimen ominaisuuksia ei ole kopioitu D7:ssä. Mutta uusi D7-ydin Bitrix Framework korvaa vähitellen vanhan. Jos vanhan ytimen käyttö johti IDE:n varoitukseen: Method/class is deprecated , sinun on käytettävä .

Useista syistä API-dokumentaatio ei välttämättä kata kaikkia menetelmiä. Toiminnan ymmärtämiseksi on joskus parempi katsoa varsinaista ohjelmakoodia. Tätä varten voit käyttää ilmainen moduuli Marketplacesta: .

Huomautus: lisäämällä #examples minkä tahansa sivun osoitteeseen, voit nopeasti siirtyä esimerkkiin, jos se on sillä. (Tämä ei toimi CHM-muotoilluissa dokumentaatiotiedostoissa.)


Entiteettiversiot

Bitrix Framework kehittyy jatkuvasti. Uusia toimintoja ilmestyy, osa vanhentuu, funktioihin ilmestyy uusia parametreja. Melko suurta osaa hankkeista ei kuitenkaan päivitetä. Ohjelmoijan työn helpottamiseksi dokumentaatiosta käy ilmi, mistä ja mille tuotteen versiolle luokka, menetelmä, parametri, tapahtuma oli olemassa (olemassa).

Versiot on kiinnitetty kahteen paikkaan: otsikkoon ja taulukoihin. Jos menetelmä on kelvollinen, otsikko sisältää vain sen versionumeron, jolla se esiintyi tuotteessa. Jos menetelmä on vanhentunut, siellä ilmoitetaan versiot, joissa se oli voimassa.

Taulukot osoittavat version, jolla entiteetti esiintyi tuotteessa, vain jos sen ulkonäkö ei ole sama kuin itse luokan, menetelmän ja niin edelleen ilmestymishetki. Alla olevassa kuvassa: COURSE_ID-parametri ilmestyi menetelmän mukana (eli versiosta 5.1.0 alkaen) ja CHAPTER_ID-parametri vain versiosta 9.5.4.

Jos tuotteen kehityksen myötä jokin parametri (yleensä tämä viittaa parametreihin) on muuttunut, sen kuvauksessa on vastaava huomautus. (Esimerkiksi: ennen versiota x.x.x parametrin nimi oli *****).

Esimerkki

Huomautuksia:

  • merkki Käytöstä poistettu menetelmälle, parametrille, avain tarkoittaa, että sen käyttöä ei suositella, koska laajennuksia ja korjauksia ei tehdä.
  • Versioiden asennus ei ole täysin valmis, työ tähän suuntaan on parhaillaan käynnissä.

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

1C-Bitrixin verkkokaupan integrointi järjestelmään voidaan tehdä käyttämällä Bitrix.Marketplacen järjestelmämoduulia.

Kun moduuli on asennettu, se auttaa lataamaan olemassa olevat tilaukset järjestelmään.

Kun moduuli on asennettu, se on:

  • lataa uusia tilauksia 1C-Bitrixistä järjestelmään;
  • päivittää tiedot olemassa olevista tilauksista ottaen huomioon 1C-Bitrixiin tehdyt muutokset;
  • lataa uudet tilaukset ja asiakkaat järjestelmästä 1C-Bitrixiin;
  • päivitä tiedot olemassa olevista tilauksista ottaen huomioon järjestelmään tehdyt muutokset (esim. tilauksen tila, tilauksen tavaramäärä jne. on muutettu järjestelmässä, nämä muutokset näkyvät myös 1C-Bitrixissä );
  • lähettää järjestelmään tiedot käyttäjän tilauksen verkkomaksusta.

On myös mahdollista muokata laajennusluokkia menettämättä muokattua koodia päivityksen aikana. Muokatun koodin toteuttamiseksi sinun on asetettava vaaditun luokan kopio tiedostosta hakemistoon bitrix/php_interface/retailcrm.

Laajennuksella on mahdollisuus mukauttaa seuraavia tiedostoja:

RestNormalizer.php
logger.php
Asiakas.php
RCrmActions.php
RetailCrmUser.php
RetailCrmICML.php
RetailCrmInventorys.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

Jos haluat mukauttaa tiedostoja, joiden nimet sisältävät käytetyn API-version, tiedostot luodaan nimellä ilman versiota, esimerkiksi - RetailCrmHistory.php .

Kun olet luonut kopion tiedostosta, jonka luokka on bitrix/php_interface/retailcrm-hakemistossa, moduuli käyttää mukautettua luokkaa, voit tehdä muutoksia sen menetelmiin.

Verkkokaupan rekisteröinti järjestelmään

Ennen asennusta rekisteröi verkkokauppasi järjestelmäesiintymään (esimerkiksi esittelyversiossa osio Hallinta > Kaupat):

Ratkaisun asentaminen 1C-Bitrixiin

  • Napsauta Marketplacen ratkaisusivulla "Asenna" ja kirjoita verkkokauppasi osoite:

  • Lataa moduuli 1C-Bitrix Update Systemin kautta:

  • Aloita moduulin asennus:

Ohjattu asennustoiminto käynnistyy.

Ohjattu asennustoiminto. Vaihe 1

Vaiheessa 1.1 sinun on määritettävä järjestelmäsi osoite (esimerkiksi https://test.retailcrm.ru) ja API-avain, jonka loit aiemmin järjestelmässä:

Tärkeä! Jos Bitrixissä on vain yksi kauppa, vaihe 1. Sivustot ohitetaan.

Ohjattu asennustoiminto. Vaihe 1. Verkkosivustot

Vaiheessa 1. Sivustot, sinun on asetettava 1C-Bitrixin myymälöiden ja järjestelmän välinen vastaavuus.

Tärkeä! Kaikilla järjestelmän myymälöilläsi on oltava yhteinen API-avain.

Ohjattu asennustoiminto. Vaihe 2

Toisessa vaiheessa sinun on määritettävä verkkokaupan ja järjestelmähakemistojen arvojen välinen vastaavuus. Moduuli itse yrittää luoda vastaavuuden tyypillisille tiloille. Jos moduuli ei onnistunut, sinun on määritettävä vastaavuus itse:

Tarkista, onko järjestelmässä tarvittavat hakuarvot, jotka vastaavat verkkokaupan hakuja. Jos ne eivät riitä, lisää ne Hallinta-osioon sulkematta ohjatun asennustoiminnon sivua:

Päivitä sen jälkeen ohjatun toiminnon sivu: uudet viitearvot tulee ladata.

Ohjattu asennustoiminto. Vaihe 3

Kolmannessa vaiheessa moduuli antaa sinun asettaa vastaavuuden 1C-Bitrixin kenttien ja järjestelmän välillä.

Tärkeä! Jos on lomake palautetta” tai tilaukset ”yhdellä napsautuksella”, ja nämä tiedot eivät kuulu Bitrixin vakiotilauksiin, niin niitä ei vedä järjestelmään.

Myös, jos työskentelet oikeushenkilöitä, sinun on täytettävä kaikki kentät alla olevan kuvakaappauksen mukaisesti.

Ohjattu asennustoiminto. Vaihe 4

Neljännessä vaiheessa moduuli mahdollistaa aiemmin tehtyjen tilausten lataamisen järjestelmään. Purkaminen voi kestää jonkin aikaa (1000 tilausta puretaan noin 5 minuutissa). Purkamisprosessin edistyminen näyttää edistymispalkin.

Tarvittaessa voit keskeyttää latauksen ja jatkaa uudelleen hetken kuluttua.

Kun lataat aiemmin tehdyt tilaukset, voit nähdä analyyttisiä raportteja KPI-paneelissa. Suosittelemme tämän vaiheen suorittamista.

Ohjattu asennustoiminto. Vaihe 5

Viidennessä vaiheessa tuoteluettelon purku konfiguroidaan. Voit tehdä tämän noudattamalla alla olevia ohjeita.

1. Tietolohkojen ja ominaisuuksien valinta

Valitut tietolohkot ladataan järjestelmään. Sinulle tarjotaan valita vain ne tietolohkot, jotka sisältävät tavaroita tai joihin on linkitetty tietolohkoja kauppatarjouksiin. Tietolohkojen valinnan rinnalla voit valita seuraavat ominaisuudet: artikkeli, valmistaja, väri, paino, koko - tätä varten sinun on määritettävä tietolohko-ominaisuus, joka vastaa vastaavan ominaisuuden tallentamisesta. Kiinteistön valitseminen on valinnaista.

2. Tiedoston polku

Määritetylle polulle luodaan tiedosto muodossa, jossa hakemistorakenne sijaitsee. Oletuspolku on - "/bitrix/catalog_export/retailcrm.xml". Jos muutat polkua, sinun on suoritettava samanlainen konfigurointi järjestelmässä.

3. Tarjousten määrän asettaminen viennissä

Luettelon vientiasetuksissa on kenttä "Maksimimäärä kauppatarjouksia per tuote", johon tulee syöttää vaihtotarjousten enimmäismäärä, joka yhdellä tuotteella voi olla (jos niitä on enemmän kuin 50). Oletuksena moduuli laskee enintään 50 kauppatarjousta tuotteelle. Jos kaupassa on alle 50 tarjousta tuotteelle, tämä asetus voidaan jättää huomiotta. Jos kauppatarjouksia on enemmän ja asetus on määritetty, on suositeltavaa siirtää agentti kruunuihin, jos se toimii osumissa.

4. Purkamistiheyden valinta

Valittavana on kolme vaihtoehtoa:

1. Ei- kun tämä kohta valitaan, luettelon säännöllistä purkamista ei konfiguroida automaattisesti, ja sinun on purettava luettelo joka kerta itse.

Tämä vaihtoehto voi olla hyödyllinen, jos verkkokaupan tuoteluettelosi vaihtuu hyvin harvoin tai jos haluat muokata latausasetuksia myöhemmin.

2. Cron- Tämän kohteen valitseminen luo automaattisesti erityisen profiilin, joka linkitetään sen palvelimen Cron-palveluun, jolla verkkokauppasivusto toimii.

cron-apuohjelma käynnistyy tausta ja suorittaa määritetyt tehtävät määrättynä aikana.

Tämän kohteen valinta voi olla hyödyllistä, jos luettelo sisältää erittäin laajan nimikkeistön ( yli 10 000 tuotetta). Tälle kohteelle sinun on määritettävä mukautetun vientiprofiilin nimi.

3. Agentti. Tässä tapauksessa luodaan myös erityinen profiili, joka muodostaa yhteyden 1C-Bitrixin "Agents"-tekniikkaan, ja lataus tapahtuu automaattisesti kerran päivässä.

Agentti on php-funktio, joka toimii tietyllä taajuudella. Kunkin sivun latauksen alussa järjestelmä tarkistaa automaattisesti, onko käynnistettävä agentti, ja tarvittaessa suorittaa sen. Ei ole suositeltavaa luoda agentteja pitkiä latauksia varten - on parempi käyttää cron.

Tämä vaihtoehto on edullisin, jos hakemisto sisältää alle 10 000 kohdetta, lataus on melko nopeaa, eikä tämä vaikuta verkkokaupan verkkosivuston nopeuteen.

Jos nimikkeistö on suuri ( yli 10 000 tuotetta), Cron-agentin lisämääritykset vaaditaan. Tälle kohteelle sinun on myös määritettävä mukautetun vientiprofiilin nimi.

4. Ilmoitus välittömästä purkamisesta

"Poista nyt" -lipun asettamisen seurauksena hakemistorakenne puretaan yllä olevaan tiedostoon heti moduulin asennuksen jälkeen.

Kun olet ladannut luettelon järjestelmän tiedostoon, siirry kohtaan Hallinta -> Kauppa -> Kaupan nimi -> Katalogi-välilehti ja valitse "Lataa luettelo ICML:stä nyt" -ruutu. Tässä tapauksessa tiedoston lataus ja sen käsittely alkavat lähes välittömästi.

5. Profiilin nimen määrittäminen

Kun tuoteluettelon lataus on määritetty oikein, osiossa Kauppa > Asetukset > Tiedonvienti tulee näkyviin uudenlainen järjestelmävienti. Jos määrität asennuksen aikana säännöllisen latauksen, näkyviin tulee myös vientiprofiili.

Huomautus:
varten itseasetus Purkamisella on mahdollisuus luoda oma vientiprofiili.

Ohjatun asennustoiminnon viimeistely

Asennuksen lopussa luodaan 2 agenttia: yksi agentti lataa tilaushistorian Bitrixistä järjestelmään, toinen agentti luo luettelon. Jos tilausten lataaminen on määritetty agentille, tilaukset ladataan järjestelmään sillä hetkellä, kun historiaa kutsutaan. Muissa tapauksissa tilaukset puretaan tapahtumakohtaisesti.

Kuljetuspalvelun purku vaihdon aikana 1C-Bitrix - järjestelmä

Jos sinulla on 1C-Bitrixiin yhdistettyjä automatisoituja toimituspalveluita, kuten eDost, joilla on monia profiileja: Venäjän posti, EMS, DHL ja monet muut, niin järjestelmässä voit hyödyntää mahdollisuutta ladata tällainen toimituspalvelu.

Toimitustavat on määritettävä järjestelmäpuolella. Jos järjestelmämoduuli on asennettu ennen toimituspalvelun yhdistämistä Bitrixiin, puuttuvat toimitustavat on syötettävä järjestelmään manuaalisesti. Jos moduuli asennettiin toimituspalvelun liittämisen jälkeen, toimitustavat asennetaan automaattisesti, samoin kuin itse palvelun purku. Toisin sanoen jokaisen tilauksen toimituskulut puretaan.

1C-Bitrix-puolella on tehtävä seuraavat asetukset, jos järjestelmämoduuli on asennettu sen jälkeen, kun toimituspalvelu on liitetty 1C-Bitrix-järjestelmään:

Mene Hallinta > Asetukset, siirry "Hakuasetukset"-välilehteen.

Aseta toimitustapojen vastaavuus (määritetty aiemmin järjestelmän puolella). Napsauta seuraavaksi "Poista toimituspalvelut" -painiketta.

Lataustiheyden asettaminen 1C-Bitrix - järjestelmä

Tuoteluetteloa päivitettäessä voidaan erottaa kaksi seikkaa:

Hakemiston luominen (yml/icml-muodossa) asiakaspuolella ja

Järjestelmä lataa luettelon kolmen tunnin välein. Polku ladattavaan tiedostoon asetetaan myymälän asetuksissa - sinun on siirryttävä osioon Järjestelmänvalvoja > Kaupat > Valitse Kauppa > Luettelo-välilehti.

Kun järjestelmämoduuli on asennettu 1C-Bitrixiin, luodaan profiili lähetystä varten. Katsoaksesi sinun on mentävä osoitteeseen Työpöytä > Kauppa > Asetukset > Tietojen vienti. Kuvakaappaus näyttää kaksi vaihtoehtoa:

Oletus,

Ladataan järjestelmähakemistoa.

Jos valitset toisen vaihtoehdon, voit avata latausvaihtoehdot napsauttamalla sitä.

Jos agentti on valittu jaksollisuusvaihtoehdoksi, sinun on siirryttävä osoitteeseen nähdäksesi agenttien luettelon Työpöytä > Asetukset > Tuoteasetukset > Edustajat.

Jos napsautat "Muuta" tai "Lisää uusi", voit määrittää tai muuttaa tehtävän aloitustiheyttä luomista varten.

Tietojen synkronoinnin taajuus vaihdon aikana 1C-Bitrix - järjestelmä

Järjestelmämoduulin avulla voit ladata tavaraluettelon järjestelmääsi sekä tehdä säännöllistä kaksisuuntaista tilausten ja asiakkaiden vaihtoa.

Kun tiedot puretaan luettelosta ajoissa, järjestelmävastaajillasi on ajantasaiset tiedot tavaroiden saatavuudesta. Tilannetta, kun tavarat tilataan ja jonkin ajan kuluttua käy ilmi, että ne ovat loppuneet varastosta, ei synny.

Tilausten vaihto on tietojen synkronointiprosessi, kun tilauksia ladataan molempiin suuntiin:

1C-Bitrixistä järjestelmään:

  • Jos purkaminen tapahtumien mukaan on käytössä, tilausta luotaessa tai muuttaessa 1C-Bitrix-järjestelmässä se puretaan välittömästi järjestelmään. Jos purkausagentti valitaan, tilaus puretaan järjestelmään 15 minuutin kuluessa (tätä mekanismia ei suositella ilman perusteltua syytä, koska tällöin tilaukset saapuvat viiveellä eikä tilausten päivityksiä siirretä systeemi).
  • Käyttäjää vaihdettaessa myös päätiedot ladataan välittömästi järjestelmään.

Järjestelmästä 1C-Bitrixiin:

  • Jos luot tilauksen uudelle käyttäjälle järjestelmässä, tilaus ladataan 1C-Bitrixiin ja uusi käyttäjä luodaan 1-15 minuutin välein.
  • Jos muutat osoitetta, toimitushintaa tai tilaa järjestelmässä tilaussivulla, kaikki nämä muutokset ladataan 1C-Bitrixiin 15 minuutin sisällä.
  • Jos muutat järjestelmässä tavaroiden alennuksia ja muutat tavaroiden määrää, tämä muuttuu myös 1C-Bitrixissä välillä 1-15 minuuttia.

Muutoksia integrointimoduuliin

Versio 2.0

  • V2.0-integrointimoduuli on suunniteltu integroimaan 1C-Bitrix, johon on asennettu "Verkkokauppa (myynti)" -moduuliversio > 16.
  • Nyt moduulin työ suoritetaan API V4:n kautta.
  • Integrointimoduuli käyttää nyt uutta 1C-Bitrix D7 -ydintä.
  • Nyt järjestelmästä sivusto vastaanottaa myös asiakkaan muutokset (koko nimi, sähköpostiosoite, puhelin).
  • Integrointimoduulin asetuksissa "Muut asetukset" -osiossa tuli mahdolliseksi lähettää tilausnumerot järjestelmästä 1C-Bitrixiin. Eli jos järjestelmään luodaan manuaalisesti tilaus numerolla, esimerkiksi 12345R, 1C-Bitrixissä luodaan tilaus samalla numerolla.
  • Koska moduulin "Verkkokauppa (ale)" versiossa > 16, Bitrix-kehittäjät jättivät alennusten soveltamisen koko tilaukseen ja jättivät alennukset vain tavaroille, järjestelmä ei toistaiseksi myöskään pysty käyttämään alennuksia koko tilauksen. Voit asettaa alennuksia vain tietyille tilaustuotteille.

Versio 2.1

  • Mittayksiköt lisätty luettelon vientiin.

Versio 2.2

  • Moduuli tukee nyt useita valinnaisia ​​API-versioita.
  • API V5 tuki.
  • Lisätty mahdollisuus purkaa jäämiä varaston yhteydessä.
  • Lisätty mahdollisuus ladata hintatyyppejä.
  • Lisätty Daemon Collectorin perusintegraatio.
  • Lisätty integraatio Universal Analyticsin kanssa.
  • Sisäänrakennettujen toimintojen logiikkaa tietojen muokkausta varten on parannettu.
  • Lisätty sisäänrakennettu retailCrmApiResult-toiminto.
  • Lisätty laukaisuversio muutoshistoriasta.

Versio 2.4

  • Käsittelijään lisätty sekki uuden tilauksen maksun tallentamiseksi.
  • Lisätty asetus vientikaupan tarjousten lukumäärälle.
  • Ostohinnan muunnos lisätty.
  • Käännöstiedostojen muuttaminen.
  • Lisätty sisäänkirjautuminen ja purkamisen muutokset järjestelmästä tilausominaisuuksiin.
  • Lisätty ALV-lataus.
  • Korjattu hintatyyppiluettelon saaminen purkamista varten. Kaikki Bitrixissä saatavilla olevat tyypit ovat valittavissa.

Muut asetukset

Tilausasetukset

Lähetä CRM:ssä luotujen tilausten määrät kauppaan

Kun luot tilauksen järjestelmässä, sillä on oma yksilöllinen numeronsa määritettyjen sääntöjen mukaisesti. Kun tämä asetus on asetettu moduulissa, tällaisen tilauksen numero siirretään kauppaan käänteisen synkronoinnin aikana.

Tilausten purkaminen

  • Tapahtuman mukaan- tilausta tallennettaessa tiedot menevät järjestelmään;
  • agentti- uudet tilaukset lähetetään ennen muutoshistorian pyytämistä järjestelmästä.

Asiakassovellusliittymän versio

Nyt voit valita API-version, jonka kanssa moduuli toimii. Valinta riippuu järjestelmän versiosta. On suositeltavaa valita uusin versio.

Saldojen purkaminen varastojen yhteydessä (käytettävissä, jos varastoja on)

Nyt voit ajoittain purkaa jäännöksiä sivuston varastoista järjestelmävarastoihin. Tätä varten tarvitset:

  • verrata sivuston varastoja järjestelmän varastoihin;
  • määritä järjestelmän varastot, joihin saldot ladataan;
  • valitse tietolohkot, joissa on ylijäämien lataamiseen tarvittavia tavaroita (sinun on valittava ne, jotka on määritetty järjestelmän luetteloviennissä).

Agentti suorittaa purkamisen 1 tunnin välein (oletusarvoisesti).

Huomaa, että vaihtoehdot on otettava käyttöön, jotta ylijäämät voidaan ladata järjestelmään.

Salli tuotteiden hintatyyppien lataaminen (käytettävissä vain, jos hintatyyppejä on useita)

Nyt voit ajoittain ladata muita hintatyyppejä kaupasta järjestelmään. Tätä varten tarvitset:

  • vertaa sivuston hintatyyppejä järjestelmähintatyyppeihin;
  • määritä järjestelmän myymälät, joihin ladataan muita hintatyyppejä;
  • valitse tietolohkot tuotteista, jotka vaativat lisähintatyyppien lataamista (sinun on valittava ne, jotka on määritetty järjestelmän luetteloviennissä).

Agentti suorittaa purkamisen 24 tunnin välein (oletusarvoisesti).

Aktivoi Daemon Collector

Voit nyt lisätä sivustollesi Collector Daemonin asetusliittymästä. Tätä varten sinun on määritettävä haluamasi avain halutulle sivustolle. Avain löytyy järjestelmästä.

Ota UA-integrointi käyttöön

Nyt voit ottaa käyttöön integroinnin Universal Analyticsin kanssa asetusliittymästä (toimii oikein normaalin kassakomponentin kanssa). Jokaiselle sivustolle, johon haluat lisätä seurannan, sinun on täytettävä seurantatunnus ja mukautetun ulottuvuuden indeksi.

Missä $order on joukko tilaustietoja, jotka lähetetään järjestelmään, ja $arFields on joukko tilauskenttiä sivustolla. function retailCrmBeforeOrderSave($order) ( //Tekemäsi muutokset palauttavat $order; //tai palauttavat false; ja sitten tämän tilauksen järjestelmästä tehdyt muutokset ohitetaan )

Missä $order on taulukko, jossa on järjestelmästä peräisin olevia muokattuja tilaustietoja.

retailCrmAfterOrderSave-toiminto

retailCrmAfterOrderSave - toiminto, joka suoritetaan välittömästi sen jälkeen, kun sivustolle on tallennettu järjestelmän historiasta tulleet tilaustiedot.

function retailCrmAfterOrderSave($order) ( //Tekemäsi muutokset palaavat; )

Missä $order on taulukko, jossa on järjestelmästä peräisin olevia muokattuja tilaustietoja.

retailCrmApiResult-toiminto

retailCrmApiResult - toiminto, joka suoritetaan välittömästi saatuaan vastauksen järjestelmän API:lta.

function retailCrmApiResult($methodApi, $res, $code) ( //Tekemäsi muutokset palaavat; )

Kun $methodApi on API-menetelmän nimi, $res on tosi/epätosi-pyynnön tulos (onnistunut tai epäonnistunut pyyntö), $code on API-vastauksen tilakoodi.

Huomaa, että koodin virheet tätä toimintoa käytettäessä voivat häiritä sivuston ja järjestelmän synkronointia.

Jos yllä luetellut työkalut eivät jostain syystä riitä, voit tehdä tarvittavat muutokset suoraan moduulin koodiin ilman riskiä, ​​että muutokset katoavat moduulia päivitettäessä. Tätä varten sinun on kopioitava vaaditun luokan tiedosto hakemistoon /bitrix/php_interface/retailcrm/ ja muutettava sitä jo siinä. Tämä mekanismi tukee luokkien vaihtamista asiakkaiden, tilausten, tapahtumien, luettelon viennin ja muiden apumekanismien kanssa työskentelyyn.


Kirjanmerkki Mukautetut tehtävät on tarkoitettu niille, jotka työskentelevät suoraan tuotteen kanssa, eli ohjelmistotuotettamme käyttävien yritysten työntekijöille.

Järjestelmänvalvojan tehtävät -välilehti on tarkoitettu niille, jotka hallitsevat laatikkoversiota Bitrix24.

Kirjanmerkki Dokumentointi suunniteltu laatikkoversioon perustuvien projektien kehittäjille Bitrix24.

Mukautetut tehtävät

Ylläpitäjän tehtävät

Kehittäjät

Kehittäjädokumentaatio on kuvaus järjestelmän API:sta. Käyttäjädokumentaatio on kuvaus järjestelmän komponenteista ja asetuksista.

Dokumentaatio on saatavilla sekä verkossa että chm-tiedostona. On suositeltavaa käyttää online-versiota, koska se on ajan tasalla. chm-tiedostoja päivitetään säännöllisesti, eivätkä ne välttämättä sisällä tietoja uusimmista versioista.

Huomio! Jos et näe muototiedoston sisältöä .chm, syynä ovat suojausasetukset käyttöjärjestelmä. Tiedoston ominaisuuksista sinun on poistettava tiedoston katselun esto. Lue lisää kohdastaFAQ.

Dokumentaatio on viitetietoa. Ei riitä, että aloitteleva kehittäjä työskentelee järjestelmän kanssa. Ohjelmoinnin periaatteiden hallinnassa Bitrix Framework erikoiskurssi auttaa sinua:

Ei niin kauan sitten, yrityksemme sai melko suuren verkkokaupan 1C-Bitrixistä ylläpitoa ja tarkistusta varten. Projekti on otettu kaupalliseen käyttöön parin kuukauden ajan, mutta samaan aikaan siinä oli useita vakavia ongelmia. Lisäksi asiakas suunnitteli saavansa uuden toiminnallisuuden viimeistelytehtävät valmiiksi mahdollisimman pian. Sain järjestelytehtävän tehokasta työtä projekti mahdollisimman vähäisellä seisokkiajalla ja maksimaalisella asiakastyytyväisyydellä.

Alkutiedot:

  • 1C-Bitrixissä on verkkokauppa
  • Projekti on useita vuosia vanha, mutta vasta muutama kuukausi sitten paikka siirrettiin 1C-Bitrixille
  • Läsnäolo 10-15 tuhatta ihmistä päivässä
  • Kauppaluettelo sisältää noin 12 000 tuotetta
  • Sivuston seisokkeja ja katkoksia ei voida hyväksyä
  • Toinen yritys kehitti projektia kuuden kuukauden ajan:
    1. Siellä on TOR, noin 100 arkkia, mikä vastaa noin 40 %:n suorittamaa työtä
    2. Ei projektidokumentaatiota
    3. Ymmärryksen puute, miksi aiemmat kehittäjät käyttivät tällaisia ​​arkkitehtonisia ratkaisuja.

Kehitys ohjelmisto yleensä, ja erityisesti web-projekteja, olen tehnyt noin 8 vuotta. Tänä aikana kohtasin vaihtelevan monimutkaisia ​​projekteja, eikä tehtävä ensisilmäyksellä tuntunut liian vaikealta. Toteutettaessa projekteja yrityksessämme käytetään pääsääntöisesti SCRUM-metodologiaa. Aloin vetäytyä hänestä.

Ensinnäkin sain pääsyn lähdekoodi hanke. Pinnallisesti analysoitu. Sovi asiakkaan kanssa luettelo ensisijaisista tehtävistä. Tein kehityssuunnitelman kolmelle kehittäjälle ja kuten Gagarin sanoi, mennään!

Ongelma numero 1 - kehittäjät ovat syyllisiä

Kuten yleensä tapahtuu, kaikki ovat syyllisiä kaikkeen paitsi asiakas. Suunnittelija teki asettelun, joka painaa liikaa, isäntä tarjosi palvelimen, joka on hidas, kehittäjät tekivät sivuston, joka on buginen ja katkeaa koko ajan, johtajat suorittivat tehtäviä, joita emme pyytäneet suorittamaan vaihdon jälkeen vanha versio 1C-Bitrixin sivustolla, hakuliikenne väheni jyrkästi jne. Tilanne ei ole selvä. Toisaalta päävastuun pitäisi tietysti olla kehittäjäyrityksellä. Oli tarpeen välittää asiakkaalle kaikkien sivuston kanssa tehtyjen toimien seuraukset ja valmistautua tulokseen. Kun suoritat työtä, tarjoa kokonaisvaltaista arkkitehtuuria tuleva järjestelmä ja kehityssuunnitelma, jota noudatetaan, kunnes virstanpylväät on saatu päätökseen. Suorita perusteellinen toimivuuden testaus ja luovuta työ. Toisaalta törmään usein tilanteeseen, jossa asiakas tietää kaiken itse paremmin, koska hänen äitinsä joskus maalasi, ja siksi on paras suunnittelija, ja hänen 7-vuotias poikansa on hyvin perehtynyt hakukoneoptimointiin, koska hän viettää kaiken aikansa tietokoneen ääressä pelaamalla GTA:ta.

Kuka on syyllinen, kuka on oikeassa, emme voi tuomita. Tässä tapauksessa edellinen urakoitsija oli melko tunnettu luotettava yritys, enkä voi sanoa mitään pahaa heidän kehityksestään. Ja asiakas objektiivisesti katsottuna on huolissaan tuotteestaan ​​ja yrittää parantaa sitä. En tiedä miten se oli, itselleni löysin selityksen urakoitsijan asiakkaalle tarjoaman analytiikan riittämättömyydestä.

Tuloksena:

  • Hanketta ei ole saatu loogiseen päätökseensä. Monet tehtävät hylätään kesken matkan
  • Hanketta ei ole dokumentoitu. Toiminnan osan toiminta ei ole ilmeinen. Uutta toiminnallisuutta kehitettäessä käy ilmi, että aiemmin toiminut toiminto, jonka olemassaoloa uusi kehittäjä ei epäillyt, lakkasi toimimasta
  • Osa edellisen suorittajan kirjoittamasta koodista on kirjoitettava uudelleen tyhjästä
  • Projektin suunniteltu arkkitehtuuri ensimmäisten työviikkojen / -kuukausien aikana ei ole selvä uudelle urakoitsijalle. Yhden moduulin toiminnallisuuden tarkentaminen johtaa sellaisen moduulin toiminnallisuuden menettämiseen, joka ei liity siihen millään tavalla
  • Asiakas on hermostunut, esiintyjä hermostunut, vierailijat eivät ole tyytyväisiä, kävijämäärä vähenee, myynti laskee

Näen vain yhden ratkaisun ongelmaan: puhdista asteittain järjestelmällisesti kaikki sivuston moduulit vuorotellen, jotta tuote saadaan haluttuun tilaan. Osa virheistä siirrettiin erillisiin tehtäviin ja suoritettiin välittömästi, jotain korjattiin rinnakkain uuden toiminnallisuuden kehittämisen kanssa. Tulos - jokaisen päivityksen jälkeen, ulos tulleiden bugien operatiivisen puhdistuksen jälkeen, sivusto paranee ja vakaampi.

Ongelma #2 on rinnakkainen kehitys.

1C-Bitrixin lisenssipolitiikan mukaisesti jokainen sivustolisenssi antaa sinun käyttää 2 kopiota järjestelmästä. Toinen tuotantopaikkana, toinen kehittämistä varten. Ongelmana on, että kehitystä tekee useita, minun tapauksessani kolme, kehittäjää jatkuvasti. Klassisen kehityksen tapauksessa kaikki on yksinkertaista. Jokainen kehittäjä työskentelee oman moduulinsa parissa. Sitten suoritetaan kunkin moduulin toimintatestaus, kaikki parannukset yhdistetään jonkin versionhallintajärjestelmän arkistoon, sitten testataan kaikki yhdessä (integraatiotestaus). Jos tulos on normaali, testiversio esitetään asiakkaalle. Kun testiversio on hyväksytty, tuotantopalvelin päivitetään. SCRUM-metodologian mukaisesti olen päättänyt, että lataan uusia versioita tuotantopaikalle kerran viikossa. Näin ollen pääkehitykseen on 3-4 päivää. 1 päivä testaukseen ja virheiden korjaamiseen ja puoli päivää taistelupalvelimen päivittämiseen. Tietenkin määräajat vaihtelevat, mutta yritin noudattaa tiukasti "vapauta joka torstai" -sääntöä.

Ensimmäinen asia, johon törmäsin, oli se, että 1C-Bitrixissä on tilanteita, joissa sama tiedosto on samanaikaisesti mukana eri toiminnoissa sivuston eri päissä. Yksinkertaisin ja ilmeisin ratkaisu on käyttää versionhallintajärjestelmää, minun tapauksessani SVN:ää, jota käytän kaikissa muissa projekteissa. Mutta versionhallinnan käyttäminen edellyttää, että jokaisella kehittäjällä on oma koodiversionsa, jota hän muokkaa ja yhdistää sitten yhteisen arkiston.

Entä lisenssi? Otin yhteyttä 1C-Bitrixin tekniseen tukeen. Sain tarjouksen ostaa lisää. kehityslisenssit. Lievästi sanottuna en ollut tyytyväinen, mutta en saanut muita tarjouksia. Löysin ulospääsyn melko nopeasti. Päätin käyttää NFR-avaimia. Onneksi kumppanin asema sallii. Tämän seurauksena loin verkkokaupan 5 asennusta:

  • Tuotantopalvelin
  • Testipalvelin
  • 3 kehityspalvelinta (yksi per kehittäjä)

Ajan myötä hän meni vielä pidemmälle. Testerille oli myös erillinen asennus. Kävi ilmi, että omalla tuurillani asiakas tulee aina testipalvelimelle sillä hetkellä, kun siellä jotain päivitetään. Bugtrackissa on monia tarpeettomia tehtäviä, jotka on jo tehty, ja asiakkaalle jää sellainen käsitys, että emme tee työtämme hyvin.

Käytän tällä hetkellä seuraavaa kaavaa:

  • Jokainen kehittäjä käyttää vain paikallista kopiotaan työhönsä
  • Kaikki valmiit parannukset yhdistetään sovittuna aikana yhteiseksi haaraksi arkiston
  • QA poimii "tahraan" version testausta varten
  • Testauksen ja vikojen korjaamisen jälkeen demopalvelin päivitetään asiakkaalle
  • Asiakkaan vahvistuksen ja hyväksynnän jälkeen parannukset siirretään taistelupalvelimelle.

Tämän lähestymistavan ilmeisistä haitoista haluan korostaa asiakkaiden vähäistä osallistumista kehitykseen. Lopputulos näkyy asiakkaalle vasta loppuvaiheessa. Tätä lähestymistapaa voidaan soveltaa, jos sinulla on hyvä analyytikko, joka tekee harvoin virheitä ja on jatkuvassa yhteydessä asiakkaaseen. Muuten monet tehtävät on tehtävä uudelleen alusta.

Piiriä rakentaessani törmäsin toiseen ongelmaan. Projekti vie levyltä noin 80 Gt. Ilman välimuistia ja väliaikaisia ​​tiedostoja - noin 60. Aluksi yritin poistaa kuvia ja videoita versionhallinnasta - se ei toiminut. Sivuston tiedot muuttuvat jatkuvasti. Sinun on testattava nykyisten tietojen perusteella. Sivuston ensimmäinen sitoutuminen arkistoon meni minulle palasina yli kahdeksi päiväksi. Ensimmäinen kirjautuminen kehityskansioon kestää useita tunteja (SVN-palvelin sisään paikallinen verkko kehitys). Jos, Jumala varjelkoon, teet vahingossa täydellisen päivityksen projektikansioon, voit mennä tupakoimaan, syömään, pelaamaan pingistä tai curlingia. Vain valittujen tiedostojen tai kansioiden sitominen on riittävän nopeaa. Ratkaisu: suoritettu tehtävän - sitoa kymmenkunta muutettua tiedostoa kerralla.

Ongelma #3 – Tuotantopalvelimen päivitys ja yhteistyö asiakkaan kanssa

Ongelma on tärkein, monimutkaisin ja loppujen lopuksi ratkaisematon. Loppujen lopuksi, jos loput ongelmat liittyvät projektin sisäiseen keittiöön, asiakkaan maine ja tulot ja siten myös tuloni riippuvat sivuston työstä.

Tässä Murphyn lait tulevat voimaan:

  • Jos jokin ei toimi hyvin testipalvelimella, se menee varmasti rikki tuotantopalvelimella.
  • Jos jokin toimii hyvin testipalvelimella, se menee varmasti rikki tuotantopalvelimella joka tapauksessa.
  • Jos sivustolla on vain 5 sekuntia bugi, joku vierailijoista löytää sen varmasti ja kirjoittaa siitä arvosteluihin tai palautelomakkeeseen.
  • Jos sivusto ei toimi minuuttiin päivityksen aikana, yrityksen omistaja näyttää sen tällä minuutilla ystävälleen tai kilpailijalleen (ja tämä tapahtuu päivitysajan ja -menettelyn koordinoinnista huolimatta).
Tietysti liioittelen, mutta jokaisessa vitsissä on osa vitsiä. Vähimmäiskuormitus työmaalla on 4-6 aamulla. Tietysti olisi parempi päivittää tällä hetkellä, mutta en todellakaan halua.

Useimmissa verkkosovelluksissa on selkeä rakenne sovelluksen jakamiseksi kerroksiin ja sivuston päivittäminen voidaan jakaa kahteen osaan:

  • Koodin päivitys
  • Tietokannan päivittäminen SQL-skripteillä

1C-Bitrixin tapauksessa kaikki on hieman monimutkaisempaa. Ensinnäkin tiedostoja on paljon. Niitä on projektissani yli miljoona. Tavallinen päivitys arkistosta kestää vähintään 20-30 minuuttia. Tietysti voit päivittää vain muuttuneet tiedostot, mutta silloin koko arkiston ydin menetetään. Toiseksi, ja tämä on paljon surullisempaa, sinun on usein päivitettäessä tehtävä manuaaliset muutokset ja asetukset hallintapaneelin kautta. Ja tämä on aina hidasta, sinun on muistettava kaikki muutokset, jotka on tehtävä, on suuri todennäköisyys tehdä vahingossa virhe. Voit tietysti kirjoittaa SQL-skriptin, joka tekee kaikki tarvittavat muutokset tietokantaan. Yksinkertaisimmissa tapauksissa teemme tietysti juuri niin. Mutta useimmissa tapauksissa tällaisen skriptin kirjoittaminen ja virheenkorjaus vie enemmän aikaa kuin itse kehitys ja paljon enemmän aikaa kuin kaikkien toimien tekeminen manuaalisesti myöhemmän vahvistuksen kanssa.

En ole vielä löytänyt hyvää ratkaisua. Nyt päivitämme tietokannan asetukset manuaalisesti. Virheiden minimoimiseksi laaditaan tarkistuslista, joka sisältää luettelon siitä, mitä päivityksen aikana on tehtävä. Pyrimme päivittämään mahdollisimman huolellisesti ja tarkasti. Päivityksen jälkeen koko tiimi tarkistaa tuotantopalvelimen päätoiminnallisuuden ja suorittaa lisätestauksia. Virheiden määrä on minimoitu, mutta päivitysten aiheuttamia bugeja ja seisokkeja ei ole vielä täysin eliminoitu.

Toinen asia jonka kohtasin on ryhmätyö asiakkaan kanssa. Koska projekti on suuri, sen parissa työskentelee jatkuvasti noin 30 henkilöä. Sisältöpäälliköt, myyntipäälliköt, SEO-optimoijat, markkinoijat ja paljon muuta. Luonnollisesti jokainen tekee joitain muutoksia sivuston sivuille ja moduulien asetuksiin. Ensimmäinen päätös oli viedä asiakkaalta oikeus tehdä muutoksia sivuston ohjelmakoodiin. Päätös on täysin oikea, mutta se vain paheni. Jos aiemmin asiakas arveli, että hän voisi myös mennä paikalle ja vahingossa rikkoa jotain, niin nyt kaikki kolhut alkoivat pudota vain meille. missä. Vaikka sisällönjohtaja muokkasi sivun tekstiä vinosti eikä sulkenut jotain tunnistetta, kehittäjä on silti syyllinen. Ratkaisu osoittautui varsin yksinkertaiseksi. Marketplacessa on ilmainen sivuversion hallintamoduuli. Tämä ei poistanut ongelmaa, kuitenkin, joku tekee silloin tällöin jotain, mutta nyt on mahdollista nähdä milloin tahansa kuka muuttui, mikä muuttui ja miksi kaikki meni rikki. Tulos ei tietenkään ole jäätä, mutta se säästää minua paljon hermoja.

Lisäksi teimme päätöksen ennen jokaista testipalvelimen päivitystä, otamme kopion tuotantopalvelimelta siihen. Tämä vie myös paljon aikaa. Arkistoi projekti, siirrä se toiselle palvelimelle, pura se. Kaikki tämä kestää useita tunteja. Mutta uusia parannuksia testataan melkein taisteluolosuhteissa. Jos testi- ja tuotantopalvelinten asetukset ovat identtiset, ero toiminnassa on minimaalinen ja virheiden määrä vähenee merkittävästi. Kuten kokemus on osoittanut, tuotantopalvelin voi muuttua viikossa niin paljon, että osa uusista toiminnoista, jotka toimivat ongelmitta viikon takaisessa kopiossa, eivät välttämättä toimi ollenkaan uudessa kopiossa.

Ongelma numero 4 - "Tee minusta kiireellinen, tämä on 5 minuutin tehtävä"

Ongelma ei liity niinkään 1C-Bitrixiin, vaan olemassa olevien projektien jalostukseen ja tukemiseen. Usein asiakkaalla on halu tehdä jotain pientä, mutta kiireellisesti ja välittömästi taistelupaikalla. Tulos on aina sama - siitä ei seuraa mitään hyvää. Parhaassa tapauksessa tämä parannus yksinkertaisesti unohtuu seuraavan julkaisun aikana, pahimmassa tapauksessa palvelin yksinkertaisesti kaatuu ja sen palauttaminen varmuuskopiosta kestää useita tunteja.

Löysin vain yhden ratkaisun - älä koskaan seuraa asiakkaan esimerkkiä luotettavuuden ja turvallisuuden kustannuksella. Riippumatta siitä, kuinka asiakas pyytää, kehittäjä on aina syyllinen. Kuten entinen pomoni sanoi minulle: "En pyytänyt sinua tekemään pahoja asioita."

Ja koska kosketimme varmuuskopioiden aihetta, haluan huomauttaa. Varmuuskopiointi 1C-Bitrikillä on varmasti hyvä ja kätevä, mutta erittäin hidas. Jos sinun on kiireellisesti palautettava 1-2 tiedostoa tai useita arvoja tietokannassa, sinun on odotettava, kunnes kaikki 60 Gt on purettu. Tässä seuraava kaava näyttää minusta tehokkaimmalta:

  • Tiedostoista ja tietokannoista tulee tehdä päivittäinen varmuuskopio arkiston muodossa ulkoinen lähde tiedot.
  • Teemme aina varmuuskopion välittömästi ennen päivittämistä jollakin kahdesta vaihtoehdosta:
    1. Asetusvalo – Kopioi koko projektikansio viereiseen kansioon palvelimella. Tietokanta vedosmuodossa tallennetaan erilliseen tiedostoon. Emme arkistoi mitään. Jos joudut palauttamaan jonkin arvon tietokannasta tai jostakin tiedostoista, kaikki on käsillä ja helposti saatavilla
    2. Vahva vaihtoehto on samanlainen kuin edellinen, vain kopioimme pohjan toiseen kantaan MySQL-tiedot. Tämä mahdollistaa täydellisen kaatumisen sattuessa 1-2 minuutissa sivuston juurikansion korjaamisen hosts-tiedostossa ja projekti alkaa toimia viereisestä kansiosta tietokannan kopiolla.

Johtopäätös

Kiitos kaikille loppuun asti lukeneille. Toivon, että kokemukseni on hyödyllinen sinulle. Otan mielelläni vastaan ​​ehdotuksia onnistuneemmista tavoista ratkaista kommenteissa tai henkilökohtaisesti ilmaistuja ongelmia. Nyt olen yrittänyt tuoda esiin tärkeimmät ongelmat jo käynnistettyjen ja korkeat luotettavuusvaatimusten omaavien projektien jalostuksessa ja tukemisessa. Jos materiaali osoittautuu mielenkiintoiseksi, aion kirjoittaa jatko-osan 1C-Bitrix-arkkitehtuurin ominaisuuksista, jotka erottavat Bitrixin sivuston kehittämisen muiden verkkoprojektien kehittämisestä.

Tietoja työskentelystä löytyy opetusohjelmista ja dokumentaatiosta. Koulutuskurssit on suunniteltu hallitsemaan työskentelytavat ohjelmistotuote, ja dokumentaatio - CMS-räätälöinnin periaatteiden hallintaan.

Kun työskentelet "1C-Bitrix: Sivustonhallinta" ongelmat ilmenevät erityisten käytännön ongelmien muodossa. Olemme koonneet eri kurssisivuille profiilin aiheisiin, jotta sinun olisi helpompi löytää vastauksia kysymyksiisi.
Koulutuskeskukset Kysy kysymys Foorumi



Kirjanmerkki Sisällön ylläpitäjät on tarkoitettu niille, jotka työskentelevät suoraan tuotteen kanssa, eli sisällönhaltijoille, jotka johtavat ohjelmistotuotteellamme luotuja projekteja.

Kirjanmerkki Järjestelmänvalvojat tarkoitettu niille, jotka hallitsevat "1C-Bitrix: Sivustonhallinta".

Kirjanmerkki Kehittäjät suunniteltu hankkeiden kehittäjille "1C-Bitrix: Sivustonhallinta".

Sisällön ylläpitäjät

Voit tuoda kurssin sivustollesi Sisältöpäällikkö tästä arkistosta. Kurssi ilman kysymyksiä kokeisiin.
Kurssin versio päivätty 5.6.2015.

Järjestelmänvalvojat

Kehittäjät

Kehittäjädokumentaatio on kuvaus järjestelmän API:sta. Käyttäjädokumentaatio on kuvaus järjestelmän komponenteista ja asetuksista.

Dokumentaatio on saatavilla sekä verkossa että chm-tiedostona. On suositeltavaa käyttää online-versiota, koska se on ajan tasalla. chm-tiedostoja päivitetään säännöllisesti, ja niistä saattaa puuttua tietoja viimeisimmät muutokset apujärjestelmässä.

Huomio! Jos et näe muototiedoston sisältöä .chm, syynä ovat käyttöjärjestelmän suojausasetukset. Tiedoston ominaisuuksista sinun on poistettava tiedoston katselun esto. Lue lisää kohdastaFAQ.

Dokumentaatio on viitetietoa. Ei riitä, että aloitteleva kehittäjä työskentelee järjestelmän kanssa. Ohjelmoinnin periaatteiden hallinnassa Bitrix Framework erikoiskurssi auttaa sinua:

Suosittu luokassa:
Kuinka asentaa CryptoPro - kuinka asentaa henkilökohtainen varmenne CryptoProon muistitikulta?
Kuinka asentaa CryptoPro - kuinka asentaa henkilökohtainen varmenne ...
lukea
Laiteohjelmisto Alcatel van touch pixielle
Laiteohjelmisto Alcatel van touch pixielle
lukea
Animoidut työpöydän taustat
Animoidut työpöydän taustat
lukea
SIRI: mikä se on ja miten sitä käytetään
SIRI: mikä se on ja miten sitä käytetään
lukea

Viimeisimmät artikkelit
Äänikortti generaattorina
lukea
Mitä tehdä, jos "objektikenttää ei löydy"
lukea
Windows 7 Ultimate -järjestelmävaatimukset
lukea
Samsung Galaxy Grand Prime: arvostelu, tekninen...
lukea
Huawei HiSuite on ohjelma synkronointiin...
lukea
Kuinka käynnistää sovellus automaattisesti, kun...
lukea
Kuinka puhdistaa levy roskista
lukea
Asenna/päivitä AMD Radeon -ajurit -...
lukea
Yläosa