Paylanmış İnformasiya Bazası: Əsaslar. RDB qurmaq "sıfırdan Enterprise Accounting 1s 8.3 bir qabırğa necə yaradılır

Bu mənim ilk yazımdır, konstruktiv tənqid xoşdur.

Hədəf auditoriyası RDB ilə ilk dəfə qarşılaşanlardır.

RDB vəzifələri

Başlamaq üçün ilk şey "Niyə RDB lazımdır?" Sualına cavab verməkdir. Çoxlu cavablar var, xüsusən:

1. Ayrı-ayrı DB-lərdə işləyən filiallarımız var. İndi biz onların arasında məlumatın sinxron olmasını istəyirik;
2. Filiallarımız var, lakin verilənlər bazasına yük çox yüksəkdir (məlumat bazanın ölçüsü deyil, əməliyyatların bloklanması deməkdir) və onlayn aktuallıq (bir neçə dəqiqə ərzində aktuallıqla qarışdırılmamalıdır, onlayn hər əməliyyatdan sonra məlumatların ötürülməsidir. ikinci node) tələb olunan filiallar üçün məlumat yoxdur;
3. Yalnız məlumatların daxil olduğu filiallarımız var (məsələn, pərakəndə mağazalar), buna görə də mərkəzi məlumat bazasına yükü əhəmiyyətli dərəcədə azalda bilərik;
4. Təhlükəsizliyə görə, biz istəyirik ki, filiallar nəzəri cəhətdən belə (inzibatçı parolu ilə) şirkətin balans hesabatı kimi vacib məlumatlara giriş əldə edə bilməsinlər.

Bir halda 2-ci və 4-cü suallar, digərində 2-ci və 3-cü suallar mənə aid idi. Birinci abzas çox genişdir və bu maddənin əhatə dairəsində nəzərdən keçirilməyəcək.

Mübadilə fayllarının daşınması məsələsini dərhal nəzərdən keçirmək daha yaxşıdır, çünki bəzi hallarda məlumat mübadiləsinin həyata keçirilməsinə əhəmiyyətli məhdudiyyətlər qoya bilər. Əvvəlcə RDB qovşaqlarının hansı filiallarda görünəcəyini müəyyən etməlisiniz (adətən bunlar regional filiallardır). Sonra, RDB qovşaqlarını harada quraşdırmaq istədiyimizi və onların onlayn uyğunluğa ehtiyacı olub olmadığını nəzərdən keçiririk. Məsələn, üçün pərakəndə satış mağazaları hətta modemi quraşdırmaq və quraşdırmaq həmişə mümkün deyil simsiz rabitəçox baha olacaq. Burada qərar qəbul etməlisiniz - bəlkə də bu mağaza oflayn rejimdə işləyə və vaxtaşırı olaraq mərkəzlə mübadilə edə bilər (gündə bir dəfə / həftədə bir dəfə) fiziki mühitdən, məsələn, flash sürücüdən istifadə edərək.

Bəzi hallarda fiziki media vasitəsilə mübadilə mümkün deyil, məsələn, bu, yüksək sürətli rabitənin qurulması ilə bağlı əhəmiyyətli problemlərin olduğu çox uzaq bir filialdır. Burada mübadilə olunan məlumatın miqdarını təxmini hesablamağa dəyər. Tez-tez, aktuallığı ilə saatda bir dəfə və ya gündə bir neçə dəfə 32k modem kifayətdir. Bununla belə, yadda saxlamaq lazımdır ki, məlumat yeniləmələri ilə yanaşı, bəzən konfiqurasiyanın özünə və ya xarici fayllara (çap formaları, məhsul şəkilləri) yeniləmələr göndərməli olacaqsınız, buna görə də vaxtaşırı mübadilə faylının artacağı vəziyyət yaranacaq. əhəmiyyətli dərəcədə bu cür yeniləmələrə görə.

Topologiya

Ümumilikdə cavablandırılmalı olan aşağıdakı sualları aldıq:

1. Hansı şöbələrdə RDB qovşaqlarının quraşdırılmasına zəmanət veriləcək və orada yüksək sürətli kanal quraşdırmaq mümkündürmü;
2. Hansı bölmələrdə RDB qovşağının quraşdırılması tələb olunmur;
3. Hansı şöbələr bir neçə saat ərzində aktuallıqla işləyə bilər;
4. Hansı şöbələr oflayn işləyə bilər (gündə 3-4 dəfədən az məlumat mübadiləsi).

Bu suallara cavab verərək RDB-mizin təxmini sxemini alırıq. Böyük şirkətlər üçün adətən belə bir şey çıxır:

Şəkil 1. Böyük bir şirkət üçün tipik RDB sxemi

"Filial" qovşaqları ilə hər şey nisbətən aydındırsa - bunlar avtomatlaşdırma tələb edən böyük mərkəzlərdirsə, "Mağaza" qovşaqları məlumat daxil edərkən verilənlər bazasında ciddi yükü olan bir qovşaq deməkdir, yükü azaltmaq üçün ayrılmalıdır. Məsələn, 50 kassası və gündəlik dövriyyəsi 10 000 ədəddən çox olan mağaza.

• Mağazalar - öz dövriyyəsi və hərəkəti haqqında məlumatların daxil edilməsi Pul. Analitika səthidir, yalnız mağazanız üçün.
• Filiallar - avtomatlaşdırılmamış məntəqələrin məlumatların daxil edilməsi, mühasibat uçotu, əmək haqqı və kadrlar, istehsalat və s. Öz filialınızda analitik.
• Mərkəz - avtomatlaşdırılmamış filialların məlumatlarının daxil edilməsi. Bütövlükdə müəssisənin analitikası.

Hər bir qovşaqda verilənlər bazasının hansı məqsədlər üçün istifadə olunacağını anlamaq vacibdir. Məqsədlərdən həyata keçirmək üçün zəruri olan vəzifələr qurulur, məsələn:

• Filiallar bir-birinin qarşı tərəfi ilə hesablaşmaların tarixini görür;
• Mağazalar müəssisənin bütün (və ya bir hissəsində) malların qalıqlarını görür;
• Gəlir/xərclər, büdcənin icrası və s. analitika yalnız öz departamentinizin iyerarxiyası daxilində görünür;
• Mühasibat uçotu, əmək haqqı və kadrlar yalnız öz departamentinin iyerarxiyasında görünür;
• Nomenklatura, onun bütün xassələri və xüsusiyyətləri bütün RDB qovşaqlarında görünür;
• Şöbələrin iyerarxiyasına nisbətən bütün məlumatlar yuxarı qalxır, lakin aşağı süzülür;
• Mərkəzdə şirkət haqqında tamamilə bütün məlumatlar var.

Bu cür sualları qarşınıza qoyaraq, ən çətin suala cavab verə bilərsiniz - RDB qovşaqları arasında hansı məlumat, harada və necə işləməlidir? Niyə ən çətin? Düyünlər arasında hansı məlumat dəstlərinin işlədiyini bilməklə, verilənlərin məntiqi olaraq ardıcıl qalması üçün cari verilənlər bazasını necə “kəsəcəyinizi” aydın başa düşə bilərsiniz. Məsələn, malların balansı haqqında məlumatları cari ehtiyatlar haqqında məlumatlardan ayırmaq olmaz.

İndi məlumat axınlarından asılı olaraq RDB sxemini yenidən çəkək:

