› › Bitrix24 kastes versijas dokumentācija. Instalēšanas vedņa pabeigšana

Bitrix24 kastes versijas dokumentācija. Instalēšanas vedņa pabeigšana

Bitrix Framework - tehnoloģiskais kodols (platforma) projektu veidošanai un vadīšanai (tīmekļa vietnes un korporatīvie portāli). Platforma ļauj izveidot neierobežotu skaitu projektu, izmantojot vienu produkta eksemplāru (licenci), izvietojot sistēmas kodolu un datu bāzi vienā kopijā serverī.

Ieslēgts Šis brīdis ne visas vecā kodola iespējas tiek dublētas D7. Bet jaunais D7 kodols Bitrix Framework pakāpeniski nomainot veco. Ja, izmantojot vecu kodolu, tika parādīts brīdinājums no IDE: Metode/klase ir novecojusi , tad jums ir jāizmanto metodes.

Vairāku iemeslu dēļ API dokumentācija var neaptvert visas metodes. Lai saprastu, kā tas darbojas, dažreiz labāk ir apskatīt faktisko programmas kodu. Šim nolūkam jūs varat izmantot bezmaksas modulis no Marketplace: .

Piezīme: pievienojot jebkuras lapas adresei #examples, varat ātri pāriet uz piemēru, ja tāds ir. (Tas nedarbojas CHM formāta dokumentācijas failos.)


Entītiju versijas

Bitrix Framework nepārtraukti attīstās. Parādās jaunas funkcijas, dažas kļūst novecojušas, un funkcijās parādās jauni parametri. Tomēr diezgan liels skaits projektu netiek atjaunināti. Lai atvieglotu programmēšanas darbu, dokumentācijā ir norādīts, ar kuru produkta versiju pastāvēja (pastāv) klase, metode, parametrs, notikums.

Versijas ir norādītas divās vietās: nosaukumā un tabulās. Ja metode ir derīga, tad nosaukumā būs tikai versijas numurs, ar kuru tā parādījās produktā. Ja metode ir novecojusi, tiks norādīts arī versiju diapazons, kurā tā bija derīga.

Tabulās ir norādīta versija, ar kādu entītija parādījās produktā tikai tad, ja tās izskats nesakrīt ar klases, metodes un tā tālāk parādīšanās brīdi. Tālāk esošajā ilustrācijā: parametrs COURSE_ID parādījās kopā ar metodi (tas ir, no 5.1.0), bet parametrs CHAPTER_ID tikai no versijas 9.5.4.

Ja kāds parametrs (parasti tas attiecas uz parametriem) ir mainījies līdz ar produkta attīstību, tā aprakstā būs attiecīga piezīme. (Piemēram: pirms versijas x.x.x parametrs saucās *****).

Piemērs

Piezīmes:

  • Atzīmēt Novecojis metode, parametrs vai atslēga nozīmē, ka nav ieteicams to izmantot, jo nebūs paplašinājumu vai labojumu.
  • Versiju instalēšana nav pilnībā pabeigta, pašlaik notiek darbs šajā virzienā.

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

Interneta veikala integrāciju uz 1C-Bitrix ar sistēmu var veikt, izmantojot Bitrix.Marketplace sistēmas moduli.

Instalēšanas laikā modulis palīdzēs augšupielādēt sistēmā esošos pasūtījumus.

Pēc instalēšanas modulis:

  • augšupielādēt sistēmā jaunus pasūtījumus no 1C-Bitrix;
  • atjaunināt datus par esošajiem pasūtījumiem, ņemot vērā 1C-Bitrix veiktās izmaiņas;
  • augšupielādēt jaunus pasūtījumus un klientus no sistēmas uz 1C-Bitrix;
  • atjaunināt datus par esošajiem pasūtījumiem, ņemot vērā sistēmā veiktās izmaiņas (piemēram, sistēmā mainīts pasūtījuma statuss, preču skaits pasūtījumā utt., šīs izmaiņas tiks atspoguļotas arī 1C-Bitrix) ;
  • nosūtīt sistēmai informāciju par lietotāja pasūtījuma tiešsaistes apmaksu.

Ir iespējams arī pielāgot spraudņu klases, nezaudējot modificēto kodu atjaunināšanas laikā. Lai ieviestu modificēto kodu, ir jāievieto faila kopija ar nepieciešamo klasi mapē bitrix/php_interface/retailcrm.

Spraudnis var pielāgot šādus failus:

RestNormalizer.php
Logger.php
Klients.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

Lai pielāgotu failus, kuru nosaukumos ir ietverta izmantotā API versija, faili tiek izveidoti ar nosaukumu, nenorādot versiju, piemēram, - RetailCrmHistory.php.

Pēc faila kopijas izveides ar klasi direktorijā bitrix/php_interface/retailcrm modulis izmantos pielāgotu klasi; varat veikt izmaiņas tās metodēs.

Interneta veikala reģistrācija sistēmā

Pirms instalēšanas reģistrējiet savu tiešsaistes veikalu savā sistēmas eksemplārā (sadaļā Administrēšana > Veikali, piemēram, demonstrācijas versijā):

Risinājuma instalēšana 1C-Bitrix

  • Tirgus risinājuma lapā noklikšķiniet uz “Instalēt” un ievadiet sava tiešsaistes veikala adresi:

  • Lejupielādējiet moduli, izmantojot 1C-Bitrix atjaunināšanas sistēmu:

  • Sāciet moduļa instalēšanu:

Tiks palaists instalēšanas vednis.

Instalācijas vednis. 1. darbība

