Platform na "1C: Enterprise" - ano ang nasa ilalim ng hood?

Hoy Habr!
Sa artikulong ito sisimulan natin ang kuwento tungkol sa kung paano ito gumagana sa loob platform "1C:Enterprise 8" at kung anong mga teknolohiya ang ginagamit sa pag-unlad nito.

Platform na "1C: Enterprise" - ano ang nasa ilalim ng hood?

Bakit sa tingin namin ito ay kawili-wili? Una, dahil ang 1C:Enterprise 8 platform ay isang malaking (higit sa 10 milyong linya ng code) na application sa C++ (client, server, atbp.), JavaScript (web client), at, mas kamakailan, At Java. Ang mga malalaking proyekto ay maaaring maging kawili-wili kahit na dahil sa kanilang sukat, dahil ang mga isyu na hindi nakikita sa isang maliit na base ng code ay bumangon nang buong puwersa sa mga naturang proyekto. Pangalawa, ang "1C:Enterprise" ay isang replicable, "naka-box" na produkto, at kakaunti ang mga artikulo tungkol sa mga naturang development sa HabrΓ©. Palaging kawili-wiling malaman kung paano ang buhay sa ibang mga koponan at kumpanya.

Kaya simulan na natin. Sa artikulong ito ay magbibigay kami ng isang pangkalahatang-ideya ng ilan sa mga teknolohiya na ginagamit sa platform at binabalangkas ang landscape, nang hindi malalim ang pagsisid sa pagpapatupad. Sa katunayan, para sa maraming mga mekanismo, ang isang detalyadong kuwento ay mangangailangan ng isang hiwalay na artikulo, at para sa ilan, isang buong libro!
Upang magsimula, sulit na magpasya sa mga pangunahing bagay - kung ano ang platform ng 1C:Enterprise at kung anong mga bahagi ang binubuo nito. Ang sagot sa tanong na ito ay hindi gaanong simple, dahil ang terminong "Platform" (para sa kaiklian, tatawagin natin itong paraan) ay tumutukoy sa isang paraan para sa pagbuo ng mga application ng negosyo, isang runtime na kapaligiran, at mga tool sa pangangasiwa. Ang mga sumusunod na sangkap ay maaaring halos nakikilala:

  • cluster ng server
  • "manipis" na kliyente na may kakayahang kumonekta sa server sa pamamagitan ng http at sarili nitong binary protocol
  • client para sa pagtatrabaho sa isang two-tier architecture na may database na matatagpuan sa isang hard drive o network folder
  • web client
  • mga tool sa pangangasiwa ng server ng application
  • development environment (kilala bilang Configurator)
  • runtime environment para sa iOS, Android at Windows Phone (mobile platform 1C)

Ang lahat ng mga bahaging ito, maliban sa web client, ay nakasulat sa C++. Bukod pa rito, mayroong kamakailang inihayag Bagong henerasyon configurator, nakasulat sa Java.

Mga katutubong app

Ang C++03 ay ginagamit upang bumuo ng mga katutubong application. Para sa Windows, ginagamit ang Microsoft Visual C++ 12 (isang profile na katugma sa Windows XP) bilang compiler, at para sa Linux at Android - gcc 4.8, para sa iOS - clang 5.0. Ang karaniwang library na ginamit ay pareho para sa lahat ng mga operating system at compiler - STLPort. Binabawasan ng solusyong ito ang posibilidad ng mga error na partikular sa pagpapatupad ng STL. Kasalukuyan kaming nagpaplanong lumipat sa pagpapatupad ng STL na ipinadala kasama ng CLang, dahil ang STLPort ay hindi na ipinagpatuloy at hindi tugma sa C++11 na mode na pinagana ng gcc.
Ang code base ng server ay 99% karaniwan, ang client - 95%. Bukod dito, kahit na ang mobile platform ay gumagamit ng parehong C++ code bilang ang "malaki" na isa, kahit na ang porsyento ng pag-iisa doon ay medyo mas mababa.
Tulad ng karamihan sa mga user ng C++, hindi namin inaangkin na ginagamit namin ang 100% ng mga kakayahan ng wika at mga aklatan nito. Kaya, halos hindi kami gumagamit ng Boost, at isa sa mga feature ng wika ay ang dynamic na uri ng casting. Kasabay nito, aktibong ginagamit namin ang:

  • STL (partikular ang mga string, container at algorithm)
  • maramihang mana, kasama. maramihang pagpapatupad na mana
  • mga template
  • pagbubukod
  • smart pointer (custom na pagpapatupad)