Şəkil 2-də nə görürük? Şirkətin bölmələrinin iyerarxiyasına uyğun olaraq verilənlər bazası qovşaqları arasında informasiya axınının topologiyası düzülüb. Həmçinin "Mərkəz 2" node əlavə edildi, niyə? Ulduz topologiyasını həyata keçirərkən mərkəzdəki yük həmişə periferik qovşaqlardakı yükdən daha yüksəkdir və çox vaxt düyünün özü tərəfindən yaradılan yük artıq yüksək olur. "Mərkəz 1" və "Mərkəz 2" qovşaqlarından istifadə nümunələri:

1. "Mərkəz 1" yalnız digər RDB qovşaqlarının məlumatlarını birləşdirməyə xidmət edir. Buna yalnız administratorun girişi var. “Mərkəz 2” baş ofisin işinə xidmət edir;
2. “Mərkəz 1” baş ofisin işinə xidmət edir. Bununla belə, “Mərkəz 2” qovşağında ağır analitik, test, verilənlər bazasında böyük yük yaradan əməliyyatlar həyata keçirilir; məsələn, qapalı dövrlərin ardıcıllığının dəyişdirilməsi, yenidən yerləşdirilməsi, uzun müddət ərzində müəssisə üzrə ümumi hesabatların yaradılması, məlumatların dəyişməsinə səbəb olan analitikanın yaradılması;
3. “Mərkəz 1” baş ofisin işinə xidmət edir. "Mərkəz 2" gözlənilməz vəziyyətlər üçün ehtiyatdır sürətli bərpa bütün RBD.

Mübadilə həyata keçirilməsi

RDB-nin işləməsi üçün 2 seçim var:

1. Avtomatik - istifadəçi müdaxiləsi olmadan baş verir. Fövqəladə hallara nəzarət ya verilənlər bazası administratoruna, ya da qabaqcıl istifadəçiyə həvalə edilir;
2. Manual - mübadilə yalnız istifadəçinin istəyi ilə baş verir.

Öz təcrübəmdən mən həmişə bütün tətbiqləri avtomatik versiyaya aparmışam. Mübadilə fayllarının nəqli ilə bağlı problemlər varsa (qovşaqda şəbəkənin olması daimi deyil), o zaman istifadəçinin icazə verdiyi maksimum "İndi mübadilə et" düyməsini sıxmaq idi. Məlumatların yenilənməsi ilə yanaşı, konfiqurasiyanın yeniləndiyi vəziyyətlər də tam avtomatik olanlara (məsələn, üçüncü tərəf proqram təminatından istifadə etməklə) səbəb olur.

Yeniləmə paketlərinin formalaşdırılması

Hansı RDB qovşaqlarına hansı funksiyaların təyin edilməsi ilə bağlı birmənalı qərar olduğundan, yalnız bu node ehtiyac duyduğu məlumat paketini formalaşdırmaq mümkündür. Bir tərəfdən, qovşaqlar arasında hansı növ obyektlərin sinxronlaşdırılacağını müəyyən etmək lazımdır. Məsələn, "Mağaza 1" qovşağı üçün uçot registrləri ümumiyyətlə sinxronlaşdırılmamalıdır, çünki məlumatlar yalnız filial saytı səviyyəsində daxil edilir. Digər tərəfdən, mübadilə edilməli olan məlumat növləri şöbəyə istinadla süzülməlidir. Məsələn, "2 nömrəli filialın 1-ci mağazası" qovşağının pul qəbulu haqqında məlumatlar yalnız "Filial 2", "Mərkəz 1" və "Mərkəz 2" qovşaqlarında yerləşdirilə bilər.

Bununla belə, əks problem var, əgər mübadilə məlumatlarını çox filtrləsəniz, məlumat paketi məntiqi bütövlüyünü itirəcəkdir. Məsələn, ehtiyatların qalıqları anbarlar tərəfindən, ehtiyatlar isə bütövlükdə şirkət tərəfindən uçota alınır, onda ehtiyatların qalıqlarını anbarlar üzrə süzgəcdən keçirsəniz və ehtiyatları süzməsəniz, məlumatlar yanlış olacaq.

Obyektin ömrünün hansı mərhələsində mübadilə olunacağına da qərar verməlisiniz. Məsələn, yalnız dərc edilmiş hesab-fakturalar dəyişdirilə bilər, ancaq saxlanılan fakturalar deyil. Ya Mağaza hesab-fakturaları, hətta düzəliş edildikdən sonra da heç vaxt Mərkəz qovşağından endirilmir, lakin əks effekti nəzərə almaq lazımdır - məlumatlar sinxronizasiya oluna bilər və ya bəzi dəyişikliklərin üzərinə yazıla bilər.

Anlamaq vacibdir - qovşaqlar arasında mübadilə edərkən onlardan biri prioritetdir. Vəziyyəti nəzərdən keçirin:

1. Mağaza 1 qovşağında sənəd yaratdı;
2. Mübadilə zamanı o, "1 nömrəli filial" qovşağına daxil oldu;
3. Sənəd hər iki qovşaqda eyni vaxtda düzəldilir.

Sənədlərdən hansı doğru hesab ediləcək? 1C 8.x-də, "Mübadilə Planları" mexanizmindən istifadə edərkən, standart olaraq, əsas node prioritetdir, yəni. bu halda, "Mağaza 1" qovşağında edilən dəyişikliklər itiriləcək və "Filial 1" qovşağının məlumatları ilə əvəz olunacaq.

İki əlaqəli obyektin eyni vaxtda düzəldildiyi başqa, daha mürəkkəb bir vəziyyət var. Məsələn, çıxan faktura və üzərindəki PKO müxtəlif qovşaqlarda düzəldilir, qiymətlər, ödəniş məbləği, podratçılar və s. dəyişdirilərsə, bütövlüyün itirilməsi ehtimalı var.

Obyektlərin silinməsinə nəzarət etmək də vacibdir, əks halda bu, məsələn, hesab-fakturanın artıq mövcud olmayacağına, lakin mühasibat hərəkətlərinin qalmasına səbəb ola bilər.

1C 8.x-də mübadilə mexanizmləri

Həyata keçirmək üçün iki yanaşma var:

1. Mexanizm "Mübadilə planları";
2. Obyekt qeydiyyatının fərdi həyata keçirilməsi.

Gəlin hər iki variantı nəzərdən keçirək.

Mübadilə planlarının mexanizmi heç bir konfiqurasiya olmadan bir neçə dəqiqə ərzində tam məlumat mübadiləsi ilə RDB yaratmağa imkan verir. Əgər siz "Paylanmış məlumat bazası”, sonra yeniləmə paketi yaradıldıqda konfiqurasiya yeniləmələri də endiriləcək. Cəmi bir neçə dəqiqə ərzində mübadilə icazəsi / rədd edilməsi qaydalarını konfiqurasiya edə bilərsiniz müxtəlif növlər mübadilə planının tərkibini açaraq məlumat. Əgər siz "Avtomatik qeydiyyat" bayrağını "Disable" mövqeyinə qoyursanız, o zaman verilmiş növü obyekt, əlavə səylər olmadan, heç vaxt dəyişdirilməyəcək.

Niyə qeydiyyat lazımdır, niyə hər şeyi bir anda yükləməyəsiniz? İstənilən halda, yalnız verilənlər bazası vəziyyəti dəyişikliklərini ehtiva edən fayl verilənlər bazasının özünün tam snapshotından kiçik olacaq. Buna görə də, tam boşaltma variantına baxılmayacaq.

