1C Enterprise սերվերների կառավարում: 1C Enterprise սերվերների կառավարում 1C Enterprise սերվերների կառավարում 8.2 ինչպես սկսել

1C սերվերի կառավարման վահանակը կամ 1C սերվերի կառավարման վահանակը կամ 1C սերվերի կլաստերի վահանակը 1C Enterprise 8.3-ում ներառված օգտակար ծրագիր է, որն անհրաժեշտ է.

  • Նիստի կառավարում;
  • Տվյալների բազաների ցանկի կառավարում;
  • 1C կլաստերների ստեղծում՝ անսարքության հանդուրժող ճարտարապետության և մասշտաբայնության համար;
  • Աշխատանքային գործընթացների ճկուն կոնֆիգուրացիա;
  • ռեսուրսների սպառման սահմանափակումներ;
  • Աշխատանքային սերվերների կողմից կատարվող առաջադրանքների տարանջատում (առանձին ծառայություններ տարբեր աշխատող սերվերներ փոխանցելու համար);
  • Անվտանգության պրոֆիլի կառավարում:


Տվյալների բազաների կառավարում կլաստերային վահանակում

Հաճախորդ-սերվեր ճարտարապետության մեջ աշխատելիս օգտվողները, ամենայն հավանականությամբ, այս կամ այն ​​կերպ հանդիպում են սերվերի կառավարման վահանակին, համենայն դեպս, երբ նոր տվյալների բազա են ավելացնում տեղեկատվական բազաների ցանկում: Նոր տվյալների բազա ավելացնելու համար անհրաժեշտ է աջ սեղմել տեղեկատվական բազաների վրա և ընտրել «Ստեղծել»:


Կբացվի պատուհան։


Այս պատուհանում լրացվում են DBMS-ին միանալու կարգավորումները, և եթե այն բացակայում է, կարող եք օգտագործել «Ստեղծել տվյալների բազա, եթե այն գոյություն չունի» տարբերակը: Մնացած կարգավորումները կարելի է թողնել որպես լռելյայն:

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


Այստեղ մենք կարող ենք բլոկ սահմանել նիստերի սկզբում (որոշակի ժամանակահատվածի համար բլոկ սահմանել): Քանի դեռ կողպեքը տեղում է, ոչ մի նիստ չի կարողանա միանալ տվյալների բազային:


Դուք կարող եք սահմանել հատուկ հաղորդագրություն, որը օգտվողը կտեսնի միանալու ժամանակ:


Այս տարբերակը կարող է օգտագործվել, օրինակ, տվյալների բազայում սովորական սպասարկում իրականացնելիս (սովորաբար տվյալների բազան թարմացնելիս): Բայց երբ ադմինիստրատորներից պահանջվում է մուտք գործել տվյալների բազա՝ նստաշրջանի արգելափակմամբ, դուք պետք է օգտագործեք «Թույլտվության կոդը» տարբերակը: Նշելով կոդը՝ հետագայում, օգտագործելով այն, հնարավոր կլինի աշխատել տվյալների բազայի հետ։ Օրինակ, ընդլայնման կոդը դնենք 123, որպեսզի հետո կարողանանք մուտք գործել տվյալների բազա։ Պարամետրը պետք է օգտագործվի թույլտվության կոդով /UC.


Արգելափակման պարամետրը կամայական պարամետր է, որը կարող է օգտագործվել ծրագրի կոդում: Արգելափակումը տեղի կունենա ֆունկցիան օգտագործելիս GetSessionLock ().

Սովորական առաջադրանքների արգելափակումը միացված է. սա նշանակում է, որ սովորական առաջադրանքները չեն կատարվի մեր տվյալների բազայում:

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

Աշխատեք Administration Console Session-ի հետ

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


Նիստերի պատուհանն ունի հետևյալ տեսքը.

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

