Платформа „1C: Enterprise“ - што има под хаубата?

Еј Хабр!
Во оваа статија ќе ја започнеме приказната за тоа како функционира внатре платформа „1C: Enterprise 8“ и кои технологии се користат во неговиот развој.

Зошто мислиме дека ова е интересно? Прво, затоа што платформата 1C:Enterprise 8 е голема (повеќе од 10 милиони линии код) апликација во C++ (клиент, сервер, итн.), JavaScript (веб-клиент) и, од неодамна, И Јава. Големите проекти можат да бидат интересни барем поради нивниот обем, бидејќи прашањата кои се невидливи во мала база на кодови се појавуваат со полна сила во таквите проекти. Второ, „1C: Enterprise“ е реплициран, „кутиран“ производ и има многу малку написи за такви случувања на Habré. Исто така, секогаш е интересно да се знае како е животот во другите тимови и компании.

Па ајде да започнеме. Во оваа статија ќе дадеме преглед на некои од технологиите што се користат во платформата и ќе го опишеме пејзажот, без длабоко да нурнеме во имплементацијата. Навистина, за многу механизми, детална приказна би барала посебна статија, а за некои цела книга!
За почеток, вреди да се одлучите за основните работи - што е платформата 1C: Enterprise и од кои компоненти се состои. Одговорот на ова прашање не е толку едноставен, бидејќи терминот „Платформа“ (за кратко, така ќе го наречеме) се однесува на средство за развој на деловни апликации, опкружување за извршување и алатки за администрација. Грубо може да се разликуваат следниве компоненти:

• серверски кластер
• „тенок“ клиент способен за поврзување со серверот преку http и свој бинарен протокол
• клиент за работа во двостепена архитектура со база на податоци лоцирана на хард диск или мрежна папка
• веб клиент
• алатки за администрирање на серверот за апликации
• развојна средина (позната како Конфигуратор)
• опкружување за траење за iOS, Android и Windows Phone (мобилна платформа 1C)

Сите овие делови, со исклучок на веб-клиентот, се напишани во C++. Дополнително, тука е и неодамна објавениот Конфигуратор на новата генерација, напишана во Јава.

Мајчин апликации

C++03 се користи за развој на домашни апликации. За Windows, Microsoft Visual C++ 12 (профил компатибилен со Windows XP) се користи како компајлер, а за Linux и Android - gcc 4.8, за iOS - clang 5.0. Стандардната библиотека што се користи е иста за сите оперативни системи и компајлери - STLPort. Ова решение ја намалува веројатноста за грешки специфични за имплементацијата на STL. Во моментов планираме да мигрираме на имплементацијата STL испорачана со CLang, бидејќи STLPort е прекинат и не е компатибилен со режимот овозможен C++11 на gcc.
Основата на кодот на серверот е 99% вообичаена, клиентот - 95%. Покрај тоа, дури и мобилната платформа го користи истиот C++ код како и „големата“, иако процентот на обединување таму е нешто помал.
Како и повеќето корисници на C++, ние не тврдиме дека користиме 100% од можностите на јазикот и неговите библиотеки. Значи, практично не користиме Boost, а една од јазичните карактеристики е кастинг од динамичен тип. Во исто време, ние активно користиме:

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

Со користење на повеќекратно наследување на интерфејси (целосно апстрактни класи), станува возможен компонентен модел, за кој ќе се дискутира подолу.

Компоненти

За да се обезбеди модуларност, целата функционалност е поделена на компоненти, кои се динамични библиотеки (*.dll за Windows, *.so за Linux). Вкупно има повеќе од сто и педесет компоненти; еве опис на некои од нив:

заднинската
Го содржи моторот за метаподатоци на платформата

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

bsl
Мотор за извршување на вграден јазик

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

dbeng8
Мотор за база на податоци за датотеки. Едноставен мотор на база на податоци за сервер за датотеки базиран на ISAM, кој исто така вклучува едноставен SQL процесор

wbase
Ги содржи основните класи и функции за имплементација на корисничкиот интерфејс на Windows - класи на прозорци, пристап до GDI итн.

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

• Раздвојувањето промовира подобар дизајн, особено подобра изолација на кодот
• Од збир на компоненти можете флексибилно да соберете различни опции за испорака:
  • На пример, инсталацијата со тенок клиент ќе содржи wbase, но нема да има backend
  • но на wbase серверот напротив нема да биде
  • двете опции секако ќе содржат nuke и bsl

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

СКОМ

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

• Обезбедува фабрички методи кои ви дозволуваат да креирате класа од друга компонента знаејќи го само нејзиното име (без откривање на имплементацијата)
• Обезбедува инфраструктура за паметни покажувачи со броење референци. Животниот век на класата SCOM не треба рачно да се следи
• Ви овозможува да дознаете дали некој објект имплементира специфичен интерфејс и автоматски да конвертирате покажувач на објектот во покажувач на интерфејсот
• Креирајте услужен објект кој е секогаш достапен преку методот get_service итн.