Şöbəyə aid olmaqla məlumatların filtrasiyasını necə qurmaq olar? Proqramlaşdırmalı olduğunuz yer budur. Tətbiqimdə hər hansı bir obyektin qeydə alınması üçün “Qeydiyyatda” hadisəsinə abunə quruldu, burada “Məlumat mübadiləsi.Recipients” xüsusiyyətindən istifadə edərək bu obyektin alıcılarının siyahısını təyin edə bilərsiniz. Bunlar. boşaldarkən standart vasitələr siyahıda olmayan qovşaq üçün obyekt yüklənməyəcək. Başqa bir həll yolu var - mübadilə planı modulunun "Məlumatları Qulluğa Göndərərkən" və "Masterə Məlumat Göndərərkən" prosedurlarında obyekti boşaltarkən birbaşa obyekti boşaltmağı seçə bilərsinizmi?

Hər iki variant etibarlıdır. Bununla belə, mən ən yaxşı variant kimi birincisini seçdim, çünki boşalma xüsusiyyətinin hesablanması obyekt yazıldıqda dərhal baş verir ki, bu da obyektin qeydinin müddətini 3-5% artırır (optimallaşdırıla bilər, bəzi hallarda 0,01%-ə qədər artırıla bilər, yəni. orta hesabla 0,1-0,3 saniyə və verilənlər bazasında artıq əhəmiyyətli yük yaradan məlumat göndərilərkən birbaşa obyektin boşaldılmasının hesablanması halında, bu vaxt bir neçə dəqiqəyə qədər olacaq.

“Mübadilə planları” mexanizminin işini tam başa düşmək üçün “1C: Müəssisə 8 sistemində peşəkar inkişaf” kitabının 15-ci fəslini oxumağı tövsiyə edirəm, Gabets A.P., Qonçarov D.I.

İstənilən yerli tətbiq, mənim fikrimcə, ya Mübadilə Planları mexanizmini təkrarlayacaq, ya da dəyişiklik edildikdən dərhal sonra obyekti boşaldacaq, ya da Mübadilə Planları mexanizmindən daha çox yükü boşaldacaq (məsələn, bu gün üçün bütün dəyişiklikləri boşaltın). Tətbiq təcrübəsi olmadığı üçün bu məsələyə baxmıram.

Nəqliyyat

Faylların masterdan kölə qovşağına daşınması vəzifəsi maksimum nasazlığa dözümlülüyünə endirilir. Faylların şifrlənməsi və ya təhlükəsiz kanal vasitəsilə ötürülməsi qeyri-adi deyil. Faylları ötürmək üçün bir neçə fərqli xidmətdən istifadə etmək və ya bir neçə fərqli əlaqə variantını hazırlamaq məsləhətdir. Məsələn, əsas ötürmə üsulu VPN tuneli vasitəsilə qoşulmuş FTP serverindən istifadə etməkdir; ehtiyat nüsxə TLS bağlantısı olan e-poçt serveridir. Niyə başqa xidmətlə ehtiyat kanala ehtiyacınız var? Təcrübə göstərir ki, 2 fərqli FTP serverindən istifadə FTP server və E-Mail-dən daha az etibarlıdır.

Xidmət paketi yaratmaq üçün xidməti nəqliyyat xidmətindən ayırmağı tövsiyə edirəm, bu, bütün məlumat mübadiləsi kompleksinin nasazlıqlara dözümlülüyünü artıracaqdır. Faylların daşınması xidməti işləmirsə, yeniləmə paketlərinin yaradılması xidməti normal işləməyə davam edəcək və müəyyən şərtlər altında nəqliyyat xidmətini yenidən işə salacaq və əksinə.

Mənim RDB Tətbiqim

Tətbiq tamamilə avtonomdur, buna görə də maksimum nasazlığa dözümlülük bir alt vəzifə idi. Bu, 2 xidmətlə nəticələndi - yeniləmə nəqliyyat xidməti və məlumatların idxal/ixrac xidməti. Hər iki xidmət bir-birindən müstəqil fəaliyyət göstərir.

Hər bir uğurlu məlumatın idxal-ixrac dövründən sonra bu qovşaqla sonuncu mübadilə vaxtı saxlandı. Mübadilə çox uzun müddət baş vermədisə, nəqliyyat xidməti ikinci qovşağın hələ də yeniləmələri alacağına və fayllarını yükləyəcəyinə əsaslanaraq, mövcud olan bütün rabitə kanallarına faylları yükləməyə başladı. İstisna hallarda sistem özü administratora mesaj göndərir Ətraflı Təsviri səhvlər.

Trafikin miqdarını azaltmaq üçün xml faylları zip arxivlərinə yığılmışdır. Sistem iki növ nəqliyyatı dəstəkləyir - FTP və E-poçt.

Məlumat filtri üçün parametrlər kimi iki cədvəl var. bir ( cədvəl hissəsi mübadilə planları) ümumi atributlar üçün şərtlər (hər bir obyekt üçün sistem bu atributu tapmağa çalışır), xüsusi metadata obyekti üçün başqa bir parametrdə saxlanılır. Hər hansı bir obyekti qeyd edərkən, şərtlər ilk növbədə ümumi atributlar (məsələn, Bölmə) üzrə axtarılır, bundan sonra sistem bütün atributları üçün bu tip obyekt üçün şəxsi qaydanın olub olmadığını müəyyən etməyə çalışır. Siyahıları süzgəcdən keçirməyi məsləhət görmürəm - səhv etmək üçün böyük bir fürsət var, məsələn, fakturanın cədvəl hissəsindən bir neçə sətir yox olacaq, qalanları isə bütün yol və əksinə hərəkət edəcək.

Xidmətlərin hansı sistem istifadəçisi altında işləyəcəyini anlamaq vacibdir, çünki hətta 1C müvəqqəti qovluğunda da fayl yaratmaq üçün kifayət qədər hüquqlar olmaya bilər. Sazlama üçün hər bir müvəffəqiyyətlə tamamlanan əməliyyatı jurnala və ya txt faylına yazmağı tövsiyə edirəm. 1C 8.1 icrasında server kodu sazlana bilməz.

Tətbiqimi sazlamaq və fərdiləşdirmək rahatlığı üçün təsviri emalın özündə olan "Dəyişikliklərin qeydiyyatı" emalını əlavə edirəm.

Məlumat mübadiləsi kompleksinin ümumi iş sxemi Şəkil 3-də göstərilmişdir.

Məlumatların filtrasiyası hər bir obyektin "BeforeWrite" hadisəsinə abunə olduqda baş verir. Unutmayın ki, ilkin qovşaq şəklini yaratarkən məlumatlar da süzülməlidir. İlkin görüntünün yaradılması proseduru olduqca uzundur, ona görə də onun kodunu maksimuma optimallaşdırmağı məsləhət görürəm (məsələn, filtrləmə parametrlərini keşləmə).

Son söz

Əsas vəzifə sualların siyahısını cavablandırmaqdır:

1. Nə üçün bizə RDB lazımdır?
2. RDP müştərisi ilə işləməyin nəyi pisdir?
3. RDB qovşaqlarını harada və niyə quraşdırmaq istəyirik?
4. Yeniləmələr necə daşınacaq?
5. Səhvlərə dözümlülük hansı səviyyədə həyata keçiriləcək?

"Qeydiyyat Dəyişiklikləri" ilə işləmək

Emal sizə obyektlərdə edilən dəyişiklikləri məcburi yoxlamağa imkan verir. Dəyişikliklərin qeydiyyatı üçün bir neçə variant var:

1. Əgər hər hansı metaməlumatda qeyd qutusu qoyulubsa və heç bir obyekt SEÇİLməyibsə və "Bütün dəyərlərə görə boşaldın" bayrağı QEYDİYYATDAN YALNIZ SEÇİLMİŞ CƏDVƏL QEYDİYYATDIR;
2. Əgər "Bütün dəyərlərə görə boşalt" bayrağı qoyulubsa, o zaman seçilmiş metadata dövrədəki bütün obyektlər tərəfindən boşaldılacaq;
3. Əgər keçid "Yalnız seçilmiş obyektləri boşalt" rejiminə qoyulubsa, onda yalnız seçilmiş obyektlər boşaldılacaq (məsələn: obyektləri seçmədən metaməlumatlarda bayrağın qoyulması "Bütün dəyərlərə görə boşalt" bayrağına və keçiddəki keçidə bərabərdir. "Yalnız seçilmiş obyektləri boşalt" mövqeyi);
4. Əgər keçid "Seçilmiş və birbaşa əlaqəli obyektləri boşalt" rejiminə qoyulubsa, o zaman seçilmiş obyektlər və mövcudluğu seçilmiş obyektin mövcudluğundan asılı olan obyektlər boşaldılacaq (məsələn: axtarışlarda tabeli axtarışlar var);
5. Keçid "Bütün bağlantılar ilə boşaltma" rejiminə qoyulubsa, seçilmiş obyektə keçid olan BÜTÜN obyektlər boşaldılacaq.

Əlavə funksionallıq mövcuddur:

• Qeydə alınmış obyektlərin yenidən qeydiyyatı, tez-tez sazlama üçün tələb olunur;
• Qeydiyyatdan keçmişlərin silinməsi tez-tez sazlama üçün tələb olunur;
• Dəyişiklikləri çap edin - dəyişdirilmiş kimi qeyd olunan obyektlərin tam siyahısını çap edin;
• Konfiqurasiya ağacının çapı yalnız bütün konfiqurasiyaya baxmaq rahatlığı üçündür.

1C 8.3 Mühasibat uçotunda (və digər konfiqurasiyalarda) paylanmış verilənlər bazasının (RIB) yaradılması və konfiqurasiyası bir verilənlər bazasına eyni vaxtda qoşularkən bir neçə istifadəçinin işləməsi mümkün olmadığı hallarda lazımdır. Bu günlərdə bu olduqca nadirdir, çünki standart uzaqdan işləyən masaüstü əla işləyir və təmin edən digər proqramlar var uzaqdan əlaqə verilənlər bazasının yerləşdiyi mərkəzi kompüterə.

Ancaq buna baxmayaraq, sadəcə İnternetin olmadığı vəziyyətlər var. Və məlumatlar bir infobazada bitməlidir. Paylanmış verilənlər bazası bunun üçündür.

Adətən əsas baza mərkəzi baza, qalan hissəsi isə periferik adlanır. Əsas odur ki, ya əl ilə, ya da içəridə avtomatik rejim(konfiqurasiyadan asılı olaraq) verilənlər bazaları birinə birləşdirilir. Yeni daxil edilmiş sənədlərin nömrələri və kataloq kodlarının təkrarlanmaması üçün hər bir verilənlər bazasına bir prefiks təyin olunur.

Bu təlimatda biz mərkəzi və periferik verilənlər bazası yaratmaq və onlar arasında mübadiləni yoxlamaq üçün bir nümunədən istifadə edəcəyik. Bu təlimat həm 1C 8.3 Mühasibat Uçotu, həm də 1C Ticarət İdarəetmə (UT) və digər konfiqurasiyalar üçün uyğundur.

Əsas (mərkəzi) paylanmış RIB məlumat bazasının qurulması

1C "İdarəetmə" menyusuna gedək, sonra "Məlumatların sinxronizasiya parametrləri" bağlantısını izləyin. Açılan pəncərədə "Məlumatları sinxronizasiya et" qutusunu yoxlayın. "Data Sync" linki aktiv olacaq. Dərhal burada əsas məlumat bazası üçün prefiksi təyin edəcəyik - məsələn, "CB":

"Məlumatların sinxronizasiyası" bağlantısı ilə gedirik, "Məlumatların sinxronizasiyasını qurun" düyməsi olan bir pəncərə açılacaqdır. Bu düyməni kliklədiyiniz zaman açılan siyahı açılacaq, burada "Tam" rejimini seçməlisiniz. Sinxronizasiya yalnız bir təşkilat üçün tələb olunursa, "Təşkilata görə ..." seçməlisiniz.

Növbəti pəncərədə proqram bizə ehtiyat nüsxəsini çıxarmağı təklif edəcək. Bunu etməyi tövsiyə edirəm, çünki aşağıdakı konfiqurasiya addımları geri qaytarıla bilməz.

Yaradıldıqdan sonra ehtiyat nüsxəsi"Növbəti" düyməsini basın. Növbəti addımda sinxronizasiyanın necə olacağına qərar verməliyik:

• yerli kataloq və ya yerli şəbəkədəki kataloq vasitəsilə;
• FTP vasitəsilə internet üzərindən.

Nümunənin sadəliyi və aydınlığı üçün biz yerli kataloq seçəcəyik. Aşağıdakı yolu göstərdim: "D: \ Baza 1C \ Sinxronizasiya". Girişi yoxlamaq artıq olmaz bu kataloq, bunun üçün xüsusi bir düymə var:

267 1C video dərsini pulsuz əldə edin:

FTP və e-poçt vasitəsilə sinxronizasiya qurmaqla növbəti addımları atlayırıq. Əsas və periferik verilənlər bazalarının adları üçün parametrlər üzərində dayanırıq. Burada periferik baza üçün prefiksi təyin edirik:

Unutmayın ki, hər bir bazanın prefiksləri unikal olmalıdır. Əks təqdirdə, "Birinci məlumat bazasının prefiks dəyəri unikal deyil" xətası alacaqsınız.

"Növbəti" düyməsini basın, daxil edilmiş məlumatları yoxlayın və yenidən "Növbəti" düyməsini basın, sonra - "Bitir". sahəsində " Tam adı fayl bazası" qovluğunda sinxronizasiya üçün yaradılmış 1Cv8.1CD faylını təyin edin. Paylanmış baza 1C-nin ilkin görüntüsünü yaradırıq:

1C-də ilkin RIB şəklini yaratdıqdan sonra sinxronizasiya cədvəlini təyin edə və ya əl ilə sinxronlaşdıra bilərsiniz:

Sinxronizasiyadan sonra siz yeni verilənlər bazasına qoşula və mərkəzi verilənlər bazasından məlumatların oraya yükləndiyinə əmin ola bilərsiniz:

Sadəcə dərhal yeni periferik verilənlər bazasında Administrator hüquqları ilə ən azı bir istifadəçi yaradın.

Kenar verilənlər bazasında sinxronizasiya qurun

1C periferik bazasında quraşdırma daha asandır. "Məlumatların sinxronizasiyası" qutusunu yoxlamaq və eyni adlı linki izləmək kifayətdir. Və demək olar ki, dərhal "Sinxronizasiya" düyməsi ilə pəncərəyə daxil oluruq. Gəlin periferik verilənlər bazasında test elementi yaratmağa və onu RIB-dən istifadə edərək əsas birinə yükləməyə çalışaq:

25 oktyabr 2016-cı il

2 qovşaq və 10 üçün RIB qurmaq və dəstəkləmək arasında böyük fərq yoxdur, lakin uzaq nöqtələrin sayı yüzdən çox olduqda, tamamilə fərqli məsələlər həll edilməlidir.

İlkin məlumatlar:

Konfiqurasiya: Pərakəndə 2.2
Platforma 1C: 8.3.7.1970



Layihənin müddəti: bir il.



Memarlıq:

Əvvəlcə RIB sxeminə qərar verdik. Mümkün olsa da, "ulduz" sxeminə diqqət yetirmək qərara alındı; texnoloji hədlərə çatdıqda - qar dənəciyi.





Məhdudiyyətlər:
- 2 GB RAM
- 1 fiziki prosessor


Yuxarıda göstərilənlərin hamısından, verilənlər bazasının maksimum həcminə məhdudiyyət əsasən zəhlətökəndir.

Ancaq bu, yalnız onu sahədəki köhnəlmiş məlumatlardan təmizləmə prosedurunu təşkil etməli olduğunuz deməkdir.

1C və MS SQL serverləri üçün ayrıca fiziki server ayrılmışdır. Birjaların və uzunmüddətli əməliyyatların əsas yükünü daşıyacaq.
Final müştəri kompüterləri dəyişdirilmir, çünki onlar nazik bir müştəri ilə işləyəcəklər və onlara yük minimal olacaqdır.
.


əsas parametrlər

60 düyündə RIB-nin həyata keçirilməsi üçün ilk layihəm olduğu UT 10.3-dən bəri, əlbəttə ki, "körpünün altından çoxlu su axdı".

1C yerində dayanmadı. Retail 2.2 indi seçmə məlumatların yüklənməsi ehtiyacını nəzərə alır.
Mağaza məlumat bazasına yalnız ona aid olan məlumatlar yüklənəcək:
- Bütün kataloqlar (xüsusi olanlar istisna olmaqla)
- Bu mağazanın sənədləri

Başqa bir sual ondan ibarətdir ki, bu və ya digər şəkildə verilənlər bazasına qovşaq əlavə etmək, yazıldıqda hər bir ümumi element üçün qeydiyyat cədvəlinə başqa bir giriş əlavə etmək deməkdir.





1) Yükləmək və yükləmək üçün onu ayrı sinxronizasiya skriptlərinə bölmək lazımdır
Məsələ ondadır ki, yükləmə uzun müddət və kilidlərlə aparılır və yükləmə olduqca problemsizdir. Eyni zamanda, tez-tez olur ki, biz gündə bir neçə dəfə məlumat verərkən pərakəndə satış yerlərindən məlumatları tez almalıyıq.

