Նշումներ Looking Glass 1s-ից: Բջջային հաճախորդ: Կառույցների ընդգծում գույնով

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

Հոդվածը կարդալուց հետո դուք կսովորեք.

• Ի՞նչ է համատեքստի հուշումը և ինչպե՞ս է այն օգնում ծրագրի կոդը գրելիս:
• Ինչի՞ համար են նախատեսված տեքստային ձևանմուշները և ինչպե՞ս դրանք կիրառել գործնականում:
• Ինչու՞ օգտագործել ծածկագրի տողերի խմբավորումը:
• Ինչպե՞ս կարող է ընդգծումը բարելավել կոդերի խմբագրի գործածելիությունը:
• Ո՞րն է նոր որոնման օգուտը կազմաձևման ծառում:
• Ինչպե՞ս արագ ցուցադրել ցանկալի ենթահամակարգի օբյեկտները:
• Վերամշակման և դեմոդալացման ի՞նչ գործիքներ կան և ինչպես օգտագործել դրանք:

Կիրառելիություն

Հոդվածում քննարկվում են կոնֆիգուրատորի հնարավորությունները՝ օգտագործելով 1C:Enterprise հարթակի օրինակը, 1C 8.3.5 - 8.3.11 հրատարակությունները, ուստի բոլոր տեղեկությունները տեղին են:

Բարելավումներ 1C:Enterprise 8.3 հարթակի կոնֆիգուրատորում

1C:Enterprise 8.3 հարթակի նոր տարբերակը թողարկելու ժամանակ մշակողները մի քանի հետաքրքիր և օգտակար նորամուծություններ են ավելացրել՝ պարզեցնելու հարյուրավոր ծրագրավորողների ամենօրյա աշխատանքը ողջ երկրում:

Այժմ, կոնֆիգուրատորի խմբագրիչում մոդուլի կոդը գրելիս, համատեքստի գործիքի հուշումը ցուցադրում է ոչ միայն տվյալ համատեքստում գործող փոփոխականների և ընթացակարգերի անունները, այլև խմբագրվողի պարամետրերը: այս պահինընթացակարգեր կամ գործառույթներ:

Նոր գործառույթը հասանելի է ինչպես ներկառուցված ընթացակարգերի, այնպես էլ մշակողի սեփական ընթացակարգերի համար:

Գործիքների հուշումը պարամետրերի ցանկով ունի հետևյալ տեսքը.

Ընթացակարգի պարամետրը, որն այժմ պետք է մուտքագրվի, ցուցադրվում է թավով: Հորիզոնական գծի տակ ներկայացված է ընթացիկ պարամետրի նկարագրությունը: Եթե ​​դա պարտադիր է, դա ընդգծվում է փակագծերում տեքստի միջոցով:

Եթե ​​ներկառուցված ընթացակարգի համար կան մի քանի շարահյուսական տարբերակներ, վերնագրում սլաքները հասանելի են դառնում այդ տարբերակների միջև անցնելու համար:

