Basis informasi terdistribusi: Dasar-dasar. Basis informasi terdistribusi

RIB adalah basis informasi terdistribusi, yang merupakan struktur seperti pohon, yang cabang-cabangnya merupakan basis data 1C Enterprise yang diterapkan secara individual. Basis data ini disebut node basis informasi terdistribusi (selanjutnya disebut node). Pertukaran informasi terbentuk antara node-node ini untuk menyinkronkan semua node (konfigurasi dan database).

Mekanisme utamanya adalah mekanisme pertukaran dengan beberapa kemampuan yang khas dan universal. Perbedaan utama dapat diidentifikasi bahwa mekanisme pertukaran RIB lebih terspesialisasi dan sempit, sedangkan pertukaran universal memberi pengguna peluang yang lebih luas.

Prinsip operasi dasar RIB

Struktur konfigurasi hanya dapat diubah di node akar utama dari basis info terdistribusi. Perubahan ini kemudian disebarkan secara hierarki ke node bawahan. Dengan demikian, ini menyediakan ruang struktur konfigurasi tunggal di semua node RIB.

Data dapat diubah di salah satu node, yang kemudian didistribusikan ke semua node lainnya. Selain itu, data ini tidak harus ditransfer ke peserta lain dalam sistem dan identitas lengkap mereka mungkin tidak dipertahankan. Pengembang dapat menyesuaikan komposisi data yang berpartisipasi dalam pertukaran dengan peserta RIB lainnya sesuai keinginan. Selain itu, pengaturan dapat dilakukan tidak hanya pada tingkat metadata konfigurasi, tetapi juga pada tingkat elemen individual, di mana pilihan khusus dapat diterapkan.

Seperti disebutkan di atas, mekanisme RIB dicapai melalui penggunaan rencana pertukaran. tetapi agar rencana tertentu dapat digunakan dalam struktur hierarki ini, properti “Basis info terdistribusi” harus diaktifkan.

Semua data dikirim ke RIB melalui pesan. Isi pesan-pesan tersebut diatur dengan jelas dan tidak bisa sembarangan, seperti dalam mekanisme pertukaran universal. Data ditempatkan dalam pesan menggunakan prinsip serialisasi XML. Selain perubahan data ini, pesan tersebut juga berisi informasi tentang perubahan konfigurasi, serta sejumlah informasi layanan. Perubahan didaftarkan dan ditempatkan di pesan pertukaran secara otomatis. Baik pengguna maupun pengembang tidak dapat mempengaruhi hal ini.

Penerimaan dan pembuatan pesan pertukaran di RIB diatur dengan satu perintah

Rencana pertukaran. Perubahan Tulis(Pesan Tulis, 0)

Konten dibaca menggunakan perintah

Kesimpulan

Kita dapat dengan aman mengatakan bahwa mekanisme RIB pada dasarnya terdiri dari mekanisme pertukaran universal dengan beberapa ciri khas yang hanya ada dalam struktur RIB.

Seringkali dalam praktiknya terdapat situasi ketika berbagai divisi atau cabang secara geografis berlokasi di tempat yang berbeda. Pada saat yang sama, data yang dimasukkan ke dalam program di departemen jarak jauh harus sampai ke kantor pusat sehingga catatan umum dapat disimpan.

Saat ini, masalah ini sering kali diselesaikan dengan memberikan akses jarak jauh ke database umum kepada karyawan yang secara geografis jauh. Hal ini dapat dilakukan dengan menerbitkan database di server web, melalui desktop jarak jauh, dll.

Namun, situasi yang sering terjadi ketika tidak ada Internet di kantor yang terpencil secara geografis, atau tidak cukup stabil untuk bekerja di basis informasi umum. Untuk tujuan ini, 1C memiliki mekanisme untuk menyiapkan database terdistribusi.

Sederhananya, kantor pusat adalah tempat basis utama berada. Departemen jarak jauh menggunakan bawahan. Mungkin ada beberapa basis budak seperti itu. Hasilnya, database terdistribusi tersebut disatukan menjadi satu melalui sinkronisasi. Hal ini dapat dilakukan secara otomatis sesuai jadwal atau secara manual.

Pada artikel ini kita akan melihat pengaturan database terdistribusi untuk 1C: Accounting 3.0. Meskipun demikian, instruksi ini cocok untuk sebagian besar konfigurasi 1C 8.3 lainnya.

Harap dicatat bahwa semua modifikasi konfigurasi yang diperlukan harus dilakukan hanya di database RIB utama. Selama sinkronisasi, perubahan ini akan dikirimkan ke semua database budak dan berlaku.

Basis informasi utama

Saat menggunakan database terdistribusi, pengaturan utama berada pada database utama. Hal ini perlu dilakukan di bagian “Administrasi”, seperti yang ditunjukkan pada gambar di bawah.

Di jendela yang terbuka, segera centang kotak “Sinkronisasi data”. Di bagian bawah, tentukan awalan utama (database saat ini). Itu dapat terdiri dari tidak lebih dari dua karakter. Dalam kasus kami, awalannya adalah "BG", karena yang kami maksud adalah RIB 1C ini adalah "Akuntansi Utama".

Sekarang Anda dapat mulai mengatur sinkronisasi itu sendiri, yaitu menentukan database (atau database) mana yang akan dipertukarkan datanya. Untuk melakukannya, ikuti hyperlink “Pengaturan sinkronisasi data”. Ini akan tersedia untuk navigasi hanya jika kotak centang di sebelah kiri dicentang.

Di jendela yang terbuka, pilih “Penuh…” dari menu. Ini akan memungkinkan kita untuk menentukan basis informasi 1C apa pun untuk sinkronisasi.

Di jendela pertama untuk menghubungkan database bawahan, yang terletak di kantor yang jauh secara geografis, centang kotak bahwa koneksi akan dilakukan melalui direktori lokal atau jaringan. Dalam kasus kami adalah “D:\DB\InfoBase”. Kami juga akan memeriksa terlebih dahulu apakah Anda dapat menulis surat kepadanya.

Pastikan untuk menentukan awalan yang berbeda untuk database yang berbeda. Faktanya adalah ketika menyinkronkan data, data yang dimuat ulang dari setiap database diberi awalannya sendiri. Jika diduplikasi, pekerjaannya akan salah, sehingga program tidak akan memberi Anda kesempatan ini.

Saat program meminta Anda untuk membuat image startup, pilih opsi ini. Prosedur ini akan memakan waktu beberapa saat, setelah itu simpan ke komputer Anda dengan nama “1Cv8.1CD”.

Sinkronisasinya sendiri bisa dilakukan secara otomatis sesuai jadwal yang bisa Anda atur sendiri, atau secara manual. Dalam kasus kedua, cukup klik tombol "Sinkronisasi" pada waktu yang Anda inginkan.

Node budak RIB

Jumlah pengaturan yang dibuat dalam database budak jauh lebih sedikit. Di bagian yang sama, setel tanda "Sinkronisasi data" dan dengan mengklik tautan yang sesuai, tombol "Sinkronisasi" akan tersedia.

Dalam contoh kita, dua item item ditambahkan ke database utama: “Beam” dan “Board”. Setelah sinkronisasi, mereka berakhir di database budak. Seperti terlihat pada gambar di bawah, mereka diberi awalan "BG". Dua posisi lainnya (“Bubut” dan “Pallet”) diberi awalan “BP”, karena keduanya dibuat langsung di database bawahan.

Harap dicatat bahwa penomoran elemen dalam kasus kita kontinu, tetapi hanya dalam awalan yang sama.

Petunjuk untuk membuat dan mengkonfigurasi database terdistribusi menggunakan komponen URDB (URIB).

Komponen URDB (Manajemen Basis Data Terdistribusi) digunakan untuk bertukar informasi antara dua basis data 1C yang identik. Jika konfigurasinya berbeda, maka Anda juga dapat menggunakannya, ini tertulis di tempat lain. Agar komponen dapat berfungsi, Anda harus memiliki file DistrDB.dll di folder BIN program 1C:Enterprise.

Mari kita lihat langkah-langkah membuat database terdistribusi. Misalnya, kita mempunyai basis kerja di direktori D:\base1. Hal ini diperlukan untuk menjadikannya pusat dan membuat basis periferal.

1. Buat direktori D:\base2 untuk database periferal.

2. Di direktori D:\base1 dan D:\base2, buat folder CP dan PC (gunakan huruf Latin).

3. Luncurkan konfigurator basis data pusat (D:\base1) dan pilih Menu - Administrasi - Keamanan Informasi Terdistribusi - Manajemen.

4. Klik tombol “Pusat Keamanan Informasi”, pada jendela yang muncul, masukkan kode dan nama database. Sebaiknya gunakan angka atau huruf latin untuk kodenya. Masukkan, misalnya, 001 dan “Pangkalan pusat”, konfirmasikan dengan menekan tombol “OK”.

5. Klik tombol "Keamanan informasi periferal baru" untuk membuat database periferal. Kami memasukkan parameter untuk itu: 002 dan "Peripheral base 1".

6. Gunakan kursor untuk memilih basis “Peripheral base 1” dan tekan tombol “Setup”. pertukaran otomatis". Di pengaturan, ubah mode manual ke otomatis. Hati-hati, ini penting.

7. Dengan menggunakan kursor, pilih database “Peripheral database 1” dan tekan tombol “Upload data”, lalu tombol “OK”. Hasil upload akan muncul file D:\base1\CP\020.zip.

8. Luncurkan 1C dalam mode konfigurator, tambahkan database baru "Peripheral database 1" di jendela peluncuran 1C, tentukan direktori yang dibuat sebelumnya D:\base2 untuk itu.

9. Pilih Menu - Administrasi - Keamanan Informasi Terdistribusi - Manajemen. Untuk pertanyaan yang diajukan “Basis informasi tidak ditemukan. Apakah Anda ingin memuat data?" Klik tombol "Yes" dan tentukan nama file "D:\base1\CP\020.zip", klik tombol "OK". Setelah pengunduhan selesai, proses pembuatan database periferal dianggap selesai.

Dalam dan juga dalam metode pembuatan database periferal dengan memulihkan salinan database pusat dari cadangan atau melampirkan file salinan database pusat untuk format SQL dan menjalankan skrip diberikan. Ini akan berguna untuk data dalam jumlah besar, ketika pengunggahan dan pengunduhan memakan waktu berjam-jam atau sama sekali tidak realistis.

Petunjuk untuk bertukar antar database terdistribusi menggunakan komponen URDB (URIB).

Mari kita pertimbangkan contoh sederhana; kita akan melakukan pertukaran secara manual dengan meluncurkan konfigurator. Anda dapat menggunakan mode batch konfigurator; Anda dapat menggunakan mail, ftp, dan penyalinan file otomatis untuk mengirimkan paket pertukaran.

Untuk melakukan pertukaran, Anda harus memilih Menu - Administrasi - Keamanan Informasi Terdistribusi - Pertukaran Otomatis. Jika pertukaran terjadi secara otomatis (lihat poin 6 dari instruksi sebelumnya), maka semuanya akan berhasil.

1. Jadi, kita mengubah atau membuat beberapa objek yang bermigrasi ke database periferal. Aturan migrasi objek ditetapkan pada tab "Migrasi" di properti objek (lihat pohon objek di konfigurator).

2. Luncurkan konfigurator database pusat, pilih Menu - Administrasi - Keamanan Informasi Terdistribusi - Pertukaran Otomatis, klik tombol "Jalankan".

3. Pindahkan file yang dihasilkan D:\base1\CP\020.zip ke folder D:\base2\CP\

4. Kami mengubah beberapa objek di database periferal. Sebaiknya bukan yang diubah sebelumnya di database pusat, karena database pusat memiliki prioritas untuk perubahan objek selama pertukaran.

5. Luncurkan konfigurator database periferal, pilih Menu - Administrasi - Keamanan Informasi Terdistribusi - Pertukaran Otomatis, klik tombol "Jalankan".

6. Sebagai hasil dari pertukaran otomatis, kita akan mendapatkan perubahan yang berasal dari database pusat. Kita juga harus memiliki file untuk ditransfer ke database pusat D:\base2\PC\021.zip

7. Copy file D:\base2\PC\021.zip ke folder D:\base1\PC

8. Ulangi poin 2. Hasilnya, perubahan yang diterima dari database periferal akan muncul di database pusat.

Jadi, prinsip umum pertukaran: eksekusi pertukaran otomatis secara bergantian dengan perpindahan file (paket pertukaran) secara bersamaan dari folder PC dari satu database ke folder PC dari database lain dan dari folder CP dari satu database ke folder CP dari basis data lain.

Perubahan konfigurasi hanya dilakukan di database pusat. Saat mengubah konfigurasi, perlu dilakukan pertukaran di database periferal dalam mode eksklusif. Agar berhasil memproses paket dari database periferal di database pusat, konfigurasi harus dimuat ke database periferal. Kalau bingung tidak apa-apa, paket yang ditolak database pusat akan diunduh lagi.

25 Oktober 2016

Tidak ada perbedaan besar antara pengaturan dan dukungan RIB untuk 2 node dan 10 node, tetapi ketika jumlah titik jarak jauh melebihi seratus, masalah yang sama sekali berbeda harus diselesaikan.

Data awal:

Konfigurasi: Ritel 2.2
Peron 1C: 8.3.7.1970



Durasi proyek: satu tahun.



Arsitektur:

Pertama, kami memutuskan skema RIB. Diputuskan untuk fokus pada skema “bintang” selama mungkin; ketika keterbatasan teknologi tercapai - kepingan salju.





Keterbatasan:
- RAM 2 GB
- 1 prosesor fisik


Dari semua hal di atas, hal utama yang mengganggu adalah batasan ukuran maksimal database.

Tapi ini berarti Anda perlu hati-hati mengatur prosedur untuk membersihkannya dari data usang di situs.

Server fisik terpisah dialokasikan untuk server 1C dan MS SQL. Ini akan menanggung beban utama pertukaran dan operasi jangka panjang.
Komputer klien akhir tidak diganti karena mereka akan bekerja dengan klien tipis dan beban pada komputer tersebut akan minimal.
.


Pengaturan dasar

Sejak masa UT 10.3, yang merupakan proyek pertama saya untuk menerapkan RIB pada kecepatan 60 knot, tentu saja, “banyak air yang mengalir di bawah jembatan.”

1C tidak tinggal diam. Retail 2.2 kini memperhitungkan kebutuhan pengunggahan data selektif.
Hanya informasi yang relevan yang akan diunggah ke database toko:
- Semua buku referensi (kecuali yang khusus)
- Dokumen untuk toko ini

Pertanyaan lainnya adalah bahwa dengan satu atau lain cara, menambahkan node ke database berarti menambahkan entri lain ke tabel registrasi untuk setiap elemen umum saat ditulis.





1) Penting untuk membaginya menjadi skenario sinkronisasi terpisah untuk mengunggah dan mengunduh
Intinya bongkarnya lama dan melibatkan pemblokiran, sedangkan bongkarnya cukup mudah. Pada saat yang sama, sering kali kita perlu menerima data dengan cepat dari gerai ritel, sementara hanya memberikannya beberapa kali sehari.

2) Identifikasi penyimpanan yang bermasalah dan hapus dari skenario sinkronisasi umum. Mungkin ada pembongkaran dalam jumlah besar - ini akan memperlambat seluruh pertukaran, termasuk node lainnya. Setelah masalah terselesaikan, masalah tersebut ditambahkan kembali.

3) Buat beberapa skrip untuk mengirim dan menerima data. Namun hal utama di sini adalah mendapatkan keseimbangan kuantitas yang tepat.
(sejak versi 8.1).
Akibatnya, paralelisme dalam pembongkaran RIB menjadi terbatas. Dalam praktiknya, ternyata menjalankan 2-3 skrip secara paralel.


Apa yang harus diperbaiki

Masalah terpenting dalam logika standar 1C RIB adalah pembaruan

Masalah pertukaran lainnya adalah register informasi. Mengunggah setiap catatan register informasi ke dalam XML akan membuat node XML terpisah dengan elemen layanan, dll. Selain itu, fungsi "SelectChanges()" untuk register informasi yang berisi 100 catatan akan menerima tabel hasil 100 baris, di pada saat yang sama, jika direktori A dengan 100 baris ini hanya akan memiliki satu entri yang dipilih di bagian tabelnya. Dan inilah saatnya pemblokiran eksklusif. Jadi jika di PC banyak sekali record-record yang didaftarkan secara rutin untuk ditukarkan ke toko lain, maka tentu lebih tepat disajikan dalam bentuk direktori dengan bagian tabel, yang dalam kasus ekstrim, saat merekam. , dapat membentuk baris register yang sama. Bagaimanapun, .

Detail penting lainnya - Untuk apa? Sudah ada hampir 3 juta kartu diskon. Sistem online eksternal digunakan untuk bekerja dengannya. Jika Anda terus mentransfer kartu diskon ke semua toko, hal ini akan meningkatkan pertukaran secara signifikan, dan juga dapat menyebabkan basis melebihi volume 10 GB.

Beberapa mekanisme diterapkan secara online dengan menghubungi database pusat: saldo di toko lain, pengembalian kwitansi dari toko lain, pengecekan keabsahan sertifikat hadiah.


Replikasi


Membuat node RIB awal secara teratur pada prinsipnya akan membuat replikasi menjadi tidak mungkin.
Oleh karena itu, node baru dibuat sebagai berikut:


2) Basis data ini menukar semua data umum di RIB tetapi tidak menerima (dokumen) khusus


5) Basis toko sudah siap.

Paket perangkat lunak yang sudah jadi disebarkan ke server, sehingga tidak memakan banyak waktu. Kemudian database yang baru dibuat diupload ke server dan siap dikirim ke toko.


Manfaat klien tipis

Dua keunggulan signifikan Retail 2.2 (Thin Client) yang “menghangatkan jiwa”:








Dukungan dan pembaruan




1) Perbarui secara manual dari toko (tidak terlalu benar, perubahan mungkin tidak diterima, akan ada panggilan dan masalah) - ini adalah kasus sebelumnya

3) Tulis skrip *.cmd atau 1C untuk diperbarui atau ambil yang sudah jadi. Seperti yang ditunjukkan oleh praktik, solusi seperti itu selalu setengah hati (tidak stabil), dan hanya mungkin untuk membangun sedikit fungsionalitas ke dalamnya.

Apa tugas kami:


2) Saat memperbarui, interaksi interaktif dengan pengguna dimungkinkan (pesan, konfirmasi, bilah kemajuan).








Fungsi utama:




4) Memeriksa status agen
5) Perbarui laporan
6) cadangan

















Misalnya, pesan kesalahan setelah pembaruan terlihat seperti ini:

Dengan demikian, proyek ini memiliki peluang bagus untuk diselesaikan dengan sukses. Setidaknya di pertengahan penerbangan, penerbangannya normal.

Jika kita menemukan solusi lain yang mungkin tampak menarik, saya akan menulisnya secara terpisah

P.S. dan yang paling penting: Perencanaan dukungan lebih lanjut yang tepat merupakan salah satu faktor kunci keberhasilan proyek-proyek tersebut. :)

25 Oktober 2016

Tidak ada perbedaan besar antara menyiapkan dan mendukung RIB untuk 2 node dan 10 node, tetapi ketika jumlah titik jarak jauh melebihi seratus, masalah yang sama sekali berbeda harus diselesaikan.

Jadi, data awal:

Konfigurasi: Ritel 2.2
Peron 1C: 8.3.7.1970
Perkiraan jumlah node pada akhir proyek: 200
Sumber daya peralatan di tengah: tanpa batasan signifikan
Peralatan pada intinya: masalah yang dibahas.
Durasi proyek: satu tahun.

Arsitektur:

Pertama, kami memutuskan skema RIB. Diputuskan untuk fokus pada skema “bintang” sebelumnya
Di gerai ritel, versi kerja klien-server digunakan, dengan server khusus yang menjalankan OS Windows.
Server 1C akan digunakan dalam versi "Server 1C MINI" https://1c.ru/news/info.jsp?id=17577
Server DBMS - MS SQL Express 2008 R2.

SQL Express 2008 R2 adalah versi terbaru dari baris SQL Server ini.
Keterbatasan:

RAM 2 GB
- 1 prosesor fisik
- Ukuran basis data maksimum 10 GB

Dari semua hal di atas, yang paling menyebalkan tentu saja adalah batasan ukuran maksimal database. Namun pada kenyataannya, ini hanya berarti bahwa prosedur untuk membersihkannya dari data usang di situs perlu diatur dengan hati-hati.

