Պլատֆորմ «1C: Enterprise» - ի՞նչ կա գլխարկի տակ:

Հե՜յ Հաբր։
Այս հոդվածում մենք կսկսենք պատմությունը այն մասին, թե ինչպես է այն աշխատում ներսում հարթակ «1C:Enterprise 8» և ինչ տեխնոլոգիաներ են օգտագործվում դրա մշակման մեջ։

Ինչո՞ւ ենք կարծում, որ սա հետաքրքիր է: Նախ, քանի որ 1C:Enterprise 8 հարթակը մեծ (ավելի քան 10 միլիոն տող կոդ) հավելված է C++-ում (հաճախորդ, սերվեր և այլն), JavaScript (վեբ-հաճախորդ) և, վերջերս, Եվ Java. Խոշոր նախագծերը կարող են հետաքրքիր լինել գոնե իրենց մասշտաբների պատճառով, քանի որ խնդիրներ, որոնք անտեսանելի են փոքր կոդերի բազայում, ամբողջ ուժով առաջանում են նման նախագծերում: Երկրորդ, «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-ը դադարեցվել է և անհամատեղելի է gcc-ի C++11 միացված ռեժիմի հետ:
Սերվերի կոդերի բազան 99% ընդհանուր է, հաճախորդինը` 95%: Ավելին, նույնիսկ բջջային հարթակն օգտագործում է նույն C++ կոդը, ինչ «մեծը», թեև այնտեղ միավորման տոկոսը փոքր-ինչ ավելի ցածր է։
Ինչպես C++ օգտագործողների մեծ մասը, մենք չենք պնդում, որ օգտագործում ենք լեզվի և դրա գրադարանների հնարավորությունների 100%-ը: Այսպիսով, մենք գործնականում չենք օգտագործում Boost-ը, և լեզվի առանձնահատկություններից մեկը դինամիկ տիպի քասթինգն է։ Միևնույն ժամանակ մենք ակտիվորեն օգտագործում ենք.

• STL (հատկապես տողեր, կոնտեյներներ և ալգորիթմներ)
• բազմակի ժառանգություն, ներառյալ. բազմակի իրականացման ժառանգություն
• կաղապարներ
• բացառություններ
• խելացի ցուցիչներ (մաքսային իրականացում)

Օգտագործելով ինտերֆեյսների բազմակի ժառանգականությունը (ամբողջովին վերացական դասեր), հնարավոր է դառնում բաղադրիչ մոդելը, որը կքննարկվի ստորև:

Բաղադրիչներ

Մոդուլյարություն ապահովելու համար ամբողջ ֆունկցիոնալությունը բաժանված է բաղադրիչների, որոնք դինամիկ գրադարաններ են (*.dll Windows-ի համար, *.so Linux-ի համար): Ընդհանուր առմամբ կան ավելի քան հարյուր հիսուն բաղադրիչներ, ահա դրանցից մի քանիսի նկարագրությունը.

backend
Պարունակում է հարթակի մետատվյալների շարժիչը

ակնտ
Օբյեկտներ, որոնք հավելվածի մշակողները օգտագործում են հաշվապահական հաշվառումներ ստեղծելու համար (հաշիվների գծապատկերներ և հաշվապահական գրանցամատյաններ)

bsl
Ներկառուցված լեզվի կատարման շարժիչ

ԱԷԿ
Հիշողության բաշխիչի անհատական ​​իրականացում

dbeng8
Ֆայլերի տվյալների բազայի շարժիչ: Պարզ ֆայլերի սերվերի տվյալների բազայի շարժիչ, որը հիմնված է ISAM-ի վրա, որը ներառում է նաև պարզ SQL պրոցեսոր

wbase
Պարունակում է բազային դասեր և գործառույթներ Windows-ի օգտատիրոջ միջերեսի իրականացման համար՝ պատուհանների դասեր, GDI մուտք և այլն:

Բազմաթիվ բաղադրիչների բաժանումը օգտակար է մի քանի տեսանկյունից.

• Տարանջատումը նպաստում է ավելի լավ դիզայնի, մասնավորապես ավելի լավ ծածկագրի մեկուսացմանը
• Բաղադրիչների մի շարքից դուք կարող եք ճկուն կերպով հավաքել առաքման տարբեր տարբերակներ.
  • Օրինակ, thin client-ի տեղադրումը կպարունակի wbase, բայց չի ունենա backend
  • բայց wbase սերվերում, ընդհակառակը, չի լինի
  • երկու տարբերակներն էլ, իհարկե, կպարունակեն միջուկային զենք և 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 գործընթացի հայեցակարգը, որը ծառայում է որպես բեռնարկղ՝ գործարկվող ծառայությունների համար (այսինքն՝ խաղում է Ծառայությունների տեղորոշիչի դերը), ինչպես նաև պարունակում է կապ տեղայնացված ռեսուրսների համար: SCOM գործընթացը կապված է ՕՀ թեմայի հետ: Դրա շնորհիվ հավելվածի ներսում կարող եք ստանալ այսպիսի ծառայություններ.

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

Ավելին, թելի հետ կապված տրամաբանական (SCOM) պրոցեսները փոխարկելով, դուք կարող եք ստանալ այնպիսի հավելվածներ, որոնք գործնականում անկախ են տեղեկատվական տարածության տեսակետից, որոնք աշխատում են նույն թելի մեջ: Ահա թե ինչպես է մեր thin client-ը աշխատում ֆայլերի տվյալների բազայի հետ. մեկ 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 ՕՀ-ում

Ինտերֆեյս 1C - վեբ հաճախորդ

Բաց կոդով

Չնայած մենք չենք օգտագործում ստանդարտ գրադարաններ C++ ծրագրավորողների համար Windows-ի տակ (MFC, վերահսկումներ WinAPI-ից), մենք ինքներս չենք գրում բոլոր բաղադրիչները: Գրադարանի մասին արդեն նշվել է wx Վիդջեթներ, և մենք նաև օգտագործում ենք.

• cURL HTTP-ի և FTP-ի հետ աշխատելու համար:
• OpenSSL գաղտնագրության հետ աշխատելու և TLS կապեր հաստատելու համար
• libxml2 և libxslt XML վերլուծության համար
• լիբեթպան փոստի արձանագրությունների հետ աշխատելու համար (POP3, SMTP, IMAP)
• միմիտիկ էլփոստի հաղորդագրությունները վերլուծելու համար
• sqllite օգտագործողների տեղեկամատյանները պահելու համար
• ICU միջազգայնացման համար

Ցուցակը շարունակվում է:
Բացի այդ, մենք օգտագործում ենք խիստ փոփոխված տարբերակ Google Test и Google Mock միավորի թեստեր մշակելիս:
Գրադարանները պահանջում էին հարմարեցում SCOM բաղադրիչի կազմակերպման մոդելի հետ համատեղելի լինելու համար:
1C-ի տարածվածությունը հարթակը դարձնում է հզորության գերազանց փորձություն դրանում օգտագործվող գրադարանների համար: Օգտատերերի և սցենարների բազմազանությունը արագորեն բացահայտում է սխալները նույնիսկ կոդերի առավել հազվադեպ օգտագործվող ոլորտներում: Մենք ինքներս ուղղում ենք դրանք և փորձում վերադարձնել գրադարանի հեղինակներին։ Փոխազդեցության փորձը շատ տարբեր է ստացվում։
Կառուցապատողներ cURL и լիբեթպան արագ արձագանքել pull-խնդրանքներին, բայց patch-ը, օրինակ, in OpenSSL Մենք երբեք չենք կարողացել վերադարձնել այն։

Ամփոփում

Հոդվածում մենք անդրադարձանք 1C: Enterprise հարթակի զարգացման մի քանի հիմնական ասպեկտներին: Հոդվածի սահմանափակ շրջանակում մենք անդրադարձանք միայն որոշ հետաքրքիր, մեր կարծիքով, կողմերի։
Տարբեր հարթակի մեխանիզմների ընդհանուր նկարագրությունը կարելի է գտնել այստեղ.
Ի՞նչ թեմաներ կհետաքրքրեն ձեզ հետագա հոդվածներում:

Ինչպե՞ս է իրականացվում 1C բջջային հարթակը:
Վեբ հաճախորդի ներքին կառուցվածքի նկարագրությո՞ւնը:
Կամ գուցե ձեզ հետաքրքրում է նոր թողարկումների համար գործառույթների ընտրության, մշակման և փորձարկման գործընթացը:

Գրեք մեկնաբանություններում!

Source: www.habr.com