25 Ekim 2016

RIB'yi 2 düğüm için ve 10 düğüm için kurmak ve desteklemek arasında büyük bir fark yoktur, ancak uzak nokta sayısı yüzü aştığında tamamen farklı sorunların çözülmesi gerekir.

İlk veri:

Yapılandırma: Perakende 2.2
Platform 1C: 8.3.7.1970



Proje süresi: bir yıl.



Mimari:

İlk önce RIB şemasına karar verdik. Mümkün olduğu kadar uzun süre “yıldız” şemasına odaklanmaya karar verildi; teknolojik sınırlamalara ulaşıldığında - bir kar tanesi.





Sınırlamalar:
- 2GB RAM
- 1 fiziksel işlemci


Yukarıdakilerin hepsinden asıl can sıkıcı şey, maksimum veritabanı boyutundaki sınırlamadır.

Ancak bu, sitedeki güncel olmayan verilerden temizlemek için bir prosedürü dikkatli bir şekilde düzenlemeniz gerektiği anlamına gelir.

1C ve MS SQL sunucusu için ayrı bir fiziksel sunucu ayrılmıştır. Borsaların ve uzun vadeli operasyonların ana yükünü üstlenecek.
Son istemci bilgisayarlar, ince istemciyle çalışacakları ve üzerlerindeki yük minimum düzeyde olacağı için değiştirilmez.
.


temel ayarlar

60 deniz mili hıza kadar RIB uygulama projemi yürüttüğüm UT 10.3'ten bu yana elbette "köprünün altından çok sular aktı."

1C hareketsiz durmadı. Perakende 2.2 artık seçici veri yükleme ihtiyacını dikkate alıyor.
Yalnızca kendisiyle ilgili bilgiler mağaza veritabanına yüklenecektir:
- Tüm referans kitapları (uzmanlaşmış olanlar hariç)
- Bu mağazaya ait belgeler

Diğer bir soru da şu ya da bu şekilde, veritabanına bir düğüm eklemek, yazıldığında her ortak öğe için kayıt tablosuna başka bir giriş eklemek anlamına gelir.





1) Yükleme ve indirme için ayrı senkronizasyon senaryolarına bölmek gerekir
Önemli olan, boşaltma işleminin uzun sürmesi ve engellemeyi gerektirmesidir, ancak yükleme işlemi oldukça sorunsuzdur. Aynı zamanda, perakende satış noktalarından hızla veri almamız ve bu verileri günde yalnızca birkaç kez vermemiz gerektiği sıklıkla görülür.

2) Sorunlu mağazaları belirleyin ve bunları genel senkronizasyon senaryosundan kaldırın. Üzerlerinde büyük miktarda boşaltma olabilir - bu, diğer düğümler de dahil olmak üzere tüm borsayı yavaşlatacaktır. Sorunlar çözüldükten sonra tekrar eklenirler.

3) Veri göndermek ve almak için çeşitli komut dosyaları oluşturun. Ancak burada asıl önemli olan miktarlarının doğru dengesini yakalamaktır.
(sürüm 8.1'den beri).
Sonuç olarak, RIB'nin boşaltılmasındaki paralellik sınırlıdır. Pratikte 2-3 komut dosyasının paralel olarak çalıştırıldığı ortaya çıkıyor.


Neyin iyileştirilmesi gerekiyordu

1C RIB'in standart mantığındaki en önemli sorun güncellemelerdir

Değişimin bir başka sorunu da bilgi kayıtlarıdır. Bilgi kaydının her kaydının XML'e yüklenmesi, hizmet öğeleri vb. içeren ayrı bir XML düğümü oluşturur. Ayrıca, içinde 100 kayıt bulunan bir bilgi kaydı için “SelectChanges()” işlevi, 100 satırlık sonuç tablosunu alacaktır. Aynı zamanda, 100 satırlı bu A dizininin tablo bölümünde yalnızca bir giriş seçilmiş olacaktır. Ve bu özel engelleme zamanıdır. Dolayısıyla, bilgisayarda diğer mağazalara takas edilmek üzere düzenli olarak kaydedilen çok sayıda kayıt varsa, o zaman bunu, aşırı durumlarda kayıt yaparken tablo şeklinde bir bölüm içeren bir dizin biçiminde sunmak elbette daha doğrudur. , aynı kaydın satırlarını oluşturabilir. Her neyse, .

Bir diğer önemli detay ise; Ne için? Zaten 3 milyona yakın indirim kartı var, bunlarla çalışmak için harici bir çevrimiçi sistem kullanılıyor. İndirim kartlarını tüm mağazalara aktarmaya devam ederseniz, bu durum alışverişleri önemli ölçüde artıracağı gibi, bazın 10 GB hacmini aşmasına da yol açabilir.

Mekanizmalardan bazıları, merkezi veri tabanıyla temasa geçilerek çevrimiçi olarak uygulanıyor: diğer mağazalardaki bakiyeler, başka bir mağazadan makbuzun iadesi, hediye sertifikasının geçerliliğinin kontrol edilmesi.


Çoğaltma


Düzenli bir şekilde bir başlangıç ​​RIB düğümü oluşturmak, kopyalamayı prensipte imkansız hale getirir.
Bu nedenle aşağıdaki gibi yeni bir düğüm oluşturulur:


2) Bu veritabanı RIB'deki tüm genel verileri değiştirir ancak özel (belgeler) almaz


5) Mağazanın tabanı hazır.

Sunucuya hazır bir yazılım paketi dağıtıldığından fazla zaman almaz. Daha sonra yeni oluşturulan veritabanı sunucuya yüklenir ve mağazaya gönderilmeye hazır hale gelir.


İnce istemcinin faydaları

Retail 2.2'nin (İnce İstemci) “ruhu ısıtan” iki önemli avantajı:








Destek ve güncellemeler




1) Mağazalardan manuel güncelleme (çok doğru değil, değişiklikler alınamayabilir, çağrılar ve sorunlar yaşanabilir) - daha önce de durum böyleydi

3) Güncelleme için bir *.cmd veya 1C betiği yazın veya hazır bir tane alın. Uygulamada görüldüğü gibi, böyle bir çözüm her zaman gönülsüzdür (kararsızdır) ve ona çok az işlevsellik kazandırmak mümkün olacaktır.

Görevlerimiz nelerdi:


2) Güncelleme sırasında kullanıcıyla etkileşimli etkileşim mümkündür (mesajlar, onay, ilerleme çubuğu).








Ana işlevler:




4) Temsilcilerin durumunun kontrol edilmesi
5) Raporları güncelleyin
6) yedekleme

















Örneğin, bir güncellemeden sonra hata mesajı şu şekilde görünür:

Böylece projenin başarılı bir şekilde tamamlanma şansı yüksek oldu. Uçuşun en azından yarısında uçuş normaldir.

İlginç gelebilecek başka çözümlere gelirsek ayrı yazacağım

Not: ve en önemlisi: Daha fazla desteğin doğru planlanması, bu tür projelerin daha fazla başarısının temel faktörlerinden biridir. :)

25 Ekim 2016

RIB'yi 2 düğüm için ve 10 düğüm için kurmak ve desteklemek arasında büyük bir fark yoktur, ancak uzak nokta sayısı yüzü aştığında tamamen farklı sorunların çözülmesi gerekir.

Yani, ilk veriler:

Yapılandırma: Perakende 2.2
Platform 1C: 8.3.7.1970
Proje sonunda tahmini düğüm sayısı: 200
Merkezdeki ekipman kaynakları: önemli kısıtlamalar olmadan
Bu noktada ekipman: tartışılan bir konu.
Proje süresi: bir yıl.

Mimari:

İlk önce RIB şemasına karar verdik. Daha önce “yıldız” şemasına odaklanılmasına karar verildi.
Perakende satış noktalarında, Windows işletim sistemi çalıştıran özel bir sunucuyla işin istemci-sunucu sürümü kullanılır.
Sunucu 1C, "Sunucu 1C MINI" sürümünde kullanılacaktır https://1c.ru/news/info.jsp?id=17577
DBMS sunucusu - MS SQL Express 2008 R2.

SQL Express 2008 R2, bu SQL Server serisinin güncel en son sürümüdür.
Sınırlamalar:

2GB RAM
- 1 fiziksel işlemci
- 10 GB maksimum veritabanı boyutu

Yukarıdakilerin hepsinden en sinir bozucu olanı elbette maksimum veritabanı boyutunun sınırlandırılmasıdır. Ancak aslında bu, sitedeki güncel olmayan verilerden temizleme prosedürünü dikkatli bir şekilde organize etmenin gerekli olacağı anlamına gelir.

1C ve MS SQL sunucusu için ayrı bir sunucu ayrılmıştır. Değişim ve işlemlerin ana yükünü üstlenecek.
Son istemci bilgisayarlar, ince istemci ile çalışacakları ve alt kısımdaki yük minimum düzeyde olacağı için değiştirilmez.
Mağazadaki sunucu sadece güçlü bir bilgisayardır. Ancak önkoşul, üzerinde MS SQL veritabanlarının bulunduğu bir SSD diskinin bulunmasıdır..
Sunucu aynı zamanda rutin operasyonların gece gerçekleştirilebilmesini ve iş kesintisi yaşanmadan mağazanın veri tabanına erişilebilmesini sağlayacak.

temel ayarlar

60 deniz mili hıza kadar RIB uygulama projemi yürüttüğüm UT 10.3'ten bu yana elbette "köprünün altından çok sular aktı." 1C hareketsiz durmadı. Perakende 2.2 artık seçici veri yükleme ihtiyacını dikkate alıyor.
Yalnızca mağazayla ilgili bilgiler mağaza veritabanına yüklenecektir:
- Tüm dizinler (bazıları hariç)
- Bu mağazaya ait belgeler
Veri kaydı, önbelleğe alınabilecek her şey olan kayıt kurallarına göre gerçekleşir. Kayıt sırasında önemli bir yavaşlama yaşanmamaktadır.
Başka bir soru da şu ya da bu şekilde, veritabanına bir düğüm eklemek, tüm veritabanlarındaki her ortak öğe için başka bir kayıt eklemek anlamına gelir.

Yüklemenin kendisinin ayarlanmasında özel bir şey yoktur. Senkronizasyon senaryolarını ayarlarken bazı nüanslar vardır:

1) Yükleme ve yüklemeyi ayrı senkronizasyon senaryolarına ayırmak gerekir
Mesele şu ki, boşaltma işlemi uzun sürüyor ve engellemeyi içeriyor, yükleme ise oldukça sorunsuz. Aynı zamanda, perakende satış noktalarından hızla veri almamız ve bu verileri günde yalnızca birkaç kez vermemiz gerektiği sıklıkla görülür.

2) Sorunlu depoları belirleyin ve bunları genel senkronizasyon senaryosundan kaldırın. Üzerlerinde büyük miktarda yük boşaltımı olabilir; bu, diğer düğümler de dahil olmak üzere tüm borsayı yavaşlatacaktır.

3) Veri göndermek ve almak için bazı gönderme ve alma komut dosyaları oluşturun. Ancak burada asıl önemli olan dengedir.
1C'deki bazı şeyler değişmez. Aynı "SelectChanges" yöntemi yalnızca sırayla yürütülebilir(sürüm 8.1'den beri).
Sonuç olarak, RIB'nin boşaltılmasındaki paralellik sınırlıdır. Uygulamada, bir seferde 2-3 komut dosyası yüklemeniz gerekir.
Alma senaryosuna gelince, burada gerekirse çok daha büyük bir paralellik mümkün elbette.

Neyin iyileştirilmesi gerekiyordu

Elbette üzücü ve üzücü ama BSP'ye iyice müdahale etmek zorunda kaldım. Standart 1C mantığındaki en önemli sorun güncellemelerdir. Güncellemeden sonra buna benzer bir pencere belirir:

Bunların hepsi tekel modunda gerçekleşir. Diğer şeylerin yanı sıra sistem, özel modda güncelleme sonrasında yine de değişim yapmaya çalışacaktır. Bütün bunların nereye varacağını tahmin etmek zor değil.
Tüm bu süre boyunca mağaza çalışamıyor, kasada müşteriler var ve şirket para kaybediyor.

Değişimin bir başka sorunu da bilgi kayıtlarıdır. Her bilgi kaydı girişinin XML'e yüklenmesi, hizmet öğelerini ve onu takip eden her şeyi içeren ayrı bir XML düğümü oluşturur. Ayrıca 100 kayıt bulunan bir bilgi kaydı için “değişiklikleri seç” fonksiyonu, ortaya çıkan tablo 100 satır içerecek, aynı zamanda bu 100 satırlı bir dizin ise, listede yalnızca bir kayıt seçilecektir. masa bölümü. Dolayısıyla, PC'de diğer mağazalara gönderilmek üzere düzenli olarak kaydedilen çok sayıda kayıt varsa, o zaman bunu, aşırı durumlarda kayıt yaparken tablo şeklinde bir bölüm içeren bir dizin biçiminde sunmak elbette daha doğrudur. , aynı kaydın kayıtlarını oluşturabilir. Her neyse, Borsalardaki bilgi kayıtları kötüdür.

Bir diğer önemli detay ise; İndirim kartları borsanın tamamen dışında tutulur ve yalnızca belirli bir mağazanın çalışanları borsanın dışında tutulur. Ne için? Zaten 3 milyona yakın indirim kartı var, bunlarla çalışmak için harici bir çevrimiçi sistem kullanılıyor. İndirim kartlarını tüm mağazalara aktarmaya devam etmeniz, alışverişleri önemli ölçüde artıracağı gibi, bazın 3GB hacmini aşmasına da yol açabilir.

Mekanizmalardan bazıları, merkezi veri tabanıyla temasa geçilerek çevrimiçi olarak uygulanıyor: diğer mağazalardaki bakiyeler, başka bir mağazadan makbuzun iadesi, hediye sertifikasının geçerliliğinin kontrol edilmesi.

Çoğaltma

Elbette çoğaltma hızlandırılmış bir hızda gerçekleştiriliyor.
İlk RIB düğümünü standart bir şekilde oluşturmak elbette çoğaltmayı imkansız hale getirecektir.
Bu nedenle aşağıdaki gibi yeni bir düğüm oluşturulur:

1) Sahte mağazaya sahip ayrı bir veritabanı var
2) Bu veritabanı RIB'deki tüm genel verileri değiştirir ancak özel bilgi almaz.
3) Yeni bir veritabanı oluşturmak istediğimizde bunu kopyalamanız yeterlidir.
4) Daha sonra ayarları yapıyoruz - mağaza, önek vb.
5) Mağazanın tabanı hazır.

Sunucuya hazır bir yazılım paketi dağıtıldığından fazla zaman almaz. Daha sonra yeni oluşturulan mağaza veri tabanı sunucuya yüklenir ve mağazaya gönderilmeye hazır hale gelir.

İnce istemcinin faydaları

“ruhu ısıtan” iki önemli avantaj.

1) Perakende satış noktalarında bilgisayar parkının tamamının değiştirilmesine gerek yoktur. İşlemlerin %90'ı sunucu üzerinde gerçekleştirilmekte ve sunucu oraya "nispeten güçlü bir bilgisayar" ile getirilmektedir.

2) Ekipmanın çalışmayı reddetme yeteneği vardır, bu özellikle yeni kurulan veya zaten yıpranmış ekipmanlarda sıklıkla görülür.
Bu durumda, eylemler artık son derece basittir - mağaza, merkezi veritabanında çalışmaya geçer.
Bu işlem 5-10 dakikadan fazla sürmez, dolayısıyla ekipmanda ciddi sorunlar olsa bile ticaret kesintiye uğramaz.

Destek ve güncellemeler

Sonunda en ilginç noktaya ulaştık; tüm bunları nasıl sürdürüp güncelleyeceğiz?
Bizim için güncellemeler de uzun süredir bir ikilem olmuştur:

1) Mağazalardan manuel güncelleme (çok doğru değil, değişiklikler gelmeyebilir, çağrılar ve sorunlar yaşanabilir)
2) Teknik desteği kullanarak güncelleme (çok fazla kaynak yok)
3) Güncellemek için *.cmd yazın veya hazır olanı alın. Uygulamada görüldüğü gibi, böyle bir çözüm her zaman gönülsüzdür (kararsızdır) ve içinde çok az işlevsellik vardır.

Görevlerimiz nelerdi:

1) Güncelleme çeşitli modlarda gerçekleşmeli ve merkezi olarak yönetilmelidir
2) Güncelleme sırasında kullanıcıyla etkileşimli etkileşim mümkündür.
3) Güncelleme durumu ve hatalara ilişkin raporlar alınmalıdır
4) Bir yedek olmalı
5) Güncelleme sistemi sorunsuz bir şekilde kendini güncelleyebilmelidir.
6) Sistem sorunsuz bir şekilde genişletilebilir olmalıdır.

Elbette sorunlar basit yöntemlerle çözülebilecek sorunların çok ötesine geçti. Çünkü bu kadar çok uç noktayla otomasyon olmadan yapamayız ve benzer işlevlere sahip az çok hazır hiçbir şey bulamadık
Sonunda MU (MagicUpdater) adını alan bir yazılım geliştirmeye başlamam gerekiyordu.

Ana işlevler:

1) Dinamik veritabanı güncellemesi (komutlu veya planlanmış)
2) Statik veritabanı güncellemesi (komutlu veya planlanmış)
3) değiştirildiğinde son bilgisayarlardaki otomatik aracılar
4) Temsilcilerin durumunun kontrol edilmesi
5) Raporları güncelleyin
6) yedekleme
7) 1C sunucusu ve MS SQL ile yönetim eylemleri
8) Ağ bilgisayarlarındaki tüm 1C istemci uygulamalarının kapatılması
9) Ana ödemede kabul ile statik güncelleme
10) Güncelleme sonrasında değişikliklerin açıklamalarının görüntülenmesi
11) Eylem sırasını ayarlama
12) Tüm bu eylemleri bir programa göre gerçekleştirin

Yaklaşık etkileşim şemaları:

MU Aracısı, mağazada yüklenen ve yapılandırılan bir hizmettir. Aslında belli görevleri yerine getirmek için merkezden emir alıyor.
MU Sunucusu - Sisteme gelen tüm istekleri alan sunucu.
Sıradan teknik destek çalışanlarının gördüğü MU monitörü, günlükleri görüntülemek ve güncelleme veya başka amaçlar için görevleri ayarlamak için kullanılır.

Bana göre oldukça iyi sonuçlandı. Artık güncellemeler neredeyse otomatik olarak gerçekleşiyor.
Örneğin güncellemeden sonra hata mesajı şu şekilde görünüyor; her şey hala merkezde bekliyor.

İstemci bilgisayarlara komutları bu şekilde gönderiyoruz

Uygulamalar kesinlikle 1C değil, oldukça iyi arayüz yeteneklerine sahip. Örneğin, tarihe göre seçim şu şekilde görünür:

Artık daha fazla çoğaltmaya hazırlar. Daha fazla desteğin doğru planlanması, bu tür projelerin sürekli başarısının temel faktörlerinden biridir.

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

Sorumluluk reddi beyanı ve kullanım şartları

Bu makalede tesadüfen adı geçen tüm ticari markalar ilgili sahiplerine aittir.
Bu makale Creative Commons Atıf-Benzer Paylaşım 3.0 Aktarılmamış Lisansı altında yayınlanmaktadır.
http://creativecommons.org/licenses/by-sa/3.0/

Hemen belirtmek isterim ki, aşağıdakilerin tümü platform 8.0.7.36 ve üzeri sürümler için geçerlidir.

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

Konfigürasyonda değişim planı oluşturuyoruz. Buna örneğin "DistributedBase" adını verelim. Gerekli
Değişim planının özelliklerinde "Dağıtılmış bilgi tabanı" onay kutusunu işaretleyin.

Değişime hangi nesnelerin dahil edileceğini belirlemek için "Diğer" sekmesinde "Kompozisyon" düğmesini tıklayın. İle
Varsayılan olarak tüm nesneleri etkinleştirebilirsiniz ("Eylemler" - "Tümünü Etkinleştir"). Önemli bir nokta parametredir
"Otomatik kayıt". Genel olarak tüm nesneler için etkinleştirilmesi gerekir.

Not: Yapılandırmaya yeni nesneler eklerken bunlar değişim planına dahil edilmez. Onlar. sonrasında
Bir nesnenin eklenebilmesi için değişim planına eklenmesi gerekir.

Bazı nesnelerin değiş tokuşa katılmamasını istiyorsanız bunları listeden hariç tutmanız yeterlidir.
değişim planı. Ancak bu durumda referans bütünlüğünün kontrolü tamamen vicdanınıza kalır. Eğer
örneğin belli bir belgenin değişim planında yer almaması ancak üzerinde hareket yaptığı sicilin yer alması,
daha sonra alıcı veritabanında kayıt hareketlerini bir kayıt cihazı belgesi olmadan almak oldukça mümkündür;
Katılıyorum, bu 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 değişim planımızı açın. Değişim açısından her zaman mevcuttur
"noktalı" önceden tanımlanmış düğüm. Bu, mevcut düğümün açıklamasıdır. Açılıp doldurulması gerekiyor. bizim
Bu durumda “Kod” ve “Ad” alanları mevcut olacaktır. Düğümümüze "AA" kodunu atayalım ve onu çağıralım.
"Merkez". Değişim planına bir düğüm ekleyelim. Ona "BB" kodunu atayalım ve "Çevre Birimi" adını verelim.

Artık çevre tabanının bir görüntüsünü oluşturabiliriz. Bu, "İlk oluştur" düğmesine tıklanarak yapılır.
görüntü". Çevresel veritabanı, düğüm listesinde seçilmelidir. Veritabanı görüntüsü, hazır bilgi güvenliği biçiminde oluşturulur.
katalogda veya 1C:Enterprise sunucusunda. (bilgi güvenliği görüntüsünün bir dosya olarak oluşturulduğu 7.7'den farklı olarak
boşaltma). Daha sonra oluşturulan veritabanı, 1CV8.1CD dosyasının kopyalanmasıyla istenen konuma taşınabilir.
(dosya sürümü için) veya Yapılandırıcı aracılığıyla verileri yükleyip indirerek.

Çevre bilgi güvenliği sisteminde değişim planını açtığınızda düğümün “noktalı” olduğunu göreceksiniz, yani. akım
“Çevresel” düğüm bir düğüm haline geldi ve “Merkezi” 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 yaz" ve "Oku" düğmeleri kullanılarak yapılabilir.
Değişiklikler". İlk durumda, değişikliklerin yazılacağı dosyayı seçmeniz istenecektir, ikincisinde ise
- değişikliklerin okunacağı dosya. Değişim xml formatında gerçekleştirilir. Değişiklikler 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, çevre birimi bilgi güvenliği sistemi oluşturduk ve hatta aralarında veri aktarımının nasıl yapılacağını öğrendik.
üsler. Şimdi görevimiz veritabanlarına e-posta yoluyla alışveriş yapmayı öğretmektir.

Değişim planına iki ayrıntı ekliyoruz: "string" türünün E-posta Adresi ve "Exchange Yürüt" türü
"Boole". E-posta adresinde düğümün e-posta adresini saklayacağız; gideceğimiz adres
değişim mesajları gönderin. Otomatik özelliği hızlı bir şekilde devre dışı bırakmak için Props ExecuteExchange gereklidir
mesaj gönderme-gönderme.

E-postayla çalışma prosedürünü evrensel hale getirelim, yani. hadi bunu mümkün kılalım
hem MAPI'nin (MS Outlook gibi bir e-posta istemcisi aracılığıyla gönderme-alma) hem de kullanımı
SMTP/POP3 sunucularına doğrudan erişim.

Yapılandırmaya birkaç sabit ekleyelim:

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

Ortak bir modül ekleyelim, buna "rbDistributedBase" adını verelim. İçine şunu yazıyoruz:

Prosedür rbSendExchangeMessages() Dışa Aktarma UseSMTP = Constants.UseSMTPExchange.Receive(); //Öncelikle ayarlara bağlı olarak InternetMail türünde olacak bir Mail nesnesi oluşturuyoruz, //sunuculara doğrudan erişim kullanılıyorsa veya MAPI kullanılıyorsa Mail. SMTP Kullanıyorsanız O Zaman //InternetMail türündeki bir nesne için bir posta profili oluşturun ve doldurun. MailProfile = Yeni InternetMailProfile; MailProfile.SMTPServerAddress = Sabitler.SMTPExchangeServerAddress.Get(); MailProfile.SMTPPort = Sabitler.SMTPExchangeServerPort.Receive(); MailProfile.SMTPUser = Sabitler.SMTPExchangeServerUser.Receive(); MailProfile.SMTP Şifresi = Constants.SMTPExchangeUserPassword.Receive(); MailProfile.WaitTime = Sabitler.ServerWaitTime.Get(); Posta = Yeni InternetMail(); Mail.Connect(MailProfile) komutunu deneyin; İstisna raporu(" DEĞİŞİM: Posta profiline bağlanırken hata oluştu! Değişim başarısız oldu!" + ErrorDescription(), MesajStatus.VeryImportant); Return; EndAttempt; Aksi takdirde Posta = Yeni Posta(); Deneme Mail.Connect(); İstisna Raporu("" + ErrorDescription(), MesajStatus.VeryImportant); Return; EndAttempt; EndIf ; //Sonra, mevcut olan hariç, değişim planındaki tüm düğümleri seçin, //Exchange gerçekleştir özniteliği ayarlanmış olan. SelectionNodes = ExchangePlans.DistributedBase.Select(); SelectNodes.Next() Döngüsü Yapılırken SelectNodes.PerformExchange Değilse Sonra Devam Edin; endIf; SelectionNodes.Link = ExchangePlans.DistributedBase.ThisNode() ise Devam Edin; endIf; ElektronikAdres = AbbrLP(SelectionNodes.ElectronicAddress); EmailAddress = "" ise Devam Edin; endIf; //XML Record ve Mesaj Kaydı nesnelerini kullanarak değişiklikleri kaydediyoruz //xml dosyasında seçilen düğüm için. Düğüm = SelectionNodes.Link; XMLRecord = YeniXMLRecord(); MesajDosyaAdı = TemporaryFileDirectory() + "Message_" + AbbreviatedLP(ExchangePlans.DistributedBase.ThisNode().Code) + "_ " + AbbreviatedLP(Node.Code) + ".xml "; EntryXML.OpenFile(MesajDosyaAdı); Mesaj Kaydı = ExchangePlans.CreateMessageRecord(); messageRecord.StartRecord(XMLRecord, Node); ExchangePlans.WriteChanges(WriteMessage); WriteMessage.FinishRecord(); WriteXML.Close(); //Sonra yeni bir harf oluşturuyoruz, ortaya çıkan xml dosyasını ona ekliyoruz ve //Düğüm E-posta Adresinde belirtilen adrese gönderin. Dosya = Yeni Dosya(MesajDosyaAdı); İleti Konusu = "1C:Exchange" + Abbr.LP(ExchangePlans.DistributedBase.ThisNode().Code) + "_" + Abbr.LP(Node.Code); UseSMTP ise MailMessage = Yeni InternetMailMessage; MailMessage.Subject = MesajSubject; MailMessage.Attachments.Add(MessageFileName, File.Name); 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; If Constants.OutputExchangeMessages.Get() Then Report(" EXCHANGE: Düğüm için mesaj alışverişi" + Düğüm.Adı + " gönderildi! ",MessageStatus.Information);EndIf;DeleteFiles(MessageFileName);EndCycle;Mail.Disconnect();EndProcedure

Arayüze, tuşlarından birinde buna çağrı yapabileceğiniz ek bir panel eklemenizi öneririm.
prosedürler. Artık geriye kalan tek şey Enterprise'ı başlatmak, çevresel bilgi güvenliğinin e-posta adresini yapılandırmak,
"Değişim" 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ı: G8'e RDB değişim mesajlarını e-posta yoluyla göndermeyi öğrettik
posta.

3. Adım. Güncellemeleri e-postayla alın ve bilgi güvenliğine kaydedin

Şimdi işlemin tersini yapalım: Güncellemeleri e-postayla alıp bilgi güvenliği sistemine kaydedelim.

Oturum parametrelerine Boolean türünde "Dağıtılmış Veritabanı Değişimi Devam Ediyor" parametresini ekleyin. Aşağıda açıklayacağım
randevu.

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

Prosedür rbGetExchangeMessages() Dışa Aktarma UseSMTP = Constants.UseSMTPExchange.Receive(); //tıpkı rbSendExchangeMessages() prosedüründe olduğu gibi, önce bir nesne oluşturun Posta SMTP Kullanıyorsa Sonra MailProfile = Yeni InternetMailProfile; MailProfile.POP3ServerAddress = Sabitler.POP3ExchangeServerAddress.Get(); MailProfile.POP3Port = Sabitler.POP3ExchangeServerPort.Get(); MailProfile.User = Sabitler.POP3ExchangeServerUser.Get(); MailProfile.Password = Constants.UserPasswordPOP3Exchange.Receive(); MailProfile.WaitTime = Sabitler.ServerWaitTime.Get(); Posta = Yeni InternetMail(); Mail.Connect(MailProfile) komutunu deneyin; İstisna raporu(" DEĞİŞİM: Posta profiline bağlanırken hata oluştu! |Değişim başarısız oldu!", MesajStatus.VeryImportant); İade; EndAttempt; Aksi takdirde Posta = Yeni Posta(); Mail.Connect() Denemesi; İstisna Raporu(" DEĞİŞİM: Kullanıcının e-posta profiline bağlanırken hata oluştu! |Değişim başarısız oldu!", messageStatus.VeryImportant); Return; EndAttempt; EndIf; messageArray = Yeni Dizi; If UseSMTP Then AllMessages = Mail.Select(False); Else 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 bu amaçla gönderildiğine inanıyoruz //tam olarak geçerli düğüm için, //onlar. değişim açısından farklı düğümlerin FARKLI e-posta adreslerine sahip olduğu. Tüm Mesajlardan Her Mesaj İçin Döngü If Leo (Mesaj. Konusu, 8 )<>"1C:Exchange" Sonra Devam Edin; endIf; TryMessageArray.Add(Mesaj); //E-posta ekini diske kaydedin. //Eklerin dikkatli kontrolünü şimdilik "perde arkasında" bırakacağız. Ek = Mesaj.Ekler; MesajDosyaAdı = TemporaryFileDirectory() + Ek.Adı; ExchangeData = Ek.Veri; ExchangeData.Write(MesajDosyaAdı); //XMLReader ve messageReader nesnelerini kullanarak verileri okuyoruz //kaydedilen dosyadan güncellemeler. Bilgi güvenliğindeki güncellemeleri kaydetmeden önce //Distributed Database Exchange in Progress oturum parametresini True olarak ayarlayın. //Daha sonra bilgi güvenliğindeki değişiklikleri okuyoruz: Exchange Plans.ReadChanges(ReadMessage). //Aynı zamanda mesajları bir diziye kaydediyoruz, böylece daha sonra hepsini bir kerede silebiliriz. ReadXML = yeni ReadXML(); ReadXML.OpenFile(MesajDosyaAdı); Mesaj Okuyucusu = ExchangePlans.CreateMessageReader(); ReadMessage.StartReading(ReadingXML); SessionParameters.DistributedBaseExchange devam ediyor = True; ExchangePlans.ReadChanges(ReadMessage); ReadMessage.FinishReading(); ReadXML.Close(); If Constants.OutputExchangeMessages.Get() Then Report(" DEĞİŞİM: Değişim verileri kabul edildi",MessageStatus.Information); EndIf; İstisna Raporu(" EXCHANGE: Değişim verileri alınırken hata oluştu:" + ErrorDescription(), MesajStatus.VeryImportant); EndAttempt; //Değişim verilerinin okunması bittikten sonra geri dön //DistributedBase Exchange devam ediyor oturum parametresi False olarak ayarlandı. SessionParameters.DistributedBaseExchange devam ediyor = Yanlış; Files(MessageFileName) Silmeye Çalışılıyor; İstisna //eğer işe yaramazsa, pekala Deneme Sonu; EndCycle; SMTP Kullanıyorsanız Mail.DeleteMessages(MessageArray); endIf; Mail.Disconnect(); Prosedürün Sonu

Şimdi Dağıtılmış Veritabanı Değişimi Devam Ediyor oturum parametresinin ne için gerekli olduğu hakkında.
Gerçek şu ki, ExchangePlans.ReadChanges() yöntemini kullanarak veri okurken bir çağrı yapılır
Değiştirilen/eklenen nesnelerin BeforeWrite() olayı için işleyici prosedürleri. Ve eğer kayıt yaparken
işleyici prosedüründeki herhangi bir nesnenin Reddetme parametresi Doğru olarak ayarlanacak, ardından
ExchangePlans.ReadChanges() yürütülürken bir istisna meydana gelecektir ve buna göre değişim
idam edilmeyecektir. DistributedBase Exchange In Progress oturum parametresinin değeri şu şekilde olabilir:
Böyle bir durumu önlemek için işleyici prosedürlerinde analiz edilir.
12. baskının piyasaya sürülmesiyle (her ne kadar versiyonlar hakkında yanılıyor olsam da), bu yöntemin geçerliliği biraz azaldı
kullanımdan kaldırıldıA, çünkü nesnelerin artık bir özelliği var Değişim Seçenekleri, kimden, kendi başına. Bu özellik şu durumlarda True olarak ayarlanır:
paylaşım planı aracılığıyla veri tasarrufu.

Şimdi panelimizin arayüzüne buna çağrı asacağımız başka bir düğme ekliyoruz
prosedürler. Enterprise'ı başlatalım ve keyfini çıkaralım.
Neredeyse her şey yapıldı, geriye çok az bir şey kaldı: prosedürlerimizin otomatik olarak yürütülmesini sağlamak.
4. Adım. Otomatik değişimi ayarlama

Yani hikayemizin amacına neredeyse yaklaştık. Geriye tek bir adım kaldı: Başlatmak
Değişim işlemlerini otomatik olarak gerçekleştirmek. Başlayalım.

Number(5,0) türünde bir sabit, DistributedBase Autoexchange Interval ekleyelim.

Kullanıcı ayarlarına Perform Distributed Database Exchange parametresini ekleyelim. Yapılandırma için
"Ticaret yönetimi" şu şekilde yapılır:

* "Kullanıcı Ayarları" özellik türlerinin planında önceden tanımlanmış bir özellik ekleyeceğiz
karakteristik Boolean tipi Dağıtılmış Veritabanlarının Değişimini Gerçekleştirin.
* "Kullanıcılar" dizin öğesi biçiminde bu parametrede bir değişiklik ayarladık (bunun gibi)
diğer parametrelere benzetilerek form modülünde yapılabilir).

Prosedürü rbDistributedBase modülüne ekleyin:

Prosedür rbPerformExchange(user) Dışarı Aktar If npGetDefaultValue(user, "") Sonra rbGetExchangeMessages(); rbSendExchangeMessages(); endIf; Prosedürün Sonu

uygulama modülüne:

Prosedür CheckConnectionAutoExchange() Dışarı Aktar If npGetDefaultValue(chCurrentUser, " Dağıtılmış Veritabanlarının Değişimini Gerçekleştirin") Ve Constants.DistributedBaseAutoExchangeInterval.Get() > 0 Sonra ConnectWaitHandler(" Otomatik Değişimi Çalıştır", Constants.DistributedBaseAutoExchangeInterval.Get()); Aksi takdirde, DisableWaitHandler(" Otomatik Değişimi Çalıştır"); EndIf; EndProcedure Prosedürü ExecuteAutoExchange() Export rbExchange(glCurrentUser); DisableWaitHandler(" Otomatik Değişimi Çalıştır"); If npGetDefaultValue(chCurrentUser, " Dağıtılmış Veritabanlarının Değişimini Gerçekleştirin") Ve Constants.DistributedBaseAutoExchangeInterval.Get() > 0 Sonra ConnectWaitHandler(" Otomatik Değişimi Çalıştır", Constants.DistributedBaseAutoExchangeInterval.Get()); EndIf; EndProcedure Prosedürü DisableAutoExchange() Dışa Aktarma DisableWaitHandler(" Otomatik Değişimi Çalıştır"); Prosedürü Sonlandır

Uygulama modülünün WhenSystemStart() prosedürüne aşağıdaki satırları ekleyeceğiz:

(ticari ekipmanı bağladıktan sonra)
...
SessionParameters.DistributedBaseExchange devam ediyor = Yanlış; CheckAutoExchangeConnection();

Süreci kontrol etmek için panelimize birkaç düğme daha ekleyelim: birine prosedür ekleyin
Diğer taraftan CheckConnectAutoExchange() - DisableAutoExchange()

Kuruluşu başlatıyoruz, kullanıcı özelliklerini ve otomatik değişim aralığını yapılandırıyoruz, hepsi bu!

Artık bu en yapılandırılmış kullanıcı altında veritabanına girildiğinde işleyici başlatılacak
ExecuteAutoExchange() bekleniyor. Doğal olarak çevre birimi veritabanında da bir kullanıcı yapılandırmanız gerekir.
degis tokus icin.

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

Yarattığımız tüm güzelliklerde tek bir sorun var: konfigürasyondaki değişiklik. Şu tarihte:
Çevresel baz, konfigürasyon değişikliklerini içeren bir mesaj aldığında,
kabul edilecektir ancak bir istisna meydana gelecektir. Bu durumda değiştirilen konfigürasyon şu şekilde olacaktır:
yüklendi. Veritabanı yapılandırmasını güncellemek için tüm kullanıcıları atmanız, şuraya gitmeniz gerekir:
yapılandırıcıyı kullanın ve veritabanı yapılandırmasını güncelleyin (bunu yapmadan önce verileri yüklemek iyi bir fikirdir). İLE
Ne yazık ki bu gerekli bir kötülüktür. Kısa bir bat dosyası yazarak hayatınızı biraz daha kolaylaştırabilirsiniz.
bunun gibi bir şey:

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

Ve bir not daha:

Ne yazık ki, xml dosyaları kompakt değildir, ancak neyse ki mükemmel şekilde sıkıştırılmıştır. Mümkün
mesaj gönderme ve alma prosedürleri, dosyaların paketlenmesi ve paketten çıkarılmasına ilişkin prosedürler. COLOR="#666666">Bu, harici bir arşivleyiciyle veya VK (örneğin Wheel.AddIn) kullanılarak yapılabilir.
(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 birlikte, önceki teklif biraz güncelliğini yitirdi, çünkü platform
ZIP algoritmasını kullanan yerleşik dosya sıkıştırma araçları vardı. Onlar. artık dosyaları sıkıştırmak mümkün
VK kullanmadan.

Bir kuruluşun coğrafi olarak birbirinden uzak birden fazla şubesi veya perakende satış noktası olması durumunda sıklıkla ortaya çıkan bir durum. Ancak kuruluş genelinde tutarlı kayıtların tutulmasına ihtiyaç duyulmaktadır. Bu sorunu çözme seçeneklerinden biri, tüm şubelerin otomatik iş istasyonlarını içerecek ve 1C bilgi tabanını genel bir sunucuda barındıracak birleşik bir ağ oluşturmaktır. Bu yöntem teknik olarak karmaşık ve pahalı olabilir. Ayrıca bilgi güvenliği ile ilgili bir takım sorunlar da ortaya çıkmaktadır.

İkinci seçenek dağıtılmış bir bilgi tabanı (RIB) oluşturmaktır. Dağıtılmış bir bilgi tabanı, 1C: Enterprise platformundaki ayrı bilgi tabanlarından oluşan, aralarında konfigürasyon ve verileri senkronize etmek amacıyla veri alışverişinin düzenlendiği hiyerarşik bir yapıdır. Bu bireysel bilgi tabanlarına RIB düğümleri denir.

1C:Enterprise sisteminin çeşitli konfigürasyonlarına dayalı olarak dağıtılmış bir bilgi tabanı oluşturulabilir. 1C: Trade Management 10.3 örneğini kullanarak yaratılışını ele alalım.

Diyelim ki bir ticaret organizasyonunda, organizasyonun genel ticaret sistemine erişimin gerekli olduğu ek bir perakende satış noktası açıldı. Bir RIB oluşturmak için aşağıdaki adımları tamamlamanız gerekir:

Bu, dağıtılmış bir bilgi tabanının oluşturulmasını tamamlar. Bilgi alışverişi yapmak için, Merkezi veritabanında (içinde meydana gelen değişiklikler indirilecektir), ardından mağazada (merkezi veritabanından değişiklikler indirilecek ve mağazada meydana gelen değişiklikler indirilecektir) veri alışverişini başlatmanız gerekir. ) ve yine merkezi veritabanında (mağazada meydana gelen değişiklikler ona indirilecektir).

Dağıtılmış bilgi tabanlarının kendi çarpışma çözümleme mekanizmaları vardır. Dolayısıyla, bir değişim sırasında hem ana hem de alt veritabanlarında herhangi bir nesnenin (belge, dizin vb.) değiştirildiği ortaya çıkarsa, ana veritabanında yapılan değişikliğin önceliği olacaktır.

Dağıtılmış bir bilgi tabanının konfigürasyonunu değiştirmek gerekiyorsa, bu kök düğümde yapılmalıdır (makalenin ilk şekline bakın), geri kalan düğümlerin konfigürasyonları kilitlenir. Gerekli değişiklikleri yaptıktan sonra, RIB düğümleri arasında veri alışverişine yönelik standart prosedür kullanılarak bağımlı düğümlere aktarılabilirler. Değişim, köle düğümün yapılandırıcısında gerçekleştirildikten sonra bilgi tabanı yapılandırmasının güncellenmesi gerekir.