2) Problemli mağazalar seçin və onları ümumi sinxronizasiya ssenarisindən çıxarın. Onlarda böyük boşalmalar ola bilər - digər qovşaqlar da daxil olmaqla, bütün mübadilə yavaşlayacaq. Problemləri həll etdikdən sonra onlar geri əlavə edilir.

3) Məlumatların göndərilməsi və qəbulu üçün bir neçə skript yaradın. Ancaq burada əsas şey onların sayının düzgün balansını tutmaqdır.
(8.1 versiyasından bəri).
Buna görə də, RIB-nin boşaldılmasında paralellik məhduddur. Praktikada paralel olaraq 2-3 ssenarinin işləndiyi ortaya çıxır.


Nə yaxşılaşdırılmalı idi

1C RIB-nin müntəzəm məntiqindəki ən vacib tıxac yeniləmələrdir

Mübadilənin digər problemi informasiya registrləridir. İnformasiya reyestrinin hər bir qeydinin XML-ə ixrac edilməsi, xidmət elementləri və s. olan ayrıca XML nodu yaradır. Bundan əlavə, 100 qeydin eyni zamanda 100 sətirdən ibarət nəticə cədvəlini alacağı məlumat registrinin "SelectChanges()" funksiyası vaxt, əgər bu cədvəl bölməsində 100 cərgədən ibarət kataloqdursa, yalnız bir qeyd seçiləcək. Və bu, eksklüziv bloklama vaxtıdır. Beləliklə, əgər RS-də müntəzəm olaraq digər mağazalara mübadilə üçün qeydiyyata alınan çoxlu qeydlər varsa, əlbəttə ki, onu həddindən artıq hallarda yarada bilən cədvəl hissəsi olan bir kataloq şəklində təqdim etmək daha düzgündür. qeyd edərkən eyni reyestrin sətirləri. Hər halda, .