1.1. darbībā jums jānorāda sistēmas adrese (piemēram, https://test.retailcrm.ru) un API atslēga, ko sistēmā ģenerējāt iepriekš:

Svarīgs! Ja Bitrix ir tikai viens veikals, 1. darbība. Vietnes tiek izlaistas.

Instalācijas vednis. 1. darbība. Vietnes

Veicot 1. darbību.Vietnes, jums ir jāiestata atbilstība starp jūsu 1C-Bitrix veikaliem un sistēmu.

Svarīgs! Visiem jūsu sistēmas veikaliem ir jābūt kopējai API atslēgai.

Instalācijas vednis. 2. darbība

Otrajā darbībā jānorāda atbilstība starp tiešsaistes veikala un sistēmas direktoriju vērtībām. Pats modulis mēģina izveidot atbilstību tipiskajiem statusiem. Ja modulim to neizdevās izdarīt, jums pašam jānorāda atbilstība:

Pārbaudiet, vai sistēmai ir nepieciešamās direktoriju vērtības, kas atbilst tiešsaistes veikala katalogiem. Ja to nav pietiekami daudz, pievienojiet tos sadaļā Administrēšana, neaizverot instalēšanas vedņa lapu:

Pēc tam atsvaidziniet vedņa lapu: ir jāielādē jaunās direktoriju vērtības.

Instalācijas vednis. 3. darbība

Trešajā darbībā modulis ļauj iestatīt atbilstību starp 1C-Bitrix laukiem un sistēmu.

Svarīgs! Ja ir veidlapa " atsauksmes"vai pasūtījumi "ar 1 klikšķi", un šie dati neietilpst standarta Bitrix pasūtījumos, tad tie netiek ievilkti sistēmā.

Tāpat, ja strādājat ar juridiskām personām, jums ir jāaizpilda visi lauki, kā norādīts tālāk esošajā ekrānuzņēmumā.

Instalācijas vednis. 4. darbība

Ceturtajā solī modulis ļauj augšupielādēt sistēmā iepriekš veiktos pasūtījumus. Izkraušana var aizņemt kādu laiku (1000 pasūtījumi tiek izkrauti apmēram 5 minūtēs). Augšupielādes procesa norise tiks parādīta progresa joslā.

Ja nepieciešams, varat apturēt lejupielādi un pēc kāda laika atsākt to vēlreiz.

Pēc iepriekš veikto pasūtījumu augšupielādes KPI panelī varēsit skatīt analītiskos pārskatus. Mēs iesakām veikt šo darbību.

Instalācijas vednis. 5. darbība

Piektajā darbībā tiek konfigurēta preču kataloga augšupielāde. Lai to izdarītu, jums ir jāaizpilda šādi punkti.

1. Informācijas bloku un rekvizītu atlase

Atlasītie informācijas bloki tiks augšupielādēti sistēmā. Jums tiks piedāvāts izvēlēties tikai tos informācijas blokus, kas satur preces vai kuriem informācijas bloki ir saistīti ar tirdzniecības piedāvājumiem. Paralēli informācijas bloku atlasei var izvēlēties šādus rekvizītus: izstrādājums, ražotājs, krāsa, svars, izmērs - šim nolūkam jānorāda informācijas bloka rekvizīts, kas atbild par atbilstošā īpašuma glabāšanu. Īpašuma izvēle nav obligāta.

2. Faila ceļš

Norādītajā ceļā tiks ģenerēts fails šādā formātā, kurā būs direktorija struktūra. Noklusējuma ceļš ir - "/bitrix/catalog_export/retailcrm.xml". Ja maināt ceļu, jums būs jāveic līdzīga iestatīšana sistēmā.

3. Piedāvājumu skaita iestatīšana eksportā

Kataloga eksporta iestatījumos ir lauks “Maksimālais tirdzniecības piedāvājumu skaits precei”, kurā jāievada maksimālais tirdzniecības piedāvājumu skaits, kāds var būt vienai precei (ja ir vairāk par 50). Pēc noklusējuma modulis aprēķina ne vairāk kā 50 tirdzniecības piedāvājumus precei. Ja veikalā vienai precei ir mazāk par 50 tirdzniecības piedāvājumiem, šo iestatījumu var ignorēt. Ja ir vairāk tirdzniecības piedāvājumu un ir norādīts iestatījums, ieteicams aģentu pārcelt uz kronām, ja tas darbojas uz trāpījumiem.

4. Izkraušanas biežuma izvēle

Būs trīs iespējas, no kurām izvēlēties:

1. Nē- atlasot šo vienumu, periodiskā kataloga augšupielāde netiks automātiski konfigurēta, un katru reizi katalogs būs jāaugšupielādē pašam.

Šī opcija var būt noderīga, ja jūsu interneta veikala preču katalogs mainās ļoti reti, vai arī vēlaties vēlāk konfigurēt augšupielādes parametrus.

2. Cron- izvēloties šo vienumu, tiks automātiski izveidots īpašs profils, kas tiks saistīts ar tā servera Cron pakalpojumu, kurā darbojas tiešsaistes veikala vietne.

Tiek palaists cron utilīta fons un veic noteiktus uzdevumus noteiktos laikos.

Šī vienuma izvēle var būt noderīga, ja katalogā ir ļoti liela prece ( vairāk nekā 10 000 produktu). Šim vienumam jānorāda īpašā eksporta profila nosaukums.

3. Aģents. Šajā gadījumā tiks izveidots arī īpašs profils, kas savienosies ar 1C-Bitrix tehnoloģiju “Agents”, un augšupielāde notiks automātiski vienu reizi dienā.

Aģents ir PHP funkcija, kas darbojas noteiktā frekvencē. Katras lapas ielādes sākumā sistēma automātiski pārbauda, ​​vai ir kāds aģents, kas ir jāpalaiž, un vajadzības gadījumā to izpilda. Nav ieteicams veidot aģentus laikietilpīgām augšupielādēm - labāk izmantot cron.

Šī opcija ir vispiemērotākā, ja direktorijā ir mazāk nekā 10 000 produktu, tad augšupielāde notiek diezgan ātri, un tas nekādā veidā neietekmēs interneta veikala vietnes ātrumu.

Liela diapazona gadījumā ( vairāk nekā 10 000 produktu), ir nepieciešams papildu pielāgošana Krona aģents. Šim vienumam jānorāda arī īpašā eksporta profila nosaukums.

4. Norādījums par tūlītēju izkraušanu

Karoga “Izlādēt tūlīt” iestatīšanas rezultātā direktoriju struktūra tiks izlādēta iepriekš minētajā failā uzreiz pēc moduļa instalēšanas.

Pēc kataloga augšupielādes failā sistēmā, jums jāiet uz Administrēšana -> Veikals -> Veikala nosaukums -> cilne "Katalogs" un jāatzīmē izvēles rūtiņa "Lejupielādēt katalogu no ICML tūlīt". Šajā gadījumā faila lejupielāde un apstrāde sākas gandrīz uzreiz.

5. Profila nosaukuma norādīšana

Pēc pareizas preču kataloga augšupielādes iestatīšanas sadaļā Veikals > Iestatījumi > Datu eksportēšana parādīsies jauns sistēmas eksportēšanas veids, ja instalēšanas laikā tiks norādīta periodiskā augšupielāde, parādīsies arī eksporta profils.

Piezīme:
Priekš paškonfigurācija augšupielādējot, ir iespējams izveidot savu eksporta profilu.

Instalēšanas vedņa pabeigšana

Instalēšanas beigās tiks izveidoti 2 aģenti: viens aģents augšupielādē pasūtījumu vēsturi no Bitrix uz sistēmu, otrs aģents ģenerē katalogu. Ja pasūtījuma augšupielāde ir konfigurēta aģentam, tad pasūtījumi tiek augšupielādēti sistēmā vēstures izsaukšanas laikā. Citos gadījumos pasūtījumi tiek izkrauti, pamatojoties uz notikumu.

Piegādes pakalpojuma izkraušana maiņas laikā 1C-Bitrix - sistēma

Ja jums ir automatizēti piegādes pakalpojumi, kas savienoti ar 1C-Bitrix, piemēram, eDost, kuriem ir daudz profilu: Krievijas pasts, EMS, DHL un daudzi citi, tad sistēmā varat izmantot iespēju augšupielādēt šāda veida piegādes pakalpojumu.

Sistēmas pusē ir jākonfigurē piegādes metodes. Ja sistēmas modulis tika instalēts pirms piegādes pakalpojuma pievienošanas Bitrix, tad trūkstošās piegādes metodes būs jāievada sistēmā manuāli. Ja modulis tika uzstādīts pēc piegādes pakalpojuma pieslēgšanas, tad piegādes metodes tiks uzstādītas automātiski, kā arī pati pakalpojuma izkraušana. Tas nozīmē, ka katram pasūtījumam tiks lejupielādēta piegādes maksa.

Ja sistēmas modulis tika instalēts pēc piegādes pakalpojuma pievienošanas sistēmai 1C-Bitrix, 1C-Bitrix pusē ir jāveic šādi iestatījumi:

Iet uz Administrēšana > Iestatījumi, dodieties uz cilni "Kataloga iestatījumi".

Konfigurējiet piegādes metožu atbilstību (sākotnēji konfigurēta sistēmas pusē). Pēc tam noklikšķiniet uz pogas Augšupielādēt piegādes pakalpojumus.

1C-Bitrix - sistēmas augšupielādes biežuma iestatīšana

Atjauninot preču katalogu, var izcelt divus punktus:

Kataloga ģenerēšana (yml/icml formātā) klienta pusē un

Sistēma lejupielādē katalogu reizi trīs stundās. Ceļš uz augšupielādējamo failu ir iestatīts veikala iestatījumos - jums jāiet uz sadaļu Administrēšana > Veikali > Atlasīt veikalu > cilne Katalogs.

Pēc sistēmas moduļa instalēšanas 1C-Bitrix tiek izveidots profils augšupielādei. Lai redzētu, jums jāiet uz Darbvirsma > Veikals > Iestatījumi > Datu eksportēšana. Ekrānuzņēmumā ir redzamas divas iespējas:

Noklusējums,

Sistēmas direktorija augšupielāde.

Ja atlasāt otro opciju, noklikšķinot uz tās, tiks atvērtas augšupielādes opcijas.

Ja aģents ir atlasīts kā biežuma opcija, lai skatītu aģentu sarakstu, jums jāiet uz Darbvirsma > Iestatījumi > Produkta iestatījumi > Aģenti.

Noklikšķinot uz Mainīt vai Pievienot jaunu, varat piešķirt vai mainīt ģenerēšanas uzdevuma izpildes biežumu.

Datu sinhronizācijas biežums apmaiņas laikā 1C-Bitrix - sistēma

Sistēmas modulis ļauj augšupielādēt jūsu sistēmā preču katalogu, kā arī veikt regulāru abpusēju pasūtījumu un klientu apmaiņu.

Savlaicīgi augšupielādējot datus no kataloga, jūsu sistēmu vadītājiem būs aktuāla informācija par produktu pieejamību. Situācija, kad tiek pasūtīta prece, un pēc kāda laika izrādīsies, ka tā ir beigusies, neradīsies.

Pasūtījumu apmaiņa ir datu sinhronizācijas process, kad pasūtījumi tiek augšupielādēti abos virzienos:

No 1C-Bitrix uz sistēmu:

  • Ja ir iespējota uz notikumiem balstīta augšupielāde, kad pasūtījums tiek izveidots vai mainīts sistēmā 1C-Bitrix, tas nekavējoties tiks augšupielādēts sistēmā. Ja tiek izvēlēts izkraušanas aģents, pasūtījums tiks augšupielādēts sistēmā 15 minūšu laikā (nav ieteicams izmantot šo mehānismu bez nepārvarama iemesla, jo tādā gadījumā pasūtījumi pienāk ar kavēšanos un šo pasūtījumu atjauninājumi netiks pārsūtīti sistēmai).
  • Mainoties lietotājam, sistēmā nekavējoties tiks augšupielādēti arī pamatdati.

No sistēmas uz 1C-Bitrix:

  • Ja sistēmā izveidojat pasūtījumu jaunam lietotājam, pasūtījums tiks augšupielādēts 1C-Bitrix un izveidots Jauns lietotājs diapazonā no 1 līdz 15 minūtēm.
  • Ja pasūtījuma lapā sistēmā maināt adresi, piegādes maksu vai statusu, visas šīs izmaiņas tiks augšupielādētas 1C-Bitrix 15 minūšu laikā.
  • Ja sistēmā mainīsiet preču atlaides un mainīsiet preču daudzumu, tas mainīsies 1C-Bitrix intervālā no 1 līdz 15 minūtēm.

Izmaiņas integrācijas modulī

Versija 2.0

  • Integrācijas moduļa versija V2.0 ir paredzēta, lai integrētu 1C-Bitrix ar tajā instalēto moduļa versiju “Tiešsaistes veikals (pārdošana)” > 16.
  • Tagad modulis darbojas, izmantojot API V4.
  • Integrācijas modulis tagad izmanto jauno 1C-Bitrix D7 kodolu.
  • Tagad no sistēmas uz vietni tiek nosūtītas arī izmaiņas attiecībā uz klientu (pilns vārds, e-pasts, tālrunis).
  • Integrācijas moduļa iestatījumos sadaļā "Citi iestatījumi" kļuva iespējams tulkot pasūtījuma numurus no sistēmas uz 1C-Bitrix. Tas ir, ja sistēmā manuāli izveidojat pasūtījumu ar numuru, piemēram, 12345R, tad 1C-Bitrix tiks izveidots pasūtījums ar tādu pašu numuru.
  • Tā kā moduļa "Internetveikals (izpārdošana)" versijā > 16, Bitrix izstrādātāji atteicās no atlaižu piemērošanas visam pasūtījumam un atstāja atlaides tikai precēm, tad sistēmai pagaidām nav arī iespējas izmantot atlaides viss pasūtījums. Atlaides varat iestatīt tikai konkrētām pasūtījuma precēm.

Versija 2.1

  • Kataloga eksportam pievienotas mērvienības.

Versija 2.2

  • Modulis tagad atbalsta vairākas API versijas ar izvēli.
  • API V5 atbalsts.
  • Pievienota iespēja izkraut atlikumus pa noliktavām.
  • Pievienota iespēja lejupielādēt cenu veidus.
  • Pievienota pamata Daemon Collector integrācija.
  • Pievienota integrācija ar Universal Analytics.
  • Ir uzlabota datu modifikācijas iebūvēto funkciju loģika.
  • Pievienota iebūvēta funkcija retailCrmApiResult.
  • Pievienota izmaiņu vēstures aktivizētāja versija.

Versija 2.4

  • Pievienots čeks procesorā par maksājuma saglabāšanu jaunam pasūtījumam.
  • Pievienots iestatījums tirdzniecības piedāvājumu skaitam eksportā.
  • Pievienota pirkuma cenas konvertēšana.
  • Tulkošanas failu maiņa.
  • Pievienota pasūtījuma rekvizītu pārbaude, izkraujot izmaiņas no sistēmas.
  • Pievienota PVN augšupielāde.
  • Novērsta cenu veidu saraksta iegūšana augšupielādei. Visi Bitrix pieejamie veidi ir pieejami atlasei.

Citi iestatījumi

Pasūtījuma iestatījumi

Pārsūtīt uz veikalu centrālajā apstrādes centrā izveidotos pasūtījumu numurus

Kad sistēmā tiek izveidots pasūtījums, tas ģenerē savu unikālo numuru atbilstoši norādītajiem noteikumiem. Kad šis iestatījums ir iestatīts modulī, šāda pasūtījuma numurs tiks pārsūtīts uz veikalu apgrieztās sinhronizācijas laikā.

Pasūtījumu izkraušana

  • Pēc notikuma- saglabājot pasūtījumu, dati nonāk sistēmā;
  • Aģents- jauni pasūtījumi tiek nosūtīti pirms izmaiņu vēstures pieprasīšanas no sistēmas.

Klienta API versija

Tagad varat izvēlēties API versiju, ar kuru modulis darbosies. Izvēle ir atkarīga no sistēmas versijas. Ieteicams izvēlēties jaunāko versiju.

Iespējot atlikumu izkraušanu pa noliktavām (pieejams, ja ir noliktavas)

Tagad jūs varat periodiski izkraut atlikumus no vietnes noliktavām uz sistēmas noliktavām. Lai to izdarītu, jums ir nepieciešams:

  • salīdzināt vietnes noliktavas ar sistēmu noliktavām;
  • norāda sistēmas veikalus, kuros tiks ielādēti atlikumi;
  • atlasīt informācijas blokus ar precēm, kas nepieciešamas iekraušanas atlikumiem (jāizvēlas tie, kas norādīti kataloga eksportā sistēmai).

Augšupielādēšanu veic aģents ar biežumu 1 stunda (pēc noklusējuma).

Lūdzu, ņemiet vērā, ka, lai ielādētu atlikumus sistēmā, ir jābūt iespējotām opcijām.

Iespējot produktu cenu veidu augšupielādi (pieejama tikai tad, ja ir vairāki cenu veidi)

Tagad jūs varat periodiski augšupielādēt papildu cenu veidus no veikala sistēmā. Lai to izdarītu, jums ir nepieciešams:

  • salīdzināt vietnes cenu veidus ar sistēmas cenu veidiem;
  • norāda sistēmas veikalus, kuros tiks ielādēti papildu cenu veidi;
  • atlasīt informācijas blokus ar precēm, kurām nepieciešama papildu cenu veidu ielāde (jāatlasa tie, kas ir norādīti sistēmas kataloga eksportā).

Aģents veic augšupielādi ik pēc 24 stundām (pēc noklusējuma).

Aktivizējiet Demon Collector

Tagad jūs varat pievienot vietnei Collector Daemon no iestatījumu saskarnes. Lai to izdarītu, jums ir jānorāda atbilstošā atslēga vēlamajai vietnei. Atslēgu var atrast sistēmā.

Iespējot UA integrāciju

Tagad iestatījumu saskarnē varat iespējot integrāciju ar Universal Analytics (pareizi darbojas ar standarta pasūtīšanas komponentu). Katrai vietnei, kurai vēlaties pievienot izsekošanu, ir jāaizpilda izsekošanas ID un pielāgoto parametru indekss.

Kur $order ir ģenerētais pasūtījuma datu masīvs, kas jānosūta sistēmai, un $arFields ir pasūtījuma lauku masīvs vietnē. function retailCrmBeforeOrderSave($order) ( //Jūsu veiktās izmaiņas atgriež $order; //vai atgriež false; un pēc tam šim pasūtījumam sistēmas veiktās izmaiņas tiks ignorētas)

Kur $order ir masīvs ar modificētiem pasūtījuma datiem, kas saņemti no sistēmas.

funkcija retailCrmAfterOrderSave

retailCrmAfterOrderSave - funkcija, kas tiek izpildīta uzreiz pēc tam, kad vietnē tiek saglabātas izmaiņas pasūtījuma datos, kas saņemti no sistēmas vēstures.

function retailCrmAfterOrderSave($order) ( //Jūsu izmaiņas atgriežas; )

Kur $order ir masīvs ar modificētiem pasūtījuma datiem, kas saņemti no sistēmas.

Funkcija retailCrmApiResult

retailCrmApiResult - funkcija, kas tiek izpildīta uzreiz pēc atbildes saņemšanas no sistēmas API.

function retailCrmApiResult($methodApi, $res, $code) ( //Jūsu izmaiņas atgriežas; )

Kur $methodApi ir API metodes nosaukums, $res ir patiesa/nepatiesa pieprasījuma rezultāts (veiksmīgs vai neveiksmīgs pieprasījums), $code ir API atbildes statusa kods.

Lūdzu, ņemiet vērā, ka kļūdas kodā, izmantojot šo funkciju, var traucēt vietnes un sistēmas sinhronizāciju.

Ja kāda iemesla dēļ ar iepriekš uzskaitītajiem rīkiem nepietiek, jūs varat veikt nepieciešamās izmaiņas tieši moduļa kodā, neriskējot šīs izmaiņas pazaudēt moduļa atjaunināšanas laikā. Lai to izdarītu, fails ar nepieciešamo klasi ir jāpārkopē /bitrix/php_interface/retailcrm/ direktorijā un jāveic tajā izmaiņas. Šis mehānisms atbalsta klases maiņu darbam ar klientiem, pasūtījumiem, pasākumiem, katalogu eksportu un citiem palīgmehānismiem.


Grāmatzīme Pielāgoti uzdevumi ir paredzēts tiem, kuri tieši strādās ar produktu, tas ir, to uzņēmumu darbiniekiem, kuri izmanto mūsu programmatūras produktu.

Cilne Administratīvie uzdevumi ir paredzēta tiem, kas administrēs ieliktņa versiju "Bitrix24".

Grāmatzīme Dokumentācija paredzēts projektu izstrādātājiem, kuru pamatā ir kastes versija "Bitrix24".

Pielāgoti uzdevumi

Administratīvie uzdevumi

Izstrādātājiem

Izstrādātāja dokumentācija ir sistēmas API apraksts. Lietotāja dokumentācija ir sistēmas komponentu un iestatījumu apraksts.

Dokumentācija ir pieejama gan tiešsaistē, gan kā fails chm formātā. Ieteicams izmantot tiešsaistes versiju, jo tā ir jaunāka. chm faili tiek periodiski atjaunināti un var nesaturēt informāciju par jaunākajām versijām.

Uzmanību! Ja neredzat formāta faila saturu .chm, iemesls ir drošības iestatījumi operētājsistēma. Faila rekvizītos jums ir jāatbloķē faila skatīšana. Vairāk lasiet sadaļāFAQ

Dokumentācija ir atsauces informācija. Nepietiek, lai iesācējs izstrādātājs strādātu ar sistēmu. Apgūstot programmēšanas principus Bitrix FrameworkĪpašs kurss jums palīdzēs:

Pirms neilga laika mūsu uzņēmums apkopei un pārveidošanai saņēma diezgan lielu tiešsaistes veikalu vietnē 1C-Bitrix. Projekts komerciālā ekspluatācijā tika nodots pirms pāris mēnešiem, taču tajā pašā laikā tam bija vairākas nopietnas problēmas. Turklāt klients plānoja pēc iespējas ātrāk pabeigt jaunās funkcionalitātes pabeigšanas uzdevumus. Man tika dots uzdevums organizēt efektīvs darbs saskaņā ar projektu ar minimālu objekta dīkstāvi un maksimālu klientu vajadzību apmierināšanu.

Sākotnējie dati:

  • Vietnē 1C-Bitrix ir tiešsaistes veikals
  • Projekts ir vairākus gadus vecs, taču tikai pirms dažiem mēnešiem vietne tika nodota 1C-Bitrix
  • Apmeklējums 10-15 tūkstoši cilvēku dienā
  • Veikala katalogā ir aptuveni 12 000 preču vienību
  • Dīkstāves un vietnes darbības pārtraukumi ir nepieņemami
  • Projektu sešu mēnešu laikā izstrādāja cits uzņēmums:
    1. Tehniskā specifikācija ir aptuveni 100 loksnēm, kas atbilst aptuveni 40% no paveiktā darba.
    2. Nav projekta dokumentācijas
    3. Izpratnes trūkums, kāpēc iepriekšējie izstrādātāji izmantoja konkrētus arhitektūras risinājumus.

Attīstība programmatūra Kopumā un jo īpaši tīmekļa projektiem es strādāju pie tīmekļa projektiem apmēram 8 gadus. Šajā laikā saskāros ar dažādas sarežģītības projektiem un, no pirmā acu uzmetiena, uzdevums man nešķita pārāk grūts. Īstenojot projektus mūsu uzņēmumā, parasti tiek izmantota SCRUM metodoloģija. Es sāku grūstīties prom no viņas.

Pirmkārt, es saņēmu piekļuvi avota kods projektu. Virspusēji analizēts. Saskaņots ar pasūtītāju par prioritāro darbu sarakstu. Uztaisīju attīstības plānu 3 izstrādātājiem un, kā teica Gagarins, ejam!

Problēma #1 – pie visa vainīgi izstrādātāji

Kā jau tas parasti notiek, vainīgi ir visi, izņemot klientu. Dizainers izveidoja izkārtojumu, kas sver pārāk daudz, mitinātājs nodrošināja serveri, kas darbojas lēni, izstrādātāji izveidoja vietni, kas visu laiku ir kļūdaina un bojāta, vadītāji izpildīja dažus uzdevumus, kurus mēs nelūdzām veikt pēc pārslēgšanās no vecā versija Vietnē 1C-Bitrix bija straujš meklēšanas trafika samazinājums utt. Situācija nav viennozīmīga. No vienas puses, galvenā atbildība, protams, jāuzņemas izstrādātāja uzņēmumam. Bija jāpaziņo klientam visu ar vietni veikto darbību sekas un jāsagatavojas rezultātam. Veicot darbu, piedāvājiet holistisku arhitektūru nākotnes sistēma un attīstības plāns, kas jāievēro, līdz tiks pabeigti atskaites punkti. Veiciet rūpīgu funkcionalitātes pārbaudi un iesniedziet darbu. Savukārt bieži nākas saskarties ar situāciju, ka pasūtītājs pats visu zina labāk, jo viņa mamma savulaik gleznoja, un tāpēc ir labākais dizainers, un viņa 7 gadus vecais dēls labi orientējas SEO optimizācijā, jo visu laiku pavada pie datora, spēlējot GTA.

Mums nav jāspriež, kurš vainīgs un kuram taisnība. Šajā gadījumā iepriekšējais darbu veicējs bija diezgan pazīstams, uzticams uzņēmums, un es nevaru teikt neko sliktu par viņu attīstību. Un klients objektīvi rūpējas par savu produktu un cenšas to uzlabot. Es nezinu, kā tas notika, es pats sev atradu izskaidrojumu nepietiekamajā analītikas apjomā, ko darbuzņēmējs sniedza klientam.

Rezultātā:

  • Projekts nav nonācis līdz loģiskam noslēgumam. Daudzi uzdevumi tiek pamesti pusceļā
  • Projekts nav dokumentēts. Dažu funkciju darbība nav acīmredzama. Izstrādājot jaunu funkcionalitāti, izrādās, ka funkcionalitāte, kas agrāk darbojās un par kuras esamību jaunajam izstrādātājam nebija aizdomas, ir pārtraukusi darboties
  • Daļa iepriekšējā izpildītāja rakstītā koda ir jāpārraksta no nulles
  • Pirmajās darba nedēļās/mēnešos jaunajam darbuzņēmējam nav skaidra projekta iecerētā arhitektūra. Viena moduļa funkcionalitātes uzlabošana noved pie tā moduļa funkcionalitātes zuduma, kas ar to nekādā veidā nav saistīts.
  • Klients ir nervozs, izpildītājs ir nervozs, apmeklētāji nav apmierināti, apmeklējums samazinās, pārdošanas apjomi krītas

Es redzu tikai vienu problēmas risinājumu: pakāpeniski sistemātiski iztīriet visus vietnes moduļus pa vienam, lai produkts nonāktu vajadzīgajā stāvoklī. Dažas kļūdas tika iekļautas atsevišķos uzdevumos un pabeigtas nekavējoties, citas tika izlabotas paralēli jaunas funkcionalitātes izstrādei. Rezultāts ir tāds, ka ar katru atjauninājumu pēc tūlītējas kļūdu novēršanas vietne kļūst labāka un stabilāka.

Problēma #2 – paralēla attīstība.

Saskaņā ar 1C-Bitrix licencēšanas politiku katra vietnes licence ļauj izmantot 2 sistēmas kopijas. Viena kā ražošanas vieta, otra attīstībai. Problēma ir tā, ka izstrādi nepārtraukti veic vairāki, manā gadījumā trīs, izstrādātāji. Klasiskās attīstības gadījumā viss ir vienkārši. Katrs izstrādātājs strādā pie sava moduļa. Pēc tam tiek veikta katra moduļa funkcionālā pārbaude, visi uzlabojumi tiek sapludināti kādas versiju kontroles sistēmas repozitorijā, pēc tam tiek pārbaudīti visi kopā (integrācijas testēšana). Ja rezultāts ir normāls, klientam tiek parādīta testa versija. Pēc testa versijas pieņemšanas tiek atjaunināts ražošanas serveris. Saskaņā ar SCRUM metodoloģiju es noteicu, ka vienu reizi nedēļā augšupielādēšu jaunas versijas ražošanas vietā. Attiecīgi pamata izstrādei ir 3-4 dienas. 1 diena testēšanai un kļūdu labošanai un puse dienas ražošanas servera atjaunināšanai. Termiņi, protams, svārstās, bet es centos stingri ievērot noteikumu “atlaid katru ceturtdienu”.

Pirmā lieta, ar ko es saskāros, bija tas, ka 1C-Bitrix ir situācijas, kad viens un tas pats fails tiek vienlaikus izmantots dažādās funkcionalitātēs dažādos vietnes galos. Vienkāršākais un acīmredzamākais risinājums ir izmantot versiju kontroles sistēmu, manā gadījumā SVN, ko izmantoju visos pārējos projektos. Bet, lai izmantotu versiju kontroli, ir nepieciešams, lai katram izstrādātājam būtu sava koda versija, kuru viņš rediģē un pēc tam apvieno kopējā repozitorijā.

Kā ar licenci? Sazinājās tehniskā palīdzība 1C-Bitrix. Saņēmu piedāvājumu iegādāties papildus. licences attīstībai. Maigi sakot, nebiju laimīga, bet citus piedāvājumus nesaņēmu. Es pietiekami ātri atradu risinājumu. Es nolēmu izmantot NFR taustiņus. Par laimi partnera statuss to atļauj. Rezultātā es izveidoju 5 tiešsaistes veikalu instalācijas:

  • Ražošanas serveris
  • Testa serveris
  • 3 izstrādes serveri (viens katram izstrādātājam)

Laika gaitā es gāju vēl tālāk. Ir arī atsevišķa instalācija testerim. Izrādījās, ka ar manu veiksmi klients vienmēr ielogojas testa serverī tajā brīdī, kad tur kaut kas tiek atjaunināts. Kļūdu trasē ir daudz nevajadzīgu uzdevumu, kas jau ir izpildīti, un klientam rodas iespaids, ka mēs savu darbu darām slikti.

Šobrīd es izmantoju šādu shēmu:

  • Katrs izstrādātājs darbam izmanto tikai savu vietējo kopiju
  • Norunātajā laikā visi pabeigtie uzlabojumi tiek apvienoti kopējā filiālē repozitorijā
  • QA testēšanai izmanto apvienoto versiju
  • Pēc pārbaudes un kļūdu novēršanas klientam tiek atjaunināts demonstrācijas serveris
  • Pēc klienta pārbaudes un pieņemšanas uzlabojumi tiek pārsūtīti uz ražošanas serveri.

Starp acīmredzamajiem šīs pieejas trūkumiem es vēlētos izcelt zemo klientu iesaistes līmeni attīstībā. Rezultāts klientam ir redzams tikai beigu posmā. Šī pieeja ir piemērojama, ja jums ir labs analītiķis, kurš reti pieļauj kļūdas un pastāvīgi sazinās ar klientu. Pretējā gadījumā daudzi uzdevumi būs jāpārstrādā no nulles.

Veidojot ķēdi, es saskāros ar citu problēmu. Projekts aizņem aptuveni 80 GB diska vietas. Bez kešatmiņas un pagaidu failiem - apmēram 60. Sākumā es mēģināju noņemt attēlus un videoklipus no versiju kontroles - tas nedarbojās. Informācija vietnē pastāvīgi mainās. Jums ir jāpārbauda, ​​izmantojot pašreizējos datus. Pirmā vietnes saistīšana ar repozitoriju man prasīja vairāk nekā 2 dienas. Pirmā izrakstīšanās izstrādes mapē aizņem vairākas stundas (SVN serverī lokālais tīkls attīstība). Ja, nedod Dievs, jūs nejauši pilnībā atjaunojat projekta mapi, varat doties uzpīpēt, pusdienot, spēlēt galda tenisu vai kērlingu. Tikai atlasīto failu vai mapju pievienošana notiek diezgan ātri. Risinājums: es pabeidzu uzdevumu lejupielādēt duci mainītu failu vienlaikus.

Problēma Nr.3 – ražošanas servera atjaunināšana un sadarbība ar klientu

Problēma ir vissvarīgākā, sarežģītākā un nav pilnībā atrisināta. Galu galā, ja citas problēmas ir saistītas ar projekta iekšējo darbu, tad klienta reputācija un ienākumi, un līdz ar to arī mani ienākumi, ir atkarīgi no vietnes darba.

Šeit lieliski darbojas Mērfija likumi:

  • Ja kaut kas nedarbojas pareizi testa serverī, tas noteikti sabojāsies ražošanas serverī.
  • Ja testa serverī kaut kas darbojas nevainojami, ražošanas serverī tas joprojām sabojās.
  • Ja kļūda vietnē pastāv tikai 5 sekundes, kāds no apmeklētājiem to noteikti atradīs un noteikti par to rakstīs atsauksmēs vai atsauksmju veidlapā.
  • Ja atjaunināšanas laikā vietne nedarbojas 1 minūti, tad tieši šajā minūtē uzņēmuma īpašnieks to parādīs savam draugam vai konkurentam (un tas notiek, neskatoties uz vienošanos par atjaunināšanas laiku un procedūru).
Protams, es pārspīlēju, bet katrā jokā ir kāds humors. Minimālā slodze objektā ir no 4 līdz 6 no rīta. Protams, šobrīd būtu labāk atjaunināt, bet es patiešām nevēlos.

Lielākajai daļai tīmekļa lietojumprogrammu ir skaidra struktūra lietojumprogrammas sadalīšanai slāņos un vietnes atjaunināšanu var iedalīt 2 daļās:

  • Koda atjaunināšana
  • Datu bāzes atjaunināšana, izmantojot SQL skriptus

1C-Bitrix gadījumā viss ir nedaudz sarežģītāk. Pirmkārt, ir daudz failu. Manā projektā to ir vairāk nekā miljons. Tipisks atjauninājums no repozitorija aizņem ne mazāk kā 20–30 minūtes. Jūs, protams, varat atjaunināt tikai mainītos failus, bet tad tiek zaudēta visa repozitorija būtība. Otrkārt, un tas ir daudz skumjāk, bieži vien, veicot atjaunināšanu, jums ir jāveic manuālas izmaiņas un iestatījumi, izmantojot administratora paneli. Un tas vienmēr notiek lēni, jums ir jāatceras visas izmaiņas, kas jāveic, pastāv liela varbūtība nejauši kļūdīties. Jūs, protams, varat uzrakstīt SQL skriptu, kas veiks visas nepieciešamās izmaiņas datu bāzē. Vienkāršākajos gadījumos, protams, mēs to darām. Bet vairumā gadījumu šāda skripta rakstīšana un atkļūdošana aizņem vairāk laika nekā pati izstrāde un daudz vairāk laika nekā visu darbību manuāla veikšana ar sekojošu testēšanu.

Es vēl neesmu atradis labu problēmas risinājumu. Tagad mēs manuāli atjauninām iestatījumus datubāzē. Lai samazinātu kļūdas, tiek sastādīts kontrolsaraksts ar sarakstu, kas jāveic atjaunināšanas laikā. Mēs cenšamies veikt atjaunināšanu pēc iespējas rūpīgāk un precīzāk. Pēc atjaunināšanas visa komanda pārbauda ražošanas servera galveno funkcionalitāti un veic papildu testēšanu. Kļūdu skaits ir samazināts līdz minimumam, taču vēl nav izdevies pilnībā atbrīvoties no kļūdām un dīkstāves atjaunināšanas laikā.

Otra lieta, ko es saskāros, ir sadarbību ar klientu. Jo Projekts ir liels, pie tā nepārtraukti strādā ap 30 cilvēku. Satura vadītāji, pārdošanas vadītāji, SEO optimizētāji, tirgotāji un daudzi citi. Protams, ikviens veic dažas izmaiņas vietnes lapās un moduļa iestatījumos. Pirmais lēmums bija atņemt klientam tiesības veikt izmaiņas vietnes programmas kodā. Lēmums bija pilnīgi pareizs, bet tas tikai pasliktinājās. Ja agrāk klients pieļāva, ka arī viņš var doties uz objektu un nejauši kaut ko salauzt, tad tagad visas nepatikšanas sāka krist tikai uz mums. Kāds tam sakars. Pat ja satura pārvaldnieks lapas tekstu rediģēja greizi un neaizvēra kādu tagu, tomēr vainīgs ir izstrādātājs. Risinājums izrādījās diezgan vienkāršs. Tirgū ir pieejams bezmaksas modulis lapas versiju kontrolei. Tas neatrisināja problēmu, kāds joprojām ik pa laikam kaut ko sajauc, bet tagad jebkurā brīdī ir iespējams redzēt, kurš mainīja to, ko mainīja un kāpēc viss sabojājās. Rezultāts, protams, nav ledus, bet tas man ļoti ietaupa nervus.

Turklāt mēs nolēmām, ka pirms katra testa servera atjaunināšanas mēs uz to nogādājam kopiju no ražošanas servera. Tas arī aizņem daudz laika. Arhivējiet projektu, pārsūtiet uz citu serveri, izpakojiet to. Tas viss aizņem vairākas stundas. Bet jauni uzlabojumi tiek pārbaudīti praktiski kaujas apstākļos. Ja testa un ražošanas serveru iestatījumi būs identiski, darbības atšķirība būs minimāla un kļūdu skaits ievērojami samazināsies. Pieredze rāda, ka nedēļas laikā ražošanas serveris var tik daudz izmainīties, ka daļa no jaunās funkcionalitātes, kas bez problēmām darbojas nedēļu vecā kopijā, var nedarboties pavisam.

4. problēma — “izdari to man steidzami, šis ir 5 minūšu uzdevums”

Problēma ir saistīta ne tik daudz ar 1C-Bitrix, bet gan ar darba projektu pilnveidošanu un atbalstu. Bieži vien klientam ir vēlme paveikt kādu sīkumu, bet steidzami un uzreiz uz ražošanas vietu. Rezultāts vienmēr ir vienāds – nekas labs no tā neiznāk. Labākajā gadījumā šī modifikācija tiks vienkārši aizmirsta nākamajā izlaidumā, sliktākajā gadījumā serveris vienkārši avarēs un vairākas stundas būs jāatjauno no dublējuma.

Es atradu tikai vienu risinājumu – nekad nesekojiet klienta norādījumiem uz uzticamības un drošības rēķina. Neatkarīgi no tā, kā klients jautā, izstrādātājs vienmēr būs vainīgs. Kā man teica mans bijušais priekšnieks: "Es nelūdzu jums darīt neko sliktu."

Un tā kā mēs pieskārāmies dublēšanas tēmai, es vēlos atzīmēt. Dublēšana, izmantojot 1C-Bitrick, protams, ir laba un ērta, taču ļoti lēna. Ja jums steidzami jāatjauno 1-2 faili vai vairākas vērtības datu bāzē, jums jāgaida, līdz visi 60 GB ir izspiesti. Man šķiet visefektīvākā šāda shēma:

  • Katru dienu jābūt failu un datu bāzu dublējumam arhīva veidā ārējais avots datus.
  • Mēs vienmēr izveidojam dublējumu tieši pirms atjaunināšanas vienā no 2 iespējām:
    1. Opcijas indikators — kopējiet visu projekta mapi uz blakus esošo mapi serverī. Mēs saglabājam datu bāzi kā izgāztuvi atsevišķā failā. Mēs neko nearhivējam. Gadījumā, ja nepieciešams atjaunot kādu vērtību datu bāzē vai kādā no failiem, viss būs pa rokai un viegli pieejams
    2. Variants spēcīgs - līdzīgi kā iepriekšējā, tikai kopējam datu bāzi uz citu datu bāzi MySQL dati. Tas ļaus pilnīgas avārijas gadījumā 1–2 minūšu laikā izlabot vietnes saknes mapi saimniekdatora failā, un projekts sāks darboties no blakus mapes ar datu bāzes kopiju.

Secinājums

Paldies visiem, kas izlasīja līdz galam. Ceru, ka mana pieredze jums noderēs. Priecāšos saņemt ieteikumus, kā labāk atrisināt izvirzītās problēmas komentāros vai personīgā ziņā. Tagad esmu mēģinājis izrunāt galvenās problēmas, kas saistītas ar jau uzsākto projektu pabeigšanu un atbalstīšanu ar augstām uzticamības prasībām. Ja materiāls izrādīsies interesants, es plānoju uzrakstīt turpinājumu par 1C-Bitrix arhitektūras iezīmēm, kas atšķir vietnes izstrādi Bitrix no citu tīmekļa projektu izstrādes.

Informācija par darbu ar var atrast apmācībās un dokumentācijā. Apmācību kursi ir paredzēti, lai apgūtu darba metodes programmatūras produkts, un dokumentācija - CMS pielāgošanas principu apgūšanai.

Strādājot ar "1C-Bitrix: vietņu pārvaldība" problēmas rodas konkrētu praktisku problēmu veidā. Mēs esam apkopojuši specializētās tēmās dažādas lapas apmācību kursi, lai jums būtu vieglāk atrast atbildes uz saviem jautājumiem.
Mācību centri Uzdod jautājumu Forums



Grāmatzīme Satura pārvaldnieki ir paredzēts tiem, kuri tieši strādās ar produktu, tas ir, satura vadītājiem, kas vada mūsu programmatūras produktā izveidotos projektus.

Grāmatzīme Administratori paredzēts tiem, kas administrēs "1C-Bitrix: vietņu pārvaldība".

Grāmatzīme Izstrādātājiem paredzēts projektu izstrādātājiem, pamatojoties uz "1C-Bitrix: vietņu pārvaldība".

Satura pārvaldnieki

Jūs varat importēt kursu savā vietnē Satura pārvaldnieks no šī arhīva. Kurss bez jautājumiem testiem.
Kursa versija datēta ar 2015. gada 5. jūniju.

Administratori

Izstrādātājiem

Izstrādātāja dokumentācija ir sistēmas API apraksts. Lietotāja dokumentācija ir sistēmas komponentu un iestatījumu apraksts.

Dokumentācija ir pieejama gan tiešsaistē, gan kā fails chm formātā. Ieteicams izmantot tiešsaistes versiju, jo tā ir jaunāka. chm formāta faili tiek periodiski atjaunināti un var nesaturēt informāciju par jaunākās izmaiņas palīdzības sistēmā.

Uzmanību! Ja neredzat formāta faila saturu .chm, iemesls ir operētājsistēmas drošības iestatījumi. Faila rekvizītos jums ir jāatbloķē faila skatīšana. Vairāk lasiet sadaļāFAQ

Dokumentācija ir atsauces informācija. Nepietiek, lai iesācējs izstrādātājs strādātu ar sistēmu. Apgūstot programmēšanas principus Bitrix FrameworkĪpašs kurss jums palīdzēs:

Populārs kategorijā:
Kā datorā izveidot karaoke klipu?
Kā datorā izveidot karaoke klipu?
lasīt
Spēlei ir nepieciešama lietotne Origin, taču tā nav instalēta. FIFA 16 nepieciešama programma Origin.
Lai atskaņotu, ir nepieciešama lietotne Origin, taču tā nav instalēta FIFA...
lasīt
Personīgās lapas reģistrēšana sociālajā tīklā Facebook
Personīgās lapas reģistrēšana sociālajā tīklā Facebook
lasīt
Kā palaist vienkāršu Nmap Nmap skenēšanu
Kā palaist vienkāršu Nmap Nmap skenēšanu
lasīt

Jaunākie raksti
Kā pagriezt attēlu par dažiem grādiem...
lasīt
Reklāmas atspējošana Yandex pārlūkprogrammā Kur...
lasīt
Notiek Wi-Fi savienojuma problēmu novēršana...
lasīt
Mainiet paroli Windows 10 profilā
lasīt
Norādījumi bezvadu maršrutētāju iestatīšanai...
lasīt
Kā izvēlēties cieto disku un kuru labāk iegādāties...
lasīt
Meizu par manekeniem. Zvani un adrešu grāmata....
lasīt
Lejupielādēt PDFMaster programmu
lasīt
Tops