Server terpisah dialokasikan untuk server 1C dan MS SQL. Ini akan menanggung beban utama pertukaran dan transaksi.
Komputer klien akhir tidak diganti karena mereka akan bekerja dengan klien tipis dan beban di bagian bawah akan minimal.
Server di toko hanyalah sebuah PC yang kuat. Namun prasyaratnya adalah keberadaan disk SSD - tempat database MS SQL berada.
Server juga akan memberikan kemampuan untuk melakukan operasi rutin di malam hari dan akses ke database toko tanpa gangguan dari pekerjaan.

Pengaturan dasar

Sejak masa UT 10.3, yang merupakan proyek pertama saya untuk menerapkan RIB pada kecepatan 60 knot, tentu saja, “banyak air yang mengalir di bawah jembatan.” 1C tidak tinggal diam. Retail 2.2 kini memperhitungkan kebutuhan pengunggahan data secara selektif.
Hanya informasi yang relevan dengan toko yang akan diunggah ke database toko:
- Semua direktori (kecuali beberapa)
- Dokumen untuk toko ini
Registrasi data terjadi sesuai aturan registrasi, segala sesuatu yang dapat di-cache. Tidak ada perlambatan yang signifikan saat registrasi.
Pertanyaan lainnya adalah bahwa dengan satu atau lain cara, menambahkan node ke database berarti menambahkan record lain untuk setiap elemen umum untuk semua database.

Tidak ada yang spesifik dalam pengaturan uploadnya sendiri. Ada beberapa perbedaan saat menyiapkan skenario sinkronisasi:

1) Pengunggahan dan pemuatan perlu dipisahkan ke dalam skenario sinkronisasi terpisah
Intinya bongkarnya lama dan melibatkan pemblokiran, tapi bongkarnya cukup bebas masalah. Pada saat yang sama, sering kali kita perlu menerima data dengan cepat dari gerai ritel, sementara hanya memberikannya beberapa kali sehari.

2) Identifikasi penyimpanan yang bermasalah dan hapus dari skenario sinkronisasi umum. Mungkin ada pembongkaran dalam jumlah besar - ini akan memperlambat seluruh pertukaran, termasuk node lainnya

3) Buat beberapa skrip kirim dan terima untuk mengirim dan menerima data. Namun hal utama di sini adalah keseimbangan.
Beberapa hal di 1C tidak berubah. Metode "SelectChanges" yang sama hanya dapat dijalankan secara berurutan(sejak versi 8.1).
Akibatnya, paralelisme dalam pembongkaran RIB menjadi terbatas. Dalam praktiknya, Anda akhirnya mengunggah 2-3 skrip sekaligus.
Mengenai skenario penerimaan, paralelisme yang jauh lebih besar mungkin terjadi di sini, jika diperlukan, tentu saja.

Apa yang harus diperbaiki

Tentu saja menyedihkan dan menyedihkan, tapi saya harus benar-benar mengganggu BSP. Masalah terpenting dalam logika standar 1C adalah pembaruan. Setelah pembaruan, jendela seperti ini muncul:

Ini semua terjadi dalam mode monopoli. Antara lain, sistem akan tetap mencoba melakukan pertukaran setelah update dalam mode eksklusif. Tidak sulit untuk menebak ke mana arah semua ini.
Selama jangka waktu ini, toko tidak dapat beroperasi, ada pelanggan di kasir, dan perusahaan merugi.

Masalah pertukaran lainnya adalah register informasi. Mengunggah setiap entri register informasi ke XML membuat node XML terpisah dengan elemen layanan dan segala sesuatu yang mengikutinya. Selain itu, fungsi "pilih perubahan" untuk register informasi yang berisi 100 record, tabel yang dihasilkan akan berisi 100 baris, sedangkan jika ini adalah direktori dengan 100 baris, hanya satu record yang akan dipilih di bagian tabel. Jadi jika di PC banyak sekali record-record yang didaftarkan secara rutin untuk ditukarkan ke toko lain, maka tentu lebih tepat disajikan dalam bentuk direktori dengan bagian tabel, yang dalam kasus ekstrim, saat merekam. , dapat menghasilkan catatan dari register yang sama. Bagaimanapun, register informasi di bursa itu jahat.

Detail penting lainnya - Kartu diskon sepenuhnya dikecualikan dari bursa, dan hanya karyawan toko tertentu yang dikecualikan dari bursa. Untuk apa? Sudah ada hampir 3 juta kartu diskon. Sistem online eksternal digunakan untuk bekerja dengannya. Jika Anda terus mentransfer kartu diskon ke semua toko, ini akan meningkatkan pertukaran beberapa kali lipat, selain itu, hal ini dapat menyebabkan basis melebihi volume 3GB.

Beberapa mekanisme diterapkan secara online dengan menghubungi database pusat: saldo di toko lain, pengembalian kwitansi dari toko lain, pengecekan keabsahan sertifikat hadiah.

Replikasi

Tentu saja, replikasi dilakukan dengan kecepatan yang dipercepat.
Membuat node RIB awal dengan cara standar tentu saja akan membuat replikasi menjadi tidak mungkin.
Oleh karena itu, node baru dibuat sebagai berikut:

1) Ada database terpisah dengan toko palsu
2) Basis data ini menukar semua data umum di RIB tetapi tidak menerima data khusus
3) Saat kita ingin membuat database baru, kita cukup menyalin database ini
4) Kemudian kita atur pengaturannya - simpan, awalan, dll.
5) Basis toko sudah siap.

Paket perangkat lunak yang sudah jadi disebarkan ke server, sehingga tidak memakan banyak waktu. Kemudian database toko yang baru dibuat diunggah ke server dan siap dikirim ke toko.

Manfaat klien tipis

dua keuntungan signifikan yang “menghangatkan jiwa.”

1) Tidak perlu mengubah seluruh tempat parkir komputer di gerai ritel. 90% operasi dilakukan di server, dan server dibawa ke sana dengan “komputer yang relatif kuat”

2) Peralatan mempunyai kemampuan untuk menolak bekerja, hal ini terutama sering terjadi pada peralatan yang baru dipasang atau sudah usang.
Dalam hal ini, tindakannya sekarang sangat sederhana - toko beralih bekerja di database pusat.
Proses ini memakan waktu tidak lebih dari 5-10 menit, sehingga perdagangan tidak terganggu meskipun ada masalah signifikan pada peralatan.

Dukungan dan pembaruan

Akhirnya kita sampai pada poin paling menarik - bagaimana cara memelihara dan memperbarui semua ini?
Bagi kami, pembaruan juga telah menjadi dilema sejak lama:

1) Perbarui secara manual dari toko (tidak terlalu benar, perubahan mungkin tidak diterima, akan ada panggilan dan masalah)
2) Pembaruan menggunakan dukungan teknis (sumber daya tidak banyak)
3) Tulis *.cmd untuk memperbarui atau ambil yang sudah jadi. Seperti yang diperlihatkan oleh praktik, solusi seperti itu selalu setengah hati (tidak stabil), dan hanya ada sedikit fungsi di dalamnya.

Apa tugas kami:

1) Pembaruan harus dilakukan dalam beberapa mode dan dikelola secara terpusat
2) Saat memperbarui, interaksi interaktif dengan pengguna dimungkinkan.
3) Laporan tentang status pembaruan dan kesalahan harus diterima
4) Harus ada cadangan
5) Sistem pembaruan harus dapat memperbarui dirinya sendiri tanpa masalah.
6) Sistem harus dapat diperluas tanpa masalah.

Tentu saja, masalahnya jauh melampaui daftar masalah yang bisa diselesaikan dengan metode sederhana. Karena kami tidak dapat melakukannya tanpa otomatisasi dengan begitu banyak titik akhir, dan kami belum menemukan apa pun yang lebih atau kurang siap pakai dengan fungsi serupa
Saya harus mulai mengembangkan perangkat lunak, yang akhirnya diberi nama MU (MagicUpdater).

Fungsi utama:

1) Pembaruan basis data dinamis (perintah atau terjadwal)
2) Pembaruan basis data statis (perintah atau terjadwal)
3) agen otomatis pada komputer akhir ketika dimodifikasi
4) Memeriksa status agen
5) Perbarui laporan
6) cadangan
7) Tindakan administratif dengan server 1C dan MS SQL
8) Menutup semua aplikasi klien 1C di komputer jaringan
9) Pembaruan statis dengan penerimaan di kasir utama
10) Menampilkan deskripsi modifikasi setelah pembaruan
11) Menetapkan urutan tindakan
12) Lakukan semua tindakan ini sesuai jadwal

Perkiraan skema interaksi:

Dimana MU Agent merupakan layanan yang diinstal dan dikonfigurasi di toko. Sebenarnya dia mendapat perintah dari pusat untuk melaksanakan tugas tertentu.
MU Server - Server yang menerima semua permintaan ke sistem.
Monitor MU - yang dilihat oleh karyawan dukungan teknis biasa - digunakan untuk melihat log dan menetapkan tugas untuk memperbarui, atau lainnya.

Menurut saya, ternyata cukup baik. Sekarang pembaruan terjadi hampir secara otomatis.
Ini misalnya seperti apa pesan kesalahan setelah pembaruan;

Dan inilah cara kami mengirimkan perintah ke komputer klien

Aplikasinya tentu saja bukan 1C, tetapi dengan kemampuan antarmuka yang cukup baik. Misalnya, seperti inilah pilihan berdasarkan tanggal:

Sekarang mereka siap untuk replikasi lebih lanjut. Perencanaan dukungan lebih lanjut yang tepat merupakan salah satu faktor kunci keberhasilan proyek-proyek tersebut.

Situasi yang sering muncul ketika sebuah organisasi memiliki beberapa cabang atau gerai ritel yang secara geografis berjauhan satu sama lain. Namun, tetap ada kebutuhan untuk memelihara catatan yang konsisten di seluruh organisasi. Salah satu opsi untuk memecahkan masalah ini adalah dengan membuat jaringan terpadu, yang akan mencakup stasiun kerja otomatis semua cabang, dan menghosting basis informasi 1C di server publik. Metode ini mungkin rumit secara teknis dan mahal. Selain itu, sejumlah masalah terkait keamanan informasi muncul.

Opsi kedua adalah membuat basis informasi terdistribusi (RIB). Basis informasi terdistribusi adalah struktur hierarki yang terdiri dari basis informasi terpisah pada platform 1C:Enterprise, di mana pertukaran data diatur untuk tujuan sinkronisasi konfigurasi dan data. Basis informasi individual ini disebut node RIB.

Basis informasi terdistribusi dapat dibuat berdasarkan berbagai konfigurasi sistem 1C:Enterprise. Mari kita pertimbangkan pembuatannya menggunakan contoh 1C: Manajemen Perdagangan 10.3.

Katakanlah gerai ritel tambahan dibuka di sebuah organisasi perdagangan, di mana diperlukan akses ke sistem perdagangan umum organisasi tersebut. Untuk membuat RIB Anda harus menyelesaikan langkah-langkah berikut:

Ini melengkapi pembuatan basis informasi terdistribusi. Untuk bertukar informasi, Anda perlu memulai pertukaran data di database Pusat (perubahan yang terjadi di dalamnya akan diunduh), kemudian di toko (perubahan dari database pusat akan diunduh dan perubahan yang terjadi di toko akan diunduh) ), dan lagi di database pusat (perubahan akan diunduh ke dalamnya, terjadi di toko).

Basis informasi terdistribusi memiliki mekanisme resolusi tabrakannya sendiri. Jadi, jika pada saat pertukaran ternyata ada objek (dokumen, direktori, dll) yang telah diubah baik di database utama maupun di bawahnya, maka perubahan yang dilakukan di database utama akan mendapat prioritas.

Jika perlu mengubah konfigurasi basis info terdistribusi, ini harus dilakukan di node root (lihat gambar pertama artikel), konfigurasi node lainnya dikunci. Setelah melakukan perubahan yang diperlukan, mereka dapat ditransfer ke node budak menggunakan prosedur standar untuk pertukaran data antar node RIB. Setelah pertukaran dilakukan di konfigurator node budak, konfigurasi infobase perlu diperbarui.

Jika Anda mengalami masalah dalam menyiapkan basis informasi terdistribusi, spesialis kami akan membantu Anda mengatur pertukaran data dan menjelaskan secara rinci cara menggunakannya.