Başqa bir vacib detal - Nə üçün? Artıq 3 milyona yaxın endirim kartı toplanıb və onlarla işləmək üçün xarici onlayn sistemdən istifadə olunur. Endirim kartlarını bütün mağazalara köçürməyə davam etsəniz, bu, mübadilələri bir neçə dəfə artıracaq, əlavə olaraq, baza həcminin 10 GB-dan çox olmasına səbəb ola bilər.

Bəzi mexanizmlər mərkəzi məlumat bazası ilə əlaqə saxlamaqla onlayn şəkildə həyata keçirilir: digər mağazalarda qalıqlar, başqa mağazadan çeklə qaytarılması, hədiyyə sertifikatının etibarlılığının yoxlanılması.


Replikasiya


İlkin RIB düyününün nizamlı şəkildə yaradılması replikasiyanı prinsipcə qeyri-mümkün edərdi.
Beləliklə, aşağıdakı kimi yeni bir node yaradılır:


2) Bu verilənlər bazası RIB-də bütün ümumi məlumatları mübadilə edir, lakin ixtisaslaşdırılmış (sənədlər) qəbul etmir.


5) Mağaza üçün baza hazırdır.

Hazır proqram paketi serverə yerləşdirilir, ona görə də çox vaxt tələb etmir. Sonra yeni yaradılmış verilənlər bazası serverə yüklənir və mağazaya göndərilməyə hazırdır.


Zərif müştəri faydaları

Pərakəndə satış 2.2-nin (Nazik Müştəri) "ruhu istiləşdirən" iki əhəmiyyətli üstünlüyü:








Dəstək və Yeniləmələr




1) Mağazaların əlləri ilə yeniləyin (çox düzgün deyil, dəyişikliklər qəbul etməyə bilər, zənglər və problemlər olacaq) - əvvəllər belə idi

3) Hazır olanı yeniləmək və ya götürmək üçün *.cmd və ya 1C skriptini yazın. Təcrübə göstərir ki, belə bir həll həmişə yarımçıqdır (qeyri-sabitdir) və onda bir az funksionallıq qoymaq mümkün olacaq.

Tapşırıqlarımız nə idi:


2) Yeniləmə zamanı istifadəçi ilə interaktiv qarşılıqlı əlaqə mümkündür (mesajlar, təsdiq, tərəqqi çubuğu).








Əsas funksiyalar:




4) Agentlərin statusunun yoxlanılması
5) Hesabatları yeniləyin
6) ehtiyat nüsxəsi

















Məsələn, yeniləmədən sonra səhv mesajı belə görünür:

Beləliklə, layihənin uğurla başa çatması üçün yaxşı şans var idi. Heç olmasa yolun ortasında “normal uçuş”.

Maraqlı görünə biləcək başqa həll yollarına gəlsək, ayrıca yazacam.

P.S. və ən əsası: gələcək dəstəyin düzgün planlaşdırılması belə layihələrin davamlı uğurunun əsas amillərindən biridir. :)

25 oktyabr 2016-cı il

2 qovşaq və 10 üçün RIB qurmaq və dəstəkləmək arasında böyük fərq yoxdur, lakin uzaq nöqtələrin sayı yüzdən çox olduqda, tamamilə fərqli məsələləri həll etmək lazımdır.