Այստեղ կարող եք նաև ավարտել նիստերը (սկսած պլատֆորմի 1C:Enterprise 8.3 տարբերակից (8.3.13) և սահմանել հաղորդագրության տեքստը, որը օգտատերը կտեսնի 1C thin client-ը փակելիս:




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

Աշխատանքային հոսքեր (կլաստերավորում)

1C 8.2 հարթակում հնարավոր եղավ ձեռքով ստեղծել կիրառական սերվերի աշխատող գործընթացներ (rphost worker process): 8.3-ում աշխատող գործընթացները ստեղծվում են ռագենտի կողմից: Միաժամանակ գործող պրոցեսների քանակը կարող է անուղղակիորեն վերահսկվել աշխատող սերվերների կարգավորումների միջոցով:



Լռելյայն կարգավորումներն օգտագործելիս մեկ rphost կօգտագործվի 8 տեղեկատվական բազայի կամ 128 կապի համար: Եթե ​​ունեք 32-բիթանոց ՕՀ (այսինքն՝ յուրաքանչյուր գործընթացի համար RAM-ի սպառման սահմանափակումներ կան), խորհուրդ է տրվում փոխել այս արժեքները, օրինակ՝ յուրաքանչյուր գործընթացի համար սահմանել մեկ բազա և կրճատել միացումների քանակը: Միացումների օպտիմալ քանակն ընտրվում է էմպիրիկ եղանակով և մեծապես կախված է կոնկրետ կոնֆիգուրացիայից և ֆոնային աշխատանքների քանակից:

Քանի որ մենք դիտարկում ենք աշխատանքային հոսքերի հատկությունները, հարկ է նշել այլ պարամետրեր.

Արժեքը բայթերով (հասանելի է այս աշխատող սերվերի բոլոր կլաստերային աշխատանքային գործընթացներին):

  • -1 - ոչ մի սահմանափակում;
  • 0 – ինքնաբերաբար որոշվում է որպես սերվերի RAM-ի 80%:

Անվտանգ հիշողության սպառում մեկ զանգի համարարժեքը բայթերով:

Կարող է արժեք վերցնել -1-ից մինչև 9 223 372 036 854 775 807:

  • -1 – սերվերի ցանկացած զանգ համարվում է վտանգավոր, եթե սերվերի զանգի ընթացքում հասնում է աշխատանքային գործընթացի առավելագույն հիշողության հզորությունը.
  • 0 – ծավալի արժեքը որոշվում է ավտոմատ կերպով որպես տվյալ աշխատող սերվերի վրա աշխատանքային գործընթացների առավելագույն հիշողության հզորության 5%-ը:

Եթե ​​զանգի ժամանակ հիշողության ծավալը գերազանցում է պարամետրը Անվտանգ հիշողության սպառում մեկ զանգի համար,և բոլոր rphost գործընթացների հիշողության ընդհանուր սպառումը գերազանցել է սահմանված արժեքը Աշխատանքային գործընթացների հիշողության առավելագույն հզորություն,նման զանգը կդադարեցվի։

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

Դրոշ մենեջեր յուրաքանչյուր ծառայության համարնշանակում է, որ յուրաքանչյուր ծառայությանը կհատկացվի կլաստերի կառավարչի առանձին օրինակ (rmngr գործընթաց): Ծառայությունների ցանկ, որոնք աշխատում են կլաստերում.


Դրոշ Կենտրոնական սերվերնշանակում է, որ այս սերվերը կկարողանա կիրառել կապեր և համաժամացնել կլաստերի ռեեստրը:

Աշխատանքային հոսքի կարգավորումները կարող են օգտագործվել միայն CORP լիցենզիաների օգտագործման ժամանակ:Եթե ​​ունեք PRO լիցենզիա, կարգավորումները հասանելի կլինեն, բայց դուք իրավունք չեք ունենա օգտագործելու դրանք:

Սերվերների համախմբում կլաստերի մեջ

1C սերվերները կարող են միավորվել կլաստերի մեջ՝ լուծելու մասշտաբայնության (բեռնվածության բաշխման) և սխալների հանդուրժողականության խնդիրները: Հեշտ է սերվերները միավորել կլաստերի մեջ, պարզապես անհրաժեշտ է ստեղծել աշխատող սերվեր:


Եթե ​​«կենտրոնական սերվեր» տարբերակը տեղադրված չէ նոր սերվերի վրա, ապա այդպիսի սերվերը կհամարվի աշխատող և չի կարողանա ընդունել սեսիաների միացումներ: Սերվերի փոխազդեցության այս ճարտարապետությունն օգտագործվում է մասշտաբայնության համար, այն չի կարող լինել սխալ հանդուրժող, քանի որ դրա համար պետք է լինեն կենտրոնական սերվերներ, իսկ անսարքության հանդուրժողականության մակարդակը պետք է նշվի կլաստերի հատկություններում:



Սխալների հանդուրժողականության մակարդակը սահմանվում է որպես կենտրոնական սերվերների քանակը -1:

Կարգավորումների պատուհանում կարող եք նաև սահմանել ռեսուրսների սպառման սահմանափակումներ յուրաքանչյուր աշխատողի գործընթացում (rphost): Կարգավորումները կսահմանվեն ամբողջ կլաստերի համար:


Վերագործարկման ընդմիջում– վայրկյանների միջակայքը, որից հետո աշխատանքային հոսքը կվերսկսվի: Հետհաշվարկը սկսվում է այս տարբերակը տեղադրելու պահից:

Թույլատրված հիշողության չափըՊետք է սահմանվի այն հիմքի վրա, որ եթե ցուցիչը գերազանցելու պայման դրվի, ապա կգործարկվի նույն չափի մեկ այլ rphost գործընթաց, այսինքն. Ժամանակի ընթացքում մենք կունենանք երկու պրոցես, քանի դեռ հինից կապերը չեն անցել նորին:

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

Հիշողության թույլատրելի քանակի գերազանցման ընդմիջում:Եթե ​​Server Error Count Tolerance հատկության արժեքը 0 է, ապա սխալների քանակի շեղումների ստուգումը չի կատարվում: Անկախ այս հատկության համար սահմանված արժեքից, աշխատանքային հոսքը, որը թույլ է տալիս ոչ ավելի, քան 1 սխալ 100 հարցումների համար, համարվում է նորմալ գործող և չի համարվում խնդրահարույց: Դիտարկենք մի օրինակ, թե ինչպես է աշխատում սերվերի սխալների քանակի «Տանելի շեղում» հատկությունը: Ասենք, որ 100 հարցումների դեպքում վերջին 5 րոպեի ընթացքում գրանցվում է միջինը 2 սխալ։ Եթե ​​սերվերի սխալների քանակի թույլատրելի շեղումը սահմանվում է 50, ապա խնդրահարույց կհամարվի աշխատանքային հոսքը, որի դեպքում գրանցվում է ավելի քան 3 սխալ 100 հարցումների համար:

Գործընթացները վերսկսվում են «փափուկ».

  • Սկսվել է նոր rphost գործընթաց;
  • Հին rphost գործընթացը սպանվել է, բայց չի դադարեցվել;
  • Միացումները նշանակվում են նորաստեղծ rphost գործընթացին, որն անմիջապես լիովին գործարկվում է.
  • Հին գործընթացը կաջակցի դրա վերաբերյալ առկա կոչերին: Արդեն նշանակված զանգերը կաջակցվեն պարամետրում նշված ժամանակի համար «Դադարեցնել գործընթացները, որոնք հետո անջատված են»վայրկյան

Մի քանի սերվերներ կլաստերի մեջ միավորելիս մենք կարող ենք որոշակի ծառայություններ տեղափոխել առանձին սերվերներ: Օրինակ՝ մենք կարող ենք ֆոնային աշխատանքների աշխատանքը տեղափոխել առանձին սերվեր կամ ստեղծել լիցենզավորման սերվեր (սերվեր, որը կբաշխի հաճախորդի լիցենզիաները): Ծառայությունների ամբողջական ցանկը, որոնք կատարում է սերվերը և որոնք կարող են վերանշանակվել.


Հատուկ արտադրական սերվերին ծառայության վերագրումն իրականացվում է ֆունկցիոնալության հանձնարարական պահանջների միջոցով:



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

Տարբեր պատճառներով 1C:Enterprise սերվերի հասանելիությունը կարող է կորցնել, և այնուհետև, երբ մենք փորձենք գործարկել կլաստերային վահանակը, մենք կտեսնենք նույնականացման տվյալներ մուտքագրելու հուշում, բայց մենք չենք կարողանա որևէ բան անել.

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

Եկեք գնանք ամենաարագ ճանապարհը: Մենք ունենք ադմինիստրատորի իրավունքներ սերվերի վրա, այնպես որ մենք կարող ենք դա անել նվազագույն ջանքերով:

Լուծում

Նախ, եկեք դադարեցնենք «1C:Enterprise 8.2 Server Agent» ծառայությունը։ Դա անելու համար գործարկեք հրամանի տողում.

Sc կանգառ» 1 C:Ձեռնարկություն 8. 2 Սերվերի գործակալ"

Նույնը կարելի է անել «Ծառայություններ» գրաֆիկական ծրագրի միջոցով.

Ֆայլի տվյալների հիման վրա կարելի է դատել, որ որոշակի գաղտնաբառով սերվերին ավելացվել է «Adm» ադմինիստրատոր։ Մենք կարող ենք կամ մեզ անհրաժեշտ օգտատիրոջ տվյալները փոխարինել «ճիշտ» գաղտնաբառով, կամ ջնջել սերվերի ադմինիստրատորի մասին գրառումը։ Եկեք ընտրենք վերջին մեթոդը. Այժմ ֆայլի բովանդակությունն այսպիսի տեսք ունի.

Սկսենք սերվերի ծառայությունը: Հաջորդ անգամ, երբ դուք գործարկեք 1C:Enterprise սերվերի կլաստերի վահանակը, ծրագիրը չի պահանջի նույնականացման տվյալներ:

Ներքեւի գիծ

Հոդվածում նկարագրվում է 1C:Enterprise 8.2 սերվերի համար ադմինիստրատորի հաշիվը վերականգնելու մեթոդ: Հարկ է հաշվի առնել, որ ադմինիստրատորի հաշիվները կարող են ավելացվել յուրաքանչյուր տեղեկատվական բազայի համար առանձին: Այս դեպքում նայեք «1CV8Reg.lst» ֆայլին, որը սովորաբար գտնվում է գրացուցակում.

C: Ծրագրի ֆայլեր (x86) 1 cv82srvinforeg_1541"

որտեղ «reg_1541»-ը կլաստերի կարգավորումների գրացուցակն է, որի գրացուցակի անվանումը կախված է դրա կարգավորումներից:

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

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

Այժմ դուք արդեն գիտեք, թե ինչ պետք է անեք: Ոչ մի դեպքում չպետք է համարեք 1C:Enterprise սերվերի ադմինիստրատորի հաշիվների վերակայման նկարագրված մեթոդը որպես հակերություն, քանի որ առանց ադմինիստրատորի իրավունքների նման ոչինչ (սերվերի ծառայության դադարեցում, սերվերի կարգավորումների տեղեկատու մուտք գործելու հնարավորություն և այլն) հնարավոր չէ անել:

Եթե ​​դուք հետաքրքրված եք, ահա որոշ հոդվածներ հարակից թեմայի վերաբերյալ, մասնավորապես 1C:Enterprise 8.2 տեղեկատվական բազայի օգտատերերի համար գաղտնաբառերի ընտրության/վերականգնման վերաբերյալ.

  1. «Որքան թեթև է գաղտնաբառը, այնքան հեշտ է այն»

  2. «Մուտքն առանց հրավերի»

  3. «Վերականգնում ենք հաշիվները: Մենք գրում ենք ունիվերսալ ծրագիր .NET Framework-ում»

21/03/2016

Տարբեր տարբերակների 1C:Enterprise սերվերների համար կառավարման վահանակի օգտագործման առանձնահատկությունները

Ներածություն

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

1C կոնսոլի գրանցում

1C:Enterprise սերվերների համար կառավարման վահանակը գրանցելու համար 1C-ն առաջարկում է օգտագործել RegMSC .cmd գործարկվող ֆայլը, որը գտնվում է 1C սերվերի գրացուցակի bin թղթապանակում: Այս ֆայլը կարող է գործարկվել Windows-ի «Սկսել» ընտրացանկից՝ «1C Enterprise 8 -> Ընդլայնված -> [1C պլատֆորմի պահանջվող տարբերակը] -> 1C Enterprise սերվերի կառավարման օգտակար ծառայության գրանցում»:

RegMSC .cmd ֆայլը պարունակում է հետևյալ սցենարը.

regsvr32 /n /i:user radmin.dll

Այս սցենարի նպատակը միայն radmin .dll բաղադրիչի գրանցումն է: Գործնականում անհարմար է օգտագործել այս սկրիպտը, քանի որ ամեն անգամ, նախքան անհրաժեշտ տարբերակի 1C:Enterprise սերվերների կառավարման վահանակը սկսելը, դուք պետք է գործարկեք համապատասխան RegMSC .cmd ֆայլը: Բացի այդ, այս սցենարը անգործունակ է և պետք է բարելավվի (ամենայն հավանականությամբ, երբ այն կատարեք, դուք կստանաք հաղորդագրություն բաղադրիչի հաջող գրանցման մասին, բայց վահանակը չի աշխատի):

Այսպիսով, մենք ցանկանում ենք ստանալ աշխատանքային սցենար, որը թույլ կտա մեզ ավտոմատացնել և կատարել հետևյալ գործողությունները մեկ սեղմումով.

  1. Գրանցման բաղադրիչներռադմին. անհրաժեշտ տարբերակի dll;
  2. 1C կլաստերային վահանակի գործարկում:

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

rem %1 - 1C:Enterprise-ի ամբողջական տարբերակի համարը

@echo անջատված է

Այս սցենարը պետք է պահվի գործարկվող ֆայլում .bat ձևաչափով (օրինակ՝ «start _console .bat»): Եկեք նայենք այս սցենարին ավելի մանրամասն: Հետևյալ տողը պատասխանատու է radmin .dll բաղադրիչի ճիշտ գրանցման համար.

սկսել / սպասել regsvr32 /s «C:\Program Files (x86)\1cv8\%1\bin\radmin.dll»

1C պլատֆորմի տարբերակի համարը փոխանցվում է նրան որպես պարամետր (%1): Հաջորդ տողը պատասխանատու է MMC կոնսոլը գործարկելու համար 1C:Enterprise սերվերների կառավարման համար snap-in-ով.

սկսել «C:\Windows\System32\mmc.exe» «C:\Program Files (x86)\1cv8\common\1CV8 Servers.msc»

start_console 8.3.7.1873

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

Խնդրում ենք նկատի ունենալ, որ առաջարկվող սցենարներն օգտագործում են բաղադրիչների 32-բիթանոց տարբերակները: Երբ փորձում եք գրանցել 64-բիթանոց բաղադրիչը նույն կերպ, դուք կստանաք հաղորդագրություն, որ այն հաջողությամբ գրանցվել է, բայց հետո, երբ գործարկեք 1C:Enterprise սերվերի կառավարման վահանակը, ամենայն հավանականությամբ կտեսնեք այնպիսի սխալ, ինչպիսին է.

MMC-ն չկարողացավ ստեղծել snap-ը, Անունը՝ 1C:Enterprise (x86-64) սերվերներ, CLSID՝…

Քանի դեռ այս խնդիրը չի լուծվել, 1C:Enterprise սերվերների համար մի քանի 64-բիթանոց կառավարման վահանակներ օգտագործելը մեկ սերվերի ներսում հնարավոր չէ: Եթե ​​ունեք այլ տեղեկություններ և գիտեք, թե ինչպես լուծել այս խնդիրը, մենք ուրախ կլինենք թարմացնել հոդվածը:

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

Հոդվածում մենք նկարագրեցինք մի մեթոդ, որը թույլ է տալիս օգտագործել մի քանի կառավարման վահանակներ տարբեր տարբերակների 1C:Enterprise սերվերների համար: Սա անհրաժեշտ է, եթե դուք աշխատում եք մի քանի աշխատանքային կամ թեստային տվյալների բազաներով սերվերի վրա, որոնց համար օգտագործվող 1C սերվերի տարբերակները տարբեր են:

Հուսով ենք, որ դուք հեշտությամբ կարող եք կատարել ձեր անհրաժեշտ առաջադրանքը և շարունակել վայելել 1C արտադրանքները: Դե, եթե ինչ-որ բան ձեզ մոտ չի ստացվում, կամ ինչ-որ դժվարությունների եք հանդիպում, մենք անպայման կօգնենք:

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

Մասնավորապես DroidRAC-ի հետ ժամանակի ընթացքում առաջացան հետևյալ խնդիրները.

DroidRAC2 0.0.4

Ամբողջովին վերաշարադրված՝ ոճային, նորաձև, երիտասարդական (Kotlin, JetPack, Single-activity)

Նոր api 1C-ից, համատեղելի 8.3.11+-ի հետ

Առաջին տարբերակում, ավանդույթի համաձայն, միայն կարդալու և մի փոքր հեռացում (օրինակ՝ ջնջելով օգտատերերի նիստերը)

Ավելացվեց «Ստեղներ» բաժինը: այն հավաքում է լիցենզիայի տվյալները օգտատերերի բոլոր աշխատանքային հոսքերից/սեանսներից՝ վերահսկելու օգտագործվող լիցենզիաների քանակը

Սերվերի և կլաստերի ադմինիստրատորների ավելացում/փոխում

Կատարման հաշվիչի հատկությունների դիտում

Կլաստերի և արտադրական սերվերի հատկությունների խմբագրում

DroidRAC2 0.0.7

Փոխել կլաստերի բաղադրիչների բոլոր հատկությունները (որոնք չեն աջակցվում նախորդ տարբերակներում)

DroidRAC2 0.0.8

Հաշվիչների և կատարողականի սահմանափակումների ավելացում/հեռացում
+ նոր տվյալների բազաների ավելացում

DroidRAC2 0.1.0

Որոնել RAS. Թույլ է տալիս գտնել և ավելացնել ras հասցե տեղական ենթացանցից: Հնարավոր է որոնել այլ ենթացանցերում և ոչ ստանդարտ պորտում։ Բայց! Կախված ձեր իրավասությունից՝ այլ մարդկանց ենթացանցերի սկանավորումը կարող է տարբեր գանձումներ առաջացնել:
- ցուցակներում տողերի բազմակի ընտրություն
- ընտրության ռեժիմում հասանելի են ցուցակի տողերի ընդհանուր թիվը և ընտրված տարրերի վրա կատարվող գործողությունները
- վերացնել նիստերը և կապերը բազմակի ընտրության ռեժիմում: Սեսիաները ջնջելիս մի ջնջեք RAS նիստը՝ սեփական կապը չկորցնելու համար: Կապերը ջնջելիս հիշեք, որ դուք կարող եք ջնջել միայն նիստի հետ կապված կապերը, բայց դա հաճախ անիմաստ է, քանի որ 1C-ը վերականգնում է դրանք

DroidRAC2 0.1.2

Կլաստերների ավելացում/հեռացում

Արտադրության սերվերների ավելացում/հեռացում

Որոնեք մեծատառերի նկատմամբ անզգայուն ցուցակներում

Սխալի ուղղում

Փորձարկումն իրականացվել է 8.3.13.1690 հարթակի համար

Բարոյական աջակցության համար կարող եք նաև ներբեռնել կից ֆայլը infomany-ի համար, եթե ցանկանում եք աջակցել նախագծին: Գործիքի մշակման արագությունը ուղղակիորեն կապված է դրա պահանջարկի հետ:

Հաճելի կլինեն նաև աստղերը, մեկնաբանությունները, զարգացման ցանկությունները հեղինակին։