Dağıtılmış bir bilgi tabanı oluşturma konusunda sorun yaşıyorsanız uzmanlarımız veri alışverişini ayarlamanıza yardımcı olacak ve bunun nasıl kullanılacağını ayrıntılı olarak açıklayacaktır.

Dağıtılmış bilgi tabanları (RIB) teknolojisi, 1C Kurumsal yapılandırmalarına dayalı olarak coğrafi olarak dağıtılmış bir sistem oluşturmanıza olanak tanır. Bu, güvenilir bir iletişim kanalına sahip olmayan departmanlarla bile ortak bir bilgi alanına sahip olmanızı sağlar ve yüksek düğüm özerkliğini hızlı bilgi alışverişi yeteneğiyle birleştirir. Makalelerimizde bu mekanizmanın 8.2 platformundaki özelliklerine ve pratik uygulamasına bakacağız.

Öncelikle kendimize şu soruyu soralım: Neden otomatik değişim? Ucuz ve hızlı İnternet ile birleşen modern teknolojiler, uzaktan çalışmayı herhangi bir zorluk yaşamadan organize etmeyi mümkün kılar. Yöntem seçimi her zamanki kadar geniş: RDP, ince istemciler ve web istemcileri, VPN kullanarak ağlara bağlanma - üzerinde düşünülecek çok şey var. Bununla birlikte, tüm bu yöntemlerin önemli bir dezavantajı vardır - iletişim kanalının kalitesine güçlü bir bağımlılık.

Yerel sağlayıcının ideal çalışmasıyla bile iletişim kanalının %100 kullanılabilirliğini garanti etmek imkansızdır. Omurga sağlayıcıyla ilgili sorunlar, güç kaynağının olmayışı, iletişim hattının fiziksel olarak hasar görmesi ve daha birçok faktör bu görevi aşılamaz hale getiriyor. Aynı zamanda uzak bir depoda veya perakende mağazada bilgi tabanına erişilememesi oldukça önemli kayıplara yol açmaktadır. Ve son olarak, kaliteli iletişim kanalı sağlamanın pahalı ve/veya sorunlu olduğu yerler (örneğin şehirlerin kenar mahallelerinde sanayi bölgeleri) olduğunu da unutmayalım.

RIB mekanizması bu eksikliklerden kurtulmanıza olanak tanır; her departmanın, dış dünyayla iletişimin tamamen yokluğunda bile bağımsız olarak çalışabileceğiniz kendi bilgi tabanı kopyası vardır. Ve iletilen az miktarda bilgi, alışveriş için mobil İnternet dahil herhangi bir iletişim kanalını kullanmanıza olanak tanır.

Platform 8.2'deki RIB, RIB platformu 7.7'nin daha da geliştirilmesini temsil eden temelde yeni bir şey değil, ancak şimdi bu teknoloji daha erişilebilir ve daha basit hale geldi. Ayrı olarak satın alınması gereken RIB bileşeninin aksine, RIB birçok standart konfigürasyonun ayrılmaz bir parçasıdır ve tamamen kullanıcı modunda çalışarak kurulum aşamasında bile Konfigüratör olmadan işlem yapmanıza olanak tanır.

Bu noktada artık pratik kısma geçmenin zamanı gelmiş olacak ama bir konu dışına daha çıkmamız gerekecek. Gerçek şu ki, halihazırda gerçekleşmiş gibi görünen 8.2 platformuna geçiş aslında iki tür konfigürasyonun ortaya çıkmasına yol açtı: yönetilen bir uygulamaya dayalı, 8.2 platformu için "yerel" ve 8.1'den uyarlanmış, devam eden eski teknolojileri ve mekanizmaları kullanmak. Konfigürasyonların (Kurumsal Muhasebe, Bordro ve İK Yönetimi) önemli bir kısmı uyarlanmış veya geçişli olduğundan indirim yapılamadığından yazımızın ilk kısmı bu konfigürasyonlara (esasen 8.1 platformu) ayrılacak, ikinci kısmı ise bu konfigürasyonlara ayrılacaktır. yönetilen bir uygulamayı (platform 8.2) temel alan yapılandırmalar için otomatik değişimin ayarlanmasını inceleyeceğiz.

Pratik bir görevi ele alalım: Kurumsal Muhasebe 2.0 yapılandırması için FTP yoluyla otomatik alışverişi ayarlama. RIB, e-posta veya dosya paylaşımlarını kullanarak alışveriş yapmanıza izin vermesine rağmen, en basit ve en güvenilir iletişim yöntemi olarak FTP'yi kullanmanızı öneririz. Kendi FTP sunucunuzu nasıl kuracağınızı okuyabilir veya herhangi bir barındırma sağlayıcısının FTP hizmetini kullanabilirsiniz.

Öncelikle exchange node’larını yapılandırmamız gerekiyor. Bunu yapmak için yapılandırmayı yönetici haklarıyla başlatın ve İşlemler - Değişim Planları.

Görüntülenen listede öğesini seçin Tam dolu planla veya Organizasyona göre Birden fazla firmanın kayıtları tek bir veritabanında tutuluyorsa ve değişimin sadece bir tanesi için yapılması gerekiyorsa. Açılan pencerede zaten bir düğüm var - merkezi olan, kodu ve adı belirterek onu düzenlememiz gerekiyor.

Daha sonra dal için aynı şekilde doldurarak başka bir düğüm oluşturacağız (eklemek için artı içeren yeşil daireye tıklayın). Bir sonraki adım, dosya modunda hazır bir bilgi tabanı olan bu düğüm için bir başlangıç ​​görüntüsü oluşturmaktır. Bunu yapmak için istediğiniz düğüme sağ tıklayın ve açılır listeden seçim yapın Bir başlangıç ​​resmi oluşturun.

Şimdi devam edelim Hizmet - Dağıtılmış Bilgi Tabanı (DIB) - RIB düğümlerini yapılandırma.

Açılan pencerede butona tıklayın Eklemek ve uzak ana bilgisayarı, değişim türünü (FTP aracılığıyla) ve sunucu bağlantı parametrelerini belirterek yeni bir değişim yapılandırın.

Yer imi Otomatik değişim bir değişim programı oluşturmanıza, olaylara göre değişim yapmanıza (iş başlangıcı ve bitiş vb.) olanak tanır, bu ayarlar, adına değişimin gerçekleştirileceği kullanıcı için yapılır, bu nedenle veri alışverişi yapma haklarına sahip olduğundan emin olun.

Araçlar - Program Ayarları'nda belge numaralandırma için düğüm önekini belirtmeyi unutmayın (aksi takdirde aynı numaralara sahip farklı belgeler alırsınız); burada diğer bazı değişim parametrelerini de yapılandırabilirsiniz. Aynı sekmede değişim görevlerini gerçekleştirecek bir kullanıcı seçmelisiniz; bunu yapmazsanız zamanlama çalışmaz. Değişimin yalnızca kullanıcı programda oturum açtığında yapılacağını unutmayın.