Beləliklə, ilkin məlumatlar:

Konfiqurasiya: Pərakəndə 2.2
Platforma 1C: 8.3.7.1970
Layihənin sonunda qovşaqların təxmini sayı: 200
Mərkəzdə avadanlıq resursları: əhəmiyyətli məhdudiyyətlər yoxdur
Nöqtədə avadanlıq: müzakirə olunan məsələ.
Layihənin müddəti: bir il.

Memarlıq:

Əvvəlcə RIB sxeminə qərar verdik. qədər "ulduz" sxeminə diqqət yetirmək qərara alındı
Pərakəndə satış məntəqələri Windows ilə işləyən xüsusi serveri olan müştəri-server iş versiyasından istifadə edir.
Server 1C "Server 1C MINI" seçimində istifadə olunacaq https://1c.ru/news/info.jsp?id=17577
DBMS serveri - MS SQL Express 2008 R2.

SQL Express 2008 R2 bu SQL Server xəttinin ən son versiyasıdır.
Məhdudiyyətlər:

2 GB RAM
- 1 fiziki prosessor
- 10 GB maksimum verilənlər bazası ölçüsü

Yuxarıda göstərilənlərin hamısından, əlbəttə ki, verilənlər bazasının maksimum miqdarının məhdudlaşdırılması əsasən zəhlətökəndir. Ancaq əslində bu, yalnız onu sahədə köhnəlmiş məlumatlardan təmizləmə prosedurunu təşkil etmək lazım olduğunu göstərir.

1C və MS SQL serverləri üçün ayrıca server ayrılmışdır. Mübadilə və əməliyyatların əsas yükünü daşıyacaq.
Son müştəri kompüterləri dəyişdirilmir, çünki onlar nazik müştəri ilə işləyəcəklər və altındakı yük minimal olacaqdır.
Mağazadakı server sadəcə güclü kompüterdir. Ancaq bir şərt varlıqdır SSD sürücü- hansı MS SQL verilənlər bazalarının yerləşdiyi.
Həmçinin, server gecə saatlarında adi əməliyyatların aparılması və iş yerində mağaza məlumat bazasına daxil olmaq imkanını təmin edəcək.

əsas parametrlər

60 düyündə RIB-nin həyata keçirilməsi üçün ilk layihəm olduğu UT 10.3-dən bəri, əlbəttə ki, "çox su axdı". 1C yerində dayanmadı. Retail 2.2 indi seçmə məlumatların yüklənməsi ehtiyacını nəzərə alır.
Mağaza məlumat bazasına yalnız onlara aid olan məlumatlar yüklənəcək:
- Bütün kataloqlar (bəziləri istisna olmaqla)
- Bu jurnalın sənədləri
Məlumatların qeydiyyatı qeydiyyat qaydalarına uyğun olaraq baş verir, keşlənə bilən hər şey. Qeydiyyatda ciddi ləngimə müşahidə olunmur.
Başqa bir sual ondan ibarətdir ki, bu və ya digər şəkildə bazaya node əlavə etmək bütün əsaslar üçün hər bir ümumi element üçün daha bir giriş əlavə etmək deməkdir.

Boşaltma özünü qurmaqda xüsusi bir şey yoxdur. Sinxronizasiya skriptlərini qurarkən bəzi nüanslar var:

1) Yükləmə və endirməni ayrı sinxronizasiya ssenarilərinə ayırmaq lazımdır
Məsələ ondadır ki, yükləmə uzun müddət və kilidlərlə aparılır və yükləmə olduqca problemsizdir. Eyni zamanda, tez-tez olur ki, biz gündə bir neçə dəfə məlumat verərkən pərakəndə satış yerlərindən məlumatları tez almalıyıq.

2) Problemli mağazalar seçin və onları ümumi sinxronizasiya ssenarisindən çıxarın. Onların böyük yükləmələri ola bilər - bütün mübadilə digər qovşaqlar da daxil olmaqla yavaşlayacaq

3) Məlumat göndərmək və qəbul etmək üçün çoxlu göndərmə və qəbul skriptləri yaradın. Ancaq burada əsas şey balansdır.
1C-də bəzi şeylər dəyişmir. Eyni "SelectChanges" metodu yalnız ardıcıl olaraq icra edilə bilər(8.1 versiyasından bəri).
Buna görə də, RIB-nin boşaldılmasında paralellik məhduddur. Praktikada bir anda 2-3 ssenarinin boşaldılması ortaya çıxır.
Qəbul ssenarisinə gəlincə, burada, təbii ki, lazım gələrsə, daha çox paralellik mümkündür.

Nə yaxşılaşdırılmalı idi

Əlbəttə ki, kədərli və kədərlidir, amma mən BSP-yə hərtərəfli müdaxilə etməli oldum. Standart 1C məntiqində ən vacib tıxac yeniləmələrdir. Yeniləmədən sonra belə bir pəncərə görünür:

Bütün bunlar eksklüziv rejimdə baş verir. Digər şeylər arasında, sistem hələ də eksklüziv rejimdə yeniləmədən sonra mübadilə etməyə çalışacaq. Bütün bunların nəyə gətirib çıxaracağını təxmin etmək çətin deyil.
Bütün bu müddət ərzində mağaza işləyə bilmir, kassada müştərilər var, şirkət pul itirir.

Mübadilənin digər problemi informasiya registrləridir. İnformasiya reyestrinin hər bir qeydinin XML-ə yüklənməsi xidmət elementləri və buradan gələn hər şey ilə ayrıca XML node yaradır. Bundan əlavə, 100 qeydin olduğu məlumat reyestrində "dəyişiklikləri seçin" funksiyası, nəticədə ortaya çıxan cədvəldə 100 sətir olacaq, eyni zamanda, əgər bu 100 sətirdən ibarət bir arayış kitabıdırsa, yalnız bir qeyd seçiləcəkdir. cədvəl bölməsində. Beləliklə, əgər RS-də müntəzəm olaraq digər mağazalara mübadilə üçün qeydiyyata alınan çoxlu qeydlər varsa, əlbəttə ki, onu həddindən artıq hallarda yarada bilən cədvəl hissəsi olan bir kataloq şəklində təqdim etmək daha düzgündür. qeyd edərkən eyni reyestrin qeydləri. Hər halda, mübadilələrdə məlumat registrləri pisdir.

Başqa bir vacib detal - endirim kartları mübadilədən tamamilə xaric edilir və fiziki şəxslər - yalnız müəyyən bir mağazanın işçiləri. Nə üçün? Artıq 3 milyona yaxın endirim kartı toplanıb və onlarla işləmək üçün xarici onlayn sistemdən istifadə olunur. Endirim kartlarını bütün mağazalara köçürməyə davam etsəniz, bu, mübadilələri bir neçə dəfə artıracaq, əlavə olaraq, baza həcminin 3 GB-dan çox olmasına səbəb ola bilər.

Bəzi mexanizmlər mərkəzi məlumat bazası ilə əlaqə saxlamaqla onlayn şəkildə həyata keçirilir: digər mağazalarda qalıqlar, başqa mağazadan çeklə qaytarılması, hədiyyə sertifikatının etibarlılığının yoxlanılması.

Replikasiya

Təbii ki, replikasiya sürətlənmiş sürətlə həyata keçirilir.
İlkin RIB nodeunu müntəzəm şəkildə yaratmaq, əlbəttə ki, təkrarlamanı qeyri-mümkün edərdi.
Beləliklə, yeni bir node belə yaradılır:

1) Saxta mağaza ilə ayrı bir baza var
2) Bu baza RIB-də bütün ümumi məlumatları mübadilə edir, lakin ixtisaslaşdırılmış məlumatları qəbul etmir
3) Yeni verilənlər bazası yaratmaq istədikdə - sadəcə bunu kopyalayın
4) Sonra parametrləri təyin edirik - mağaza, prefiks və s.
5) Mağaza üçün baza hazırdır.

Hazır proqram paketi serverə yerləşdirilir, ona görə də çox vaxt tələb etmir. Daha sonra yeni yaradılmış mağazaların məlumat bazası serverə yüklənir və mağazaya göndərilməyə hazırdır.

Zərif müştəri faydaları

"ruhunu isitmiş" iki əhəmiyyətli fayda.

1) Pərakəndə satış məntəqələrində bütün kompüter parkının dəyişdirilməsinə ehtiyac yoxdur. Əməliyyatların 90%-i serverdə yerinə yetirilir və server ora “nisbətən güclü kompüter” gətirilir.

2) Avadanlıq işləməkdən imtina etmək qabiliyyətinə malikdir, xüsusilə tez-tez bu, yeni quraşdırılmış və ya artıq köhnəlmiş avadanlıqla olur.
Bu halda, hərəkətlər indi son dərəcə sadədir - mağaza mərkəzi məlumat bazasında işləməyə keçir.
Bu proses 5-10 dəqiqədən çox çəkmir, belə ki, avadanlıqla bağlı əhəmiyyətli problemlər olsa belə, ticarət kəsilmir.

Dəstək və Yeniləmələr

Nəhayət, ən maraqlı məqama gəldik - bütün bunları necə saxlamaq və yeniləmək olar?
Bizim üçün də yeniləmələr uzun müddətə dilemma idi:

1) Mağazaların əlləri ilə yeniləmə (çox düzgün deyil, dəyişikliklər qəbul etməyə bilər, zənglər və problemlər olacaq)
2) Yeni qüvvələr texniki dəstək(çox resurs deyil)
3) Yeniləmək və ya hazır etmək üçün *.cmd yazın. Təcrübə göstərir ki, belə bir həll həmişə yarımçıqdır (qeyri-sabitdir) və içərisində az funksionallıq var.

Tapşırıqlarımız nə idi:

1) Yeniləmə bir neçə rejimdə baş tutmalı və mərkəzdən idarə olunmalıdır
2) Yeniləmə zamanı istifadəçi ilə interaktiv qarşılıqlı əlaqə mümkündür.
3) Yeniləmənin vəziyyəti və səhvləri haqqında hesabatlar alınmalıdır
4) Yedəklənməlidir
5) Yeniləmə sistemi problemsiz özünü yeniləməyi bacarmalıdır.
6) Sistem heç bir problem olmadan genişlənməlidir.

Əlbəttə ki, vəzifələr həll edilə bilənlər siyahısından çox-çox kənara çıxdı sadə üsullar. Bu qədər son nöqtə ilə avtomatlaşdırma olmadan edə bilməyəcəyimizdən və oxşar funksionallıqla daha çox və ya daha az hazır bir şey tapmadıq.
Sonda MU (MagicUpdater) adını qazanan proqram təminatının hazırlanmasına başlamalı oldum.

Əsas funksiyalar:

1) Dinamik verilənlər bazası yeniləməsi (komanda və ya planlaşdırılmış)
2) Statik baza yeniləməsi (əmr və ya planlaşdırılmış)
3) avtomatik agentlər onlar dəyişdirildikdə son kompüterlərdə
4) Agentlərin statusunun yoxlanılması
5) Hesabatları yeniləyin
6) ehtiyat nüsxə
7) Server 1C və MS SQL ilə inzibati tədbirlər
8) Şəbəkə kompüterlərində bütün 1C müştəri proqramlarının bağlanması
9) Əsas kassada qəbul edilən statik yeniləmə
10) Yeniləmədən sonra dəyişikliklərin təsvirini göstərin
11) Hərəkətlərin ardıcıllığının təyin edilməsi
12) Bütün bu hərəkətlərin qrafik üzrə yerinə yetirilməsi

Qarşılıqlı əlaqənin təxmini sxemləri:

MU Agent mağazada quraşdırılmış və konfiqurasiya edilmiş bir xidmətdir. Əslində o, müəyyən tapşırıqları yerinə yetirmək üçün mərkəzdən əmr alır.
MU Server - Sistemə bütün sorğuları qəbul edən server.
MU monitoru - adi texniki dəstək işçilərinin gördükləri - qeydlərə baxmaq və yeniləmə üçün tapşırıqlar təyin etmək və ya başqaları üçün istifadə olunur.

Mənim fikrimcə, olduqca yaxşı çıxdı. İndi yeniləmələr demək olar ki, avtomatikdir.
Məsələn, yeniləmə mərkəzdə qaldıqdan sonra səhv mesajı belə görünür, hər şey gözləyir.

Və biz müştəri kompüterlərinə əmrlər göndəririk

Tətbiqlər, əlbəttə ki, 1C deyil, kifayət qədər layiqli interfeys xüsusiyyətlərinə malikdir. Beləliklə, məsələn, tarixə görə seçim belə görünür:

İndi biz sonrakı replikasiyaya hazırıq. Gələcək dəstəyin düzgün planlaşdırılması belə layihələrin davamlı uğurunun əsas amillərindən biridir.

Niyə sizə 1C: Enterprise 7.7 lazımdır. Paylanmış məlumat bazalarının idarə edilməsi (1C URBD, 1C URIB)

İxtisarlar və abbreviaturalar: 1C URBD- İdarəetmə paylanmış əsaslar məlumat; 1C URIB- Paylanmış məlumat bazalarının idarə edilməsi.

"Paylanmış məlumat bazalarının idarə edilməsi" əlavə komponenti - 1C URBD - 1C URIB - müəssisələrdə vahid avtomatlaşdırılmış uçot sisteminin təşkili üçün istifadə olunur. coğrafi cəhətdən uzaqşöbələr (məsələn, mərkəzi ofis, mağaza, anbar və s.) yerli şəbəkə ilə bağlı deyil. Bu komponentin təmin etdiyi imkanlar qeyri-məhdud sayda avtonom işləyən periferik məlumat bazaları ilə paylanmış informasiya sisteminin işini təşkil etməyə imkan verir.

Paylanmış infobaza bir mərkəzi və qeyri-məhdud sayda periferik infobazadan ibarətdir. Məlumat bazalarının hər biri müstəqil olaraq yeni məlumatlar daxil edir və mövcud olanları dəyişdirir. Sistem konfiqurasiyası yalnız mərkəzi məlumat bazasında dəyişdirilə və ya yenilənə bilər. Məlumatların mərkəzi və periferik məlumat bazaları arasında sinxronizasiyası üçün dəyişdirilmiş məlumatların ötürülməsi vaxtaşırı həyata keçirilməlidir. Transfer faylları hər hansı bir şəkildə nəql edilə bilər əlçatan yollar(disketdə, vasitəsilə E-poçt və s.). Sistem bütün məlumat dəyişikliklərini avtomatik izləyir və təsvir olunan sinxronizasiya qaydalarına uyğun olaraq ötürür.

1C URBD komponenti yalnız 1C: Enterprise 7.7 sisteminin proqramlarının peşəkar versiyaları ilə istifadə edilə bilər.

