პლატფორმა "1C: Enterprise" - რა არის ქუდის ქვეშ?

ჰეი ჰაბრ!
ამ სტატიაში ჩვენ დავიწყებთ ისტორიას იმის შესახებ, თუ როგორ მუშაობს იგი შიგნით პლატფორმა "1C: Enterprise 8" და რა ტექნოლოგიები გამოიყენება მის განვითარებაში.

რატომ ვფიქრობთ, რომ ეს არის საინტერესო? პირველ რიგში, იმიტომ, რომ 1C:Enterprise 8 პლატფორმა არის დიდი (10 მილიონზე მეტი კოდის ხაზი) ​​აპლიკაცია C++-ში (კლიენტი, სერვერი და ა.შ.), JavaScript (ვებ კლიენტი) და, ახლახან, და Java. მსხვილი პროექტები შეიძლება იყოს საინტერესო სულ მცირე მათი მასშტაბის გამო, რადგან პრობლემები, რომლებიც უხილავია მცირე კოდის ბაზაში, მთელი ძალით წარმოიქმნება ასეთ პროექტებში. მეორეც, „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 შეწყვეტილია და შეუთავსებელია gcc-ის C++11 ჩართულ რეჟიმში.
სერვერის კოდის ბაზა 99% საერთოა, კლიენტის - 95%. უფრო მეტიც, მობილური პლატფორმაც კი იყენებს იგივე C++ კოდს, როგორც „დიდი“, თუმცა იქ გაერთიანების პროცენტი გარკვეულწილად დაბალია.
C++ მომხმარებლების უმეტესობის მსგავსად, ჩვენ არ ვაცხადებთ, რომ ვიყენებთ ენისა და მისი ბიბლიოთეკების შესაძლებლობების 100%-ს. ასე რომ, ჩვენ პრაქტიკულად არ ვიყენებთ Boost-ს და ენის ერთ-ერთი მახასიათებელია დინამიური ტიპის კასტინგი. ამავდროულად, ჩვენ აქტიურად ვიყენებთ:

• STL (კონკრეტულად სტრიქონები, კონტეინერები და ალგორითმები)
• მრავალჯერადი მემკვიდრეობა, მათ შორის. მრავალჯერადი განხორციელების მემკვიდრეობა
• თარგები
• გამონაკლისები
• ჭკვიანი მაჩვენებლები (მორგებული განხორციელება)

ინტერფეისების მრავალჯერადი მემკვიდრეობის გამოყენებით (სრულიად აბსტრაქტული კლასები) შესაძლებელი ხდება კომპონენტის მოდელი, რომელიც ქვემოთ იქნება განხილული.

კომპონენტები

მოდულარობის უზრუნველსაყოფად, ყველა ფუნქცია დაყოფილია კომპონენტებად, რომლებიც წარმოადგენენ დინამიურ ბიბლიოთეკებს (*.dll Windows-ისთვის, *.so Linux-ისთვის). სულ ას ორმოცდაათზე მეტი კომპონენტია; აქ არის ზოგიერთი მათგანის აღწერა:

backend
შეიცავს პლატფორმის მეტამონაცემების ძრავას

აქნტ
ობიექტები, რომლებსაც აპლიკაციის შემქმნელები იყენებენ სააღრიცხვო ჩანაწერების შესაქმნელად (ანგარიშების დიაგრამები და სააღრიცხვო რეგისტრები)

ბსლ
ჩაშენებული ენის შესრულების ძრავა

ნუკე
მეხსიერების ალოკატორის მორგებული განხორციელება

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 პროცესი მიბმულია 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 ვებ კლიენტის შექმნა, რომელიც იმეორებს JavaScript კონტროლის C++ ლოგიკას. ჩვენ ვცდილობთ შევინარჩუნოთ ფუნქციური ეკვივალენტობა თხელი და ვებ კლიენტებს შორის. იმ შემთხვევებში, როდესაც ეს შეუძლებელია, მაგალითად, 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 ვიჯეტებიდა ჩვენ ასევე ვიყენებთ:

• Curl HTTP და FTP-თან მუშაობისთვის.
• OpenSSL კრიპტოგრაფიასთან მუშაობისა და TLS კავშირების დასამყარებლად
• libxml2 და libxslt XML პარსინგისთვის
• ლიბეტპანი ფოსტის პროტოკოლებთან მუშაობისთვის (POP3, SMTP, IMAP)
• მიამიტი ელ.ფოსტის შეტყობინებების გასაანალიზებლად
• sqllite მომხმარებლის ჟურნალების შესანახად
• ICU ინტერნაციონალიზაციისთვის

სია გრძელდება.
გარდა ამისა, ჩვენ ვიყენებთ ძლიერ შეცვლილ ვერსიას Google ტესტი и Google Mock ერთეულის ტესტების შემუშავებისას.
ბიბლიოთეკები საჭიროებდნენ ადაპტაციას SCOM კომპონენტის ორგანიზაციის მოდელთან თავსებადობისთვის.
1C-ის გავრცელება პლატფორმას სიძლიერის შესანიშნავ ტესტად აქცევს მასში გამოყენებული ბიბლიოთეკებისთვის. მრავალფეროვანი მომხმარებელი და სცენარი სწრაფად ავლენს შეცდომებს კოდის ყველაზე იშვიათად გამოყენებულ სფეროებშიც კი. ჩვენ თვითონ ვასწორებთ მათ და ვცდილობთ დავუბრუნოთ ბიბლიოთეკის ავტორებს. ურთიერთქმედების გამოცდილება ძალიან განსხვავებული გამოდის.
დეველოპერები Curl и ლიბეტპანი სწრაფად უპასუხეთ pull-მოთხოვნებს, მაგრამ პატჩი, მაგალითად, in OpenSSL ჩვენ ვერასდროს მოვახერხეთ მისი დაბრუნება.

დასკვნა

სტატიაში ჩვენ შევეხეთ 1C: Enterprise პლატფორმის განვითარების რამდენიმე ძირითად ასპექტს. სტატიის შეზღუდული მოცულობით ჩვენ შევეხეთ მხოლოდ რამდენიმე საინტერესო, ჩვენი აზრით, ასპექტს.
შეგიძლიათ იპოვოთ სხვადასხვა პლატფორმის მექანიზმების ზოგადი აღწერა აქ.
რა თემები იქნება თქვენთვის საინტერესო მომავალ სტატიებში?

როგორ არის დანერგილი 1C მობილური პლატფორმა?
ვებ კლიენტის შიდა სტრუქტურის აღწერა?
ან იქნებ გაინტერესებთ ახალი გამოშვებების ფუნქციების შერჩევის პროცესი, განვითარება და ტესტირება?

დაწერეთ კომენტარებში!

წყარო: www.habr.com