Ընթացակարգի և գործառույթի պարամետրերի համատեքստային օգնությունը հասանելի է սեղմելով ստեղնաշարի դյուրանցումը Ctrl + Shift + Spacebar: Այն կարող է նաև ինքնաբերաբար կանչվել «(» և «,» նիշերը մուտքագրելիս: Այս վարքագիծը կարող է միացված լինել կոնֆիգուրատորի պարամետրերի երկխոսության մեջ (մենյուի տարր Գործիքներ - Ընտրանքներ, Մոդուլներ ներդիր - Համատեքստային օգնություն):

Համատեքստի նոր գործիքի հուշման մեկ այլ օգտակար հատկանիշ է անհատական ​​ընթացակարգերի և գործառույթների պարամետրերը ցուցադրելու հնարավորությունը:

Մեծացնելու համար սեղմեք նկարի վրա։

Հիշեցնենք, որ կա «1C: Enterprise 8 պլատֆորմի համար կոնֆիգուրացիաների մշակման ստանդարտների և մեթոդների համակարգ» փաստաթուղթ, որը նկարագրում է 1C ընկերության առաջարկությունները մշակված ծրագրի կոդի համար:

Այսպիսով, «Պարամետրեր» բաժինը նկարագրում է ընթացակարգի (գործառույթի) պարամետրերը: Եթե ​​դրանք չկան, բաժինը բաց է թողնվում:

Դրան նախորդում է «Պարամետրեր:» տողը, այնուհետև բոլոր պարամետրերի նկարագրությունները տեղադրվում են նոր տողում: Պարամետրերի նկարագրությունը սկսվում է նոր տողից, որին հաջորդում է պարամետրի անունը, այնուհետև գծիկ և տեսակների ցանկ, այնուհետև գծիկ և պարամետրի տեքստային նկարագրություն:

Օրինակ.

// Պատրաստել պատասխանի ձևը գոյություն ունեցող նամակին:
// Պարամետրեր:
// IncomingLetter - DirectoryLink - նամակ, որին դուք պետք է պատասխանեք:
// OutgoingLetter – DirectoryLink.OutgoingLetter – ձևի տվյալներ DirectoryLink.OutgoingLetter տեսակի համար,
// գտնվում է ելքային նամակների խմբագրման ձևում:
// Text – FormattedDocument – ​​տառի տեքստային խմբագրի դաշտ, որը գտնվում է ձևի մեջ
// ելքային նամակների խմբագիր.
Ընթացակարգը Լրացնել նամակի պատասխանը (Մուտքային նամակ, ելքային նամակ, տեքստ) Արտահանում

Եվ կոնֆիգուրատորը վերլուծում է այս կանոնների համաձայն գրված մեկնաբանությունները և օգտագործում դրանք համատեքստային օգնություն ցուցադրելու համար:

Մեծացնելու համար սեղմեք նկարի վրա։

Տվյալ ձևաչափի համաձայն ձեռքով մեկնաբանություն գրելուց խուսափելու համար հարթակը տրամադրում է տեքստային կաղապարներ, որոնք կարելի է դիտել՝ սեղմելով Ctrl + Shift + T ստեղնաշարի համադրությունը։

«Ընթացակարգ (վերնագրով)» անվանումով ձևանմուշը կազմում է ճիշտ մեկնաբանությունը։

Որպեսզի այս կաղապարն աշխատի, պարզապես խմբագրում մուտքագրեք «Proc» նիշերը, սեղմեք Ctrl+Q և ընտրեք ցանկալի ձևանմուշը համակարգի կողմից առաջարկվող ցանկից:

Կոդի տողերի խմբավորում

Մոդուլներ ստանդարտ լուծումներ 1C:Enterprise 8 հարթակում բավականին ծավալուն են, պարունակում են բավականաչափ մեծ թվովծածկագրի տողեր:

Ծրագրի կոդի ընթերցման և վերլուծության հեշտությունը բարելավելու նպատակով իրականացվել են պայմանական և ցիկլային հայտարարությունների խմբավորման գործառույթներ, ինչպես նաև ընթացակարգեր:

8.3 պլատֆորմը տալիս է ևս մեկ տարբերակ՝ խմբավորել կամայական մոդուլի տողերը մեկ խմբի մեջ՝ ըստ տրամաբանական սկզբունքի, այնուհետև այն փլուզել, որպեսզի այն ավելի քիչ տեղ զբաղեցնի էկրանին՝ տեքստի ընթեռնելիությունը բարելավելու համար:

Տեքստի տարածք ընտրելու համար ներկայացվել են երկու նոր նախապրոցեսորի հրահանգներ #Area և #EndArea:

Կոդի կատարման ժամանակ այս հրահանգները անտեսվում են: Դրանք անհրաժեշտ են միայն ծալվող կոդի տողերը նշելու համար:

Մեծացնելու համար սեղմեք նկարի վրա։

Դուք պետք է համոզվեք, որ խմբավորված տարածքները չեն հատվում միմյանց հետ, քանի որ այս դեպքում նրանք չեն փլվի էկրանին:

Տեքստի ձևանմուշն ավելացվել է #Region հապավումների կոնֆիգուրատորին, որն ավտոմատ կերպով կավելացնի նոր տարածաշրջան ստեղծելու հրահանգներ մոդուլի տեքստում:

Կազմաձևողի կարգավորումների երկխոսության մեջ (մենյուի տարր Գործիքներ – Ընտրանքներ, ներդիր Մոդուլներ – Խմբավորում) կարող եք կարգավորել տեքստի տարածքների խմբավորումն ու փլուզումը:

Կառույցների ընդգծում գույնով

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

Մեծացնելու համար սեղմեք նկարի վրա։

Հարթակի մեկ այլ նորամուծություն է բացվող և փակվող փակագծերի գունավոր ընդգծումը։ Սա շատ օգտակար է երկար արտահայտություններ գրելիս, երբ շարահյուսական հսկողությունը հայտնում է սխալի մասին, և մշակողը պետք է գտնի լրացուցիչ կամ բացակայող փակագծեր։

Մեծացնելու համար սեղմեք նկարի վրա։

Կազմաձևողի պարամետրերի երկխոսության մեջ (մենյուի տարր Գործիքներ – Ընտրանքներ, ներդիր Մոդուլներ – Խմբագրում) կարող եք կարգավորել ևս մի քանի օգտակար կառույցների գունային ընդգծումը:

Եթե ​​դուք ընտրում եք «Ընթացիկ նույնացուցիչ» պարամետրը և դրան վերագրում եք խմբագրման ֆոնի գույնից տարբերվող գույն (սպիտակ լռելյայն), ապա երբ կուրսորը տեղադրում եք որևէ ծրագրի կոդի նույնացուցիչի վրա, այն ինքնին ընդգծվում է ընտրված գույնով, և բացի այդ. բոլոր նույն նույնացուցիչները ընդգծված են, որոնք տեղի են ունենում մոդուլում, և լարային հաստատունները նույն նույնացուցիչով փակված չակերտների մեջ.

Մեծացնելու համար սեղմեք նկարի վրա։

Հետաքրքիր է նաև «Ընտրված ID» պարամետրը: Եթե ​​այն սահմանված է այնպիսի գույնի վրա, որը չի համապատասխանում խմբագրման ֆոնի գույնին, ապա երբ դուք կրկնակի սեղմում եք նույնացուցիչի վրա, և՛ այն, և՛ բոլոր համապատասխան նույնացուցիչները մոդուլի տեքստում կնշվեն:

Մեծացնելու համար սեղմեք նկարի վրա։

Մոդուլի տեքստում որոնում կատարելիս որոնման տողի միջոցով կամ Ctrl + F ստեղնաշարի համակցությունը սեղմելուց հետո ընդգծվում է գտնված բառը և ընդգծվում են նույն գտնված բառերը:

Մեծացնելու համար սեղմեք նկարի վրա։

Բջիջների միացում աղյուսակային փաստաթղթում

Նախկինում աղյուսակային փաստաթղթի բջիջները կարող էին միավորվել միայն ցանկի տարրի կամ համապատասխան հրամանի տողի կոճակի միջոցով:

Այժմ հայտնվել է Ctrl + M ստեղների համակցությունը, սեղմելիս աղյուսակի փաստաթղթի բջիջները միաձուլվում են: «Միաձուլում» գործողությունը հասանելի է նաև աղյուսակային փաստաթղթի համատեքստային ընտրացանկում:

Հուսով ենք, որ 1C:Enterprise 8 պլատֆորմի հաջորդ թողարկումներում մշակողները ուշադրություն կդարձնեն կոնֆիգուրատորի հետ աշխատելու հարմարավետության բարելավմանը:

Նոր հնարավորություններ մշակողների համար 1C:Enterprise 8.3.5

Որոնեք կոնֆիգուրատորում

Կարգավորելիս դուք պետք է անընդհատ օգտագործեք որոնումը: Քանի դեռ կոնֆիգուրացիան պարունակում է համեմատաբար փոքր թվով մետատվյալների օբյեկտներ, դուք կարող եք որոնել տեսողականորեն՝ ձեր աչքերով, ոլորելով կազմաձևման ծառի միջով:

Այնուամենայնիվ, բնորոշ կոնֆիգուրացիաները բավականին մեծ են, և այս մոտեցմամբ որոնումը երկար ժամանակ կպահանջի:

Մինչև 8.3.5 հարթակի թողարկումը, մետատվյալների ծառի որոնումը կարող էր կատարվել հետևյալ կերպ.

• մուտքագրեք օբյեկտի անունը ստեղնաշարից, և համակարգը կփնտրի անվան համապատասխանությունը՝ սկսած անվան առաջին տառից, բայց միայն կազմաձևման ծառի ընդլայնված տողերում.
• Օգտագործեք ստեղնաշարի դյուրանցումը Ctrl+F՝ որոնման պատուհանը բացելու համար.

Գտնված օբյեկտները կցուցադրվեն Որոնման արդյունքների պատուհանում, որտեղից կարող եք կրկնակի սեղմել՝ կոնֆիգուրացիայի ծառի ցանկալի մետատվյալների օբյեկտին գնալու համար:

Պլատֆորմ 8.3.5-ը ներկայացրեց նոր որոնման դաշտ, որը գտնվում է կազմաձևման ծառի վերևում.

Որոնումն իրականացվում է տողի առաջացման հիման վրա, և վերլուծվում են կազմաձևման օբյեկտների Անունը, Հոմանիշը և Մեկնաբանությունը:

Ավելին, կոնֆիգուրացիայի ծառը զտվում է «թռիչքի վրա». դրանում մնում են միայն այն օբյեկտները, որոնք բավարարում են մուտքագրված ֆիլտրը:

Եկեք տեսնենք, թե ինչ են նշանակում գույները ֆիլտրը կիրառելուց հետո ծառի մեջ մնացած առարկաների համար:

Եթե ​​որոնման տողը գտնվել է, ապա կոնֆիգուրացիայի ծառում նման օբյեկտի անունը ընդգծված է սևով:

Եթե, ի լրումն, որոնված տողը առկա է օբյեկտի անվան մեջ (ոչ հոմանիշի մեջ, ոչ մեկնաբանությունում), ապա նման երևույթները ընդգծվում են կարմիրով:

Օբյեկտները, որոնք իրենք չեն համապատասխանում մուտքագրված ֆիլտրին, բայց ունեն ստորադաս (երեխա) օբյեկտներ, որոնք բավարարում են նշված ֆիլտրը, ընդգծված են մոխրագույնով:

Վերոնշյալ նկարում հենարանները IB օգտվողի IDգրացուցակ Օգտատերերցուցադրվում է ծառի մեջ, քանի որ դրա հոմանիշը պարունակում է «փոստ» ենթատողը.

Որոնման համար ընդունելի է մուտքագրել մի քանի ենթատողեր, որոնք բաժանված են բացատներով.

Նմանատիպ որոնման տող հայտնվեց պատուհանում, որը պարունակում է ընտրված օբյեկտի հատկությունների մի շարք (հատկությունների պալիտրա).

Գտնված հատկությունները կցուցադրվեն ընդհանուր ցանկում՝ առանց կատեգորիաների բաժանվելու:

Որոնումը կիրականացվի կամ սեփականության անվանումներով կամ սեփականության դիտումներով (տարբերությունը ցույց է տրված վերը նշված երկու սքրինշոթներում):

Դուք կարող եք անցնել անուն/ներկայացման ռեժիմների միջև՝ օգտագործելով համատեքստի ընտրացանկի «Ցուցադրել սեփականության անունները» հրամանը.

Նույն որոնման տողը ավելացվել է տվյալների տեսակի ընտրության պատուհանում.

Իսկ մետատվյալների օբյեկտ ընտրելու պատուհանում (օրինակ՝ ընտրելով տեղեկատվական ռեգիստր, որը կօգտագործվի որպես հաշվարկային ռեգիստրի գրաֆիկ).

Մեկ կոնկրետ ենթահամակարգում ընդգրկված օբյեկտները արագ ցուցադրելու համար համատեքստի ընտրացանկում հայտնվել է «Ենթահամակարգի օբյեկտներ» նոր տարր.

Հիշենք, թե ինչպես կարելի էր դրան հասնել պլատֆորմի նախորդ տարբերակներում:

Անհրաժեշտ էր բացել ենթահամակարգերի ընտրության պատուհանը, ստուգել անհրաժեշտ ենթահամակարգի վանդակը և հանել բոլոր մյուս ենթահամակարգերի նշումը.

Այժմ դուք կարող եք նույն արդյունքը ստանալ ավելի արագ: Բացի այդ, ընտրությունն ըստ մեկ ենթահամակարգի առավել հաճախ օգտագործվում է և ամենապահանջվածը:

Եվ, հետևաբար, այս փոքրիկ հարմար նորարարությունը կխնայի մշակողի ժամանակը:

Արագ ցուցադրեք պահեստում նկարահանված օբյեկտները

Եթե ​​կոնֆիգուրացիան միացված է պահեստին, ապա «Գրված օբյեկտներ» կոճակը հասանելի է հենց կազմաձևման ծառի վերևում գտնվող հրամանի վահանակում.

Այժմ զտումն իրականացվում է ուղղակիորեն կազմաձևման ծառում, կարիք չկա առանձին պատուհան բացել պահեստի հետ աշխատելու և դրա մեջ գրավված օբյեկտների ընտրությունը սահմանելու համար:

Refactoring Tools

Երբ մի քանի ծրագրավորողներից բաղկացած խումբը աշխատում է կոնֆիգուրացիայի վրա, անհրաժեշտ է ապահովել, որ կոդը հասկանալի է և հետևում է ընդհանուր ստանդարտներին:

Միշտ չէ, որ դա հնարավոր է անընդհատ վերահսկել, ուստի պարբերաբար աշխատանքներ են իրականացվում կոդի ընթեռնելիությունը բարելավելու և արդեն իսկ իրականացված հատվածները վերանայելու ուղղությամբ:

Նման գործողությունները կոչվում են կոդի վերամշակում: Սա ծրագրի ներքին կառուցվածքի փոփոխման գործընթաց է՝ առանց դրա արտաքին վարքագծի վրա ազդելու և նպատակաուղղված է հեշտացնելու այն, թե ինչպես է այն աշխատում:

Բացի այդ, մշակողները պետք է աշխատեն իրենց կոնֆիգուրացիաներում, որպեսզի հրաժարվեն մոդալից՝ վերացնել մոդալ զանգերը:

Հետևաբար, պլատֆորմի 8.3.5 կոնֆիգուրատորն այժմ ներառում է կոդի վերամշակման մեխանիզմներ և գործիքներ՝ մոդալ զանգերի հետ աշխատելու համար։

Դրանք հասանելի են կոնֆիգուրատորի տեքստային խմբագրիչի համատեքստային մենյուում՝ առանձին Refactoring մենյուում:

Մեծացնելու համար սեղմեք նկարի վրա։

Եկեք մանրամասն նայենք իրականացված վերամշակման գործիքներին:

1. Ընտրեք հատված

Այս հրամանը վերափոխում է կոդի ընտրված հատվածը առանձին ընթացակարգի կամ ֆունկցիայի:

Եթե ​​պրոցեդուրան, որի շրջանակներում գտնվում է ընտրված բաժինը, պարունակում է կոմպիլյացիոն հրահանգ (&Client-ի վրա, &On the Server և այլն), ապա ստեղծված պրոցեդուրան կամ ֆունկցիան կունենա նույն կոմպիլյատորական հրահանգը:

Եթե ​​կոդի ընդգծված հատվածը կարող է տեղակայվել հանձնարարության օպերատորի աջ կողմում, ապա կստեղծվի ֆունկցիա: Դիտարկենք մի օրինակ։ Թող լինի կոդի հատված.

&OnClient
Ընթացակարգը ԱպրանքներԱպրանք Երբ փոխվում է(տարր)
Փող = ;
Էջի գին = Ստացեք ապրանքի գինը(Object.Date, Page.Product);

Ընթացակարգի ավարտը

Եթե ​​կիրառեք «Ընտրել հատված» հրամանը կոդի ընտրված հատվածի վրա, համակարգը կստեղծի հետևյալ ծրագրի կոդը (ստեղծեք նոր գործառույթ).

&OnClient
Ընթացակարգը ԱպրանքներԱպրանք Երբ փոխվում է(տարր)
Էջ = Items.Products.CurrentData;
Էջի գին = Ստացեք ապրանքի գինը(Object.Date, Page.Product);
Էջի գումարը = CalculateAmount(էջ);
Ընթացակարգի ավարտը
&OnClient
Գործառույթ CalculateAmount(Արժեքի էջ)
Հետադարձ Էջի քանակ * Էջի գինը ;
EndFunction

Նաև գործառույթ կստեղծվի, եթե կոդի ընտրված հատվածում կա վերագրում մեկ փոփոխականի, որն օգտագործվում է ստորև կոդի մեջ: Օրինակ.

&OnClient
Ընթացակարգը ԱպրանքներԳինը երբ փոխվում է(տարր)
Էջ = Items.Products.CurrentData;
Էջի գումարը = Էջի քանակը * Էջի գինը ;
Ընթացակարգի ավարտը

Ընտրված տարածքը կփոխակերպվի հետևյալ կերպ.

&OnClient
Ընթացակարգը ԱպրանքներԳինը երբ փոխվում է(տարր)
Էջ = CurrentLineProducts();
Էջի գումարը = Էջի քանակը * Էջի գինը ;
Ընթացակարգի ավարտը
&OnClient
Գործառույթ CurrentLineProducts()
Փոփոխական էջ;
Էջ = Items.Products.CurrentData
Վերադարձի էջ;
EndFunction

2. Վերանվանել

Այս հրամանը թույլ է տալիս փոխել փոփոխականի կամ ընթացակարգի (ֆունկցիայի) անվանումը բոլոր այն վայրերում, որտեղ այն իրականում օգտագործվում է:

Եթե ​​փոփոխականի կամ մեթոդի բոլոր երևույթները եզակիորեն նույնականացվեն, համակարգը ձեզ կառաջարկի նշել նոր անուն և կատարել փոխարինում, որտեղ էլ որ հայտնվի այս նույնացուցիչը:

Եթե ​​փոփոխականի կամ մեթոդի բոլոր կիրառությունները չեն կարող եզակիորեն նույնականացվել, ապա համակարգը ցուցադրում է հարց և ցուցադրում երևույթները.

Եկեք դիտարկենք մի իրավիճակ, երբ համակարգը չի կարող ավտոմատ կերպով փոխարինել ընթացակարգի անվանումը:

Փաստաթղթի մոդուլում թող լինի ընթացակարգ.

Procedure Recalculate() Export
Բոլորի համար TechStringProductsԱպրանքների ցիկլից
TechStringProducts.Amount= TechStringProducts.Quantity* TechStringProducts.Price;
Վերջնական ցիկլ;
Ընթացակարգի ավարտը

Եվ այս փաստաթղթի ձևի մոդուլում կա հետևյալ մշակիչը.

&Սերվերի վրա
Ընթացակարգը RecalculateOnServer()
Փաստաթուղթ = PropsFormValue(«Օբյեկտ»);
Փաստաթուղթ.Վերահաշվարկել();
ValueInFormProps(Փաստաթուղթ, «Օբյեկտ»);
//հետագա մշակում...

Ընթացակարգի ավարտը

Պատկերապատում կարմիրով բացականչական կետորոնման արդյունքների պատուհանում նշանակում է, որ դուք կարող եք եզակի և ճշգրիտ բացահայտել ընթացակարգի օգտագործումը կոդերի տողում Վերահաշվարկ ()համակարգը ձախողվեց:

Դա պայմանավորված է նրանով, որ համակարգը չի կարող ավտոմատ կերպով որոշել փոփոխականի տեսակը Փաստաթուղթֆունկցիան կատարելուց հետո FormAttributesValue().

Համատեքստային գործիքի հուշման մեխանիզմն այս դեպքում նույնպես հնարավոր տարբերակներ չի առաջարկում փոփոխականից հետո կետը սեղմելիս Փաստաթուղթկամ սեղմելով ստեղների համակցությունը Ctrl+Space:

Մեծացնելու համար սեղմեք նկարի վրա։

Ընթացակարգի վերանվանումը ձևի մոդուլում, օգտագործելով refactoring հրամանը, փոխում է նաև կարգավորիչի հղումը ձևի տարրերի հատկությունների և հրամանների մեջ:

3. Ստեղծեք ֆունկցիայի նկարագրություն

Հրամանը ստեղծում է մեկնաբանություն ընթացակարգից կամ ֆունկցիայից առաջ, որը ճիշտ կընկալվի համատեքստի գործիքի կողմից։

// Ընթացակարգ – Լրացրեք նամակը կաղապարի միջոցով
// Պարամետրեր:
// Ելքային Նամակ – –
// Տեքստ - -
Ընթացակարգը Լրացրեք նամակ՝ օգտագործելով ձևանմուշ(Ելքային Նամակ, Տեքստ ) Արտահանում
//…
Ընթացակարգի ավարտը

Համակարգը ստեղծում է մեկնաբանությունների ձևանմուշ, որում անհրաժեշտ է տեղադրել պարամետրերի տեսակներն ու բացատրությունները:

Այնուհետև կոդ գրելիս կարող եք օգտագործել ընդլայնված հուշումը։

4. Ստեղծեք ահազանգերի մշակում

Այս հրամանը հասանելի է դառնում համատեքստի ընտրացանկում, երբ կուրսորը տեղադրվում է մեթոդի անվան վրա, որին հաջորդում է բացվող փակագիծը:

Ավելին, սրանք այնպիսի մեթոդներ են, ինչպիսիք են ShowQuestion (),ShowWarning (), ShowNumberEnter()և մոդալ մեթոդների արգելափակման այլ անալոգներ:

Դիտարկենք մի օրինակ։ Սկսենք գրել հաճախորդի հրամանների մշակիչ, կուրսորը դրեք հանդիպած մեթոդին ShowQuestion (), զանգահարեք «Ստեղծել ծանուցման մշակիչ» հրամանը՝

&OnClient
Ընթացակարգը Լրացրեք նյութեր(Թիմ)
Ցույց տալ Հարցը (
Ընթացակարգի ավարտը
Արդյունքում համակարգը կստեղծի հետևյալ ծրագրի կոդը.
&OnClient
Ընթացակարգը Լրացրեք նյութեր(Թիմ)
ShowQuestion (Նոր Նկարագրություն Ահազանգեր(«Լրացրեք նյութերը Ավարտված», ThisObject ));
Ընթացակարգի ավարտը
&OnClient
Ընթացակարգը Լրացրեք Նյութերի ավարտը(Հարցի արդյունք, Լրացուցիչ ընտրանքներ) Արտահանում
Ընթացակարգի ավարտը

5. Փոխակերպել մոդալ զանգը

Այս հրամանը փոխակերպում է մոդալ մեթոդ պարունակող կոդի հատվածը իր ասինխրոն օրինակին։ Դիտարկենք մի քանի օրինակ։

Եկեք զանգը փոխակերպենք Warning() մեթոդի.

&OnClient
Ընթացակարգը ՆյուՀենդլեր()
A = 1;
Զգուշացում («Տեքստ»);
A = 2;
Ընթացակարգի ավարտը // NewHandler ()

Նշված հրամանը կիրառելուց հետո ծրագրի կոդը կստանա հետևյալ ձևը.

&OnClient
Ընթացակարգը ՆյուՀենդլեր()
A = 1;
Ցույց տալ Զգուշացում(Նոր Նկարագրություն Ահազանգեր(«NewHandlerCompletion», այս օբյեկտը),
«Տեքստ»);
Ընթացակարգի ավարտը
&OnClient
Ընթացակարգը NewHandlerCompletion(Լրացուցիչ ընտրանքներ) Արտահանում
A = 2;
Ընթացակարգի ավարտը

Բարդացնենք օրինակը. Դիտարկենք մոդալ ֆունկցիայի և պայմանական օպերատորի օգտագործումը.

&OnClient
Ընթացակարգը ՆյուՀենդլեր()
Պատասխան = Հարց (,
Երկխոսության ռեժիմ Հարց: Այո Ոչ);
Եթե ​​Պատասխան = Երկխոսության վերադարձի կոդը: ԱյոՀետո
//լրացման ալգորիթմ
Վերջ Եթե ;
Ընթացակարգի ավարտը

Մոդալ զանգը փոխակերպելուց հետո մենք ստանում ենք.

&OnClient
Ընթացակարգը ՆյուՀենդլեր()
Պատասխան = Չսահմանված;
ShowQuestion (Նոր Նկարագրություն Ահազանգեր(«NewHandlerCompletion», այս օբյեկտը),
«Աղյուսակային մասը կջնջվի։ Շարունակե՞լ»։, Երկխոսության ռեժիմ Հարց: Այո Ոչ);
Ընթացակարգի ավարտը
&OnClient
Ընթացակարգը NewHandlerCompletion(Հարցի արդյունք, Լրացուցիչ ընտրանքներ) Արտահանում
Պատասխան = Հարցի արդյունք;
Եթե ​​Պատասխան = Երկխոսության վերադարձի կոդը: ԱյոՀետո
//լրացման ալգորիթմ
Վերջ Եթե ;
Ընթացակարգի ավարտը

Ստացված հատվածում պետք է ընդգծել Answer փոփոխականի սկզբնավորումը:

6. Փոխակերպել ասինխրոն ընթացակարգի

Վերևում քննարկված օրինակներում փոխակերպվեցին մեթոդներ, որոնք ունեին իրենց ասինխրոն նմանակները: Օրինակ՝ Հարց ()Եվ ShowQuestion (), Զգուշացում ()Եվ ShowWarning ().

Այնուամենայնիվ, եթե մոդալ զանգը գտնվում է ընթացակարգի ներսում, որն իր հերթին գտնվում է մեկ այլ ընթացակարգի ներսում, ապա մոդալ մեթոդով ամբողջ ընթացակարգի կանչը ներսում կլինի մոդալ:

Սա նշանակում է, որ այն պետք է փոխարինվի «ասինխրոն անալոգով», բայց ոչ թե ներկառուցված լեզվով գոյություն ունեցողով, այլ մեր մշակած մեթոդով։

Դրա համար նախատեսված է «Refactoring» ենթամենյուի մեկ այլ հրաման՝ «Փոխակերպել ասինխրոն ընթացակարգին»: Եկեք բացատրենք ընթացակարգի օրինակով, որը կանչում է մեկ այլ ընթացակարգ՝ ներսում մոդալ ֆունկցիայով.

&OnClient
Ընթացակարգը ՆյուՀենդլեր()
A = 1;
NestedProcedure();
A = 2;
Ընթացակարգի ավարտը & Հաճախորդի վրա
Ընթացակարգը NestedProcedure()
Զգուշացում («Տեքստ»);
Ընթացակարգի ավարտը

Տեղադրեք կուրսորը ընթացակարգի հայտարարության վրա NestedProcedure (), մենք փոխակերպում ենք ասինխրոն ընթացակարգի: Համակարգը մեզ կառուցում է հետևյալ կոդը՝&OnClient
Ընթացակարգը NewHandlerCompletion(Արդյունք, Լրացուցիչ ընտրանքներ) Արտահանում
Զգուշացում = ;
A = 2;
Կատարել ահազանգերի մշակում(Զգուշացում);
Ընթացակարգի ավարտը & Հաճախորդի վրա
Ընթացակարգը NestedProcedure(Զգուշացման արժեք)
Զգուշացում («Տեքստ»);
Կատարել ահազանգերի մշակում(Զգուշացում);
Ընթացակարգի ավարտը

Խնդրում ենք նկատի ունենալ համակարգի կողմից ավելացված մեթոդը Կատարել ահազանգերի մշակում (), որն օգտագործվում է ընթացակարգերի իրականացման համար, որոնք կարող են ներսից բացել արգելափակող պատուհանները, սակայն դրանց արդյունքը պետք է վերադարձնի կանչի ընթացակարգերին։

Պետք է հիշել, որ ասինխրոն ընթացակարգի փոխարկելու անմիջական խնդիրն է ընտրված ընթացակարգի զանգերի հաջորդականությունը փոխարկել ասինխրոն ձևի, բայց ինքնին ընթացակարգում տեղակայված զանգերը չեն փոխվում:

Ահա թե ինչու մեթոդը Զգուշացում ()չի փոխարինվել։ Դա պետք է արվի ասինխրոն ընթացակարգի փոխարկվելուց հետո՝ առանձին զանգահարելով «Փոխակերպել մոդալ զանգը» հրամանը:

Եթե ​​բնօրինակ կոդի հատվածում պարունակող տողում Զգուշացում (), գործարկեք «Փոխակերպեք մոդալ զանգը» հրամանը, համակարգը կհարցնի.

Արդյունքը կլինի հետևյալը.

&OnClient
Ընթացակարգը ՆյուՀենդլեր(Զգուշացման արժեք)
A = 1;
NestedProcedure(Նոր Նկարագրություն Ահազանգեր(«NewHandlerCompletion»,
ThisObject , Նոր կառուցվածք («Alert» , Alert )));
Ընթացակարգի ավարտը & Հաճախորդի վրա
Ընթացակարգը NewHandlerCompletion(Արդյունք, Լրացուցիչ ընտրանքներ) Արտահանում
Զգուշացում = AdditionalOptions.Ծանուցում;
A = 2;
Կատարել ահազանգերի մշակում(Զգուշացում);
Ընթացակարգի ավարտը & Հաճախորդի վրա
Ընթացակարգը NestedProcedure(Զգուշացման արժեք)
Ցույց տալ Զգուշացում(Նոր Նկարագրություն Ահազանգեր(«Ներդրված ընթացակարգի ավարտը»,
ThisObject, New Structure («Ծանուցում», Ծանուցում )), «Text»);
Ընթացակարգի ավարտը
&OnClient
Ընթացակարգը NestedProcedureԱվարտում ( Լրացուցիչ ընտրանքներ) Արտահանում
Զգուշացում = AdditionalOptions.Ծանուցում;
Կատարել ահազանգերի մշակում(Զգուշացում);
Ընթացակարգի ավարտը

7. Հատկացնել ասինխրոն ընթացակարգին

Այս հրամանը վերափոխում է կոդի ընդգծված հատվածը ընթացակարգի կամ ֆունկցիայի՝ միաժամանակ ընդգծված մեթոդը փոխակերպելով ասինխրոն մեթոդի։

Ի տարբերություն նախորդ պարբերության, այս հրամանը «կոմպոզիտ» է. նախ կոդի ընտրված հատվածը տեղափոխվում է նոր ընթացակարգ, որի անունը օգտվողը մուտքագրում է երկխոսության վանդակում:

Այնուհետև այն կատարում է նույն քայլերը, կարծես օգտագործողը պետք է աջ սեղմի նոր ստեղծված ընթացակարգի վերնագրի վրա և այնուհետև սեղմի «Փոխարկել ասինխրոն ընթացակարգին»:

8. Գտեք մոդալ մոդուլի զանգեր

Վերը նկարագրված հրամաններն աշխատում են մեկ մեթոդով կամ կոդի ընտրված հատվածով:

Գործարկվել են ընթացակարգեր, որոնք մշակում են ամբողջ մոդուլը, օրինակ՝ մոդալ զանգերի որոնում ամբողջ մոդուլի ներսում:

Գտնված կոդի տողերը կցուցադրվեն որոնման արդյունքների պատուհանում.

Մեծացնելու համար սեղմեք նկարի վրա։

9. Փոխարկել մոդալ մոդուլի զանգերը

Այս հրամանը փոխակերպումներ է կատարում բաց մոդուլում, բայց միայն այն զանգերը, որոնք չեն պահանջում մշակողի միջամտությունը:

Նաև հիմնական ընտրացանկում կա հրաման (Կազմաձևում – Վերափոխում – Վերլուծեք մոդալ կոնֆիգուրացիայի կանչերը):

Այն նաև որոնում է մոդալ զանգեր, միայն ամբողջ կազմաձևում, ստուգում՝ արդյոք մոդալ զանգերը կարող են ինքնաբերաբար փոխարկվել:

Մեծացնելու համար սեղմեք նկարի վրա։

Եզրակացություն

Եզրափակելով, ժամանակագրական կարգով մենք հակիրճ կնշենք, թե ինչ լրացուցիչ օգտակար հատկություններ է ձեռք բերել կազմաձևիչը.

• Էջանիշների ցուցակները հայտնվել են մոդուլի տեքստերում, որոնք կարող են պահպանվել աշխատանքային նիստերի միջև (8.3.6+)
• Դինամիկ թարմացման դեպքում ինֆաբազայի հաճախորդ-սերվեր տարբերակում աշխատելիս անհրաժեշտություն չկար կոնֆիգուրատորը վերագործարկել (8.3.7+)
• Իրականացվել է OS X 10.8 և ավելի բարձր (8.3.7+) կոնֆիգուրացիաներ մշակելու հնարավորությունը: Այժմ և՛ կոնֆիգուրատորը, և՛ հաճախորդի հավելվածը (հաստ և բարակ հաճախորդներ) հասանելի են այս օպերացիոն համակարգում:
• Զգալիորեն ընդլայնվել են գործողությունները, որոնք կարող են կատարվել խմբաքանակի ռեժիմում (8.3.8+): Դրա շնորհիվ ավտոմատացված կազմաձևման թարմացման գործընթացը զգալիորեն պարզեցված է
• Գործարկվել է ադմինիստրատիվ կոնսոլային կոմունալ ծրագիր, որի օգնությամբ հնարավոր է դարձել շտկել ինֆաբազայի հետ կապված որոշ խնդիրներ՝ առանց կոնֆիգուրատորը գործարկելու (8.3.8+)
• Ավելացվել է ֆունկցիոնալություն՝ ընդլայնումը կազմաձևմանը միացնելու հետ կապված խնդիրները ստուգելու համար: Նախկինում նման գործառույթ չկար, և ախտորոշումը ցուցադրվում էր հաղորդագրության պատուհանում, երբ ընդլայնումը միացված էր (8.3.9+)
• 64-բիթանոց կոնֆիգուրատորի աջակցությունն իրականացվել է: Այս հատկությունը հնարավորություն տվեց վերացնել համեմատության և միաձուլման գործողությունների անբավարար հիշողության խնդիրները կոնֆիգուրացիան և ռեսուրսներ ինտենսիվ այլ գործողությունները թարմացնելու ժամանակ (8.3.9+)
• Կազմաձևիչում կառավարվող ձևի առաջին բացումը զգալիորեն արագացվել է (8.3.9+)
• Այժմ հնարավոր է մասամբ վերբեռնել խմբագրված կոնֆիգուրացիան XML ֆայլերում: Այժմ դուք կարող եք բեռնաթափել միայն այն օբյեկտները, որոնք փոխվել են վերջին բեռնաթափումից հետո: Սա զգալիորեն արագացրեց XML ֆայլեր վերբեռնելու գործընթացը, երբ փոփոխություններ են կատարվում մեծ կոնֆիգուրացիաներում (8.3.10+)
• Մոդուլները համատեղելու բարելավված կարողություն՝ հաշվի առնելով մեթոդների գտնվելու վայրը նախապրոցեսորային հրահանգներով (8.3.10+) նշված տարածքներում:
• Հաճախակի օգտագործվող զարգացման գործառնությունների արագությունը մեծացել է (8.3.11):

Բացի այդ, պլատֆորմի մշակողները թողարկումից մինչև թողարկում բարելավում են կոնֆիգուրատորի կատարումը և էրգոնոմիկան, ուստի խորհուրդ ենք տալիս, որ հնարավորության դեպքում զարգանաք ընթացիկ թողարկումների հարթակում:

Այսպիսով, եկեք անցնենք առաջ - հաջորդ հոդվածում մենք կվերադառնանք ծրագրավորմանը և կուսումնասիրենք ծրագրի կոդի համատեքստի հայեցակարգը:

Վերջերս հոդվածներ նվիրված 1C as հավելվածների մշակման միջավայր. Հոդվածներն իրենց իմաստով ավելի շատ հայեցակարգային են, քան կիրառական. Հեղինակները վերանայում են 1C:Enterprise 8 հարթակը որպես ամբողջություն՝ փորձելով հասկանալ՝ 1C-ի կողմից առաջարկվող բիզնես հավելվածների ստեղծման տեխնոլոգիան լավ է, թե վատ:

Ես չեմ քննարկի՝ հեղինակներից յուրաքանչյուրը ճիշտ է, թե սխալ. 1C հարթակը, ինչպես ցանկացած տեխնոլոգիա, ունի իր առավելություններն ու թերությունները։ Եվ դա նույնպես ունի իր հետաքրքիր առանձնահատկությունները, իր զարգացումներն ու մեխանիզմները։ Սրանք են, որոնց մասին ուզում եմ խոսել։ Եվ ես նաև ուզում եմ հոդված գրել 1C-ի մասին 1C-ին անծանոթ մարդկանց համար, հոդված, որը ցույց է տալիս, թե ինչ տեղ է զբաղեցնում 1C-ն նմանատիպ ծրագրային արտադրանքների մեջ: Անձամբ ես իսկապես բաց եմ թողել նման ներածական վերանայման հոդվածը, երբ դեռ ծանոթ չէի 1C-ին, բայց ծանոթ էի մի շարք այլ ERP արտադրանքների:

Այսպիսով, եկեք սկսենք:

Ի՞նչ է արտադրում 1C-ը:

Կարծում եմ, որ լայն հասարակությունը կպատասխանի այս հարցին. «1C: Հաշվապահություն»: Ինչ-որ մեկը կհիշի մարզումների ծրագրերը կամ հայտնի «IL-2 Sturmovik» խաղերի շարքը:

Habr-ի մասնակիցները, իհարկե, տեղյակ են, որ 1C-ը ոչ միայն «1C: Հաշվապահություն» է, որ կա «1C: Enterprise» ծրագրերի մի ամբողջ համակարգ, ներառյալ բիզնես հավելվածների մշակման գործիքները և այս գործիքների միջոցով ստեղծված բիզնես հավելվածները: Իսկ 1C մշակման գործիքների օգնությամբ գրվել են հաշվապահական հաշվառում, CRM և ERP (հազար ու տասնյակ հազարավոր օգտատերերի ներդրումներով) և շատ ավելին։

ERP համակարգերը ամենահետաքրքիր և ֆունկցիոնալ առումով հարուստ բիզնես հավելվածներն են. Օգտագործելով նրանց օրինակը՝ տեսնենք, թե ինչ տեղ են զբաղեցնում 1C:Enterprise տեխնոլոգիաները դրանց անալոգների շարքում։

Որո՞նք են ERP-ների տեսակները:

Ո՞րն է ERP համակարգերի (և ցանկացած բիզնես հավելվածների) ամենաարժեքավոր հատկությունը: Իմ կարծիքով, սա ճկունություն է, վերջնական օգտագործողի բիզնես գործընթացներին հնարավորինս ցածր գնով հարմարվելու ունակություն:

Հասկանալի է, որ ERP համակարգը ծրագրավորելիս անհնար է ապահովել բիզնես գործընթացների բոլոր տարբերակները: Պարամետրիզացիան գալիս է օգնության. Համակարգում ներդնելով պարամետրեր, որոնք կարող են փոփոխվել համակարգի կարգավորումներում օգտատիրոջ (խորհրդատու, ադմինիստրատոր) կողմից, մենք համեմատաբար ցածր գնով բարձրացնում ենք համակարգի ճկունությունը: Առաջին ERP համակարգերը հիմնված էին պարամետրերի վրա, այսինքն. կարգավորելի՝ օգտագործելով պարամետրերը:

Ոչ բոլոր բիզնես դեպքերը կարող են նախատեսված լինել պարամետրիզացվող համակարգերում: Երբ միայն պարամետրերի կարգավորումը բավարար չէ, դուք պետք է փոխեք աղբյուրի կոդը: Այստեղ ERP արտադրողը կանգնած է հարցի առաջ՝ փոխել կոդը՝ սպառողների կարիքներին համապատասխան և թողարկել թարմացումներ կամ մատակարարել համակարգը սկզբնական կոդով, որպեսզի օգտվողները կարողանան ինքնուրույն վերաշարադրել համակարգը՝ իրենց կարիքներին համապատասխան (ինչն, ի դեպ, անում է. չազատել արտադրողին թարմացումներ տրամադրելուց. համակարգը պետք է զարգանա, աջակցի նոր ֆունկցիոնալությանը, որպեսզի մրցունակ լինի):

Առանձին խնդիր է ERP համակարգ գրելու համար ծրագրավորման լեզվի ընտրությունը։ ERP համակարգի մեծ մասը բիզնես տրամաբանությունն է, որի համար սովորական ծրագրավորման լեզուները, ինչպիսին է C++-ը, միշտ չէ, որ լավագույնս համապատասխանում են: Իդեալում, լավ կլիներ բիզնես տրամաբանությունը ծրագրավորել բարձր մակարդակի լեզվով, որը կարող է բիզնես ծրագրավորողին առավելագույն հարմարավետություն ապահովել բիզնես տրամաբանություն գրելիս՝ վերացելով այն ցածր մակարդակի մանրամասներից (շտեմարանների հետ աշխատելու առանձնահատկությունները, ֆայլը I/O և տպագրական ենթահամակարգ, օգտագործողի միջերեսի պատուհանի ենթահամակարգ և այլն): Իհարկե, այս դեպքում պետք է նաև ստեղծել այս լեզվի կոմպիլյատոր/թարգմանիչ և զարգացման միջավայր։

Մենք ունենք հնարավոր համակցությունների մատրիցա.

• բաց կամ փակ հավելվածի կոդը (այստեղ ես նկատի ունեմ ոչ թե բաց կոդը՝ սովորական իմաստով, այլ հավելվածի սկզբնական կոդը տրամադրելու հնարավորությունը, այդ թվում՝ վճարովի)։
• բիզնես տրամաբանության ծրագրավորման լեզու՝ «սովորական» (C/Java/Perl/...) կամ հատուկ մշակված, սեփականություն:

1C-ի միջոցով ստեղծված բիզնես հավելվածներ. Ձեռնարկությունների տեխնոլոգիաները համակարգեր են բաց կոդով հավելվածի կոդով, որը գրված է սեփական լեզվով, որը չունի կարճ անուն; պաշտոնապես այն կոչվում է «Ներկառուցված ծրագրավորման լեզու 1C: Enterprise», ոչ պաշտոնական և հակիրճ՝ «1C լեզու»:

Ժամանակակից ERP շուկայի առաջատարներից շատերը բաց կոդով համակարգեր են: Ոլորտում ելակետային կոդը փոփոխելու ունակությունը հսկայական ճկունություն և մրցակցային առավելություն է տալիս: Փակ աղբյուրի արտադրանքը ստիպված է օգտագործել տարբեր տեխնիկա. Ամենատարածված քայլը CallBacks-ի անալոգն է՝ նախապես սահմանված իրադարձություններին հատուկ կոդ կցելու հնարավորություն՝ և՛ տեսողական (ձևի բացում և փակում, արժեքների ցանկից ընտրություն, ...), և՛ բիզնես իրադարձություններ (պատվերի մշակում, վաճառքի մուտքագրում: հաշիվ-ապրանքագիր, ...): Որոշ համակարգեր կարող են գրել իրենց մշակողները C#-ով (կամ մյուսները ունեն Visual Basic for Applications, այդ նպատակով լիցենզավորված Microsoft-ից և այլն):

Ինչպես են աշխատում ERP-ները

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

Պլատֆորմը սովորաբար գրված է ցածր մակարդակի լեզվով (C, C++), հաճախ հարթակի սկզբնական կոդը փակ է վերջնական օգտագործողների համար։ Պլատֆորմի նպատակն է ծրագրավորողին թույլ տալ վերացական լինել ցածր մակարդակի մանրամասներից (ՕՀ-ի և DBMS-ի առանձնահատկություններից և այլն) և կենտրոնանալ իրական բիզնես տրամաբանությունը գրելու վրա։ Պլատֆորմը հաճախ ներառում է նաև բիզնես հավելվածների մշակման գործիքներ և համակարգի կառավարման գործիքներ (և ես համաձայն եմ այս մոտեցման հետ): Ի դեպ, նրանք չեն կարող առանց հարթակի և համակարգի, որտեղ բիզնես տրամաբանությունը գրված է «սովորական» ծրագրավորման լեզուներով։ Այնտեղ հայտի կոդը մեկնաբանելու կարիք չկա, բայց հարթակի ֆունկցիոնալության անհրաժեշտությունը մնում է (օրինակ՝ տվյալների բազայի շուրջ «փաթաթիչներ» կամ օգտվողների ցուցակի և նրանց իրավունքների միասնական մուտք):

Պլատֆորմը, որպես բիզնես հավելվածների կատարման միջավայր, կարելի է բնութագրել որպես վիրտուալ մեքենա: Որպես կանոն, պլատֆորմը պետք է ընդօրինակի երեք հիմնական բան ERP-ի համար.

• Բիզնես տրամաբանության կատարման միջավայր.
• Տվյալների բազա.
• Հաճախորդի հավելվածը ցուցադրելու գրաֆիկական ենթահամակարգ: Հաճախորդի հավելվածը կարող է լինել գրաֆիկական, մատուցվել՝ օգտագործելով ստանդարտ ՕՀ գործիքներ (ներառյալ շարժական ՕՀ), կամ կարող է լինել վեբ հավելված: Վեբ հավելվածի դեպքում հարթակը կամ իրականացնում է իր սեփական վեբ սերվերը կամ ապահովում է ստանդարտ վեբ սերվերների աջակցություն (IIS, Apache և այլն):

Սկզբունքորեն, պլատֆորմը փոփոխելով, դուք կարող եք ERP-ն պատրաստել, որը գրված է սեփական լեզվով, աշխատեցնել ցանկացած ՕՀ-ի տակ և պահել տվյալները գրեթե ցանկացած DBMS-ում: Սովորաբար, ERP արտադրողները սահմանափակվում են մեկ կամ երկու օպերացիոն համակարգերով և մեկ կամ երկու DBMS-ներով: Լրացուցիչ OS և DBMS աջակցությունը նշանակում է զարգացման և փորձարկման ծախսերի ավելացում. ERP արտադրողները հաճախ հայտարարում են իրենց արտադրանքի նոր տարբերակներում, որ այլևս չեն աջակցի որևէ DBMS:

1C հարթակն առաջարկում է հետևյալը OS և DBMS աջակցության առումով.

• Բիզնես տրամաբանության կատարման միջավայր. կիրառական սերվերների սխալ հանդուրժող կլաստեր՝ բեռի հավասարակշռմամբ; ՕՀ - Windows կամ Linux
• Տվյալների բազա՝ սեփական ֆայլի DBMS (խորհուրդ է տրվում մշակման և փոքր տեղադրման համար), MS SQL, Oracle, IBM DB2, PostgreSQL
• Հաճախորդ:
  • thin client (միայն ցուցադրել և մուտքագրել տեղեկատվություն հաճախորդի մասին) – Windows և Linux: Կարող է աշխատել հավելվածի սերվերի հետ տեղական ցանցի կամ վեբ ծառայությունների միջոցով (այս դեպքում Microsoft IIS-ը կամ Apache-ը պետք է տեղակայվեն սերվերի կողմից)
  • Վեբ հաճախորդ՝ սերվերի կողմից Microsoft IIS կամ Apache, հաճախորդի կողմից՝ չորս բրաուզերներից որևէ մեկը՝ Internet Explorer, Chrome, Firefox, Safari
  • հաստ հաճախորդ (հաճախորդի վրա բիզնես տրամաբանության մի մասը կատարելու ունակությամբ) – Windows և Linux: Այն ունի մի շարք սահմանափակումներ (օրինակ, այն կարող է աշխատել միայն նույն տեղական ցանցում հավելվածի սերվերի հետ): Այն համարվում է հնացած;
  • Բջջային օֆլայն հաճախորդ (պարբերական համաժամացման հնարավորությամբ) – iOS և Android:

Եթե ​​1C ծրագիր գրելիս օգտագործում ենք կառավարվող հավելվածի տեխնոլոգիա (հասանելի է 2008թ.-ից), ապա մեկ հավելվածի կոդից ստանում ենք և՛ thin client Windows/Linux-ի, և՛ վեբ հաճախորդ։

ERP հավելվածի լեզու

Առանձին թեմա է այն լեզուն, որով գրված է բիզնես տրամաբանությունը։ Համար արդյունավետ աշխատանքԲիզնես ծրագրավորողի համար այս լեզուն պետք է հնարավորինս մոտ լինի բիզնես տիրույթին (իդեալական DSL, Domain Specific Language) և հեռու լինի ՕՀ-ի և DBMS-ի տեխնիկական մանրամասներից:

Վերցնենք տիպիկ բիզնես առաջադրանք՝ մենք պետք է համակարգին ավելացնենք նոր տեսակի փաստաթուղթ (օրինակ՝ պատվեր) մուտքագրելու և մշակելու հնարավորություն։ «սովորական» ծրագրավորման լեզվով գրված համակարգում դա պահանջում է.

1. Տվյալների բազայում ստեղծեք աղյուսակներ, որտեղ կպահվի փաստաթղթի մասին տեղեկատվությունը:
2. Գրեք դաս (կամ դասեր), որոնք իրականացնում են փաստաթղթի հետ աշխատելու բիզնես տրամաբանությունը: Բացի բիզնես տրամաբանությունից, դասերը պետք է իրականացնեն նաև տվյալների բազայի հետ փոխազդեցություն՝ կարդալ և գրել փաստաթղթերի տվյալները:
3. Ստեղծեք օգտատիրոջ միջերես՝ նոր փաստաթղթի տեսակը խմբագրելու համար: Հաճախ անհրաժեշտ է նաև ձևաթղթեր ստեղծել, որը կցուցադրի փաստաթղթերի ցանկ՝ ըստ տարբեր դաշտերի որոնելու հնարավորությամբ և այլն:

Եթե ​​մենք աշխատում ենք C#-ով Visual Studio-ում, բոլոր քայլերը կարող են կատարվել մեկ զարգացման միջավայրում (ներառյալ տվյալների բազայի ձևավորումը):
Մի շարք ERP համակարգերում, որոնք օգտագործում են սեփականության լեզուներ, դուք նույնպես պետք է անցնեք վերը նկարագրված բոլոր երեք քայլերը, սովորաբար զարգացման նույն միջավայրում:

Այս 3 քայլերը կապահովեն պահանջվող նվազագույնը; Բայց դուք դեռ պետք է փաստաթղթի հետ աշխատելու համար օգտագործողի միջերես ստեղծեք, այն հասանելի դարձնեք հաշվետվություններում, կարողանաք գրանցել օգտվողների կողմից կատարված փոփոխությունները նոր տեսակի փաստաթղթերում, համակարգի գրանցամատյանում և այլն:

1C-ում անհրաժեշտ է գրաֆիկական դիզայների մեջ նկարագրել նոր փաստաթղթի տեսակի դաշտերը և գրել կոդ, որն իրականացնում է փաստաթղթին հատուկ բիզնես տրամաբանություն (օրինակ, թե որ հաշիվներին պետք է գրվեն փաստաթղթում առկա գումարները): Համակարգում փաստաթղթի հետ լիարժեք աշխատանքի համար անհրաժեշտ մնացած ամեն ինչը կիրականացվի հարթակի կողմից.

• Ստեղծում է կառուցվածքներ DBMS-ում՝ տվյալների պահպանման համար:
• Ձևաթղթեր կստեղծի փաստաթուղթ խմբագրելու, այս տեսակի փաստաթղթերի ցանկը ցուցադրելու և այլն: Եթե ​​ինքնաբերաբար ստեղծված ձևերը մեզ ինչ-որ կերպ չեն համապատասխանում, մենք կարող ենք ստեղծել մերը՝ ընդլայնելով և/կամ փոխելով ստանդարտները։
• Փաստաթուղթը հասանելի կդառնա հաշվետվություններում:
• Փաստաթուղթը և դրա դաշտերը հասանելի կդառնան հավելվածի անվտանգության համակարգում կարդալու/գրելու իրավունքների բաշխման համար:
• Փաստաթղթերի դաշտերը հասանելի կդառնան ամբողջ համակարգում ամբողջական տեքստի որոնման համար (ներառյալ հոմանիշները, տառադարձման աջակցությունը, անորոշ որոնումը և այլն):
• Նոր տեսակի փաստաթղթերի բոլոր փոփոխությունները կգրանցվեն դիմումի մատյանում:
• Մեթոդները ավտոմատ կերպով կստեղծվեն փաստաթուղթը XML-ից և JSON-ից պահելու և կարդալու համար:
• Փաստաթուղթը հասանելի կդառնա REST ինտերֆեյսի միջոցով (OData արձանագրության միջոցով):
• Եվ շատ ավելին

1C-ի զարգացման առանձնահատկությունն այն է, որ համակարգում կա մոտ 20 ներկառուցված օբյեկտի տեսակ, և բոլոր նոր օբյեկտները, որոնք մշակողը ստեղծում է, պետք է պատկանեն այս տեսակներից մեկին: Այս տեսակների մեծ մասը նկարագրում է օբյեկտներ ձեռնարկության հաշվապահական գործունեության շրջանակից՝ գրացուցակներ, փաստաթղթեր, հաշվային գծապատկերներ և այլն: Օբյեկտների տեսակների մեկ այլ մասը տեխնոլոգիական են, օրինակ՝ վեբ և HTTP ծառայություններ; դրանք թույլ են տալիս 1C ծրագրերին շփվել արտաքին աշխարհի հետ:

1C կոնֆիգուրատոր – դրանում ստեղծվում են կիրառական լուծումներ: Ձախ կողմում ներկառուցված 1C տիպի ծառ է. յուրաքանչյուր ճյուղի տակ - այս տեսակի կիրառական օբյեկտներ:

Կիրառական լուծումների մշակումը կատարվում է Configurator-ում (Designer-ը անգլերեն տարբերակում): Վերջերս թողարկվեց 1C:Enterprise Development Tools գործիքի փորձնական տարբերակը, որը թույլ է տալիս մշակել 1C լուծումներ հանրաճանաչ Eclipse միջավայրում: Դեռևս հնարավոր չէ արդյունաբերական զարգացում իրականացնել 1C:Enterprise Development Tools-ում, սակայն օգտագործելով այս տարբերակը միանգամայն հնարավոր է հասկանալ, թե տեխնոլոգիապես դեպի ուր է գնում ընկերությունը։ Մասնավորապես, աջակցվում է կոլեկտիվ զարգացումը՝ օգտագործելով տարբերակի կառավարման հանրաճանաչ համակարգեր (Git, SVN և ցանկացած այլ, որի համար կան պլագիններ Eclipse-ի համար); Հնարավոր է նաև գրել ձեր սեփական պլագինները Eclipse IDE-ի համար, որոնք ընդլայնում են 1C-ի հետ աշխատելու զարգացման միջավայրի հնարավորությունները։

Ձեռնարկությունների զարգացման գործիքներ - մշակում է 1C հավելված IDE Eclipse-ում

1C ծրագրավորման լեզուն ինքնին շարահյուսության մեջ ամենաշատը հիշեցնում է JavaScript-ը: Լեզուն, խիստ ասած, առարկայական չէ: Նրա մեջ ժառանգություն չկա. բայց քանի որ 1C ծրագրերի բոլոր օբյեկտները պատկանում են ներկառուցված օբյեկտների տեսակներից մեկին, դա կարելի է անվանել պարզեցված ժառանգություն. ներկառուցված օբյեկտների տեսակները իրականացնում են նախապես սահմանված ֆունկցիոնալություն, որը ծրագրավորողը կարող է վերասահմանել իրենց իրավահաջորդ օբյեկտներում: Նման ժառանգությունը մեկ մակարդակի է, այլևս հնարավոր չէ ժառանգել հավելվածի օբյեկտներից. ժառանգության նկատմամբ նմանատիպ մոտեցում է ընդունված նախատիպի վրա հիմնված ծրագրավորման հայեցակարգում. Այս հայեցակարգի հայտնի ներկայացուցիչներից մեկը JavaScript-ն է։

Այս մոտեցումը միտումնավոր սահմանափակում է կիրառական լուծումներ մշակողի ազատությունը՝ ստիպելով նրան ընտրել ցանկալի օբյեկտի տեսակը ներկառուցված տեսակների ողջամիտ սահմանափակ գունապնակից՝ իր առաջադրանքները կատարելու համար: Դրա դիմաց ծրագրավորողը ստանում է հարուստ ֆունկցիոնալություն, որն իրականացվում է հարթակի կողմից և իսկապես արագ զարգացում: Այս մոտեցման առավելություններն ակնհայտ են. 1C-ում հաշվապահական համակարգերը հեշտ և արագ են ստեղծվում: Կան նաև թերություններ. եթե ձեզ անհրաժեշտ է իրականացնել մի բան, որի համար պլատֆորմը չունի ներկառուցված տեսակներ (օրինակ՝ աշխատել SFTP-ի հետ), ապա ձեզ հարկավոր է կամ սպասել հարթակի նոր տարբերակին, որում կլինի այս գործառույթը: իրականացվել է, կամ գրել ձեր սեփական կատարումը «սովորական» լեզվով և զանգահարել այն 1C-ից արտաքին բաղադրիչ տեխնոլոգիայի միջոցով:

Մի քանի փաստ ներկառուցված 1C ծրագրավորման լեզվի մասին.

• Աջակցվում է անգլերենի (եթե... ապա) և ռուսերենի (եթե... ապա) շարահյուսությունը:
• Լեզուն Թյուրինգի ամբողջական է:
• Դա դինամիկ տպագրված լեզու է։ Փոփոխականը կապված է տիպի հետ արժեքի նշանակման պահին, ոչ թե փոփոխականի հայտարարման պահին: Փոփոխական հայտարարելիս չեք կարող նշել դրա տեսակը:
  Դուք կարող եք դա անել. var a; a = 1;
  Դուք չեք կարող դա անել. var a as Int; a = 1;
• DBMS-ից տվյալներ կարդալու համար 1C-ն ունի հարցումների իր լեզուն, որը նման է SQL-ին: Փաստորեն, այն թարգմանվում է SQL-ի 1C ծրագրերն իրականացնելիս։

Ինչպես է այդ ամենը աշխատում

Ինչպե՞ս են 1C լուծումները տրամադրվում վերջնական օգտագործողներին: Եվ ինչպես են նրանք աշխատում այս նույն վերջնական օգտագործողների համար:

Այս հարցին ավելի լիարժեք պատասխանելու համար պետք է հիշել մեկը բնորոշ հատկանիշ 1C.
1C-ում նախագիծը կոչվում է կոնֆիգուրացիա: Կազմաձևը լիարժեք ինքնաբավ ծրագիր է, օրինակ՝ հաշվապահություն կամ ERP; այն ներառում է բիզնես հավելվածի լիարժեք գործարկման համար անհրաժեշտ բոլոր օբյեկտները և ծածկագիրը: 1C-ի առանձնահատկությունն այն է, որ կոնֆիգուրացիան պահվում է տվյալների բազայում, նույնը, որում պահվում են հենց հավելվածի տվյալները (տեղադրումներ, տեղեկագրքերից և փաստաթղթերից տվյալներ և այլն), այսինքն. ծրագիրը պահվում է տվյալների հետ միասին: 1C տերմինաբանությամբ կոնֆիգուրացիայով (և կիրառական տվյալների) տվյալների բազան կոչվում է տեղեկատվական բազա (կրճատ՝ ինֆոբազա):

Կազմաձևը կարող է վերբեռնվել ֆայլ; Ֆայլի տեսքով այն սովորաբար ստացվում է ծրագրավորողից մինչև հաճախորդի համակարգում, այս ֆայլը ներմուծվում է տեղեկատվական բազա. Դրանից հետո լուծումը պատրաստ է:

1C լուծումների ճարտարապետություն

Որտեղ է տեղադրված ծրագրաշարը.

• DBMS սերվեր – մեկ կամ մի քանի DBMS աջակցվող 1C-ի կողմից (MS SQL, Oracle, IBM DB2, PostgreSQL): Եթե ​​մի քանի 1C հավելվածներ տեղադրված են 1C սերվերի վրա, ապա հավելվածները կարող են օգտագործել տարբեր DBMS; օրինակ՝ հաշվապահությունը MS SQL է, իսկ ERP-ը՝ Oracle:
• Սերվեր – մեկ կամ մի քանի սերվեր ֆայլով ընդլայնվող կլաստերի մեջ: Այստեղ պետք է տեղադրվի ծրագրային արտադրանք«Սերվեր 1C» (գրադարանների և գործարկվող ֆայլերի մի շարք): Կլաստերի սխալների հանդուրժողականությունը և մասշտաբայնությունը, ինչպես նաև կլաստերի սերվերների միջև բեռի հավասարակշռումը ապահովված են 1C ծրագրաշարով: Մեկ կլաստերը կարող է պարունակել Windows և Linux սերվերներ, իսկ համակարգը կարող է ունենալ պահեստային կլաստեր:
• Հաճախորդ. Windows կամ Linux OS, բարակ հաճախորդ (1cv8c.exe/1cv8) կամ 1C հաստությամբ հաճախորդ (1Cv8.exe Windows-ի համար, 1cv8 Linux-ի համար) պետք է տեղադրվի:
  • Նիհար հաճախորդը կարող է կատարել ներկառուցված 1C լեզվի սահմանափակ գործառույթների շարք: Գործում է ներկառուցված լեզուների տեսակների սահմանափակ հավաքածուով, որը նախատեսված է միայն հիշողության մեջ տվյալները ցուցադրելու և փոխելու համար: Ամբողջ աշխատանքը տվյալների բազայի, օբյեկտի տվյալների և հարցումների կատարումն իրականացվում է սերվերի կողմից: Թին հաճախորդը ստանում է միայն ցուցադրման համար պատրաստված պատրաստի տվյալները:
  • Հաստ հաճախորդը կարող է կատարել ներկառուցված 1C լեզվով նախատեսված գրեթե բոլոր գործառույթները՝ դիմելով սերվերի օգնությանը միայն այն դեպքում, երբ անհրաժեշտ է տվյալների բազայից գրել կամ կարդալ տվյալներ: Սահմանափակումներ. պահանջում է զգալի քանակությամբ ապարատային ռեսուրսներ և կարող է «շփվել» 1C սերվերների կլաստերի հետ միայն տեղական ցանցի միջոցով: Համարվում է հնացած, պահպանվում է հետընթաց համատեղելիության համար:
• Վեբ սերվեր – IIS կամ Apache: 1C-ից – տեղադրված է վեբ սերվերների ընդլայնումների մի շարք:
• Վեբ հաճախորդ – չորս աջակցվող բրաուզերներից որևէ մեկը՝ Internet Explorer, Chrome, Firefox, Safari:
• Բջջային հաճախորդ՝ iOS կամ Android և ցանկացած 1C բջջային հավելված: 1C բջջային հավելվածի և սերվերի միջև կապի եղանակը կախված է կոնկրետ հավելվածից. Ամենից հաճախ օգտագործվում են վեբ կամ HTTP ծառայություններ:

1C բաղադրիչները` սերվերը, բարակ և հաստ հաճախորդները և վեբ ընդլայնումները, շփվում են միմյանց հետ կամ օգտագործելով իրենց սեփական արձանագրությունը (իրականացված TCP-ի վերևում) կամ http-ի միջոցով:

Ինչն է հատուկ 1C-ի մասին

Ինչո՞վ է առանձնանում 1C: Enterprise տեխնոլոգիան: Զարգացման կազմակերպման նորարարական մոտեցման շնորհիվ (այդ մասին ավելին ստորև) 1C-ում հեշտ է անել երկու բան՝ Enterprise. ստեղծել բիզնես լուծումներ զրոյից և հարմարեցնել առկա լուծումները՝ վերջնական օգտագործողների կարիքներին համապատասխան:

Զարգացում

Հեշտ է զրոյից լուծումներ ստեղծել՝ ներկառուցված օբյեկտների շնորհիվ, որոնք իրականացնում են հաշվապահական համակարգերի հիմնական ֆունկցիոնալությունը: Դա ներկառուցված օբյեկտների լավ մտածված համակարգ է (և ոչ թե լեզու, որն ընդհանուր առմամբ սովորական սցենարային լեզու է), որը 1C:Enterprise-ին դարձնում է բիզնես հավելվածներ ստեղծելու հզոր գործիք։ Մշակողը կարիք չունի գրել տվյալների հասանելիության շերտ, հիմնական UI և այլն: – Դուք կարող եք անմիջապես կենտրոնանալ բիզնեսի խնդրի լուծման վրա: Բիզնեսի խնդիրները լուծելու համար շատ բան արդեն ներդրվել է ներկառուցված օբյեկտներում (կարդա – հիմնական գրադարաններ) – օրինակ՝ հիերարխիկ գրացուցակների աջակցություն, հաշվապահական հաշվառման և ապրանքային հաշվառման իրականացման հաշվապահական հաշվառման մեքենաներ, բարդ պարբերական հաշվարկների մեխանիզմներ (օրինակ՝ աշխատավարձ): և շատ ավելին:

«Տուփից դուրս» ծրագրավորողը ստանում է ներկառուցված օբյեկտներ (տեղեկատուներ, փաստաթղթեր, գրանցամատյաններ և այլն), որոնք իրականացվում են հարթակի կողմից. սրանք օրինաչափություններ են հաշվապահական համակարգերի աշխարհից: Կիրառական լուծման (կոնֆիգուրացիայի) դեպքում մշակողն իրականացնում է այս օրինաչափությունները՝ լրացնելով դրանք կոնկրետ բիզնես տրամաբանությամբ։

1C:Enterprise-ում հավելվածի լուծումը գրված չէ բառացիորենծրագրավորման լեզվով։ Զարգացման գաղափարախոսության երկու հիմնաքարերն են՝ մետատվյալների վրա հիմնված զարգացումը և մոդելի վրա հիմնված զարգացումը:

Բիզնես հավելվածի հիմքում ընկած են մետատվյալները, որոնք ինքնին հավելվածի դեկլարատիվ նկարագրությունն են: Կիրառական լուծումը նկարագրված չէ հարաբերական աղյուսակների, օբյեկտների ծրագրավորման լեզուների դասերի և այլնի տեսքով, ինչպես համակարգերի մեծ մասում: Լուծումը 1C-ում. Ձեռնարկությունը նկարագրվում է մետատվյալներով՝ կիրառական օբյեկտների մի շարքի տեսքով, որոնք ընտրված են նախատիպերի որոշակի շարքից (տեղեկատուներ, փաստաթղթեր, հաշվային գծապատկերներ, ...):

Մետատվյալները կազմում են օբյեկտների հիերարխիա, որոնցից ձևավորվում են կիրառական համակարգի բոլոր բաղադրիչները և որոնք որոշում են դրա վարքագծի բոլոր ասպեկտները: Բիզնես հավելված գործարկելիս հարթակը մեկնաբանում է մետատվյալները՝ ապահովելով բոլոր անհրաժեշտ ֆունկցիոնալությունը։

Մետատվյալները նկարագրում են տվյալների կառուցվածքները, տեսակների կազմը, օբյեկտների միջև կապերը, դրանց վարքագծի առանձնահատկությունները և տեսողական ներկայացումը, մուտքի իրավունքների սահմանազատման համակարգ, օգտատիրոջ միջերես և այլն: Մետատվյալները պարունակում են տեղեկատվություն ոչ միայն տվյալների բազայում պահվողի, այլև այն մասին, թե ինչի մասին է խոսքը: , ինչու է պահվում այս կամ այն ​​տեղեկատվությունը, որն է դրա դերը համակարգում և ինչպես են փոխկապակցված տեղեկատվական զանգվածները։ Ծրագրավորման լեզվի օգտագործումը սահմանափակվում է հիմնականում այն ​​խնդիրների լուծմամբ, որոնք իրականում պահանջում են ալգորիթմական նկարագրություն (հարկերի հաշվարկ, մուտքագրված տվյալների ճշգրտության ստուգում և այլն): 1C-ում զարգացման հիմնական սկզբունքը. Enterprise-ը կարելի է հակիրճ ձևակերպել հետևյալ կերպ.

1C. Ձեռնարկությունն ի սկզբանե ուղղված էր կոնկրետ մոդելի հիման վրա կիրառական լուծում ստեղծելուն: Մոդելը վերաբերում է կիրառական լուծում կառուցելու ողջ գաղափարախոսությանը։ Սրանք տվյալների կառուցվածքների կառուցման մեթոդներ են, տվյալների միջև կապի տեսակները, դրանց մանիպուլյացիայի սկզբունքները, բիզնես տրամաբանության նկարագրության ձևերը, տվյալների միջերեսի օբյեկտների հետ կապելու եղանակները, գործառույթների բաժանումը համակարգի մակարդակներով և շատ ավելին:

Բոլոր բիզնես հավելվածները հետևում են ընդհանուր մոդելին՝ ապահովելով հետևողական և կանխատեսելի վարքագիծ: Ծրագրավորողը, ով ցանկանում է արտացոլել կոնկրետ առարկայի առանձնահատկությունները կիրառական լուծման մեջ, ունի այս խնդիրը լուծելու շատ կոնկրետ եղանակներ՝ օգտագործելով հարթակում ներկառուցված միջոցները: Մի կողմից, այս մոտեցումը սահմանափակում է (իմաստով!) ծրագրավորողի ազատությունը, բայց մյուս կողմից՝ պաշտպանում է նրան բազմաթիվ սխալներից և թույլ է տալիս արագ ձեռք բերել գործունակ լուծում, որը կարող է հետագայում մշակվել և աջակցել ինչպես իր, այնպես էլ նրա կողմից: անհրաժեշտության դեպքում՝ այլ մասնագետների կողմից։

Համակարգի յուրացման հեշտության վրա դրական է ազդում միասնական մոդելի առկայությունը։ Ամբողջ զարգացումն իրականացվում է հասկացությունների մեկ ծայրից ծայր համակարգի շրջանակներում՝ ներս ընդհանուր տարածությունտվյալների տեսակները. Մետատվյալներում որոշակի օբյեկտների (սուբյեկտների) նկարագրությունը անմիջապես որոշում է ներկառուցված ծրագրավորման լեզվի համապատասխան տեսակները և դրանց պահպանման համար անհրաժեշտ տվյալների բազայի կառուցվածքները: Այս օբյեկտների բոլոր հետագա մանիպուլյացիաները ինչպես հիշողության մեջ, այնպես էլ տվյալների բազայում կատարվում են միատեսակ՝ առանց DBMS-ի և DBMS-ի հետ աշխատելիս ընդունված տարբեր նշումների միջև խոչընդոտների հաղթահարման պահանջի: համընդհանուր լեզուներծրագրավորում։

Պատրաստի հավելվածը (կոնֆիգուրացիա), որը տրամադրվում է բաց կոդով (օրինակ՝ հաշվապահական հաշվառում կամ ERP), հաճախորդի կողմից ծրագրավորողի համար գործնականում DSL է (Դոմենի հատուկ լեզու, տիրույթի հատուկ լեզու): Ծրագրավորողը կարող է օգտագործել պատրաստի կոնֆիգուրացիայի օբյեկտներ (կոնտրագենտների գրացուցակ, հաշվային պլան, աշխատավարձի ցուցակ)՝ փոփոխելու համակարգի վարքագիծը՝ հաճախորդի կարիքներին համապատասխան:

Անհատականացում և աջակցություն

Հակիրճ կիրառական լուծման բիզնես տրամաբանության մասին կարելի է ասել հետևյալը՝ այն փոխված է։ Այն փոխվում է հաճախորդի ՏՏ բաժնի աշխատակիցների կողմից՝ լուծումը հարմարեցնելով ձեռնարկության բիզնես գործընթացներին: Եվ լուծումների մատակարարը փոխում է այն՝ ավելացնելով նոր գործառույթներ, աջակցելով օրենսդրության փոփոխություններին և պարբերաբար թարմացումներ թողարկելով։

Թարմացում տեղադրելու ընթացակարգը, որտեղ բիզնես տրամաբանությունը փոխվել է «տեղում»՝ հաճախորդի կարիքներին համապատասխանելու համար, հաճախ ոչ տրիվիալ գործողություն է, երբեմն հղի է սխալներով: Ընդհանուր առմամբ, սա մատակարարից նոր հավելվածի սկզբնական կոդերի միաձուլումն է փոփոխված (համեմատած մատակարարի նախորդ տարբերակի հետ) հաճախորդի հավելվածի հետ: Մի կողմից, դուք պետք է ստանաք թարմացման հետ բերված նոր գործառույթը. մյուս կողմից, մի կորցրեք ձեր ձեռքբերումները:

Այս առաջադրանքը ծանոթ է բոլորին, ովքեր ստիպված են եղել թիմում աշխատել մեկ հավելվածի վրա և միավորել (միաձուլել) սկզբնաղբյուրի իրենց փոփոխությունները թիմի մյուս անդամների փոփոխությունների հետ: Նույնիսկ եթե բոլոր ծրագրավորողները նույն թիմից են և հետևում են կոդի մշակման և ձևաչափման կանոնների միևնույն շարքին, սկզբնական կոդը միավորելու խնդիրը երբեմն կարող է դժվար լինել: Դե, ERP համակարգերի դեպքում դա բարդանում է նրանով, որ մատակարարի և պատվիրատուի մշակողները աշխատում են տարբեր կազմակերպություններում և միշտ չէ, որ հնարավորություն ունեն շփվելու կոդը հասկանալու դժվարությունների դեպքում։

Հիշեք, որ եթե հաճախորդի կողմից կատարված փոփոխությունները չափազանց ծավալուն են, հավելվածի մատակարարը կարող է որոշել, որ նրանք չեն տրամադրի հետագա աջակցություն հաճախորդի լուծմանը:

Վերը նշվածը ամենադժվար խնդիրներից մեկն է կյանքի ցիկլըգրեթե ցանկացած բիզնես համակարգ՝ բաց կոդով հավելվածով: Շուկայում հավելվածի հաջողությունը մեծապես կախված է նրանից, թե ծրագրային ապահովման արտադրողը որքանով է հաջողությամբ լուծում այս խնդիրը: 1C-ի դեպքում թարմացման ժամանակ երկու կոնֆիգուրացիաների (մատակարարի և օգտագործողի) միաձուլումը պարզապես երկու հավելվածների սկզբնական կոդերի միաձուլում չէ, դա, առաջին հերթին, հավելվածների մոդելների միաձուլումն է, որը պետք է տեղի ունենա որոշակի կանոնների համաձայն։

Այս խնդիրը լուծելու համար 1C-ը մշակել է աջակցության մեխանիզմ (1C: Enterprise պլատֆորմի մի մասը), որը լուծումների մատակարարին թույլ է տալիս որոշել, թե որ կոնֆիգուրացիայի օբյեկտները (տեղեկատուներ, փաստաթղթեր և այլն) կարող է հաճախորդը փոխել, իսկ որոնք՝ ոչ, այսինքն՝ դեպի: դրանց փոփոխությունը կխաթարի համակարգի ֆունկցիոնալությունը կամ անհնարին կդարձնի դրա հետագա կենտրոնացված աջակցությունը մատակարարի կողմից:

Իր հերթին, հաճախորդը, օգտագործելով այս մեխանիզմը, կարող է որոշել իր կոնֆիգուրացիայի օբյեկտներին աջակցելու կանոնները, օրինակ, նա կարող է հրաժարվել մատակարարի կողմից որոշակի օբյեկտի աջակցությունից, եթե նա պատասխանատվություն է կրում այս օբյեկտի հետագա փոփոխության համար կամ եթե դա չի անում: անհրաժեշտ է այս օբյեկտը իր աշխատանքում: Կամ, ընդհակառակը, դուք կարող եք արգելել խմբագրել «ձեր» կոնֆիգուրացիայի օբյեկտը (նույնիսկ եթե մատակարարը դա թույլ է տալիս)՝ պատահական փոփոխություններից ապահովագրվելու համար:

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

Առաջին մոտեցումը արտաքին մշակման և արտաքին հաշվետվությունների օգտագործումն է: Այս մեխանիզմները թույլ են տալիս համակարգի «վերևում» ավելացնել լրացուցիչ գործառույթներ՝ առանց սկզբնաղբյուրի կազմաձևման կոդը փոխելու: Ըստ էության, դրանք գրաֆիկական ինտերֆեյսով սցենարներ են, որոնք նախատեսված են հատուկ կիրառական լուծման վրա գործարկելու համար: Այս մեխանիզմները առաջացրել են իրենց անալոգը՝ «App Store»-ը, առցանց խանութ, որտեղ անկախ ծրագրավորողները տեղադրում են, իսկ վերջնական օգտատերերը գնում են տարբեր ծրագրերի համար անհրաժեշտ հավելումներ:

Երկրորդ մոտեցումը, որը համեմատաբար վերջերս է ի հայտ եկել, ընդարձակումն է։ Ընդլայնումների կողմից առաջարկվող ռազմավարությունն այն է, որ կարիք չկա փոխելու լռելյայն կոնֆիգուրացիան: Բոլոր փոփոխությունները կատարվում են այսպես կոչված ընդլայնման մեջ, որը, ըստ էության, նույնպես կոնֆիգուրացիա է (բայց մաքսային, վաճառողի կոնֆիգուրացիայից առանձին): Այս դեպքում մատակարարից թարմացման տեղադրումը ավտոմատ կլինի. աջակցության մեխանիզմի տեսանկյունից ստանդարտ կոնֆիգուրացիան չի փոխվել: Եվ երբ վերջնական կոնֆիգուրացիան (որը ստանդարտ կոնֆիգուրացիայի և ընդլայնման համադրություն է) աշխատի, այն օբյեկտները, որոնք ավելացվել են (կամ փոփոխվել) ընդլայնման մեջ, կօգտագործվեն:

Էլ ի՞նչ։

Էլ ի՞նչն է հետաքրքիր/կարևոր 1C տեխնոլոգիական գծում: Ցանկը պարունակում է ամենակարևոր մեխանիզմները, որոնցից յուրաքանչյուրի մասին կարող եք գրել առանձին հոդված (կամ մի քանի).

• Cloud լուծումը 1cFresh-ը «ամպից դուրս» է, հորիզոնական մասշտաբային միջավայր՝ սպասարկման մոդելում (SaaS) 1C-ի (և գործընկեր ընկերությունների) կիրառական լուծումների հետ աշխատելու համար: Ապրանքը պարունակում է SaaS-ի շահագործման համար անհրաժեշտ բոլոր գործառույթները՝ օգտատերերի գրանցում և կառավարում, նոր հավելվածների լուծումներ արագ հրապարակելու հնարավորություն, օգտատիրոջ տվյալների կրկնօրինակ պատճեններ ստեղծելու հնարավորություն և այլն: 1C ընկերությունն ինքը օգտագործում է 1cFresh արտադրանքը՝ իր արտադրանքը վարձով տրամադրելու համար (http://1cfresh.com), ինչպես նաև վաճառում է 1cFresh լուծումը որպես տուփի արտադրանք՝ թույլ տալով գործընկերներին և հաճախորդներին տեղակայել իրենց սեփական ամպերը՝ 1C-ի վրա հիմնված կիրառական լուծումների համար։ Ձեռնարկությունների տեխնոլոգիաներ.
• 1C շարժական հարթակ (վերը նշված), որը թույլ է տալիս ստեղծել հավելվածներ բջջային օպերացիոն համակարգերի համար (iOS, Android) մեկ աղբյուրի կոդից՝ օգտագործելով նույն մեթոդաբանությունը և զարգացման միջավայրը (Կազմաձևիչը), ինչ «սովորական» 1C հավելվածների համար:
• Հզոր և ճկուն հաշվետվության համակարգ: Հաշվետվությունները չափազանց կարևոր մեխանիզմ են ցանկացած բիզնես համակարգում. Շատ ERP-ներ օգտագործում են այլ արտադրողների արտաքին հաշվետվությունների գեներատորներ, քանի որ... Հաշվետվությունների լավ գեներատոր ստեղծելը հեշտ գործ չէ շատ առանձնահատկություններով: 1C-ում հաշվետվությունները մշակվում են նույն միջավայրում (Կոնֆիգուրատոր), ինչ հավելվածն է. Հաշվետվության մեխանիզմը հիմնված է տվյալների կազմման համակարգի (DCS) վրա, որը հաշվետվությունների դեկլարատիվ նկարագրության մեխանիզմ է: 1C-ում հաշվետվությունների կարևոր առանձնահատկություններից մեկն այն է, որ վերջնական օգտագործողը կարող է փոխել մշակողի կողմից ստեղծված զեկույցը «իրեն հարմարեցնելու համար»՝ օգտագործելով նույն հաշվետվության ձևավորման հնարավորությունները, ինչ մշակողը:
• Տվյալների փոխանակման մեխանիզմ, որը թույլ է տալիս ստեղծել աշխարհագրորեն բաշխված տեղեկատվական համակարգերտվյալների փոխանակում անցանց, առանց մշտական ​​կապի: Տվյալների փոխանակումը հնարավոր է ինչպես 1C: Enterprise հավելվածների, այնպես էլ 1C: Enterprise հավելվածների և երրորդ կողմի համակարգերի միջև:
• Եվ շատ ավելի հետաքրքիր բաներ

«1C:Enterprise» - տեխնոլոգիաներ և գործիքներ

Եզրակացության փոխարեն

Հուսով եմ, որ ընթերցողները, ովքեր ծանոթ չեն 1C-ին, քիչ թե շատ հստակ պատկերացում կունենան՝ ինչ է 1C-ն, ինչպես է այն աշխատում և ինչ հնարավորություններ է տալիս ծրագրավորողներին: Այս վերանայման շրջանակներից դուրս շատ բան է մնացել հետաքրքիր թեմաներ; հաջորդ անգամ նրանց մասին:

Հավելվածների ճարտարապետության պլատֆորմի վրա հիմնված մոտեցումն ընտրվել է 1C-ի կողմից դեռ 1990-ականների կեսերին: Հզոր հարթակի և ողջամտորեն սահմանափակ կիրառական լեզվի այս եզակի համադրությունը լավ է ապացուցել իրեն. ավելի քան 1000 պաշտոնապես հավաստագրված 1C լուծումներ ստեղծվել են՝ օգտագործելով 1C տեխնոլոգիաները տարբեր բիզնես ոլորտների համար՝ փոքր բիզնեսի ավտոմատացումից մինչև ձեռնարկությունների կառավարման համակարգեր՝ հազարավոր միաժամանակյա համակարգերով: օգտվողներ.

Ավելացնել պիտակներ

Սիրելի և սիրելի հաճախորդներ, մենք ձգտում ենք ավելի լավը դառնալ ձեզ համար:Այս առումով մենք սկսում ենք վերափոխումը Կենտրոնգեղեցկություն Տուլայում

հուլիսի 15-ից։ Վերանորոգումը կտևի 2 շաբաթ։ Նորացված և արդիականացված կենտրոնն իր դռները կբացի ձեր առջև հուլիսի 29-ին։Այս ընթացքում մենք ուրախ կլինենք տեսնել ձեզ Կանտեմիրովսկայայի կենտրոնում, ինչպես նաև

Տեղեկացնենք, որ վերանորոգման ընթացքում Կանտեմիրովսկայայում կաշխատեն Տուլայի որոշ մասնագետներ։

Հայցում ենք ձեր ներողամտությունը պատճառված անհարմարության համար։Լրացուցիչ տեղեկություններմեկ զանգի կենտրոնում+7 495 134 22 22.

Բաժանորդագրվեք մեր Instagramև հետևեք ընթացքին, հետաքրքիր կլինի։

Կրիոլիպոլիզ - ՆՈՐՈՒՅԹ!!!

ՕԳՈՒՏ ԱՌԱՋ 54 400*!

ԲԱՑԱՐՁԱԿ ՀԻԹ ԵՎՐՈՊԱՅԻ ԿԼԻՆԻԿԱՆԵՐ -ԿՐԻՈԼԻՊՈԼԻԶ ԿՈԿԿՈՆ :

✔️ ԱՆՑԱՎ;

✔️ ԱՐԱԳ ԱՐԴՅՈՒՆՔ;

​ ✔️ ԱՆԳԱՄ ՃԱՐՊԱՅԻՆ ՀՅՈՒՍՔԻ ՆՎԱԶՈՒՄ;
✔️ ՈՉ ԿՈՂՄԻ ԷՐԴԵՖԱՆԵՐ;
✔️ ԿԻՐԱՌՄԱՆ ԼԱՅՆ ՏԱՐԱԾՔ - ՈՐՈՎԱՅՆԻՑ ԵՎ ԱԶԿԵՐԻՑ ՄԻՆՉԵՎ ԿԶԱԿ։

*Ակցիայի մասին լրացուցիչ տեղեկությունների համար հարցրեք ադմինիստրատորներին կամ հեռախոսով:

Հեղափոխական PRX-T33 էմուլսիան ԱՅԺՄ ՄԵԶ ՄՈՏ է:

PRX-T33-ը եզակի արտոնագրված արտադրանք է, որը հեղափոխություն կատարեց կոսմետոլոգիայում Իտալիայում և 10 տարվա կլինիկական փորձարկումներից հետո մտավ ռուսական շուկա: PRX-T33 - քիմիական պիլինգ մաշկի վերակենդանացման (երիտասարդացման) համար: Մաշկի վերահսկվող վնասման պրոցեդուրա՝ այն խթանելու և վերականգնելու համար՝ առանց էպիդերմիսը վնասելու և առանց կլեպ առաջացնելու։ Պիլինգների մեծ մասը խորհուրդ է տրվում անել աշուն-ձմեռ ժամանակահատվածում, սակայն PRX-T33 - ամբողջ սեզոն:

ՆՈՐ ՍՊԱՍԱՐԱՊԵՏ!

Այժմ ցանցային կենտրոններում գեղեցկուհի «Ապակի միջով» (մ. Կանտեմիրովսկայա, մ. Տուլսկայա) հայտնվեցին վարսահարդարները. սրանք վարպետներ են, որոնց ժամանակակից մարդը կարող է վստահորեն վստահել իր կերպարը. . Վարսավիրը կօգնի ձեզ ընտրել մազերի խնամք և հարդարում, խորհուրդ կտա ձեր արտաքին տեսակին համապատասխան սանրվածք և կատարյալ մորուք: Տղամարդկանց համար սանրվածքները ներկայացված են լայն տեսականիով: Երիտասարդը կարող է օգտագործել սանրվածքը՝ արտահայտելու իր բնավորությունը, տրամադրությունը, կերպարը:

Բաբոր - «Մաքրման արվեստը»

Zazerkalye գեղեցկության կենտրոններում հայտնվել է տնային խնամքի համար նախատեսված կոսմետիկայի նոր շարք՝ «The Art of Cleansing» գերմանական Babor ընկերության կողմից:
Գիծը ներառում է.
Մաքրող փոշու ֆերմենտ, Մաշկը մաքրող տրիո հավաքածու, փափուկ պիլինգ, էսենս-տոնիկ ջերմային ջրով, էսենս-տոնիկ վարդի ջրով, մաքրող կաթ:

Կատարյալ մատնահարդարումը Luxio-ի հետ այժմ գտնվում է Կանտեմիրովսկայայի վրա՝ նայող ապակու միջով

Գեղեցկության սրահ Zazerkalye ներկայացնում է մատնահարդարման և պեդիկյուրի ժամանակակից գիծ՝ LUXIO:

Այս հոդվածը նոր ֆունկցիոնալության հայտարարություն է:
Խորհուրդ չի տրվում օգտագործել այս հոդվածի բովանդակությունը նոր գործառույթներ սովորելու համար:
Նոր ֆունկցիոնալության ամբողջական նկարագրությունը կտրամադրվի համապատասխան տարբերակի փաստաթղթերում:
Նոր տարբերակի փոփոխությունների ամբողջական ցանկը ներկայացված է v8Update.htm ֆայլում:

Իրականացված տարբերակով8.3.12.64 շարժական հարթակ.

Մենք իրականացրել ենք նոր տեխնոլոգիա- բջջային հաճախորդ: Այն թույլ է տալիս ստեղծել հավելվածներ շարժական սարքերի համար, որոնք համատեղում են բջջային հարթակի հարմար ինտերֆեյսը և առցանց աշխատանքը տեղեկատվական բազայի հետ՝ նման thin client-ի:

Բջջային աշխատանքի սցենարներ

Մինչև վերջերս 1C:Enterprise հարթակն առաջարկում էր միակ տեխնոլոգիան, որով հնարավոր էր աշխատել իր հավելվածների հետ՝ օգտագործելով շարժական սարքեր։ Սա բջջային հարթակ է:

Այս տեխնոլոգիան թույլ է տալիս ստեղծել մասնագիտացված օֆլայն բջջային հավելվածներ, որոնք ունեն հարմար և ֆունկցիոնալ բջջային ինտերֆեյս: Բջջային հավելվածները մշակվել են հատուկ բջջային խնդիրներ լուծելու համար և դրանց համար առավելագույնս օպտիմիզացված են ճարտարապետության և ինտերֆեյսի առումով: Նման հավելվածներն իրականացնում են բջջային աշխատանքի սցենարներ և հարմար են աշխատել ինչպես պլանշետների, այնպես էլ սմարթֆոնների վրա:

Իրենց ճարտարապետությամբ նման հավելվածները շատ նման են 1C:Enterprise համակարգի ֆայլային տարբերակին։ Բջջային սարքն ունի իր սեփական տվյալների բազան բջջային հավելվածի «ներսում» կա և՛ հաճախորդ, որն ապահովում է փոխազդեցություն օգտատիրոջ հետ, և՛ սերվեր, որն ապահովում է տվյալների բազայի հետ փոխգործակցությունը:

Նման բջջային հավելվածները կարող են փոխազդել գրասենյակում տեղադրված «հիմնական» հավելվածի հետ։ Բայց սա առցանց փոխազդեցություն չէ, այլ տվյալների պարբերական փոխանակում back office-ի հետ: Բջջային հավելվածում հիմնական աշխատանքն իրականացվում է օֆլայն։ Եվ երբ հայտնվում է ինտերնետ կապ, տվյալները համաժամացվում են:

Այսպիսով, բջջային հարթակը հարմար է ինքնավար աշխատատեղեր մշակելու համար այն աշխատակիցների համար, ովքեր ընկերությունից դուրս են և չունեն հուսալի ինտերնետ կապ գրասենյակի հետ: Այնուամենայնիվ, նման աշխատանքային կայանները սովորաբար ունեն սահմանափակ գործունակություն, ավելի քիչ, քան «հիմնական» հավելվածը: Բացի այդ, նրանք չեն ապահովում առցանց փոխազդեցություն տեղեկատվական բազայի հետ:

Պարզվում է, որ խնդիրների զգալի շրջանակը լուսաբանված չէ՝ ունենալով հետևյալ բնորոշ հատկանիշները.

• Տեղեկատվական բազայի հետ փոխգործակցությունը պետք է իրականացվի առցանց.
• «Հիմնական» հավելվածի լուծման ողջ ֆունկցիոնալությունը, նույնիսկ այնպիսի մեծը, ինչպիսին, օրինակ, «1C:ERP Enterprise Management»-ը պետք է հասանելի լինի շարժական սարքի վրա.
• Ինտերֆեյսը պետք է ապահովի հարմարավետ շահագործում ցանկացած շարժական սարքի վրա՝ ցանկացած էկրանի չափով և տեղակայմամբ:

Բջջային հաճախորդ

Այս դասի խնդիրների լուծման համար մենք մշակել ենք բջջային հաճախորդ: Բջջային հաճախորդը բջջային սարքերի համար նախատեսված բարակ հաճախորդ է, որն ունի բջջային հարթակի նման ինտերֆեյս: Բջջային հաճախորդի բաշխումը պարունակում է բոլոր անհրաժեշտ գործարկվող ֆայլերը, որոնցից ծրագրավորողը կարող է բջջային սարքի համար հավելված ստեղծել այնպես, ինչպես բջջային հավելվածները կառուցված են բջջային հարթակից:

Նման հավելվածը, մի կողմից, կարող է ուղղակիորեն փոխազդել 1C:Enterprise սերվերների կլաստերի հետ այնպես, ինչպես դա անում է thin client-ը: Մյուս կողմից, բջջային հաճախորդը ապահովում է ձևերի ավտոմատ վերափոխում, որոնք նկարագրված են կոնֆիգուրացիայի մեջ, բջջային հարթակի ինտերֆեյսի նման ինտերֆեյսի:

Այն ավտոմատ կերպով դասավորում է 1C:Enterprise-ի աշխատասեղանի տարբերակի համար մշակված ձևերը այնպես, որ ապահովի բջջային հեռախոսների փոքր էկրանների օգտագործման հարմարավետությունը ընդունելի մակարդակով:

Իհարկե, որպեսզի այս փոխակերպումն էլ ավելի լավ իրականացվի, անհրաժեշտ է նշել ձևի տարրերի որոշ նոր հատկություններ հատուկ բջջային հաճախորդի համար և ազատվել որոշ հատուկ և ոչ ստանդարտ ինտերֆեյսի լուծումներից: Այսինքն՝ պահանջվում է հավելվածի լուծման որոշակի վերամշակում հատուկ բջջային հաճախորդի համար: Բայց այս վերամշակումը շատ ավելի պարզ է, քան սովորական, լիարժեք բջջային հավելված ստեղծելը:

Հնարավոր օգտվողներ

Մեր կարծիքով, այս տեխնոլոգիան պահանջված կլինի այն ծրագրերում, որտեղ անհրաժեշտ է բջջային սարքերից համակարգ մուտք գործել առցանց: Այսպիսով, բջջային սարքի վրա մուտքագրված տվյալները ուղղակիորեն գնում են «ընդհանուր» տվյալների բազա՝ շրջանցելով միջանկյալ համաժամացման քայլերը:

Նաև բջջային հաճախորդը պահանջված կլինի փոքր ընկերություններում, որոնք չունեն ոչ բյուջե, ոչ էլ ժամանակ՝ մասնագիտացված բջջային հավելվածներ մշակելու համար: Իսկապես, մեր գնահատականներով՝ ամենաշատը դժվար փուլբջջային հավելվածների մշակումը հենց տվյալների փոխանակման համակարգի ստեղծումն է:

Բացի այդ, բջջային հաճախորդը օգտակար կլինի 1Cfresh տեխնոլոգիայի վրա հիմնված ծառայություններից օգտվողների համար: Սրանք 1Cfresh.com և Հաշվապահական ծառայությունների ծառայություններն են, որոնք աջակցվում են 1C-ի կողմից, ինչպես նաև ցանկացած այլ ծառայություններ, որոնք կիրառվում են այս տեխնոլոգիայի միջոցով:

Ֆունկցիոնալություն

Եթե ​​համեմատենք բջջային հաճախորդի ֆունկցիոնալությունը այն բանի հետ, թե ինչ կարող է անել բարակ հաճախորդը, ապա կան ոչ միայն սահմանափակումներ, այլև առավելություններ:

Բջջային հաճախորդի կարևոր առավելությունն այն է, որ այն պարունակում է բջջային հարթակի ողջ ֆունկցիոնալությունը՝ որոշված ​​իրենց կողմից օգտագործվող սարքերով: Այսինքն՝ այն թույլ է տալիս, օրինակ, լուսանկարել, հավաքել բաժանորդի համարը, ստանալ PUSH հաղորդագրություններ և շատ ավելին։

Բջջային հաճախորդի մեկ այլ առավելությունն այն է, որ այն աշխատում է ոչ միայն սերվերի այն տարբերակի հետ, որի համար ստեղծվել է: Այն կաշխատի սերվերի գրեթե ցանկացած տարբերակի հետ, մինչև կապի արձանագրության կամ պլատֆորմի ճարտարապետության մեջ զգալի փոփոխություն տեղի ունենա: Մենք դա արեցինք, քանի որ բջջային հավելվածների հրապարակումը բավականին աշխատատար և ժամանակատար գործընթաց է, որը գրեթե անհնար է ավարտել սերվերի կլաստերը հարթակի նոր տարբերակ տեղափոխելու հետ միաժամանակ:

Եթե ​​խոսենք սահմանափակումների մասին, ապա դրանցից ամենաակնհայտն այն է, որ բջջային հաճախորդը սերվերի կլաստերի հետ փոխազդում է միայն HTTP (HTTPS) արձանագրության միջոցով։

Մեկ այլ սահմանափակում, սակայն, ինչ վերաբերում է շարժական հարթակին, որոշ ներկառուցված լեզվական օբյեկտների և որոշ ինտերֆեյսի տարրերի անհասանելիությունն է: Բայց մենք կփորձենք նվազագույնի հասցնել այդ տարբերությունները, քանի որ բջջային հաճախորդը զարգանում է:

Ձևերի ինտերֆեյսի կառուցման ավտոմատացում

Բջջային հաճախորդը ստեղծելիս մենք մեծ ուշադրություն ենք դարձրել ապահովելու, որ բջջային հաճախորդի համար կոնֆիգուրացիան հարմարեցնելը նվազագույն ջանք է պահանջում: Մենք մշակել ենք մի քանի տեխնոլոգիաներ և մոտեցումներ մեծ ձևեր, նախատեսված է աշխատասեղանի տարբերակի համար, ավտոմատ կերպով հարմարեցված շարժական սարքերի փոքր էկրաններին։

Օրինակ, մենք պարզեցինք, որ մեծ ձևերը հակված են ունենալ փոքր թվով կարևոր տարրեր: Այսինքն այնպիսի տարրեր, որոնց հետ մենք անընդհատ աշխատում ենք։ Եվ միևնույն ժամանակ դրանք պարունակում են շատ ավելի քիչ կարևոր տարրեր, որոնց վրա ժամանակ առ ժամանակ աշխատում են։

Օրինակ՝ կարևոր տարրերն են ցուցակի դինամիկ աղյուսակը՝ ցուցակի տեսքով, աղյուսակային փաստաթուղթը՝ հաշվետվության տեսքով։ Կարևոր սյունակներն են, օրինակ, «Անուն» և «Ամսաթիվ» սյունակները:

Համապատասխանաբար, ձևի հետ աշխատելու հարմարության բավարար մակարդակ ապահովելու համար շարժական հաճախորդն ավելի շատ տեղ է հատկացնում ձևի կարևոր տարրերին, իսկ ավելի քիչ տեղ է տալիս ավելի քիչ կարևոր տարրերին՝ դրանք դնելով, օրինակ, ծալվող խմբում:

Երկրորդ, շարժական հաճախորդը ուղղահայաց ընդլայնում է հորիզոնական խմբերը, եթե դրանք չեն համապատասխանում էկրանի լայնությանը: Բջջային սարքերում սովորական և անհարմար չէ ձևը հորիզոնական ոլորել, ուստի այս լուծումը բավականին հարմար և արդարացված է:

Կազմաձևերի հարմարեցում բջջային հաճախորդին

Չնայած բոլոր ավտոմատացմանը, որոշ ջանքեր կպահանջվեն կազմաձևման մշակողից՝ հավելվածի լուծումը բջջային հաճախորդին հարմարեցնելու համար:

Չխորանալով մանրամասների մեջ՝ կարելի է ասել, որ բոլոր նման բարելավումները տեղավորվում են երկու հիմնական ուղղությունների մեջ։

Առաջինը ինտերֆեյսի հատուկ և հատուկ լուծումներից ազատվելն է՝ ավելի շատ հենվելով պլատֆորմի կողմից տվյալների տիպի տվյալների վրա հիմնված ավտոմատ ձևերի դասավորության վրա: Նման հատուկ լուծումները կարող են լինել դաշտերի ֆիքսված չափերը, տարրերի խիստ հաստատված հորիզոնական խմբավորումը և այլն:

Մեկ այլ ուղղություն բջջային հաճախորդին հուշելն է լրացուցիչ տեղեկություններձևի տարրերի մասին. Մենք բջջային հաճախորդին սովորեցրել ենք հեշտությամբ ճանաչել տարրերը ստանդարտ կամ փոքր ձևերով և որոշել դրանց կարևորությունը: Բայց եթե ձևը ոչ ստանդարտ է կամ մեծ, ապա օգտակար կլինի ձեռքով նշել, թե դրա տարրերից որն է ավելի ու ավելի քիչ կարևոր: Դա անելու համար կարող եք օգտագործել տարրերի նոր հատկությունը՝ Կարևորություն ցուցադրման ժամանակ՝ բարձր, նորմալ, ցածր և այլն:

Հավանաբար անհրաժեշտ կլինի նաև վերլուծել կիրառական լուծման այն վայրերը, որտեղ տարբերվում են thin client-ի և web client-ի գործող ալգորիթմները: Դա պետք է արվի, որպեսզի նշվի, թե որ ալգորիթմը կօգտագործվի բջջային հաճախորդում աշխատելիս: Դա անելու համար մենք ավելացրել ենք MobileClient կոմպիլյացիայի նոր հրահանգ:

Բաշխում, հավաքում և հրապարակում

Բջջային հաճախորդը, ըստ էության, մի տեսակ «կեղև» է, որը կարող է գործարկել այս կամ այն ​​հավելվածի լուծումը: Միևնույն ժամանակ, գործարկված կիրառական լուծումների ֆունկցիոնալությունը կարող է զգալիորեն տարբերվել միմյանցից: Միևնույն ժամանակ, AppStore հավելվածների խանութը պահանջում է, որ խանութում հրապարակված հավելվածը հրապարակումից հետո էապես չփոխի իր ֆունկցիոնալությունը։

Հետևաբար, մենք չենք հրապարակում բջջային հաճախորդը որպես առանձին ունիվերսալ հավելված: Բջջային հաճախորդին տրամադրվում է շարժական հարթակ՝ որպես գործարկվող ֆայլերի հավաքածու: Այս ֆայլերի հիման վրա մշակողը պետք է ստեղծի հավելված, որը կաշխատի շարժական սարքի վրա: Հավելվածների ստեղծման և հրապարակման ընթացակարգերը, ինչպես բջջային հարթակի, այնպես էլ բջջային հաճախորդի համար, նման են: Օգտագործվում է նույն գործիքը՝ բջջային հավելվածների ստեղծող։

Որպեսզի հավելվածների խանութում հրապարակված շարժական հաճախորդն ունենա ֆիքսված ֆունկցիոնալություն, այն կառուցելիս պետք է նշեք կոնկրետ կոնֆիգուրացիաները, որոնցով կաշխատի այս հավելվածը: Գործողության ընթացքում բջջային հաճախորդը ստուգում է, որ նշված կոնֆիգուրացիաներից միայն մեկն է օգտագործվում և առանց էական փոփոխությունների: Սա հատուկ պաշտպանություն է՝ ապահովելու, որ շարժական հաճախորդը, որը հրապարակված է որոշակի կոնֆիգուրացիաների համար, չի կարող աշխատել այլ կոնֆիգուրացիաների հետ: Ինչպես ցույց է տալիս պրակտիկան, օգտվողների համար հարմար է ունենալ մեկ բջջային հավելված, որը համապատասխանում է մեկ կոնֆիգուրացիայի կամ նմանատիպ կոնֆիգուրացիաների: