Dağıtılmış 1s. Alexey Alekseev benim şirin küçük bloguma hoşgeldiniz

Bu benim ilk yazım, yapıcı eleştirilere açığım.

Hedef kitle, RDB ile ilk kez karşılaşan kişilerdir.

RDB görevleri

Başlamak için ilk şey, "Neden RDB'ye ihtiyacımız var?" Sorusunu yanıtlamaktır. Pek çok cevap var, özellikle:

1. Ayrık veritabanlarında çalışan şubelerimiz var. Şimdi aralarındaki bilgilerin senkronize olmasını istiyoruz;
2. Şubelerimiz var, ancak veritabanı üzerindeki yük çok yüksek (veri tabanının boyutu değil, işlemlerin engellenmesi anlamına gelir) ve çevrimiçi alaka düzeyi (birkaç dakikadaki alaka düzeyi ile karıştırılmaması gerekir, çevrimiçi, her işlemden sonra verilerin aktarıldığı zamandır) ikinci düğüme) gereken dallar için veri yoktur;
3. Sadece veri girişinin yapıldığı şubelerimiz (örneğin perakende satış mağazaları) var, böylece merkezi veri tabanı üzerindeki yükü önemli ölçüde azaltabiliyoruz;
4. Güvenlik nedenleriyle, şubelerin şirket bilançosu gibi önemli verilere teorik olarak (yönetici şifresiyle) erişmesini istemiyoruz.

Bir durumda 2. ve 4. sorular beni ilgilendiriyordu, diğer 2 ve 3. sorularda. Birinci paragraf çok kapsamlıdır ve bu makale kapsamında değerlendirilmeyecektir.

Bazı durumlarda veri alışverişinin uygulanmasına önemli kısıtlamalar getirebileceğinden, değişim dosyalarının taşınması konusunu da hemen düşünmek daha iyidir. Öncelikle, RDB düğümlerinin tam olarak hangi dallarda görüneceğini belirlemeniz gerekir (genellikle bunlar bölgesel dallardır). Ardından, RDB düğümlerini başka nereye kurmak istediğimizi ve bunların çevrimiçi alaka düzeyine ihtiyaç duyup duymadıklarını ele alıyoruz. Örneğin, perakende mağazaları için bir modem bile kurmak her zaman mümkün olmaktan uzaktır ve kurulum kablosuz iletişimçok pahalı olacak Burada bir karar vermeniz gerekiyor - belki bu mağaza çevrimdışı çalışabilir ve flash sürücü gibi fiziksel bir ortam kullanarak merkezle periyodik olarak (günde bir / haftada bir) alışveriş yapabilir.

Bazı durumlarda, fiziksel medya aracılığıyla alışveriş yapmak mümkün değildir, örneğin, bu, yüksek hızlı iletişim kurma konusunda önemli sorunların olduğu çok uzak bir şubedir. Burada, değiş tokuş edilen bilgi miktarını kabaca hesaplamaya değer. Çoğu zaman, alaka düzeyi ile saatte bir veya günde birkaç kez, 32k modem yeterlidir. Bununla birlikte, veri güncellemelerinin yanı sıra, bazen konfigürasyonun kendisine veya harici dosyalara (basılı formlar, ürün fotoğrafları) güncellemeler göndermeniz gerekeceğini hatırlamakta fayda var, bu nedenle zaman zaman değişim dosyasının artacağı bir durum olacaktır. önemli ölçüde bu tür güncellemeler nedeniyle.

topoloji

Toplamda, cevaplanması gereken aşağıdaki soruları aldık:

1. Hangi departmanlarda RDB düğümleri kuracağımız garanti edilecek ve orada yüksek hızlı bir kanal kurmak mümkün mü;
2. Hangi alt bölümlerde RDB düğümünün kurulumu gerekli değildir;
3. Hangi departmanlar birkaç saat içinde alakalı olarak çalışabilir;
4. Hangi departmanlar çevrimdışı çalışabilir (günde 3-4 defadan az veri alışverişi).

Bu soruları cevapladıktan sonra, RDB'mizin yaklaşık bir şemasını alıyoruz. Büyük şirketler için genellikle şöyle bir şey ortaya çıkar:

Şekil 1. Büyük bir şirket için tipik RDB şeması

"Şube" düğümlerinde her şey nispeten açıksa - bunlar otomasyon gerektiren büyük merkezlerdir, o zaman "Mağaza" düğümleri, veri girerken veri tabanında ciddi bir yük olan ve yükü azaltmak için ayrılması gereken bir düğüm anlamına gelir. Örneğin, 50 kasaya ve günlük cirosu 10.000'den fazla olan bir mağaza.

• Mağazalar - kendi ciroları ve hareketleriyle ilgili verileri girme Para. Analitik, yalnızca mağazanız için yüzeyseldir.
• Şubeler - otomatik olmayan noktaların veri girişi, muhasebe, bordro ve personel, üretim vb. Analitik kendi şubenizde.
• Merkez - otomatik olmayan dalların veri girişi. Bir bütün olarak işletmenin analitiği.

Veritabanının her düğümde hangi amaçlarla kullanılacağını anlamak önemlidir. Hedeflerden, uygulama için gerekli görevler oluşturulur, örneğin:

• Şubeler birbirlerinin muhataplarıyla yapılan anlaşmaların geçmişini görürler;
• Mağazalar, işletmenin tamamında (veya bir kısmında) mal kalıntılarını görür;
• Gelir / giderler, bütçe uygulaması vb. Analitikleri yalnızca kendi departmanınızın hiyerarşisi içinde görünür;
• Muhasebe, bordro ve İK sadece kendi departmanlarının hiyerarşisinde görünür;
• İsimlendirme, tüm özellikleri ve karakteristikleri tüm RDB düğümlerinde görülebilir;
• Departman hiyerarşisine göre tüm veriler yükselir, ancak filtrelenir;
• Merkez, şirket hakkında kesinlikle tüm bilgileri içerir.

Bu tür soruları önünüze koyarak en zor soruyu cevaplayabilirsiniz - RDB düğümleri arasında hangi bilgiler, nerede ve nasıl çalışmalıdır? Neden en zoru? Düğümler arasında hangi veri kümelerinin çalıştığını bilerek, verilerin mantıksal olarak tutarlı kalması için mevcut veritabanını nasıl "keseceğinizi" açıkça anlayabilirsiniz. Örneğin, mal dengesine ilişkin veriler cari rezervlere ilişkin verilerden ayrılamaz.

Şimdi bilgi akışlarına bağlı olarak RDB şemasını yeniden çizelim:

Şekil 2'de ne görüyoruz? Şirketin bölümlerinin hiyerarşisine göre, veri tabanı düğümleri arasındaki bilgi akışının topolojisi sıralandı. Ayrıca "Merkez 2" düğümü eklendi, neden? Yıldız topolojisini uygularken, merkezdeki yük her zaman çevresel düğümlerdeki yükten daha fazladır ve genellikle düğümün kendisi tarafından üretilen yük zaten yüksektir. "Merkez 1" ve "Merkez 2" düğümlerini kullanma örnekleri:

1. "Merkez 1" yalnızca diğer RDB düğümlerinin verilerini birleştirme işlevi görür. Yalnızca yöneticinin erişimi vardır. "Merkez 2" genel müdürlük işleri için hizmet vermektedir;
2. "Merkez 1" genel müdürlük işleri için hizmet vermektedir. Ancak ağır analitik, test, veri tabanı üzerinde büyük bir yük oluşturan, işlemler "Merkez 2" düğümünde gerçekleştirilir; örneğin, yeniden sıralama, kapalı dönemleri yeniden yayınlama, uzun bir süre boyunca kurum çapında özet raporlar oluşturma, veri değişikliklerine yol açan analitik oluşturma;
3. "Merkez 1" genel müdürlük işleri için hizmet vermektedir. "Merkez 2", öngörülemeyen durumlarda tüm RDB'nin hızlı bir şekilde geri yüklenmesi için bir yedektir.

Değişim Uygulaması

RDB'nin çalışması için 2 seçenek vardır:

1. Otomatik - kullanıcı müdahalesi olmadan gerçekleşir. Acil durumlar üzerindeki kontrol, veritabanı yöneticisine veya ileri düzey bir kullanıcıya atanır;
2. Manuel - değişim yalnızca kullanıcının talebi üzerine gerçekleşir.

Kendi deneyimlerime göre, tüm uygulamaları her zaman otomatik sürüme yönlendirdim. Değişim dosyalarının taşınmasıyla ilgili sorunlar varsa (düğümde bir ağın varlığı kalıcı değildir), kullanıcının izin verdiği maksimum değer "Şimdi değiştir" düğmesini tıklamaktı. Verilerin güncellenmesine ek olarak, yapılandırmanın güncellendiği durumlar da, tam otomatik olanlara (örneğin, üçüncü taraf yazılım kullanarak) yönlendirilmesi istenebilir.

Güncelleme paketlerinin oluşturulması

Hangi RDB düğümlerine hangi işlevlerin atanacağı konusunda kesin bir karar olduğundan, yalnızca bu düğümün ihtiyaç duyduğu veri paketini oluşturmak mümkündür. Bir yandan, düğümler arasında ne tür nesnelerin senkronize edileceğini belirtmek gerekir. Örneğin, "Mağaza 1" düğümü için muhasebe kayıtları hiç senkronize edilmemelidir, çünkü veriler yalnızca şube sitesi düzeyinde girilir. Öte yandan, değiş tokuşa konu olan bu tür veriler departman referans alınarak filtrelenmelidir. Örneğin, "Şube 2'nin Mağaza 1" düğümünün para girişine ilişkin veriler yalnızca "Şube 2", "Merkez 1" ve "Merkez 2" düğümlerinde bulunabilir.

Ancak bunun tersi bir sorun var, eğer alışveriş verilerini çok fazla filtrelerseniz, veri paketi mantıksal bütünlüğünü kaybeder. Örneğin, stok bakiyeleri depolar tarafından muhasebeleştirilir ve rezervler bir bütün olarak şirket tarafından muhasebeleştirilir, bu durumda stok bakiyelerini depolara göre filtrelerseniz ve rezervleri filtrelemezseniz, veriler yanlış olacaktır.

Ayrıca, nesnenin ömrünün hangi aşamasında değiş tokuşa tabi olacağına da karar vermelisiniz. Örneğin, yalnızca deftere nakledilen faturalar değiş tokuşa tabidir, yalnızca kayıtlı olanlar değil. Ya Mağaza faturaları, ayarlandıktan sonra bile asla Merkez düğümden indirilmez, ancak ters etkiyi hesaba katmanız gerekir - veriler senkronize olmayabilir veya bazı değişikliklerin üzerine yazılabilir.

Anlamak önemlidir - düğümler arasında değiş tokuş yaparken bunlardan biri önceliklidir. Durumu göz önünde bulundurun:

1. Mağaza 1 düğümünde bir belge oluşturuldu;
2. Değişim sırasında "Şube 1" düğümüne girdi;
3. Belge her iki düğümde de aynı anda düzeltilir.

Belgelerden hangisi doğru kabul edilecek? 1C 8.x'te, "Değişim Planları" mekanizmasını kullanırken, varsayılan olarak ana düğüm önceliktir, yani. bu durumda "Mağaza 1" düğümünde yapılan değişiklikler kaybolacak ve "Şube 1" düğümündeki verilerle değiştirilecektir.

Birbirine bağlı iki nesne aynı anda düzeltildiğinde, daha karmaşık başka bir durum daha vardır. Örneğin bir giden fatura ve üzerindeki PKO farklı düğümlerde ayarlanıyor, fiyatlar, ödeme tutarı, yükleniciler vb. değişirse bütünlüğün kaybolma olasılığı var.

Nesnelerin silinmesini kontrol etmek de önemlidir, aksi takdirde bu, örneğin artık bir faturanın olmayacağı, ancak muhasebe hareketlerinin kalacağı gerçeğine yol açabilir.

1C 8.x'te değişim mekanizmaları

Uygulama için iki yaklaşım vardır:

1. Mekanizma "Değişim planları";
2. Nesne kaydının özel uygulaması.

Her iki seçeneği de ele alalım.

Değişim planları mekanizması, herhangi bir yapılandırma olmaksızın birkaç dakika içinde tam veri alışverişi ile bir RDB oluşturmaya izin verir. "Dağıtılmış" bayrağını ayarlarsanız bilgi bankası”, ardından güncelleme paketi oluşturulduğunda yapılandırma güncellemeleri de indirilecektir. Sadece birkaç dakika içinde, değişim planının bileşimini açarak çeşitli veri türlerinin değiş tokuşuna izin verme / yasaklama kurallarını da yapılandırabilirsiniz. "Otomatik kayıt" bayrağını "Devre Dışı Bırak" konumuna ayarlarsanız, bu tür nesneler ek çaba sarf edilmeden asla değiştirilmez.

Kayıt neden gerekli, neden her şeyi bir kerede yüklemiyorsunuz? Her durumda, yalnızca veritabanı durumu değişikliklerini içeren bir dosya, veritabanının kendisinin tam bir anlık görüntüsünden daha küçük olacaktır. Bu nedenle, tam boşaltma seçeneği dikkate alınmayacaktır.

Bir departmana ait olarak veri filtreleme nasıl kurulur? Programlamanız gereken yer burasıdır. Uygulamamda, herhangi bir nesnenin kaydı için, "Kayıt Üzerine" olayına bir abonelik ayarlandı; burada "Veri Alışverişi.Alıcılar" özelliğini kullanarak, bu nesnenin alıcılarının listesini ayarlayabilirsiniz. Onlar. Listede olmayan bir düğüm için standart araçlarla boşaltma yapılırken, nesne boşaltılmayacaktır. Başka bir çözüm daha var - değişim planı modülünün "Bir Köleye Veri Gönderirken" ve "Ana Veri Gönderirken" prosedürlerinde, bir nesneyi boşaltırken doğrudan bir nesneyi boşaltmayı seçip seçemeyeceğiniz.

Her iki seçenek de geçerlidir. Ancak, en iyi seçenek olarak ilkini seçtim, çünkü yüklenemezlik özelliğinin hesaplanması, nesne yazıldığında hemen gerçekleşir, bu da nesne kayıt süresini %3-5 oranında artırır (optimize edilebilir, bazı durumlarda %0,01'e yükseltilebilir, yani ortalama 0,1-0,3 saniye ve veri gönderirken doğrudan bir nesnenin yüklenemezliğinin hesaplanması durumunda, bu zaten veritabanında önemli bir yük oluşturur, bu süre birkaç dakikaya kadar çıkacaktır.

"Değişim Planları" mekanizmasının işleyişini tam olarak anlamak için, "1C: Enterprise 8 sisteminde profesyonel gelişim" kitabının 15. bölümünü okumanızı tavsiye ederim, Gabets A.P., Goncharov D.I.

Bana göre herhangi bir yerel uygulama, ya Değişim Planları mekanizmasını tekrarlayacak ya da değişiklikten hemen sonra nesneyi kaldıracak ya da Değişim Planları mekanizmasından daha fazlasını kaldıracaktır (örneğin, bugün için tüm değişiklikleri kaldıracaktır). Bu konuyu uygulama deneyimi eksikliği olarak görmüyorum.

Ulaşım

Dosyaları ana düğümden bağımlı düğüme taşıma görevi, maksimum hata toleransına indirgenmiştir. Dosyaların güvenli bir kanal üzerinden şifrelenmesi veya iletilmesi alışılmadık bir durum değildir. Dosyaları aktarmak için birkaç farklı hizmet kullanmanız veya birkaç farklı bağlantı seçeneği hazırlamanız önerilir. Örneğin, ana aktarım yöntemi, bir VPN tüneli aracılığıyla bağlanan bir FTP sunucusu kullanmaktır; yedek, TLS bağlantısı olan bir e-posta sunucusudur. Neden başka bir hizmetle bir yedek kanala ihtiyacınız var? Uygulamada görüldüğü gibi, 2 farklı FTP sunucusu kullanmak, FTP sunucusu ve E-Posta'dan daha az güvenilirdir.

Bir hizmet paketi oluşturma hizmetini taşıma hizmetinden ayırmanızı öneririm, bu, tüm veri alışverişi kompleksinin hata toleransını artıracaktır. Dosya taşıma hizmeti çalışmazsa, güncelleme paketleri oluşturma hizmeti normal şekilde çalışmaya devam eder ve belirli koşullar altında taşıma hizmetini yeniden başlatır ve bunun tersi de geçerlidir.

RDB Uygulamam

Uygulama tamamen otonom olduğundan maksimum hata toleransı bir alt görevdi. Bu, 2 hizmetle sonuçlandı - güncelleme taşıma hizmeti ve veri içe/dışa aktarma hizmeti. Her iki hizmet de birbirinden bağımsız çalışır.

Her başarılı veri alma-verme döngüsünden sonra, bu düğüm ile son alışverişin zamanı kaydedildi. Değişim çok uzun bir süre gerçekleşmediyse, taşıma hizmeti, ikinci düğümün yine de güncellemeleri alacağına ve dosyalarını yükleyeceğine güvenerek, kendisine sunulan tüm iletişim kanallarına dosya yüklemeye başladı. İstisnai durumlarda, sistem yöneticiye bir mesaj gönderir. Detaylı Açıklama hatalar.

Trafik miktarını azaltmak için, xml dosyaları zip arşivlerine paketlendi. Sistem iki tür aktarımı destekler - FTP ve E-posta.

Veri filtresi ayarları olarak iki tablo vardır. Bir ( tablo bölümü değişim planları) genel özniteliklerin koşulları (sistemin bu özniteliği bulmaya çalıştığı her nesne için), belirli bir meta veri nesnesi için başka bir ayarda saklanır. Herhangi bir nesneyi kaydederken, koşullar önce ortak özniteliklere (örneğin, Alt Bölme) göre aranır, ardından sistem, tüm öznitelikleri için bu tür nesne için kişisel bir kural olup olmadığını belirlemeye çalışır. Listelerin filtrelenmesini önermiyorum - hata yapmak için harika bir fırsat var, örneğin, faturanın tablo kısmından birkaç satır kaybolacak ve geri kalanı tamamen hareket edecek ve bunun tersi de geçerli.

Hizmetlerin hangi sistem kullanıcısı altında çalışacağını anlamak önemlidir, çünkü 1C geçici klasöründe bile dosya oluşturmak için yeterli hak olmayabilir. Hata ayıklama için, başarıyla tamamlanan her işlemi günlüğe veya bir txt dosyasına yazmanızı önemle tavsiye ederim. 1C 8.1'de, sunucu kodunun yürütülmesinde hata ayıklanamaz.

Uygulamamda hata ayıklama ve özelleştirme kolaylığı için, açıklaması işlemenin kendisinde bulunan "Değişikliklerin kaydı" işlemini ekliyorum.

Veri değişim kompleksinin genel çalışma şeması Şekil 3'te gösterilmektedir.

Veri filtreleme, her nesnenin "BeforeWrite" olayına abonelikte gerçekleşir. İlk düğüm görüntüsünü oluştururken verilerin de filtrelenmesi gerektiğini unutmayın. İlk görüntüyü oluşturma prosedürü oldukça uzundur, bu nedenle kodunu maksimuma optimize etmenizi öneririm (örneğin, önbelleğe alma filtreleme ayarları).

sonsöz

Ana görev, bir soru listesini yanıtlamaktır:

1. Neden RDB'ye ihtiyacımız var?
2. Bir RDP istemcisi aracılığıyla çalışmanın nesi yanlış?
3. RDB düğümlerini nereye ve neden kurmak istiyoruz?
4. Güncellemeler nasıl taşınacak?
5. Hangi düzeyde hata toleransı uygulanacaktır?

"Kayıt Değişikliklerini" İşleme

İşleme, nesnelerdeki değişiklikleri teslim etmeye zorlamanıza olanak tanır. Değişiklikleri kaydetmek için birkaç seçenek vardır:

1. Herhangi bir meta veride bir onay kutusu ayarlanmışsa ve tek bir nesne SEÇİLMEMİŞSE ve "Tüm değerlere göre kaldır" bayrağı AYARLANMAMIŞSA, YALNIZCA SEÇİLEN TABLO KAYITLI OLUR;
2. "Tüm değerlere göre kaldır" bayrağı ayarlanırsa, seçilen meta veriler döngüdeki tüm nesneler tarafından kaldırılacaktır;
3. Anahtar "Yalnızca seçilen nesneleri kaldır" moduna ayarlanmışsa, yalnızca seçilen nesneler kaldırılacaktır (örneğin: nesneleri seçmeden meta verilerdeki bayrağı ayarlamak, "Tüm değerlere göre kaldır" bayrağına eşdeğerdir ve anahtar "Yalnızca seçili nesneleri kaldır" konumu);
4. Anahtar "Seçili ve doğrudan ilgili nesneleri kaldır" moduna ayarlanmışsa, seçilen nesneler ve varlığı seçilen nesnenin varlığına bağlı olan nesneler kaldırılacaktır (örneğin: aramaların alt aramaları vardır);
5. Anahtar "Tüm bağlantılarla kaldır" moduna ayarlanmışsa, seçilen nesneye bağlantı bulunan TÜM nesneler kaldırılacaktır.

Mevcut ek işlevsellik:

• Genellikle hata ayıklama için gerekli olan kayıtlı nesnelerin yeniden kaydı;
• Hata ayıklama için genellikle kayıtlı olanları kaldırmak gerekir;
• Değişiklikleri yazdır - değiştirilmiş olarak işaretlenen nesnelerin tam listesini yazdırın;
• Konfigürasyon ağacının yazdırılması, yalnızca tüm konfigürasyonun görüntülenmesi kolaylığı içindir.

Uygulamada genellikle farklı bölümlerin veya şubelerin coğrafi olarak farklı yerlerde bulunduğu durumlar vardır. Aynı zamanda uzak bölümlerde programa girilen verilerin genel bir kayıt tutabilmesi için bir şekilde merkeze ulaşması gerekmektedir.

Şu anda, bu sorun genellikle coğrafi olarak uzak çalışanlara ortak bir veri tabanına uzaktan erişim sağlayarak çözülmektedir. Veritabanını bir web sunucusunda, uzak masaüstünde vb. yayınlayarak yapılabilir.

Bununla birlikte, coğrafi olarak uzak bir ofiste İnternet olmadığında veya ortak bir bilgi tabanında çalışacak kadar kararlı olmadığında bu tür durumlar nadir değildir. Bunun için 1C, dağıtılmış bir veritabanı kurmak için bir mekanizmaya sahiptir.

Basitçe söylemek gerekirse, ana üs merkez ofiste bulunur. Uzak departman, bir alt departman kullanır. Bu tür birkaç alt üs olabilir. Sonuç olarak, böyle bir dağıtılmış taban, senkronizasyon yoluyla birleştirilir. Hem programa göre otomatik hem de manuel olarak yapılabilir.

Bu yazıda 1C: Accounting 3.0 için dağıtılmış bir veritabanı kurmayı ele alacağız. Buna rağmen, talimat diğer birçok 1C 8.3 konfigürasyonu için de uygundur.

Not tüm gerekli yapılandırma değişikliklerinin yalnızca ana RIB veri tabanında yapılması gerektiğini. Senkronizasyon sırasında, bu değişiklikler tüm alt veritabanlarına aktarılacak ve geçerli olacaktır.

Ana bilgi bankası

Dağıtılmış bir veritabanı kullanırken, ana ayarlar ana üs. Bunları aşağıdaki görseldeki gibi "Yönetim" bölümünden yapmanız gerekiyor.

Açılan pencerede hemen "Veri senkronizasyonu" onay kutusunu işaretleyin. Altta, ana (geçerli taban) önekini belirtin. En fazla iki karakter uzunluğunda olabilir. Bizim durumumuzda, bu RIB 1C'nin "Ana Muhasebe" olduğunu kastettiğimiz için önek "BG" olacaktır.

Artık senkronizasyonun kendisini kurmaya, yani verilerin hangi baz (veya bazlar) ile değiş tokuş edileceğini belirlemeye başlayabilirsiniz. Bunu yapmak için "Veri senkronizasyon ayarları" köprüsünü izleyin. Yalnızca soldaki onay kutusu işaretlenirse geçiş için uygun olacaktır.

Açılan pencerede menüden "Tam ..." öğesini seçin. Senkronizasyon için herhangi bir 1C bilgi tabanını belirlememize izin verecektir.

Coğrafi olarak uzak bir ofiste bulunan bir bağımlı üssü bağlamak için ilk pencerede, bağlantının yerel veya ağ dizini aracılığıyla yapılacağını bir bayrakla işaretleyin. Bizim durumumuzda bu "D:\DB\InfoBase" şeklindedir. Ayrıca önceden yazma olasılığını da kontrol edeceğiz.

Farklı tabanlar için farklı önekler belirttiğinizden emin olun. Gerçek şu ki, her veritabanından yeniden yüklenen veriler için verileri senkronize ederken, kendi öneki ayarlanmıştır. Çoğaltılırsa çalışma yanlış olur, bu nedenle program size böyle bir fırsat vermez.

Program sizden bir başlangıç ​​görüntüsü oluşturmanızı istediğinde, bu seçeneği seçin. Bu prosedür biraz zaman alacaktır, ardından "1Cv8.1CD" adıyla bilgisayarınıza kaydedin.

Senkronizasyon, kendiniz ayarlayabileceğiniz bir programa göre otomatik olarak veya manuel olarak gerçekleştirilebilir. İkinci durumda, sizin için uygun bir zamanda "Senkronize Et" düğmesine tıklamanız yeterlidir.

RIB köle düğümü

Alt veritabanında yapılan ayarların sayısı çok daha azdır. Aynı bölümde "Veri senkronizasyonu" bayrağını ayarlayın ve uygun bağlantıya tıklayın, "Senkronize Et" düğmesi mevcut olacaktır.

Örneğimizin bir parçası olarak, ana veri tabanına iki öğe konumu eklendi: "Kiriş" ve "Tahta". Senkronizasyondan sonra, ikincil bir veritabanında sona erdiler. Aşağıdaki resimde görebileceğiniz gibi, onlara "BG" ön eki verilmiştir. Kalan iki konuma ("Torna" ve "Palet"), doğrudan alt veri tabanına girildikleri için "BP" ön eki atanır.

Not bizim durumumuzdaki öğelerin numaralandırılması uçtan uca, ancak yalnızca aynı önek içindedir.

Anahtar Kelimeler: dağıtılmış, URDB, XML, kayıt, düğüm, düğüm, otomatik kayıt, ilk, görüntü, POP3, SMTP, MailMessage, çevre birimi, merkezi, çoğaltma, değiş tokuş

Feragatname ve kullanım koşulları

Bu makalede yanlışlıkla bahsedilen tüm ticari markalar ilgili sahiplerine aittir.
Bu makale Creative Commons Attribution-Share Alike 3.0 Unported Lisansı altında yayınlanmıştır.
http://creativecommons.org/licenses/by-sa/3.0/

Aşağıdakilerin tümünün 8.0.7.36 ve sonraki sürümlerin piyasaya sürülmesi için geçerli olduğunu hemen not edeceğim.

Adım 1. Bir değişim planı oluşturun

Yapılandırmada bir değişim planı oluşturuyoruz. Biz buna örneğin "DağıtılmışTemel" diyoruz. zorunlu
Değişim planının özelliklerinde "Dağıtılmış bilgi bankası" kutusunu işaretleyin.

"Diğer" sekmesinde "Kompozisyon" butonuna tıklayarak hangi nesnelerin değiş tokuşa dahil edileceğini belirliyoruz. İle
Varsayılan olarak, tüm nesneleri etkinleştirebilirsiniz ("Eylemler" - "Tümünü Etkinleştir"). Önemli olan parametredir.
"Otomatik kayıt". Genel olarak, tüm nesneler için etkinleştirilmesi gerekir.

Not: Konfigürasyona yeni nesneler eklerken, değişim planına dahil edilmezler. Onlar. sonrasında
bir nesnenin eklenmesi, değişim planına eklenmesi gerekir.

Bazı nesnelerin değiş tokuşa katılmamasını istiyorsanız, onları kompozisyondan çıkarmanız yeterlidir.
takas planı Ancak referans bütünlüğünün kontrolü tamamen sizin vicdanınızda kalır. Eğer
örneğin, belirli bir belgenin değişim planında yer almaması ve hareketlerini yaptığı sicilin dahil edilmesi,
o zaman alıcı tabanında, bir sicil belgesi olmadan sicil hareketlerini almak oldukça mümkündür;
katılıyorum, iyi değil

Prensip olarak, bu eylemler RDB'nin "manuel" modda çalışması için yeterlidir. Bunu yapmak için başlatıyoruz
Enterprise, "İşlemler" menüsünden takas planımızı aç. Değişim planında her zaman mevcuttur
"noktalı" önceden tanımlanmış düğüm. Bu, geçerli düğümün açıklamasıdır. Açılıp doldurulması gerekiyor. bizim
Bu durumda "Kod" ve "Ad" alanları kullanılabilir olacaktır. Düğümümüze "AA" kodunu atayalım ve çağıralım
"Merkez". Değişim planına bir düğüm ekleyelim. "BB" kodunu atayalım ve "Çevresel" olarak adlandıralım.

Artık periferik tabanın bir görüntüsünü oluşturabiliriz. Bu, "Başlangıç ​​oluştur" düğmesine basarak yapılır.
görüntü". Düğümler listesinde, bir çevre birimi tabanı seçilmelidir. Temel görüntü, hazır bir IB şeklinde oluşturulur.
katalogda veya 1C:Enterprise sunucusunda. (IB görüntüsünün bir dosya olarak oluşturulduğu 7.7'den farklı olarak)
boşaltma). Ayrıca, oluşturulan veri tabanı, 1CV8.1CD dosyasını basitçe kopyalayarak doğru yere taşınabilir.
(dosya sürümü için) veya Konfigüratör aracılığıyla veri yükleme ve indirme yoluyla.

Çevre birimi IS'de değişim planını açarsanız, düğümün "noktalı" olduğunu göreceksiniz, yani. akım
"Çevresel" düğüm, düğüm haline geldi ve "Merkez" düğümün simgesi kırmızı oldu, yani. düğüm
"Merkez", mevcut olana göre ana düğümdür.

"Manuel" modda değişim, "Değişiklikleri kaydet" ve "Oku" düğmeleri kullanılarak yapılabilir.
Değişiklikler". İlk durumda, ikinci durumda, değişikliklerin yazılacağı bir dosya seçmeniz istenecektir.
- değişikliklerin okunacağı dosya. Değişim xml formatında gerçekleştirilir. Değişiklikler için kaydedilir
seçilen düğüm

2. Adım: Değişiklikleri bir XML dosyasına yükleyin ve e-postayla gönderin

Böylece bir değişim planı oluşturduk, çevresel bilgi güvenliği oluşturduk ve hatta veriler arasında nasıl veri aktarılacağını öğrendik.
bazlar. Şimdi görevimiz, üsleri e-posta ile değiş tokuş etmeyi öğretmek.

Değişim planına iki ayrıntı ekliyoruz: "string" türünde EmailAddress ve "PerformExchange" türünde
"boole". EmailAddress özelliğinde, düğümün e-postasını saklayacağız, örn. hangi adres
değiş tokuş mesajları gönderin. Otomatik değiştirmeyi hızlı bir şekilde devre dışı bırakmak için gerekli PerformExchange gereklidir.
mesaj gönderme-gönderme.

E-posta ile çalışma prosedürünü evrensel hale getireceğiz, yani. mümkün kılalım
hem MAPI'yi (bir e-posta istemcisi yoluyla gönderme-alma, örneğin MS Outlook) hem de
SMTP/POP3 sunucularına doğrudan erişim.

Konfigürasyona bazı sabitler ekleyelim:

bir yerde genel bir formda bu sabitlerin değerlerinin düzenlenmesini sağlıyoruz.

Ortak bir modül ekleyelim, adını "rbDistributedBase" koyalım. İçinde şunları yazıyoruz:

Prosedür pbSendExchangeMessages() Dışa Aktar UseSMTP = Constants.UseExchangeBySMTP.Get(); //Önce, ayarlara bağlı olarak InternetMail türünde olacak Posta nesnesini oluşturun, //sunuculara doğrudan erişim kullanılıyorsa veya MAPI kullanılıyorsa Mail. SMTP Kullanılırsa O Zaman //InternetMail türündeki bir nesne için bir posta profili oluşturun ve doldurun. MailProfile = Yeni InternetMailProfile; MailProfile.SMTPServerAddress = Constants.SMTPServerAddressExchange.Get(); MailProfile.SMTPPort = Constants.InterchangeSMTPServerPort.Get(); MailProfile.SMTPUser = Constants.SMTPServerUserExchange.Get(); MailProfile.SMTPPassword = Constants.SMTPUserPasswordExchange.Get(); MailProfile.Timeout = Constants.TimeoutServer.Get(); Posta = Yeni InternetMail(); Mail.Connect(MailProfile); deneniyor İstisna raporu(" DEĞİŞİM: Posta profiline bağlanırken hata oluştu! Değişim başarısız oldu!" + ErrorDescription(), MessageStatus.VeryImportant); Return; EndTry; Else Mail = NewMail(); Mail.Connect() girişimi; İstisna Raporu("" + ErrorDescription(), MessageStatus.VeryImportant); Return; EndTry; EndIf ; //Ardından, geçerli olan hariç, değişim planından tüm düğümleri seçin, //PerformanceExchange özniteliğinin ayarlandığı yer. NodeSelection = Exchange Plans.DistributedBase.Select(); SelectNodes.Next() Değilse Döngü Yaparken SelectNodes.PerformExchange Devam Ediyor; EndIf; NodeSelection.Reference = Exchange Plans.DistributedBase.ThisNode() ise Devam Edin; EndIf; EmailAddress = KısaltılmışLP(Nodes.EmailAddress Seçimi); EmailAddress = "" ise Devam Edin; EndIf; //XMLWrite ve MessageWrite nesnelerini kullanarak değişiklikleri yazıyoruz //seçilen düğüm için bir xml dosyasına. Düğüm = DüğümSeçimi.Referans; XMLWriter = Yeni XMLWriter(); MessageFileName = TempFile Directory() + "Message_ " + Kısaltılmış LP(Exchange Plans.DistributedBase.ThisNode().Code) + "_" + KısaltılmışLP(Node.Code) + ".xml"; WriteXML.OpenFile(MesajDosyaAdı); MessageRecord = ExchangePlans.CreateMessageRecord(); WriteMessage.StartWrite(WriteXML, Düğüm); Exchange Plans.WriteChanges(WriteMessage); WriteMessage.EndWrite(); WriteXML.Close(); //Ardından yeni bir harf oluşturuyoruz, ortaya çıkan xml dosyasını buna ekliyoruz ve //düğümün E-Adresi özniteliğinde belirtilen adrese gönder. Dosya = Yeni Dosya(MesajDosyaAdı); MessageSubject = "1C: Exchange" + Kısaltılmış LP(Exchange Plans.DistributedBase.ThisNode().Code) + "_" + KısaltılmışLP(Node.Code); UseSMTP ise MailMessage = New InternetMailMessage; MailMessage.Subject = MesajSubject; MailMessage.Attachments.Add(MesajDosyaAdı, Dosya.Adı); MailMessage.Recipients.Add(EmailAddress); Mail.Send(MailMessage); Aksi takdirde MailMessage = Yeni MailMessage; MailMessage.Subject = MesajSubject; MailMessage.Attachments.Add(MessageFileName); MailMessage.Recipients.Add(EmailAddress); Mail.Send(MailMessage, False); EndIf; Constants.OutputMessages.Get() ise Report(" EXC: Düğüm için mesaj alışverişi" + Node.Name + " gönderildi! ", MessageStatus.Information); EndIf; DeleteFiles(MessageFileName); EndCycle; Mail.Disconnect(); EndProcedure

Arayüze, düğmelerden birine buna çağrı asabileceğiniz ek bir panel eklemenizi öneririm.
prosedürler. Şimdi Enterprise'ı başlatmaya, yapılandırmaya devam ediyor e-posta adresi periferik IS,
"Değişim gerçekleştir" kutusunu işaretleyin, paneldeki prosedür düğmesine tıklayın ve posta almak için çalıştırın
belirtilen e-posta adresler. "1C: Exchange AA_BB" konulu bir mektup ve ekli bir dosya almalısınız.
"Mesaj_AA_BB.xml".

Böylece işin yarısı tamamlandı: "sekiz" e e-posta ile RDB değişim mesajları göndermeyi öğrettik.
posta.

3. Adım. Güncellemelerin e-posta ile alınması ve IB'ye kaydedilmesi

Şimdi prosedürün tersini yapalım: güncellemeleri e-posta ile alıp IB'ye yazalım.

Boolean türünden "DistributedBaseExchange in Progress" parametresini session parametrelerine ekleyelim. Aşağıda anlatacağım
randevu.

Aşağıdaki yordamı rbDistributedBase ortak modülüne ekleyelim:

Prosedür rbGetInterchangeMessages() Dışa Aktar UseSMTP = Constants.UseExchangeBySMTP.Get(); //rbSendExchangeMessages() prosedüründekiyle aynı, önce bir nesne yarat Mail Kullanılırsa SMTP Sonra MailProfile = Yeni InternetMailProfile; MailProfile.POP3ServerAddress = Constants.POP3ExchangeServerAddress.Get(); MailProfile.POP3 Bağlantı Noktası = Constants.POP3ExchangeServerPort.Get(); MailProfile.User = Constants.POP3ExchangeServerUser.Get(); MailProfile.Password = Constants.POP3UserPasswordExchange.Get(); MailProfile.Timeout = Constants.TimeoutServer.Get(); Posta = Yeni InternetMail(); Mail.Connect(MailProfile); deneniyor İstisna raporu(" DEĞİŞİM: Posta profiline bağlanırken hata oluştu! |Değişim başarısız!", MessageStatus.Very Önemli); Geri Dön; EndTry; Else Mail = Yeni Posta(); Mail.Connect()'i Deneyin; İstisna Raporu(" DEĞİŞİM: Kullanıcı posta profiline bağlanırken hata oluştu! |Değişim başarısız!", MessageStatus.Very Önemli); Geri Dön; EndTry; EndIf;MessageArray = Yeni Dizi; UseSMTP ise O Zaman AllMessages = Mail.Select(False); Aksi takdirde AllMessages = Mail.Select(False, False); EndIf; //Tüm harfler arasından "1C: Exchange" konusuna sahip olanları seçin. //Küçük ama önemli not: //"1C: Exchange" konulu alınan tüm mektupların amaçlandığını düşünüyoruz. // yani mevcut düğüm için, //onlar. değişim açısından farklı düğümlerin FARKLI e-posta adreslerine sahip olması. AllMessages Döngüsünden Gelen Her Mesaj İçin Lion(Message.Subject, 8 )<>"1C: Exchange" Ardından Devam Edin; EndIf; TryingMessageArray.Add(Mesaj); //Harf ekini diskete kaydedin. //Doğru iç içe yerleştirme kontrolünü şimdilik perde arkasında bırakalım. Ek = Mesaj Ekler; MessageFileName = TempFileDirectory() + Ek.Adı; ExchangeData = Ek.Veri; ExchangeData.Write(MesajDosyaAdı); //XMLReader ve MessageReader nesnelerini kullanarak verileri okuyoruz //kaydedilen dosyadan güncellemeler. Güncellemeleri IB'ye yazmadan önce // DistributedBaseExchange In Progress oturum parametresini True olarak ayarlayın. //Ardından IB'deki değişiklikleri okuyun: Exchange Plans.ReadChanges(ReadingMessage). //Aynı zamanda mesajları bir diziye kaydediyoruz, böylece daha sonra hepsini bir kerede silebiliriz. XMLReader = Yeni XMLReader(); ReadingXML.OpenFile(MesajDosyaAdı); ReadMessage = ExchangePlans.CreateReadMessage(); ReadingMessage.StartReading(ReadingXML); SessionParameters.DistributedBaseExchange Devam Ediyor = True; Exchange Plans.ReadChanges(ReadMessage); ReadMessage.FinishReading(); ReadXML.Close(); Constants.OutputMessages.Get() ise Report(" DEĞİŞİM: Değişim verileri kabul edildi",MessageStatus.Information); EndIf; İstisna Raporu(" EXCHANGE: Exchange verileri alınırken hata oluştu:" + ErrorDescription(), MessageStatus.Very Önemli); EndTry; //Değiş tokuş veri okuması tamamlandıktan sonra dönüş //oturum parametresi IsExchangeDistributedBase değeri False. SessionParameters.DistributedBaseExchange Devam Ediyor = Yanlış; Dosyaları Silme Girişimi(MessageFileName); İstisna // eğer işe yaramazsa, tamam Girişimin Sonu; Döngü Sonu; UseSMTP ise, Mail.DeleteMessages(MessageArray); EndIf; Mail.Disconnect(); Prosedürü Bitir

Şimdi oturum parametresinin ne için olduğu hakkında.
Gerçek şu ki, verileri Exchange Plans.ReadChanges() yöntemiyle okurken bir çağrı gerçekleşir.
Değiştirilen/eklenen nesnelerin BeforeWrite() olay işleyici prosedürleri. Ve eğer kayıt yaparken
işleyici prosedüründeki herhangi bir nesnenin, İptal parametresi True olarak ayarlanacak ve ardından
ExchangePlans.ReadChanges() yürütülürken, bir istisna meydana gelir ve buna göre değişim
idam edilmeyecektir. IsInDistributedBaseExchange oturum parametresinin değeri şu olabilir:
bu durumu önlemek için işleyici prosedürlerinde ayrıştırılır.
12. revizyonun yayınlanmasıyla (sürümler konusunda yanılıyor olsam da), bu yöntemin alaka düzeyi biraz
kullanımdan kaldırıldıA çünkü nesnelerin bir özelliği var Takas Seçenekleri. Bu özellik şu durumlarda True olarak ayarlanır:
bir değişim planı aracılığıyla veri kaydetme.

Şimdi panelimizin arayüzüne bir buton daha ekliyoruz ve bunun çağrısını kapatıyoruz.
prosedürler. Enterprise'ı başlatıyoruz ve keyfini çıkarıyoruz.
Neredeyse her şey yapıldı, biraz kaldı: prosedürlerimizin otomatik olarak çalışmasını sağlamak.
4. Adım. Otomatik değişimi ayarlama

Yani, hikayemizin amacına neredeyse yaklaştık. Tek bir adım kaldı: başlatmak
değişim prosedürlerinin otomatik modda yürütülmesi. Başlayalım.

Number(5,0) türünden DistributedBaseAutoExchange Interval sabitini ekleyelim.

Kullanıcı ayarlarına PerformDistributedBaseExchange parametresini ekleyelim. yapılandırma için
"Ticaret Yönetimi" şu şekilde yapılır:

* "Kullanıcı Ayarları" özellik türleri planında önceden tanımlanmış bir tane ekleyin
Boolean türündeki DistributedBases'in karakteristik PerformExchange.
* "Kullanıcılar" dizin öğesi biçiminde, bu parametrenin değişikliğini yapılandırıyoruz (olarak
diğer parametrelere benzetilerek form modülünde görüntülenebilir).

rbDistributedBase modülüne bir prosedür ekleyin:

Prosedür rbExecuteExchange(prUser) Verme Eğer npGetDefaultValue(prUser, "") O zaman rbGetExchangeMessages(); rbSendExchangeMessages(); EndIf; Prosedürü Bitir

uygulama modülüne:

Prosedür CheckConnectionAutoExchange() If npGetDefaultValue(chCurrentUser, ") Dışa Aktar Gerçek DağıtılmışBaseExchange") Ve Constants.DistributedBaseAutoExchange Interval.Get() > 0 Sonra ConnectWaitingHandler(" Otomatik Değişimi Yürüt", Constants.DistributedBaseAutoExchange Interval.Get()); Aksi takdirde DisableWaitingHandler(" Otomatik Değişimi Yürüt"); EndIf; EndProcedure Prosedürü ExecuteAutoExchange() Dışa Aktar rbExecuteExchange(chCurrentUser); DisableWaitingHandler(" Otomatik Değişimi Yürüt"); If npGetDefaultValue(chCurrentUser, " Gerçek DağıtılmışBaseExchange") Ve Constants.DistributedBaseAutoExchange Interval.Get() > 0 Sonra ConnectWaitingHandler(" Otomatik Değişimi Yürüt", Constants.DistributedBaseAutoExchange Interval.Get()); EndIf; EndProcedure Prosedür DisableAutoExchange() Export DisableWaitingHandler(" Otomatik Değişimi Yürüt"); Prosedürü Bitir

uygulama modülünün AtStartSystem() prosedürüne aşağıdaki satırları ekleyin:

(ticari ekipmanı bağladıktan sonra)
...
SessionParameters.DistributedBaseExchange Devam Ediyor = Yanlış; CheckConnectionAutoExchange();

Süreci kontrol etmek için panelimize birkaç düğme daha ekleyelim: prosedürü bir tanesine asıyoruz
CheckConnectingAutoExchange(), diğerine - DisableAutoExchange()

İşletmeyi başlatıyoruz, kullanıcı özelliklerini ve otomatik değişim aralığını ayarlıyoruz ve hepsi bu kadar!

Şimdi, bu en yapılandırılmış kullanıcı altında veritabanına girildiğinde işleyici başlatılacak
ExecuteAutoExchange() bekleniyor. Doğal olarak, çevresel veritabanında da kullanıcıyı yapılandırmanız gerekir.
degis tokus icin.

Küçük ama önemli bir not daha:

Yarattığımız tüm tılsımlarda bir sıkıntı var: konfigürasyon değişiklikleri. -de
Kenar tabanı, konfigürasyon değişikliklerini içeren bir mesaj aldığında,
kabul edilecek, ancak bir istisna oluşacaktır. Bu durumda, değiştirilen konfigürasyon
yüklendi. Veritabanı yapılandırmasını güncellemek için tüm kullanıcıları atmanız gerekir, şu adrese gidin:
yapılandırıcı ve veritabanı yapılandırmasını güncelleyin (bundan önce verileri boşaltmak iyi bir fikirdir). İLE
Ne yazık ki, bu gerekli bir kötülük. Kısa bir bat dosyası yazarak hayatınızı biraz kolaylaştırabilirsiniz.
bu içerik gibi bir şey:

1cv8.exe YAPILANDIRMA /F<путь к ИБ>/N<Пользователь>/P<Пароль>/GüncellemeIBCfg

Ve bir not daha:

Ne yazık ki, xml dosyaları kompakt değildir, ancak neyse ki mükemmel bir şekilde sıkıştırılır. içinde olabilir
mesaj gönderme ve alma prosedürleri paketleme-açma dosyalarını ekler. COLOR="#666666">Bunu harici bir arşivleyici ile veya örneğin Wheel.AddIn gibi VK kullanarak yapabilirsiniz.
(http://1c.proclub.ru/modules/mydownloads/personal.php?cid=81&lid=2714) .
10. (görünüşe göre) baskının piyasaya sürülmesiyle, önceki cümle biraz modası geçmiş, çünkü platform
ZIP algoritmasını kullanarak dosyaları sıkıştırmanın yerleşik araçlarıydı. Onlar. artık dosyaları sıkıştırmak mümkün
VK kullanmadan.

RIB, dalları 1C Enterprise'ın ayrı dağıtılmış üsleri olan ağaç benzeri bir yapı olan dağıtılmış bir bilgi tabanıdır. Bu tabanlara dağıtılmış bilgi tabanı düğümleri (bundan sonra düğümler olarak anılacaktır) denir. Bu düğümler arasında, tüm düğümleri (yapılandırmalar ve veritabanları) senkronize etmek için bir bilgi alışverişi oluşturulur.

Ana mekanizma, bazı ayırt edici ve çok yönlü özelliklere sahip bir değişim mekanizmasıdır. Temel fark, RIB değişim mekanizmasının daha uzmanlaşmış ve dar olması, evrensel değişimlerin ise kullanıcıya daha geniş bir fırsat yelpazesi sunmasıdır.

RIB çalışmasının temel ilkeleri

Konfigürasyon yapısını yalnızca dağıtılmış bilgi bankasının ana kök düğümünde değiştirebilirsiniz. Ayrıca, bu değişiklikler hiyerarşik olarak alt düğümlere yayılır. Böylece tüm RIB düğümlerinde tek bir konfigürasyon yapısı alanı sağlar.

Veriler, sırayla diğer tüm düğümlere dağıtılan düğümlerin herhangi birinde değiştirilebilir. Ayrıca, bu verilerin sistem katılımcılarının geri kalanına aktarılması gerekmez ve tam kimlikleri desteklenmeyebilir. Diğer RIB katılımcıları ile değiş tokuşa katılan verilerin bileşimi, geliştirici tarafından isteğe göre yapılandırılabilir. Ayrıca, ayarlar yalnızca yapılandırma meta verileri düzeyinde değil, aynı zamanda özel seçimlerin uygulanabileceği bireysel öğeler düzeyinde de yapılabilir.

Yukarıda bahsedildiği gibi, RIB mekanizması değişim planlarının kullanılmasıyla sağlanır. ancak bu hiyerarşik yapıda belirli bir planın kullanılabilmesi için "Dağıtılmış bilgi bankası" özelliğinin etkinleştirilmesi gerekir.

RIB'deki tüm veriler mesajlar aracılığıyla iletilir. Bu mesajların içeriği, evrensel değişim mekanizmasında olduğu gibi açıkça düzenlenmiştir ve keyfi olamaz. Veriler, XML serileştirme ilkesi kullanılarak mesaja yerleştirilir. Bu veri değişikliklerine ek olarak, belirli bir miktarda hizmet bilgisinin yanı sıra, yapılandırma değişikliği ile ilgili bilgiler de mesaja yerleştirilir. Değişiklikler tam otomatik olarak exchange mesajına yerleştirilmekten kaydedilir. Ne kullanıcı ne de geliştirici bunu etkileyemez.

RIB'de değişim mesajlarının alınması ve oluşturulması tek bir komutla ayarlanır

Değişim planları. Değişiklikleri Yaz(Mesaj Yaz, 0 )

İçerik komut ile okunur.

Çözüm

RIB mekanizmasının, yalnızca RIB yapısında bulunan bazı ayırt edici özelliklere sahip evrensel bir değişim mekanizmasından oluştuğunu rahatlıkla söyleyebiliriz.

1s 8.3'te mi yoksa 1s 8.2'de mi? Dağıtılmış bir bilgi bankası kurmak. adım adım talimat.

Bilgi bankası dağıtımı, çeşitli nedenlerle fiziksel bağlantısı olmayan veritabanlarında ortak muhasebenin sürdürülmesi gerektiğinde kullanılır. Bir örnek, büyük bir şehirde ve küçük bir köyde internet bağlantısı olmayan bir bölümü olan bir şirketin muhasebesidir. Veya periyodik olarak bazı özel durumlarda, ofiste ve ofis dışında, örneğin evde bir veritabanıyla aynı anda çalışmak gerekir. Bu ve benzeri durumlarda, dağıtılmış bilgi tabanının (DIB) kullanılması haklı ve gereklidir.

Bu makalede, yerel veya ağ dizini aracılığıyla 1C Accounting for Russia sürüm 8.3 yapılandırmasında bir bilgi veritabanının dağıtımının organizasyonunu ele alacağız. 8.2 1C sürümünde bu talimat ayrıca yararlı olacaktır, çünkü esasen küçük farklılıklarla bir süreci tanımlar.

==== Ana taban için ayar ====

1C 8.3'ü "Kuruluş" modunda açtıktan sonra "Yönetim" bölümüne geçelim. 1C 8.2 sürümünde, başlamak için "Servis" - "Dağıtılmış bilgi tabanı (RIB)" - "RIB düğümlerini yapılandır" ana menüsüne gitmeniz gerekir.

Ayrıca, süreci IB sürüm 8.3 bağlamında ele alacağız. Bu nedenle, "Yönetim" bölümüne giderek "Program ayarları" nı seçin. Ayarlarda "Veri Senkronizasyonu" bölümüne gidin. Burada "Veri senkronizasyonunu kullan" kutusunu işaretliyoruz ve veritabanı önekini belirtiyoruz. Merkezi bir üssü ima eden "CB" belirtiyoruz.

Bundan sonra, sağ menüde "Veri senkronizasyonu" öğesi belirir. Hadi onu seçelim. Açılan alt pencerede "Veri senkronizasyonunu ayarla" düğmesini tıklayın. Açılır menüde, çeşitli senkronizasyon kullanım durumları için ayar seçenekleri belirleyebilirsiniz. "Dağıtılmış bilgi bankası ..." seçeneğini seçiyoruz.

Genel geliştirme için, bir sonraki pencerenin içeriğiyle tanışıyoruz ve "İleri" yi tıklıyoruz.

Bir sonraki pencerede, . Yükleme boyutunu küçültmek için veri sıkıştırmayı belirtiyoruz ve siz de veri arşivi için hemen bir parola belirleyebilirsiniz. Unutmamak önemlidir. Doldurmayı "İleri" düğmesiyle onaylayın.

Sonraki iki pencere, FTP sunucusu ve e-posta yoluyla değiş tokuş ayarlarını belirlemek içindir. Daha önce de belirtildiği gibi, bir dizin aracılığıyla bir değiş tokuş yöntemi düşünüyoruz, bu nedenle FTP ve e-posta ayarlarını atlıyoruz.

Bir sonraki pencere, çevresel veri tabanı bölümündeki değişim parametrelerini belirtmek için tasarlanmıştır. Adını ve önekini belirtin. Sonraki - "İleri" düğmesi.

Oluşturduğumuz değişim parametrelerini kontrol edelim ve geleneksel "İleri" düğmesiyle doğruluğunu onaylayalım.

Değişim için gerekli ayar seti otomatik olarak oluşturulacaktır. Biraz zaman alacak.

Önemli! Aşağı akış düğümü için ilk görüntünün oluşturulması önemli miktarda zaman alır. Bu önemin boyutu, bilgisayarın kaynaklarına ve ana veritabanındaki muhasebe hacmine bağlıdır.

Bir görüntü oluşturmaya karar verdiğimizi varsayalım. Bir önceki pencerede "Finish" butonuna tıkladıktan sonra, slave IS imajını oluşturmak için ayarlara gireceğiz. Yerel işlemler için en basit durumu ele alıyoruz. Bunun için açılan pencerede gerekli detayları belirtiniz. "Dosya tabanının tam adı" parametresine özellikle dikkat edin. Bir "ağ" biçiminde yerel bir yol oluşumunu varsayan tam UNC biçiminde belirtilmelidir. Örneğin - "\\Server1C\Databases\RIB". Veritabanı dosyasının adını belirtilen yola ekleyin - 1Cv8.1CD.

"Başlangıç ​​görüntüsünü oluştur" düğmesine tıkladıktan sonra, bağımlı taban için bir görüntü oluşturma işlemi başlar.

İşlem bittikten sonra belirtilen dizinde bir veritabanı dosyası oluşturulacaktır. Bu yeni oluşturulan veritabanı, tam kullanımdan önce yapılandırılmalıdır.

==== Kenar tabanı için kurulum ====

Bunu yapmak için 1C'ye bağlı olması gerekir. Bunu nasıl yapacağınızı makalemizdeki talimatlarda bulacaksınız - Bağlandıktan sonra, yeni üs konfigüratör modunda çalıştırmanız ve kullanıcılar oluşturmanız gerekir. Ardından, IB'nin 1C "Kurumsal" modunda başlatılması gerekiyor.

Herhangi bir nedenle, kullanıcıların oluşturulmasının daha sonraya ertelenmesi gerekiyorsa, bağlandıktan sonra, veritabanını 1C "Kuruluş" modunda başlatabilirsiniz. Sizden bir "Yönetici" kullanıcı oluşturmanız istenecek, bunu kabul edeceksiniz ve başlangıç ​​popülasyonu gerçekleştirilecektir.

Ardından, ana üs ile eşleştirmeyi kurmaya devam etmeniz gerekir. Bu ayar, yukarıda ana taban için açıklanana benzer.

Ana üs ile iletişim için bir ayar oluşturulacaktır.

============================================

Böylece, şimdi ana ve çevresel üsleri oluşturduk. Ayrıca bu veritabanlarının her birinde senkronizasyon ayarları oluşturuldu. Artık bu ayarları düzenlemeye ve uygun forma getirmeye devam edebilirsiniz. Otomatik değişim kuralları oluşturabilir veya değişimi manuel olarak gerçekleştirebilirsiniz.

Ana veritabanında yapalım. Çevre birimi tabanı da aynı şekilde yapılandırılır.

Düzenleme, kurallara ve veri senkronizasyon programına uygulanabilir.

"Veri senkronizasyon programı" bölümündeki "Yapılandır" düğmesine tıklayarak, seçilen veritabanı için veri yüklemek/indirmek için otomatik çalışma programı için komut dosyalarını düzenlemeniz gerekir. Düzenleyemezsiniz, sadece varsayılan seçeneklerle aynı fikirde olursunuz.

Parametreleri düzenlemek için, otomatik program verilerinin bulunduğu bağlantıya tıklamanız yeterlidir. Ardından, görevleri başlatmak için zaman parametrelerini düzenleriz. Yer imlerinden geçerek lansmanın hem saatini, tarihlerini hem de haftanın günlerini değiştirebilirsiniz.

Ana betik penceresindeki "Görevi çalıştır" düğmesine tıklayarak görevi manuel olarak başlatabilirsiniz.

"Veri senkronizasyon kuralları" bölümündeki "Ayarlar" düğmesine tıklayarak, görev başlatma komut dosyalarını değiştirme işlemlerini gerçekleştirebileceğiniz gibi yükleme/indirme günlüğünü de görüntüleyebilirsiniz. İkincisi, erişimi yönetmek ve değiş tokuşların düzenliliğini izlemek için yeterince önemlidir.

Dağıtılmış bir veritabanının değiş tokuşunu otomatik olarak başlatmak için komut dosyaları oluşturmayı ve düzenlemeyi bitirdikten sonra, verileri boşaltmaya ve ardından yüklemeye devam edebilirsiniz.

Bunun üzerine, temel olarak, merkezi ve çevresel düğümler için dağıtılmış hamam veri tabanının konfigürasyonu sona ermiştir.

Resimli talimatları indirin

Dağıtılmış bilgi tabanı. adım adım talimat
Dağıtılmış Bilgi Bankası (RIB) 1C: Kurumsal
Dağıtılmış bir bilgi bankasının oluşturulması ve konfigürasyonu
1s 8.2'de nervür nasıl kurulur
1C'de dağıtılmış bir bilgi tabanı nasıl kurulur
1C'de nasıl kurulur
1C'de nasıl kurulur
1C'de dağıtılmış bir bilgi tabanı (RIB) kurma
1C için RIB kurulumuna bir örnek: Muhasebe 8
Dağıtılmış bir bilgi bankasının oluşturulması ve konfigürasyonu