Sa pamamagitan ng paggamit ng maramihang pamana ng mga interface (ganap na abstract na mga klase), nagiging posible ang isang component model, na tatalakayin sa ibaba.

Piraso

Upang matiyak ang modularity, ang lahat ng functionality ay nahahati sa mga bahagi, na mga dynamic na library (*.dll para sa Windows, *.so para sa Linux). Mayroong higit sa isang daan at limampung bahagi sa kabuuan; narito ang mga paglalarawan ng ilan sa mga ito:

backend
Naglalaman ng platform metadata engine

accnt
Mga bagay na ginagamit ng mga developer ng application upang bumuo ng mga talaan ng accounting (mga chart ng mga account at mga rehistro ng accounting)

bsl
Naka-embed na engine ng pagpapatupad ng wika

nuke
Custom na pagpapatupad ng memory allocator

dbeng8
Engine ng database ng file. Isang simpleng file server database engine batay sa ISAM, na kinabibilangan din ng isang simpleng SQL processor

wbase
Naglalaman ng mga batayang klase at pag-andar para sa pagpapatupad ng interface ng gumagamit ng Windows - mga klase sa window, pag-access sa GDI, atbp.

Ang paghahati sa maraming bahagi ay kapaki-pakinabang mula sa ilang mga punto ng view:

  • Ang paghihiwalay ay nagpo-promote ng mas mahusay na disenyo, sa partikular na mas mahusay na paghihiwalay ng code
  • Mula sa isang hanay ng mga bahagi maaari mong flexible na bumuo ng iba't ibang mga opsyon sa paghahatid:
    • Halimbawa, ang pag-install ng thin client ay maglalaman ng wbase, ngunit hindi magkakaroon ng backend
    • ngunit sa wbase server, sa kabaligtaran, hindi ito magiging
    • ang parehong mga pagpipilian ay siyempre naglalaman ng nuke at bsl

Ang lahat ng mga sangkap na kinakailangan para sa opsyon sa paglulunsad na ito ay na-load kapag nagsimula ang programa. Ito, sa partikular, ay kinakailangan para sa pagpaparehistro ng mga klase ng SCOM, na tatalakayin sa ibaba.

SCOM

Para sa decomposition sa mas mababang antas, ginagamit ang SCOM system, isang library na katulad ng ideolohiya sa ATL. Para sa mga hindi pa nagtrabaho sa ATL, maikli naming inilista ang mga pangunahing kakayahan at tampok.
Para sa isang espesyal na idinisenyong klase ng SCOM:

  • Nagbibigay ng mga pamamaraan ng pabrika na nagbibigay-daan sa iyong lumikha ng isang klase mula sa isa pang bahagi na alam lamang ang pangalan nito (nang hindi inilalantad ang pagpapatupad)
  • Nagbibigay ng reference-counting smart pointer infrastructure. Ang buhay ng klase ng SCOM ay hindi kailangang manu-manong subaybayan
  • Binibigyang-daan kang malaman kung ang isang bagay ay nagpapatupad ng isang partikular na interface at awtomatikong nagko-convert ng isang pointer sa bagay sa isang pointer sa interface
  • Gumawa ng object ng serbisyo na laging naa-access sa pamamagitan ng get_service method, atbp.

Halimbawa, maaari mong ilarawan ang isang klase para sa pagbabasa ng JSON (halimbawa, JSONStreamReader) sa bahagi ng json.dll.
Maaaring malikha ang mga klase at instance mula sa iba pang mga bahagi; kailangan nilang mairehistro sa makina ng SCOM:

