Платформа "1C: Enterprise" - какво има под капака?

Хей Хабр!
В тази статия ще започнем историята за това как работи вътре платформа "1C:Enterprise 8" и какви технологии се използват при разработването му.

Защо мислим, че това е интересно? Първо, защото платформата 1C:Enterprise 8 е голямо (повече от 10 милиона реда код) приложение в C++ (клиент, сървър и т.н.), JavaScript (уеб клиент) и, отскоро, И Ява. Големите проекти могат да бъдат интересни най-малкото поради техния мащаб, защото проблемите, които са невидими в малка кодова база, възникват с пълна сила в такива проекти. На второ място, „1C:Enterprise“ е репликируем продукт в „кутия“ и има много малко статии за подобни разработки на Habré. Освен това винаги е интересно да се знае как е животът в други екипи и компании.

Така че да започваме. В тази статия ще направим общ преглед на някои от технологиите, които се използват в платформата и ще очертаем пейзажа, без да навлизаме дълбоко в имплементацията. Всъщност за много механизми подробната история би изисквала отделна статия, а за някои цяла книга!
Като начало си струва да вземете решение за основните неща - какво представлява платформата 1C:Enterprise и от какви компоненти се състои. Отговорът на този въпрос не е толкова прост, тъй като терминът „Платформа“ (за краткост ще го наричаме така) се отнася до средство за разработване на бизнес приложения, среда за изпълнение и инструменти за администриране. Могат грубо да се разграничат следните компоненти:

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

Всички тези части, с изключение на уеб клиента, са написани на C++. Освен това има наскоро обявеното Конфигуратор от ново поколение, написан на Java.

Родни приложения

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 (по-специално низове, контейнери и алгоритми)
• множествено наследяване, вкл. наследяване на множество реализации
• Templates
• изключения
• интелигентни указатели (персонализирано внедряване)

Чрез използване на множествено наследяване на интерфейси (напълно абстрактни класове) става възможен компонентен модел, който ще бъде обсъден по-долу.

Елементи

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

бекенд
Съдържа механизма за метаданни на платформата

accnt
Обекти, които разработчиците на приложения използват за изграждане на счетоводни записи (сметкопланове и счетоводни регистри)

bsl
Вграден двигател за изпълнение на език

бомбата
Персонализирана реализация на разпределител на памет

dbeng8
Машина за файлова база данни. Проста машина за база данни на файлов сървър, базирана на ISAM, която включва и прост SQL процесор

wbase
Съдържа базовите класове и функции за внедряване на потребителския интерфейс на Windows - класове на прозорци, GDI достъп и др.

Разделянето на множество компоненти е полезно от няколко гледни точки:

• Разделянето насърчава по-добър дизайн, по-специално по-добра изолация на кода
• От набор от компоненти можете гъвкаво да сглобите различни опции за доставка:
  • Например инсталацията на тънък клиент ще съдържа wbase, но няма да има бекенд
  • но на сървъра wbase, напротив, няма да бъде
  • и двата варианта разбира се ще съдържат nuke и bsl

Всички компоненти, необходими за тази опция за стартиране, се зареждат при стартиране на програмата. Това по-специално е необходимо за регистриране на SCOM класове, които ще бъдат разгледани по-долу.

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 процес, който служи като контейнер за изпълнявани услуги (т.е. играе ролята на Service Locator), а също така съдържа обвързване към локализирани ресурси. Процесът SCOM е свързан с нишката на OS. Благодарение на това вътре в приложението можете да получавате услуги като тези:

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

Освен това, чрез превключване на логически (SCOM) процеси, свързани с нишка, можете да получите приложения, които са практически независими от гледна точка на информационното пространство, работещи в една и съща нишка. Ето как нашият тънък клиент работи с файлова база данни - вътре в един OS процес има два SCOM процеса, единият свързан с клиента, а вторият със сървъра. Този подход ни позволява да обединим писането на код, който ще работи както в локалната файлова база данни, така и в „истинската“ версия клиент-сървър. Цената за такова еднообразие е скъпа, но практиката показва, че си заслужава.

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

Потребителски интерфейс

Между другото, относно интерфейсите. Ние не използваме стандартни Windows контроли; нашите контроли са внедрени директно в Windows API. За версията на Linux е направен слой, който работи чрез библиотеката wxWidgets.
Библиотеката от контроли не зависи от други части на 1C:Enterprise и се използва от нас в няколко други малки вътрешни помощни програми.

През годините на развитие на 1C:Enterprise външният вид на контролите се промени, но сериозна промяна в принципите настъпи само веднъж, през 2009 г., с пускането на версия 8.2 и появата на „управлявани форми“. В допълнение към промяната на външния вид, принципът на оформлението на формуляра се промени фундаментално - имаше отхвърляне на позиционирането на елементите пиксел по пиксел в полза на поточно оформление на елементи. Освен това в новия модел контролите не работят директно с обекти на домейн, а със специални DTO (Обекти за трансфер на данни).
Тези промени направиха възможно създаването на уеб клиент 1C:Enterprise, който копира C++ логиката на JavaScript контролите. Опитваме се да поддържаме функционална еквивалентност между тънки и уеб клиенти. В случаите, когато това не е възможно, например поради ограничения на наличния API на JavaScript (например възможността за работа с файлове е много ограничена), ние често прилагаме необходимата функционалност, използвайки разширения на браузъра, написани на 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), ние не пишем всички компоненти сами. Библиотеката вече беше спомената wxWidgets, и ние също използваме:

• къдрица за работа с HTTP и FTP.
• OpenSSL за работа с криптография и установяване на TLS връзки
• libxml2 и libxslt за анализ на XML
• либетпан за работа с пощенски протоколи (POP3, SMTP, IMAP)
• миметичен за анализиране на имейл съобщения
• sqllite за съхраняване на потребителски регистрационни файлове
• ICU за интернационализация

Списъкът продължава.
Освен това използваме силно модифицирана версия Тест на Google и Google Mock при разработване на единични тестове.
Библиотеките изискваха адаптация, за да бъдат съвместими с организационния модел на SCOM компонент.
Разпространението на 1C прави платформата отличен тест за силата на използваните в нея библиотеки. Разнообразието от потребители и сценарии бързо разкрива грешки дори в най-рядко използваните области на кода. Ние сами ги коригираме и се опитваме да ги върнем на авторите на библиотеката. Опитът от взаимодействието се оказва много различен.
Разработчици къдрица и либетпан реагира бързо на заявки за изтегляне, но корекцията, например, в OpenSSL Така и не успяхме да го върнем.

Заключение

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

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

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

Източник: www.habr.com