На пример, можете да опишете класа за читање JSON (на пример, JSONStreamReader) во компонентата json.dll.
Класите и примерите може да се креираат од други компоненти; тие треба да се регистрираат во машината SCOM:

SCOM_CLASS_ENTRY(JSONStreamReader)

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

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

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

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

Покрај тоа, со префрлување на логички (SCOM) процеси врзани за нишка, можете да добиете апликации кои се практично независни од гледна точка на просторот за информации, кои работат во истата нишка. Вака работи нашиот тенок клиент со база на податоци за датотеки - во еден процес на ОС има два SCOM процеси, еден поврзан со клиентот, а вториот со серверот. Овој пристап ни овозможува да го обединиме пишувањето на код кој ќе работи и на локалната база на податоци за датотеки и во „вистинската“ верзија клиент-сервер. Цената за таквата униформност е над глава, но практиката покажува дека вреди.

Врз основа на моделот на компонента SCOM, се имплементирани и деловната логика и делот за интерфејс на 1C: Enterprise.

Кориснички интерфејс

Патем, за интерфејси. Не користиме стандардни контроли на Windows; нашите контроли се имплементирани директно на Windows API. За верзијата на Linux, направен е слој кој работи преку библиотеката wxWidgets.
Библиотеката со контроли не зависи од другите делови на 1C: Enterprise и се користи од нас во неколку други мали внатрешни комунални услуги.

Со текот на годините на развој на 1C: Enterprise, изгледот на контролите се промени, но сериозна промена во принципите се случи само еднаш, во 2009 година, со објавувањето на верзијата 8.2 и појавата на „управувани форми“. Покрај промената на изгледот, принципот на распоред на формата е фундаментално променет - имаше отфрлање на позиционирање на елементите од пиксел по пиксел во корист на распоред на елементите. Покрај тоа, во новиот модел, контролите не работат директно со објекти на доменот, туку со специјални DTO (Објекти за пренос на податоци).
Овие промени овозможија да се создаде веб-клиент 1C:Enterprise кој ја реплицира логиката C++ на контролите на JavaScript. Се трудиме да одржиме функционална еквивалентност помеѓу тенки и веб-клиенти. Во случаи кога тоа не е можно, на пример поради ограничувањата на достапниот JavaScript API (на пример, можноста за работа со датотеки е многу ограничена), ние често ја имплементираме потребната функционалност користејќи екстензии на прелистувач напишани во C++. Во моментов поддржуваме Internet Explorer и Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows и Linux) и Safari (MacOS).

Покрај тоа, технологијата за управувани форми се користи за создавање интерфејс за мобилни апликации на платформата 1C. На мобилните уреди, прикажувањето на контролите се имплементира со помош на технологии кои потекнуваат од оперативниот систем, но за логиката на распоредот на формата и одговорот на интерфејсот, се користи истиот код како во „големата“ платформа 1C: Enterprise.

1C интерфејс на Linux OS

1C интерфејс на мобилен уред

1C интерфејс на други платформи
1C интерфејс на Windows OS

Интерфејс 1C - веб-клиент

Отворен извор

Иако не користиме стандардни библиотеки за развивачи на C++ под Windows (MFC, контроли од WinAPI), ние самите не ги пишуваме сите компоненти. Библиотеката е веќе спомната wxВиџети, а ние исто така користиме:

• навивам за работа со HTTP и FTP.
• OpenSSL за работа со криптографија и воспоставување TLS врски
• libxml2 и libxslt за XML парсирање
• либетпан за работа со протоколи за пошта (POP3, SMTP, IMAP)
• мимички за анализа на е-пораки
• sqllite за складирање на дневници на корисници
• Одделението за интензивна нега за интернационализација

Списокот продолжува.
Дополнително, користиме мошне изменета верзија Тест на Google и Google Mock кога се развиваат единични тестови.
Библиотеките бараа адаптација за да бидат компатибилни со моделот на организација на компонентите SCOM.
Распространетоста на 1C ја прави платформата одличен тест за силата за библиотеките што се користат во неа. Различни корисници и сценарија брзо откриваат грешки дури и во најретко користените области на кодот. Сами ги коригираме и се обидуваме да им ги вратиме на авторите на библиотеката. Искуството на интеракција се покажува многу различно.
Програмери навивам и либетпан брзо реагирајте на барањата за повлекување, но лепенката, на пример, во OpenSSL Никогаш не успеавме да го вратиме.

Заклучок

Во написот допревме неколку главни аспекти на развојот на платформата 1C: Enterprise. Во ограничениот опсег на статијата, допревме само некои интересни, според наше мислење, аспекти.
Може да се најде општ опис на различните механизми на платформата тука.
Кои теми би биле од интерес за вас во идните статии?

Како се имплементира мобилната платформа 1C?
Опис на внатрешната структура на веб-клиентот?
Или можеби сте заинтересирани за процесот на избор на функции за нови изданија, развој и тестирање?

Напиши во коментари!

Извор: www.habr.com