SCOM_CLASS_ENTRY(JSONStreamReader)

Ilalarawan ng macro na ito ang isang espesyal na klase ng static recorder, ang constructor nito ay tatawagin kapag na-load ang component sa memorya.
Pagkatapos nito, maaari kang lumikha ng isang instance nito sa isa pang bahagi:

IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));

Upang suportahan ang mga serbisyo, nag-aalok ang SCOM ng karagdagang, medyo kumplikadong imprastraktura. Ang sentro nito ay ang konsepto ng isang proseso ng SCOM, na nagsisilbing lalagyan para sa pagpapatakbo ng mga serbisyo (i.e., gumaganap sa papel ng Service Locator), at naglalaman din ng isang binding sa mga lokal na mapagkukunan. Ang proseso ng SCOM ay nakatali sa OS thread. Salamat dito, sa loob ng application maaari kang makatanggap ng mga serbisyong tulad nito:

SCOM_Process* process = core::current_process();
if (process)
         return get_service<IMyService>(process);

Bukod dito, sa pamamagitan ng paglipat ng mga prosesong lohikal (SCOM) na nakatali sa isang thread, maaari kang makakuha ng mga application na halos independyente mula sa punto ng view ng espasyo ng impormasyon, na tumatakbo sa loob ng parehong thread. Ito ay kung paano gumagana ang aming thin client sa isang database ng file - sa loob ng isang proseso ng OS mayroong dalawang proseso ng SCOM, ang isa ay nauugnay sa kliyente, at ang pangalawa sa server. Ang diskarte na ito ay nagbibigay-daan sa amin na pag-isahin ang pagsulat ng code na gagana pareho sa lokal na database ng file at sa "tunay" na bersyon ng client-server. Ang presyo para sa gayong pagkakapareho ay nasa itaas, ngunit ang pagsasanay ay nagpapakita na ito ay katumbas ng halaga.

Batay sa modelo ng bahagi ng SCOM, ang parehong lohika ng negosyo at ang bahagi ng interface ng 1C: Enterprise ay ipinatupad.

User interface

Sa pamamagitan ng paraan, tungkol sa mga interface. Hindi kami gumagamit ng karaniwang mga kontrol sa Windows; ang aming mga kontrol ay direktang ipinapatupad sa Windows API. Para sa bersyon ng Linux, isang layer ang ginawa na gumagana sa pamamagitan ng wxWidgets library.
Ang library ng mga kontrol ay hindi nakadepende sa iba pang bahagi ng 1C:Enterprise at ginagamit namin sa ilang iba pang maliliit na panloob na kagamitan.

Sa paglipas ng mga taon ng pag-unlad ng 1C:Enterprise, ang hitsura ng mga kontrol ay nagbago, ngunit ang isang seryosong pagbabago sa mga prinsipyo ay nangyari nang isang beses lamang, noong 2009, sa paglabas ng bersyon 8.2 at ang pagdating ng "pinamamahalaang mga form". Bilang karagdagan sa pagbabago ng hitsura, ang prinsipyo ng layout ng form ay sa panimula ay nagbago - nagkaroon ng pagtanggi sa pixel-by-pixel na pagpoposisyon ng mga elemento na pabor sa daloy-layout ng mga elemento. Bilang karagdagan, sa bagong modelo, ang mga kontrol ay hindi direktang gumagana sa mga bagay ng domain, ngunit sa mga espesyal na DTO (Mga Bagay sa Paglilipat ng Data).
Ang mga pagbabagong ito ay naging posible upang lumikha ng isang 1C:Enterprise web client na ginagaya ang C++ na lohika ng mga kontrol ng JavaScript. Sinusubukan naming mapanatili ang functional equivalence sa pagitan ng thin at web client. Sa mga kaso kung saan hindi ito posible, halimbawa dahil sa mga limitasyon ng JavaScript API na magagamit (halimbawa, ang kakayahang magtrabaho kasama ang mga file ay napakalimitado), madalas naming ipinapatupad ang kinakailangang paggana gamit ang mga extension ng browser na nakasulat sa C++. Kasalukuyan naming sinusuportahan ang Internet Explorer at Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows at Linux) at Safari (MacOS).

Bilang karagdagan, ang teknolohiya ng mga pinamamahalaang form ay ginagamit upang lumikha ng isang interface para sa mga mobile application sa 1C platform. Sa mga mobile device, ang pag-render ng mga kontrol ay ipinapatupad gamit ang mga teknolohiyang native sa operating system, ngunit para sa form layout logic at interface na tugon, ang parehong code ay ginagamit tulad ng sa "malaking" 1C:Enterprise platform.

Platform na "1C: Enterprise" - ano ang nasa ilalim ng hood?
1C interface sa Linux OS

Platform na "1C: Enterprise" - ano ang nasa ilalim ng hood?
1C interface sa isang mobile device

1C interface sa iba pang mga platform Platform na "1C: Enterprise" - ano ang nasa ilalim ng hood?
1C interface sa Windows OS

Platform na "1C: Enterprise" - ano ang nasa ilalim ng hood?
Interface 1C - web client

open source

Bagama't hindi kami gumagamit ng mga karaniwang aklatan para sa mga developer ng C++ sa ilalim ng Windows (MFC, mga kontrol mula sa WinAPI), hindi namin isinusulat ang lahat ng mga bahagi sa aming sarili. Nabanggit na ang library wxWidgets, at ginagamit din namin ang:

  • magkulot para sa pagtatrabaho sa HTTP at FTP.
  • OpenSSL para sa pagtatrabaho sa cryptography at pagtatatag ng mga koneksyon sa TLS
  • libxml2 at libxslt para sa XML parsing
  • libetpan para sa pagtatrabaho sa mga mail protocol (POP3, SMTP, IMAP)
  • gayahin para i-parse ang mga mensaheng email
  • sqllite para sa pag-iimbak ng mga log ng gumagamit
  • ICU para sa internasyonalisasyon

Ang listahan ay nagpapatuloy.
Bukod pa rito, gumagamit kami ng lubos na binagong bersyon Pagsubok sa Google ΠΈ Google Mock kapag bumubuo ng mga pagsubok sa yunit.
Ang mga aklatan ay nangangailangan ng adaptasyon upang maging tugma sa modelo ng organisasyong bahagi ng SCOM.
Ang paglaganap ng 1C ay gumagawa ng platform na isang mahusay na pagsubok ng lakas para sa mga aklatan na ginagamit dito. Ang iba't ibang mga user at mga sitwasyon ay mabilis na nagpapakita ng mga error sa kahit na ang pinaka-bihirang ginagamit na mga lugar ng code. Itinutuwid namin ang mga ito sa aming sarili at sinusubukang ibalik ang mga ito sa mga may-akda ng aklatan. Ang karanasan ng pakikipag-ugnayan ay lumalabas na ibang-iba.
Mga Nag-develop magkulot ΠΈ libetpan mabilis na tumugon sa mga pull-request, ngunit ang patch, halimbawa, sa OpenSSL Hindi namin nagawang ibalik ito.

Konklusyon

Sa artikulo ay hinawakan namin ang ilang pangunahing aspeto ng pagbuo ng 1C: Enterprise platform. Sa limitadong saklaw ng artikulo, hinawakan lamang namin ang ilang mga kawili-wiling, sa aming opinyon, mga aspeto.
Ang isang pangkalahatang paglalarawan ng iba't ibang mga mekanismo ng platform ay matatagpuan dito.
Anong mga paksa ang magiging kawili-wili sa iyo sa mga artikulo sa hinaharap?

Paano ipinapatupad ang 1C mobile platform?
Paglalarawan ng panloob na istraktura ng web client?
O baka interesado ka sa proseso ng pagpili ng mga feature para sa mga bagong release, pagbuo at pagsubok?

Sumulat sa mga komento!

Pinagmulan: www.habr.com

Magdagdag ng komento