Bu, merkezi düğümün yapılandırmasını tamamlar; şimdi, ilk görüntüyü mevcut bir bilgi güvenliği sistemi olarak bağlayarak çevresel düğüm için benzer ayarlar yapmanız gerekir. Bundan sonra veri alışverişine başlayabilirsiniz. Kontrol etmek için kullanmalısınız İletişim monitörü, yalnızca yükleme/indirme işleminin başarısını izlemenize izin vermekle kalmaz, aynı zamanda ortaya çıkan veya geciken hareketleri de gösterir (değişimi yapan kullanıcının veritabanında herhangi bir işlem gerçekleştirmek için yeterli hakkı yoksa). Bu aracın varlığı, otomatik değişim sırasında ortaya çıkan çeşitli sorunları hızlı ve etkili bir şekilde çözmenize olanak tanır.

Bu noktada santral kurulumu tamamlanmış sayılabilir ve dağıtık modda çalışmaya başlayabilirsiniz. Özellikle konfigürasyonun güncellenmesi veya değişiklik yapılması üzerinde durmak faydalı olacaktır. Bu eylemler yalnızca merkezi düğümde mümkündür; yapılan tüm değişiklikler bir sonraki değişim sırasında otomatik olarak çevresel düğümlere aktarılacaktır. Otomatik olarak değişiklik yapmak için çevre birimi veritabanının özel modda olması gerekir, aksi takdirde çalıştırmanız gerekir. Yapılandırıcı ve yürüt Veritabanı Yapılandırmasını Güncelleme manuel olarak.

Dağıtılmış bir bilgi tabanı oluşturmak için programa 1C: Kurumsal modda girmeniz gerekir. Dağıtılmış veritabanı düğümleri oluşturmak için menüden seçim yapın: Operasyonlar - Değişim planları. “Nesne seç: Değişim planı” penceresi açılacaktır.

1. “Tam” değişim planı seçeneğini değerlendirin.

Değişim, dağıtılmış bilgi tabanında yer alan tüm kuruluşlar arasında gerçekleştirilecektir.

“Tam” değişim planını seçelim. “Tam Değişim Planı” penceresi açılacaktır.

İki girişi dolduruyoruz:

İlk girişi “Ana düğüm” olarak adlandıralım, “GU” kodunu belirtelim,

İkinci girişi “Alt düğüm” olarak adlandıralım ve “PU” kodunu belirtelim.

Şekilden de görebileceğimiz gibi, ilk girişte yeşil daireli bir simge var; bu “Ana Düğüm” simgesidir.

“Ana düğüm” bilgi tabanının bir kopyasını oluşturmak için “Yardımcı düğüm”e tıklayın ve “İlk görüntüyü oluştur” simgesine tıklayın. Bu “Alt Düğüm” bilgi tabanı olacaktır.

“İlk bilgi güvenliği görüntüsü oluşturma” penceresi açılacaktır, “Bu bilgisayarda veya yerel ağdaki bir bilgisayarda” seçeneğini seçin, “İleri” ye tıklayın.

“Bilgi Tabanı Dizini” alanında “Ana Düğüm” kopyasının kurulacağı konumu seçin ve “Son”a tıklayın.

“Alt Düğüm” bilgi tabanını oluşturduktan sonra aşağıdaki mesaj görünecektir:

"Tamam"a tıklayın.

“Alt Düğüm” bilgi tabanını “1C: Enterprise” a ekleyin. "1C: Enterprise" modunda alt veritabanına gidiyoruz. Hadi açalım: Operasyonlar - Değişim Planları. “Nesne seç: Değişim planı” penceresi açılacaktır. “Tam” değişim planını seçelim. “Tam Değişim Planı” penceresi açılacaktır. “Ana Düğüm” simgesinin turuncu renkte olduğunu görüyoruz, bu da bu düğümün içinde bulunduğumuz bilgi tabanının ana düğümü olduğu anlamına geliyor.

Hem Master hem de Slave düğümlerde aşağıdaki ayarları yapıyoruz:

1. Dağıtılmış bilgi tabanı için bir önek ekleyin.

Bu, iki veritabanında oluşturulan belge ve dizinlerin sayı ve kodlarında çakışma olmayacak şekilde yapılır, böylece her veritabanında belge numaralarına ve dizin kodlarına eklenecek bir önek belirtiriz. Açın: Araçlar - Program ayarları - "Veri alışverişi" sekmesi. “Dağıtılmış bir bilgi tabanı için düğüm öneki:” alanına, alt veritabanına “PU” ve ana veritabanına “GU” girin.

2. Düğümler arasında veri alışverişi için bir ayar ekleyin:

Açık: Hizmet - Dağıtılmış Bilgi Tabanı (DIB) - RIB düğümlerini yapılandırın. “Veri Değişimi Ayarları” penceresi açılacaktır.

“Ekle”ye tıkladığınızda “Veri alışverişi ayarları” penceresi açılacaktır. Ayarınızın “Adını” girin.

“Düğüm” alanında otomatik olarak bir düğüm görünecektir, “Ana düğüm” için bir “Köle düğüm” olacak, “Köle düğüm” için bir “Ana düğüm” olacaktır.

"Dizin" alanında, değişim verilerinin gönderileceği klasörü seçin; ana ve yardımcı veritabanları için bir dizin belirlemek en iyisidir.

“Değişim Türü” alanında veritabanları arasında veri aktarımını yapılandırıyoruz: bir dosya veya FTP kaynağı aracılığıyla. Örneğin "bir dosya kaynağı aracılığıyla paylaşma"yı seçelim.

Kalan alanlarda hiçbir değişiklik yapmıyoruz.

"Tamam"a tıklayın. Bir ayarın ortaya çıktığını görüyoruz.

3. Veri alışverişi yapmak için aşağıdakileri yaparız:

Öncelikle değişikliklerin yapıldığı veritabanında şekilde görüldüğü gibi “Geçerli ayarlara göre takas” ikonuna tıklayın.

Yüklemeden sonra yükleme sonucu penceresi görünecektir.

Daha sonra değişiklikleri aktarmak istediğiniz veritabanında “Geçerli ayarlara göre değiştir” ikonuna tıklayın, veriler istediğiniz veritabanına gidecektir.

2. “Kuruluş bazında” değişim planı seçeneğini değerlendirin.

Değişim, dağıtılmış bir bilgi tabanında yer alan seçilmiş kuruluşlar arasında gerçekleştirilecektir.

Dağıtılmış bir veritabanının düğümlerini oluşturmak için menüden seçim yapın: İşlemler - Değişim planları. “Nesne seç: Değişim planı” penceresi açılacaktır.

“Kuruluş bazında” değişim planını seçelim. “Kuruluşlara Göre Değişim Planı” penceresi açılacaktır.

İki girişi dolduruyoruz:

İlk girdiye “Ana Düğüm” adını verelim, “GU” kodunu belirtin, “Değişim Planı: Tam”dan farkını görüyoruz, takasın gerçekleşeceği Organizasyonları belirttiğimiz bir tablo ortaya çıktı.

İkinci girişi “Alt düğüm” olarak adlandıralım, “PU” kodunu belirtelim, organizasyonu belirtelim.

Diğer tüm açılardan kurulum kesinlikle “Değişim Planı: Tam” ile aynıdır.