Məsələn, baş ofis və iki uzaq anbar üçün neçə ədəd "1C:Enterprise 7.7. Paylanmış infobase Management" almaq lazımdır?

"1C: Enterprise 7.7. Paylanmış infobazaların idarə edilməsi" komponenti - 1C URDB - üçün quraşdırılmışdır. mərkəzi məlumat bazası. Bir komponent limitsiz sayda periferik infobazaları sinxronlaşdırmağa imkan verir. Beləliklə, məsələn, baş ofisi və iki uzaq anbarı sinxronlaşdırmaq üçün "1C: Müəssisə 7.7. Paylanmış infobaza idarəçiliyi" nin bir nüsxəsi tələb olunur.

URDB komponentindən (URİB) istifadə edərək paylanmış verilənlər bazalarının yaradılması və konfiqurasiyası üçün təlimatlar

URBD komponenti (Distributed Database Management) iki eyni 1C verilənlər bazası arasında məlumat mübadiləsi üçün istifadə olunur. Konfiqurasiyalar fərqlidirsə, onu da tətbiq edə bilərsiniz, bu başqa bir şəkildə yazılmışdır. Komponentin işləməsi üçün DistrDB.dll faylı 1C: Enterprise proqramının BIN qovluğunda olmalıdır.

Paylanmış verilənlər bazası yaratmaq üçün addımları nəzərdən keçirin. Məsələn, bizim D:\base1 qovluğunda işləyən bazamız var. Onu mərkəzləşdirmək və periferik baza yaratmaq tələb olunur.

1. Periferik baza üçün D:\base2 kataloqunu yaradın.

2. D:\base1 və D:\base2 qovluqlarında CP və PC qovluqlarını yaradın (biz latın hərflərindən istifadə edirik).

3. Mərkəzi verilənlər bazası konfiquratorunu işə salın (D:\base1) və Menyu - İdarəetmə - Paylanmış IB - İdarəetmə seçin.

4. "Mərkəzi İS" düyməsini basın, görünən pəncərədə verilənlər bazasının kodunu və adını daxil edin. Kod üçün rəqəmlərdən və ya Latın hərflərindən istifadə etmək daha yaxşıdır. Məsələn, 001 və "Mərkəzi baza" daxil edin, "OK" düyməsini basaraq təsdiqləyin.

5. Periferik verilənlər bazası yaratmaq üçün "Yeni Periferik IB" düyməsini klikləyin. Bunun üçün parametrləri daxil edirik: 002 və "Periferik baza 1".

6. Kursorla "Periferik baza 1" bazasını seçin və "Tənzimlə" düyməsini basın. avtomatik mübadilə. Parametrlərdə dəyişiklik əl rejimi avtomatik. Ehtiyatlı olun, bu vacibdir.

7. Kursorla "Periferik baza 1" verilənlər bazasını seçin və "Məlumatları yüklə" düyməsini, sonra isə "OK" düyməsini basın. Yükləmə nəticəsində D:\base1\CP\020.zip faylı görünəcək.

8. 1C-ni konfiqurator rejimində işə salırıq, 1C-nin işə salınma pəncərəsində yeni baza "Periferik baza 1" əlavə edirik, onun üçün əvvəllər yaradılmış D:\base2 kataloqunu təyin edirik.

9. Menyu - İdarəetmə - Paylanmış İS - İdarəetmə seçin. Aktiv sual verildi"İnfobaza tapılmadı. Məlumat yükləmək istərdinizmi?" "Bəli" düyməsini basın və fayl adını "D:\base1\CP\020.zip" təyin edin, "OK" düyməsini basın. Yükləmə tamamlandıqdan sonra periferik bazanın yaradılması prosesi başa çatmış hesab edilə bilər.

Həmçinin, mərkəzi verilənlər bazasının surətini ehtiyat nüsxədən bərpa etməklə və ya SQL formatı üçün mərkəzi verilənlər bazası nüsxəsinin fayllarını əlavə etməklə və skripti icra etməklə periferik verilənlər bazası yaratmaq yolları verilmişdir. Bu, yükləmələr və endirmələr bir neçə saat çəkdikdə və ya ümumiyyətlə qeyri-real olduqda, böyük həcmdə məlumat üçün faydalı olacaq.

URDB komponentindən (URİB) istifadə edərək paylanmış verilənlər bazaları arasında mübadilə üçün təlimatlar

Sadələşdirilmiş bir nümunəni nəzərdən keçirək, konfiquratoru işə salmaqla mübadiləni əl ilə həyata keçirəcəyik. Siz konfiquratorun toplu rejimindən istifadə edə bilərsiniz, mübadilə paketlərini çatdırmaq üçün poçt, ftp, faylların avtomatik surətini çıxara bilərsiniz.

Mübadiləni həyata keçirmək üçün Menyu - İdarəetmə - Paylanmış IB - Avtomatik mübadilə seçməlisiniz. Mübadilə avtomatik olarsa (əvvəlki təlimatların 6-cı bəndinə baxın), onda biz uğur qazanacağıq.

1. Beləliklə, biz periferik bazaya miqrasiya edən bəzi obyektləri dəyişdiririk və ya yaradırıq. Obyektin miqrasiyası qaydaları obyektin xassələrindəki "Miqrasiya" sekmesinde təyin olunur (konfiquratorda obyekt ağacına baxın).

2. Mərkəzi verilənlər bazası konfiquratorunu işə salın, Menyu - İdarəetmə - Paylanmış IB - Avtomatik mübadilə seçin, "İşlə" düyməsini basın.

3. Nəticədə D:\base1\CP\020.zip faylı D:\base2\CP\ qovluğuna köçürülür.

4. Biz periferik verilənlər bazasının bəzi obyektlərini dəyişirik. Tercihen mərkəzi verilənlər bazasında əvvəllər dəyişmiş olanlar deyil, tk. mərkəzi baza mübadilə zamanı obyekt dəyişikliklərinin prioritetinə malikdir.

5. Periferik baza konfiquratorunu işə salın, Menyu - İdarəetmə - Paylanmış IB - Avtomatik mübadilə seçin, "Çalış" düyməsini basın.

6. Avtomübadilə nəticəsində mərkəzi məlumat bazasından bizdə dəyişikliklər olmalıdır. D:\base2\PC\021.zip mərkəzi verilənlər bazasına köçürmək üçün bir faylımız da olmalıdır

7. D:\base2\PC\021.zip faylını D:\base1\PC qovluğuna kopyalayın

8. 2-ci nöqtəni təkrarlayın. Nəticədə periferik verilənlər bazasından gələn dəyişikliklər mərkəzi verilənlər bazasında görünəcək.

Beləliklə, mübadilənin ümumi prinsipi: bir bazanın PC qovluğundan digər bazanın PC qovluğuna və bir bazanın CP qovluğundan CP qovluğuna faylların (mübadilə paketlərinin) eyni vaxtda hərəkəti ilə avtomatik mübadilənin alternativ icrası. başqa bazadan.

Konfiqurasiya dəyişiklikləri yalnız mərkəzi verilənlər bazasında edilir. Konfiqurasiyanı dəyişdirərkən, eksklüziv rejimdə periferik verilənlər bazalarında mübadilə etmək lazımdır. Mərkəzi verilənlər bazasında periferik verilənlər bazalarından paketləri uğurla emal etmək üçün konfiqurasiya yüklənməlidir. periferik əsaslar. Əgər çaşqınsınızsa - yaxşıdır, mərkəzi baza tərəfindən rədd edilən paket yenidən yüklənəcək.