บ่อยครั้งในทางปฏิบัติมีสถานการณ์ที่แผนกหรือสาขาต่างๆ ตั้งอยู่ในสถานที่ที่แตกต่างกัน ในเวลาเดียวกัน ข้อมูลที่ป้อนลงในโปรแกรมในแผนกระยะไกลจะต้องถูกส่งไปยังสำนักงานใหญ่ด้วยวิธีใดวิธีหนึ่งเพื่อเก็บรักษาบันทึกทั่วไป

ปัจจุบันปัญหานี้มักได้รับการแก้ไขโดยการให้พนักงานที่อยู่ห่างไกลทางภูมิศาสตร์สามารถเข้าถึงฐานข้อมูลทั่วไปจากระยะไกลได้ สามารถทำได้โดยการเผยแพร่ฐานข้อมูลบนเว็บเซิร์ฟเวอร์ ผ่านเดสก์ท็อประยะไกล ฯลฯ

อย่างไรก็ตาม สถานการณ์ไม่ใช่เรื่องแปลกเมื่อไม่มีอินเทอร์เน็ตในสำนักงานที่อยู่ห่างไกล หรือไม่มีเสถียรภาพเพียงพอที่จะทำงานในฐานข้อมูลทั่วไป เพื่อจุดประสงค์นี้ 1C มีกลไกในการตั้งค่าฐานข้อมูลแบบกระจาย

พูดง่ายๆ ก็คือสำนักงานใหญ่คือที่ตั้งฐานหลัก แผนกระยะไกลใช้ผู้ใต้บังคับบัญชา อาจมีฐานทาสดังกล่าวอยู่หลายแห่ง เป็นผลให้ฐานข้อมูลแบบกระจายดังกล่าวถูกรวมเป็นหนึ่งเดียวผ่านการซิงโครไนซ์ สามารถทำได้โดยอัตโนมัติตามกำหนดเวลาหรือด้วยตนเอง

ในบทความนี้เราจะดูการตั้งค่าฐานข้อมูลแบบกระจายสำหรับ 1C: การบัญชี 3.0 อย่างไรก็ตามคำแนะนำนี้เหมาะสำหรับการกำหนดค่า 1C 8.3 อื่น ๆ ส่วนใหญ่

โปรดทราบการแก้ไขการกำหนดค่าที่จำเป็นทั้งหมดควรทำในฐานข้อมูล RIB หลักเท่านั้น ในระหว่างการซิงโครไนซ์ การเปลี่ยนแปลงเหล่านี้จะถูกส่งไปยังฐานข้อมูลทาสทั้งหมดและมีผล

ฐานข้อมูลหลัก

เมื่อใช้ฐานข้อมูลแบบกระจาย การตั้งค่าหลักจะอยู่ที่ฐานข้อมูลหลัก จำเป็นต้องดำเนินการในส่วน "การดูแลระบบ" ดังที่แสดงในภาพด้านล่าง

ในหน้าต่างที่เปิดขึ้น ให้ทำเครื่องหมายในช่อง "การซิงโครไนซ์ข้อมูล" ทันที ที่ด้านล่าง ให้ระบุคำนำหน้าของฐานข้อมูลหลัก (ฐานข้อมูลปัจจุบัน) สามารถประกอบด้วยอักขระได้ไม่เกินสองตัว ในกรณีของเรา คำนำหน้าจะเป็น "BG" เนื่องจากเราหมายความว่า RIB 1C นี้คือ "การบัญชีหลัก"

ตอนนี้คุณสามารถเริ่มตั้งค่าการซิงโครไนซ์ได้เอง กล่าวคือ ระบุว่าฐานข้อมูลใด (หรือฐานข้อมูล) ที่จะแลกเปลี่ยนข้อมูล ในการดำเนินการนี้ ให้ทำตามไฮเปอร์ลิงก์ "การตั้งค่าการซิงโครไนซ์ข้อมูล" จะพร้อมใช้งานสำหรับการนำทางเฉพาะเมื่อมีการเลือกช่องทำเครื่องหมายทางด้านซ้ายเท่านั้น

ในหน้าต่างที่เปิดขึ้น ให้เลือก "เต็ม..." จากเมนู มันจะช่วยให้เราระบุฐานข้อมูล 1C ใด ๆ สำหรับการซิงโครไนซ์

ในหน้าต่างแรกสำหรับการเชื่อมต่อฐานข้อมูลรองซึ่งตั้งอยู่ในสำนักงานระยะไกลทางภูมิศาสตร์ ให้ทำเครื่องหมายในช่องว่าจะทำการเชื่อมต่อผ่านไดเรกทอรีท้องถิ่นหรือเครือข่าย ในกรณีของเราคือ “D:\DB\InfoBase” เราจะตรวจสอบล่วงหน้าด้วยว่าคุณสามารถเขียนถึงมันได้หรือไม่

อย่าลืมระบุคำนำหน้าที่แตกต่างกันสำหรับฐานข้อมูลที่แตกต่างกัน ความจริงก็คือเมื่อทำการซิงโครไนซ์ข้อมูลข้อมูลที่โอเวอร์โหลดจากแต่ละฐานข้อมูลจะถูกกำหนดคำนำหน้าของตัวเอง หากมีการทำซ้ำงานจะไม่ถูกต้องดังนั้นโปรแกรมจะไม่ให้โอกาสนี้แก่คุณ

เมื่อโปรแกรมแจ้งให้คุณสร้างอิมเมจเริ่มต้น ให้เลือกตัวเลือกนี้ ขั้นตอนนี้จะใช้เวลาสักครู่ หลังจากนั้นให้บันทึกลงในคอมพิวเตอร์ของคุณชื่อ “1Cv8.1CD”

การซิงโครไนซ์นั้นสามารถทำได้โดยอัตโนมัติตามกำหนดเวลาที่คุณสามารถตั้งค่าได้เองหรือด้วยตนเอง ในกรณีที่สอง เพียงคลิกที่ปุ่ม "ซิงโครไนซ์" ในเวลาที่สะดวกสำหรับคุณ

โหนดทาส RIB

จำนวนการตั้งค่าที่ทำในฐานข้อมูลทาสนั้นน้อยกว่ามาก ในส่วนเดียวกันให้ตั้งค่าสถานะ "การซิงโครไนซ์ข้อมูล" และเมื่อคลิกที่ลิงก์ที่เกี่ยวข้องปุ่ม "ซิงโครไนซ์" จะพร้อมใช้งาน

ในตัวอย่างของเรา มีการเพิ่มรายการสองรายการลงในฐานข้อมูลหลัก: “Beam” และ “Board” หลังจากการซิงโครไนซ์แล้วพวกเขาก็ไปอยู่ในฐานข้อมูลสลาฟ ดังที่คุณเห็นในภาพด้านล่าง มีคำนำหน้าว่า "BG" ตำแหน่งที่เหลืออีกสองตำแหน่ง ("เครื่องกลึง" และ "พาเลท") ได้รับการกำหนดคำนำหน้า "BP" เนื่องจากถูกสร้างขึ้นโดยตรงในฐานข้อมูลรอง

โปรดทราบว่าการนับจำนวนองค์ประกอบในกรณีของเรามีความต่อเนื่อง แต่อยู่ภายในคำนำหน้าเดียวกันเท่านั้น

นี่เป็นบทความแรกของฉัน ยินดีรับคำวิจารณ์ที่สร้างสรรค์

กลุ่มเป้าหมายคือผู้ที่เผชิญหน้ากับ RBD เป็นครั้งแรก

งาน RDB

สิ่งแรกที่คุณต้องเริ่มต้นคือการตอบคำถาม “ทำไมเราถึงต้องมี RDB” มีคำตอบที่เป็นไปได้มากมาย โดยเฉพาะ:

1. เรามีสาขาที่ทำงานอยู่ในฐานข้อมูลที่ไม่เชื่อมต่อ ตอนนี้เราต้องการให้ข้อมูลระหว่างกันตรงกัน
2. เรามีสาขา แต่โหลดบนฐานข้อมูลสูงเกินไป (ซึ่งหมายถึงการบล็อกธุรกรรม ไม่ใช่ปริมาณของฐานข้อมูล) และความเกี่ยวข้องทางออนไลน์ (เพื่อไม่ให้สับสนกับความเกี่ยวข้องในเวลาไม่กี่นาที ออนไลน์คือเมื่อหลังจากแต่ละธุรกรรมข้อมูลจะถูก โอนไปยังโหนดที่สอง) ไม่มีข้อมูลสำหรับสาขาที่ต้องการ
3. เรามีสาขาที่มีการป้อนข้อมูลเท่านั้น (เช่น ร้านค้าปลีก) ดังนั้นเราจึงสามารถลดภาระในฐานข้อมูลกลางได้อย่างมาก
4. ด้วยเหตุผลด้านความปลอดภัย เราต้องการให้สาขาไม่สามารถเข้าถึงข้อมูลสำคัญ เช่น งบดุลของบริษัทได้ ในทางทฤษฎี (ด้วยรหัสผ่านผู้ดูแลระบบ)

ในกรณีหนึ่ง คำถามที่ 2 และ 4 มีความเกี่ยวข้องกับฉัน อีกกรณีหนึ่งคือคำถามที่ 2 และ 3 ประเด็นแรกกว้างเกินไปและจะไม่ได้รับการพิจารณาภายในขอบเขตของบทความนี้

ควรพิจารณาปัญหาการขนส่งไฟล์แลกเปลี่ยนทันทีเนื่องจากในบางกรณีอาจกำหนดข้อ จำกัด ที่สำคัญในการดำเนินการแลกเปลี่ยนข้อมูลได้ ขั้นแรก คุณต้องพิจารณาว่าโหนด RDB จะปรากฏที่สาขาใด (โดยปกติจะเป็นสาขาตามภูมิภาค) ต่อไป เราจะพิจารณาว่าต้องการติดตั้งโหนด RDB ที่ใดอีก และโหนดเหล่านั้นจำเป็นต้องมีความเกี่ยวข้องทางออนไลน์หรือไม่ ตัวอย่างเช่น สำหรับร้านค้าปลีก ไม่สามารถติดตั้งแม้แต่โมเด็มได้เสมอไป และการติดตั้งการเชื่อมต่อไร้สายจะมีราคาแพงเกินไป คุณต้องตัดสินใจที่นี่ - บางทีร้านค้านี้อาจดำเนินการแบบออฟไลน์และแลกเปลี่ยนกับศูนย์เป็นระยะๆ (วันละครั้ง/สัปดาห์ละครั้ง) โดยใช้สื่อทางกายภาพ เช่น แฟลชไดรฟ์

ในบางกรณี การแลกเปลี่ยนผ่านสื่อทางกายภาพไม่สามารถทำได้ เช่น สาขานี้เป็นสาขาที่ห่างไกลมากซึ่งมีปัญหาสำคัญในการตั้งค่าการสื่อสารความเร็วสูง ที่นี่คุ้มค่าที่จะคำนวณปริมาณข้อมูลที่แลกเปลี่ยนโดยประมาณ บ่อยครั้ง หากเกี่ยวข้องชั่วโมงละครั้งหรือหลายครั้งต่อวัน โมเด็มขนาด 32,000 ก็เพียงพอแล้ว อย่างไรก็ตาม ควรจำไว้ว่าพร้อมกับการอัปเดตข้อมูลในบางครั้ง คุณจะต้องส่งการอัปเดตไปยังการกำหนดค่าเองหรือไฟล์ภายนอก (แบบฟอร์มที่พิมพ์ รูปถ่ายของสินค้า) ดังนั้นในบางครั้งสถานการณ์จะเกิดขึ้นเมื่อไฟล์การแลกเปลี่ยนเพิ่มขึ้นอย่างมากเนื่องจาก เพื่อการอัพเดตดังกล่าว

โทโพโลยี

โดยรวมแล้วเราได้รับคำถามต่อไปนี้ที่ต้องตอบ:

1. เรารับประกันว่าแผนกใดจะติดตั้งโหนด RDB และสามารถติดตั้งช่องสัญญาณความเร็วสูงที่นั่นได้หรือไม่
2. แผนกใดบ้างที่ไม่จำเป็นต้องติดตั้งหน่วย RBD?
3. หน่วยงานใดสามารถทำงานที่เกี่ยวข้องได้ภายในเวลาหลายชั่วโมง
4. หน่วยงานไหนสามารถทำงานแบบออฟไลน์ได้ (แลกเปลี่ยนข้อมูลน้อยกว่า 3-4 ครั้งต่อวัน)

เมื่อตอบคำถามเหล่านี้แล้ว เราจะได้แผนภาพ RDB ของเราโดยประมาณ สำหรับบริษัทขนาดใหญ่ มักจะมีลักษณะดังนี้:

รูปที่ 1 แผนภาพทั่วไปของ RDB ของบริษัทขนาดใหญ่

หากทุกอย่างชัดเจนกับโหนด "สาขา" - เหล่านี้เป็นศูนย์กลางขนาดใหญ่ที่ต้องใช้ระบบอัตโนมัติโหนด "ร้านค้า" หมายถึงโหนดที่มีภาระร้ายแรงในฐานข้อมูลเมื่อป้อนข้อมูลซึ่งควรแยกออกเพื่อลดภาระ เช่น ร้านค้าที่มีเครื่องบันทึกเงินสด 50 เครื่อง และมียอดขายมากกว่า 10,000 หน่วยต่อวัน

• ร้านค้า - ป้อนข้อมูลการหมุนเวียนและกระแสเงินสดของคุณเอง การวิเคราะห์เป็นเพียงข้อมูลผิวเผินสำหรับร้านค้าของคุณเองเท่านั้น
• สาขา - การป้อนข้อมูลจุดที่ไม่อัตโนมัติ การบัญชี เงินเดือนและบุคลากร การผลิต ฯลฯ การวิเคราะห์ภายในสาขาของคุณเอง
• Center - การป้อนข้อมูลสาขาที่ไม่อัตโนมัติ การวิเคราะห์องค์กรโดยรวม

สิ่งสำคัญคือต้องเข้าใจว่าฐานข้อมูลจะใช้ในแต่ละโหนดเพื่อจุดประสงค์ใด จากเป้าหมายจะมีการสร้างงานที่จำเป็นสำหรับการดำเนินการเช่น:

• สาขาต่างๆ ดูประวัติการตั้งถิ่นฐานร่วมกันกับคู่สัญญาของกันและกัน
• ร้านค้ามองเห็นสินค้าเหลือใช้ทั่วทั้งองค์กร (หรือบางส่วน)
• การวิเคราะห์รายได้/ค่าใช้จ่าย การดำเนินการตามงบประมาณ ฯลฯ จะมองเห็นได้เฉพาะในลำดับชั้นของแผนกของคุณเองเท่านั้น
• การบัญชี บัญชีเงินเดือน และบุคลากรจะมองเห็นได้เฉพาะในลำดับชั้นของแผนกของคุณเองเท่านั้น
• ระบบการตั้งชื่อ คุณสมบัติและคุณลักษณะทั้งหมดสามารถมองเห็นได้ในทุกโหนดของ RDB
• ด้วยความเคารพต่อลำดับชั้นของแผนก ข้อมูลทั้งหมดจะไหลขึ้นด้านบน แต่จะถูกกรองลงด้านล่าง
• ศูนย์ประกอบด้วยข้อมูลทั้งหมดเกี่ยวกับบริษัท

ด้วยการถามตัวเองด้วยคำถามดังกล่าว คุณสามารถตอบคำถามที่ยากที่สุดได้ - ข้อมูลใด, ที่ไหนและอย่างไรควรไหลระหว่างโหนด RDB? ทำไมยากที่สุด? เมื่อทราบว่าชุดข้อมูลใดหมุนเวียนระหว่างโหนด คุณสามารถเข้าใจวิธี "ตัด" ฐานข้อมูลปัจจุบันได้อย่างชัดเจน เพื่อให้ข้อมูลยังคงสอดคล้องกันในเชิงตรรกะ ตัวอย่างเช่น ข้อมูลยอดคงเหลือสินค้าไม่สามารถแยกออกจากข้อมูลปริมาณสำรองปัจจุบันได้

ตอนนี้ มาวาดแผนภาพ RDB ใหม่กัน ขึ้นอยู่กับการไหลของข้อมูล:

เราเห็นอะไรในรูปที่ 2? ตามลำดับชั้นของแผนกของบริษัท มีการสร้างโทโพโลยีของการไหลของข้อมูลระหว่างโหนดฐานข้อมูล มีการเพิ่มโหนด “Center 2” เข้าไปด้วย เพราะอะไร? เมื่อใช้โทโพโลยีแบบ Star โหลดบนศูนย์กลางจะสูงกว่าโหลดบนโหนดต่อพ่วงเสมอ และบ่อยครั้งที่โหลดที่สร้างโดยตัวโหนดเองก็สูงอยู่แล้ว ตัวอย่างการใช้โหนด “Center 1” และ “Center 2”:

1. “Center 1” ทำหน้าที่รวบรวมข้อมูลจากโหนด RDB อื่นๆ เท่านั้น มีเพียงผู้ดูแลระบบเท่านั้นที่สามารถเข้าถึงได้ “ศูนย์ 2” ทำหน้าที่ของสำนักงานใหญ่
2. “ศูนย์ 1” ทำหน้าที่บริหารสำนักงานใหญ่ อย่างไรก็ตาม การดำเนินการวิเคราะห์และทดสอบอย่างหนักซึ่งสร้างภาระงานจำนวนมากบนฐานข้อมูลจะดำเนินการในโหนด “Center 2” ตัวอย่างเช่น การเรียกคืนลำดับ การกำหนดตารางเวลาปิดใหม่ การสร้างรายงานสรุปสำหรับทั้งองค์กรในระยะเวลาอันยาวนาน การสร้างการวิเคราะห์ที่นำไปสู่การเปลี่ยนแปลงข้อมูล
3. “ศูนย์ 1” ทำหน้าที่บริหารสำนักงานใหญ่ “Center 2” เป็นตัวสำรองในกรณีที่เกิดสถานการณ์ที่ไม่คาดฝันเพื่อการฟื้นฟู RDB ทั้งหมดอย่างรวดเร็ว

การดำเนินการแลกเปลี่ยน

มี 2 ​​ตัวเลือกสำหรับการดำเนินการ RDB:

1. อัตโนมัติ - เกิดขึ้นโดยที่ผู้ใช้ไม่ต้องดำเนินการใดๆ การควบคุมสถานการณ์ฉุกเฉินถูกกำหนดให้กับผู้ดูแลระบบฐานข้อมูลหรือผู้ใช้ขั้นสูง
2. คู่มือ - การแลกเปลี่ยนเกิดขึ้นตามคำขอของผู้ใช้เท่านั้น

จากประสบการณ์ของฉัน ฉันมักจะนำการใช้งานทั้งหมดไปใช้เวอร์ชันอัตโนมัติเสมอ หากมีปัญหากับการขนส่งไฟล์แลกเปลี่ยน (การมีอยู่ของเครือข่ายในโหนดไม่คงที่) ดังนั้นจำนวนสูงสุดที่ผู้ใช้สามารถทำได้คือคลิกปุ่ม "แลกเปลี่ยนทันที" สถานการณ์ที่นอกเหนือจากการอัปเดตข้อมูลแล้ว ยังมีการอัปเดตการกำหนดค่าอีกด้วย ขอแนะนำให้ดำเนินการทั้งหมดโดยอัตโนมัติด้วย (เช่น การใช้ซอฟต์แวร์บุคคลที่สาม)

กำลังสร้างแพ็คเกจอัพเดต

เนื่องจากมีการตัดสินใจที่ชัดเจนเกี่ยวกับโหนด RDB ที่ได้รับมอบหมายฟังก์ชันใด จึงเป็นไปได้ที่จะสร้างเฉพาะแพ็คเกจข้อมูลที่โหนดนี้ต้องการเท่านั้น ในอีกด้านหนึ่ง จำเป็นต้องระบุประเภทของออบเจ็กต์ที่จะซิงโครไนซ์ระหว่างโหนด ตัวอย่างเช่นการลงทะเบียนการบัญชีสำหรับโหนด "ร้านค้า 1" ไม่ควรซิงโครไนซ์เลยเพราะว่า ข้อมูลจะถูกป้อนที่ระดับโหนดสาขาเท่านั้น ในทางกลับกันข้อมูลประเภทที่มีการแลกเปลี่ยนจะต้องถูกกรองโดยอ้างอิงกับแผนก ตัวอย่างเช่น ข้อมูลเกี่ยวกับการรับเงินจากโหนด "ร้านค้า 1 สาขา 2" สามารถพบได้ในโหนด "สาขา 2", "ศูนย์ 1" และ "ศูนย์ 2" เท่านั้น

อย่างไรก็ตาม ยังมีปัญหาตรงกันข้าม: หากคุณกรองข้อมูลการแลกเปลี่ยนมากเกินไป แพ็กเก็ตข้อมูลจะสูญเสียความสมบูรณ์ทางตรรกะ ตัวอย่างเช่น ยอดคงเหลือของสินค้าจะถูกนำมาพิจารณาในบริบทของคลังสินค้า และปริมาณสำรองจะถูกนำมาพิจารณาในบริบทของบริษัทโดยรวม ดังนั้น หากคุณกรองยอดคงเหลือของสินค้าตามคลังสินค้า และไม่กรองปริมาณสำรอง ข้อมูลจะไม่ถูกต้อง

คุณควรตัดสินใจด้วยว่าควรแลกเปลี่ยนวัตถุในช่วงใดของชีวิต ตัวอย่างเช่น เฉพาะใบแจ้งหนี้ที่ผ่านรายการแล้วเท่านั้นที่สามารถแลกเปลี่ยนได้ แต่ไม่สามารถแลกเปลี่ยนเพียงใบแจ้งหนี้ที่บันทึกไว้เท่านั้น ใบแจ้งหนี้ของร้านค้าอย่างใดอย่างหนึ่งจะไม่ยกเลิกการโหลดจากโหนดกลางแม้ว่าจะปรับแล้วก็ตาม แต่ต้องคำนึงถึงผลตรงกันข้าม - ข้อมูลอาจไม่ซิงค์หรือการเปลี่ยนแปลงบางอย่างอาจถูกเขียนทับ

สิ่งสำคัญคือต้องเข้าใจว่าเมื่อทำการแลกเปลี่ยนระหว่างโหนด หนึ่งในนั้นจะมีลำดับความสำคัญ พิจารณาสถานการณ์:

1. มีการสร้างเอกสารในโหนด "ร้านค้า 1"
2. ในระหว่างการแลกเปลี่ยน เขาจบลงที่โหนด “สาขา 1”
3. เอกสารได้รับการแก้ไขพร้อมกันในทั้งสองโหนด

เอกสารใดจะถือว่าเป็นความจริง? ใน 1C 8.x เมื่อใช้กลไก "แผนการแลกเปลี่ยน" ลำดับความสำคัญเริ่มต้นคือโหนดหลัก เช่น ในกรณีนี้ การเปลี่ยนแปลงที่ทำในโหนด “Store 1” จะหายไปและแทนที่ด้วยข้อมูลจากโหนด “Branch 1”

มีอีกสถานการณ์หนึ่งที่ซับซ้อนมากขึ้นเมื่อมีการปรับวัตถุที่เชื่อมต่อกันสองชิ้นพร้อมกัน ตัวอย่างเช่น ใบแจ้งหนี้และ PQR ของใบแจ้งหนี้ได้รับการปรับปรุงในโหนดที่แตกต่างกัน อาจมีความเป็นไปได้ที่จะสูญเสียความสมบูรณ์หากราคา จำนวนเงินที่ชำระ คู่สัญญา ฯลฯ มีการเปลี่ยนแปลง

สิ่งสำคัญคือต้องควบคุมการลบออบเจ็กต์ มิฉะนั้นอาจนำไปสู่ความจริงที่ว่า ตัวอย่างเช่น จะไม่มีใบแจ้งหนี้อีกต่อไป แต่ความเคลื่อนไหวทางบัญชีจะยังคงอยู่

กลไกการแลกเปลี่ยนใน 1C 8.x

มีสองแนวทางในการดำเนินการ:

1. กลไก “แผนการแลกเปลี่ยน”
2. การดำเนินการลงทะเบียนวัตถุด้วยตนเอง

ลองพิจารณาทั้งสองตัวเลือก

กลไกของแผนการแลกเปลี่ยนช่วยให้สามารถสร้างฐานข้อมูลที่มีการแลกเปลี่ยนข้อมูลได้อย่างสมบูรณ์ภายในไม่กี่นาทีโดยไม่ต้องกำหนดค่าใด ๆ หากคุณตั้งค่าสถานะ "ฐานข้อมูลแบบกระจาย" เมื่อสร้างแพ็คเกจการอัปเดต การอัพเดตการกำหนดค่าจะถูกดาวน์โหลดด้วย ในเวลาเพียงไม่กี่นาที คุณสามารถตั้งกฎสำหรับการอนุญาต/ห้ามการแลกเปลี่ยนข้อมูลประเภทต่างๆ ได้โดยการเปิดองค์ประกอบของแผนการแลกเปลี่ยน หากคุณตั้งค่าสถานะ "การลงทะเบียนอัตโนมัติ" ไว้ที่ตำแหน่ง "ปฏิเสธ" ออบเจ็กต์ประเภทนี้จะไม่ถูกแลกเปลี่ยนโดยไม่ต้องใช้ความพยายามเพิ่มเติม

ทำไมคุณต้องลงทะเบียน ทำไมไม่อัพโหลดทุกอย่างพร้อมกัน? ไม่ว่าในกรณีใด ไฟล์ที่มีเฉพาะการเปลี่ยนแปลงสถานะของฐานข้อมูลจะมีขนาดเล็กกว่าสแน็ปช็อตที่สมบูรณ์ของฐานข้อมูลเอง ดังนั้นจะไม่พิจารณาตัวเลือกในการขนถ่ายโดยสมบูรณ์

จะตั้งค่าการกรองข้อมูลตามสังกัดแผนกได้อย่างไร? ที่นี่คุณจะต้องตั้งโปรแกรมแล้ว ในการใช้งานของฉัน มีการติดตั้งการสมัครสมาชิกเหตุการณ์ "เมื่อเขียน" ในการบันทึกออบเจ็กต์ใด ๆ โดยที่การใช้คุณสมบัติ "การแลกเปลี่ยนข้อมูลผู้รับ" คุณสามารถตั้งค่ารายชื่อผู้รับของออบเจ็กต์นี้ได้ เหล่านั้น. เมื่อทำการขนถ่ายโดยใช้วิธีมาตรฐานสำหรับโหนดที่ไม่อยู่ในรายการ วัตถุจะไม่ถูกขนถ่าย มีวิธีแก้ไขอื่น - คุณสามารถเลือกได้ว่าจะยกเลิกการโหลดออบเจ็กต์โดยตรงหรือไม่เมื่อทำการยกเลิกการโหลดออบเจ็กต์ ในขั้นตอน "เมื่อส่งข้อมูลไปยังผู้ใต้บังคับบัญชา" และ "เมื่อส่งข้อมูลไปยังมาสเตอร์" ของโมดูลแผนการแลกเปลี่ยน

ทั้งสองตัวเลือกมีสิทธิ์ที่จะมีอยู่ อย่างไรก็ตาม ฉันเลือกตัวเลือกแรกเป็นตัวเลือกที่ดีที่สุด เนื่องจากการคำนวณแอตทริบิวต์ความสามารถในการโหลดล่วงหน้าจะเกิดขึ้นทันทีเมื่อมีการเขียนออบเจ็กต์ ซึ่งจะเพิ่มระยะเวลาในการบันทึกออบเจ็กต์ขึ้น 3-5% (สามารถปรับให้เหมาะสมได้ ในบางกรณีสามารถทำได้ ลดลงเหลือ 0.01%) เช่น โดยเฉลี่ย 0.1-0.3 วินาที และในกรณีของการคำนวณความสามารถในการไม่สามารถโหลดของวัตถุได้โดยตรงเมื่อส่งข้อมูลซึ่งสร้างภาระที่สำคัญบนฐานข้อมูลแล้ว เวลานี้จะใช้เวลานานหลายนาที

เพื่อให้เข้าใจการทำงานของกลไก "แผนการแลกเปลี่ยน" อย่างถ่องแท้ ฉันแนะนำให้อ่านบทที่ 15 ของหนังสือ "การพัฒนาทางวิชาชีพใน 1C:ระบบองค์กร 8", Gabets A.P., Goncharov D.I.

ในความคิดของฉัน การใช้งานใด ๆ ของตัวเองจะต้องทำซ้ำกลไก "แผนการแลกเปลี่ยน" หรือจะยกเลิกการโหลดวัตถุทันทีเมื่อมีการเปลี่ยนแปลง หรือจะยกเลิกการโหลดมากกว่ากลไก "แผนการแลกเปลี่ยน" (เช่น ยกเลิกการโหลดการเปลี่ยนแปลงทั้งหมดสำหรับวันนี้) ฉันไม่พิจารณาปัญหานี้เนื่องจากขาดประสบการณ์ในการดำเนินการ

ขนส่ง

งานการขนส่งไฟล์จากต้นแบบไปยังโหนดทาสจะลดลงเหลือระดับความผิดพลาดสูงสุด ไม่ใช่เรื่องแปลกที่ไฟล์จะถูกเข้ารหัสหรือส่งผ่านช่องทางที่ปลอดภัย ในการถ่ายโอนไฟล์ ขอแนะนำให้ใช้บริการต่างๆ หรือเตรียมตัวเลือกการเชื่อมต่อต่างๆ ตัวอย่างเช่น วิธีการถ่ายโอนหลักคือการใช้เซิร์ฟเวอร์ FTP ที่เชื่อมต่อผ่านอุโมงค์ VPN ตัวสำรองคือเซิร์ฟเวอร์อีเมลที่มีการเชื่อมต่อ TLS ทำไมต้องมีช่องทางสำรองกับบริการอื่น? ตามที่แสดงในทางปฏิบัติ การใช้เซิร์ฟเวอร์ FTP ที่แตกต่างกัน 2 ตัวมีความน่าเชื่อถือน้อยกว่าเซิร์ฟเวอร์ FTP และอีเมล

ฉันแนะนำให้แยกบริการสร้างแพ็คเกจอัพเดตออกจากบริการขนส่ง ซึ่งจะเพิ่มความทนทานต่อข้อผิดพลาดของคอมเพล็กซ์การแลกเปลี่ยนข้อมูลทั้งหมด หากบริการขนส่งไฟล์ไม่ทำงาน บริการสำหรับการสร้างแพ็คเกจการอัพเดทจะยังคงทำงานตามปกติ และจะรีสตาร์ทบริการการขนส่งและในทางกลับกัน ภายใต้เงื่อนไขบางประการ

การใช้งาน RDB ของฉัน

การใช้งานเป็นแบบอัตโนมัติโดยสมบูรณ์ ดังนั้นความทนทานต่อข้อผิดพลาดสูงสุดจึงเป็นงานย่อย ส่งผลให้มี 2 บริการ ได้แก่ บริการอัปเดตการขนส่ง และบริการนำเข้า/ส่งออกข้อมูล บริการทั้งสองทำงานแยกจากกัน

หลังจากแต่ละรอบการนำเข้า-ส่งออกข้อมูลสำเร็จ เวลาของการแลกเปลี่ยนครั้งล่าสุดกับโหนดนี้จะถูกบันทึกไว้ หากการแลกเปลี่ยนไม่ได้เกิดขึ้นเป็นเวลานาน บริการการขนส่งจะเริ่มอัปโหลดไฟล์ไปยังช่องทางการสื่อสารทั้งหมดที่มี โดยคาดหวังว่าโหนดที่สองจะยังคงได้รับการอัปเดตและอัปโหลดไฟล์ ในกรณีที่มีสถานการณ์พิเศษ ระบบจะส่งข้อความถึงผู้ดูแลระบบพร้อมคำอธิบายโดยละเอียดของข้อผิดพลาด

เพื่อลดปริมาณการรับส่งข้อมูล ไฟล์ xml จะถูกรวมไว้ในไฟล์ zip ระบบรองรับการขนส่งสองประเภท - FTP และอีเมล

มีสองตารางเป็นการตั้งค่าสำหรับตัวกรองข้อมูล หนึ่ง (ส่วนที่เป็นตารางของแผนการแลกเปลี่ยน) เก็บเงื่อนไขสำหรับรายละเอียดทั่วไป (สำหรับแต่ละออบเจ็กต์ที่ระบบพยายามค้นหารายละเอียดนี้) อีกอันมีการตั้งค่าสำหรับออบเจ็กต์ข้อมูลเมตาเฉพาะ เมื่อบันทึกวัตถุใดๆ เงื่อนไขจะถูกค้นหาในรายละเอียดทั่วไปก่อน (เช่น กอง) หลังจากนั้นระบบจะพยายามพิจารณาว่ามีกฎส่วนบุคคลสำหรับวัตถุประเภทนี้โดยใช้รายละเอียดทั้งหมดหรือไม่ ฉันไม่แนะนำให้กรองรายการ - มีความเป็นไปได้สูงที่จะทำผิดพลาด เช่น หลายบรรทัดจะหายไปจากส่วนที่เป็นตารางของใบแจ้งหนี้ และยอดคงเหลือจะย้ายและในทางกลับกัน

สิ่งสำคัญคือต้องเข้าใจว่าผู้ใช้ระบบใดที่บริการจะทำงานเนื่องจาก คุณอาจมีสิทธิ์ไม่เพียงพอที่จะสร้างไฟล์แม้จะอยู่ในโฟลเดอร์ชั่วคราว 1C สำหรับการดีบัก ฉันขอแนะนำเป็นอย่างยิ่งให้เขียนแต่ละการดำเนินการที่เสร็จสมบูรณ์ลงในบันทึกการลงทะเบียนหรือไฟล์ txt ใน 1C 8.1 การเรียกใช้โค้ดเซิร์ฟเวอร์ไม่สามารถดีบั๊กได้

เพื่อความสะดวกในการแก้ไขข้อบกพร่องและตั้งค่าการใช้งานของฉัน ฉันกำลังแนบการประมวลผล "การลงทะเบียนการเปลี่ยนแปลง" ซึ่งมีคำอธิบายอยู่ในการประมวลผล

แผนภาพการทำงานทั่วไปของศูนย์แลกเปลี่ยนข้อมูลแสดงในรูปที่ 3

การกรองข้อมูลเกิดขึ้นในการสมัครรับเหตุการณ์ "BeforeRecording" ของแต่ละออบเจ็กต์ อย่าลืมว่าเมื่อสร้างอิมเมจโหนดเริ่มต้น ข้อมูลก็ต้องถูกกรองด้วย ขั้นตอนการสร้างภาพเริ่มต้นนั้นค่อนข้างยาว ดังนั้นฉันแนะนำให้ปรับโค้ดให้เหมาะสมที่สุด (เช่น การตั้งค่าการกรองแคช)

คำหลัง

ภารกิจหลักคือการตอบคำถาม:

1. ทำไมเราถึงต้องการ RDB?
2. อะไรที่ไม่ชอบเกี่ยวกับการทำงานผ่านไคลเอนต์ RDP
3. เราต้องการติดตั้งโหนด RDB ที่ไหนและทำไม?
4. การอัพเดตจะถูกส่งต่ออย่างไร?
5. ความทนทานต่อข้อผิดพลาดจะถูกนำมาใช้ในระดับใด?

กำลังประมวลผล "การลงทะเบียนการเปลี่ยนแปลง"

การประมวลผลทำให้คุณสามารถบังคับให้บันทึกการเปลี่ยนแปลงออบเจ็กต์ได้ มีหลายตัวเลือกสำหรับการบันทึกการเปลี่ยนแปลง:

1. หากมีการตรวจสอบข้อมูลเมตาใดๆ และไม่มีการเลือกออบเจ็กต์และไม่ได้ตั้งค่าสถานะ "โหลดตามค่าทั้งหมด" จะมีการลงทะเบียนเฉพาะตารางที่เลือกเท่านั้น
2. หากตั้งค่าแฟล็ก "อัปโหลดสำหรับค่าทั้งหมด" ข้อมูลเมตาที่เลือกจะถูกยกเลิกการโหลดสำหรับออบเจ็กต์ทั้งหมดในวงจร
3. หากสวิตช์ถูกตั้งค่าเป็นโหมด "อัปโหลดเฉพาะออบเจ็กต์ที่เลือก" เฉพาะออบเจ็กต์ที่เลือกเท่านั้นที่จะยกเลิกการโหลด (เช่น การตั้งค่าสถานะบนข้อมูลเมตาโดยไม่เลือกออบเจ็กต์จะเทียบเท่ากับการเปิดแฟล็ก "อัปโหลดตามค่าทั้งหมด" และสวิตช์ ในตำแหน่ง "ยกเลิกการโหลดเฉพาะวัตถุที่เลือก"
4. หากสวิตช์ถูกตั้งค่าเป็นโหมด "ยกเลิกการโหลดวัตถุที่เลือกและเกี่ยวข้องโดยตรง" ดังนั้นวัตถุที่เลือกและวัตถุเหล่านั้นซึ่งมีอยู่ขึ้นอยู่กับการมีอยู่ของวัตถุที่เลือกจะถูกยกเลิกการโหลด (ตัวอย่างเช่น: สำหรับไดเรกทอรี - ไดเรกทอรีรอง)
5. หากสวิตช์ถูกตั้งค่าเป็นโหมด "อัปโหลดโดยใช้ลิงก์ทั้งหมด" ออบเจ็กต์ทั้งหมดที่มีลิงก์ไปยังออบเจ็กต์ที่เลือกจะถูกยกเลิกการโหลด

มีฟังก์ชันเพิ่มเติมให้เลือก:

• การลงทะเบียนออบเจ็กต์ที่ลงทะเบียนใหม่มักจำเป็นสำหรับการดีบัก
• การลบรายการที่ลงทะเบียนไว้มักจำเป็นสำหรับการดีบัก
• พิมพ์การเปลี่ยนแปลง - พิมพ์รายการออบเจ็กต์ทั้งหมดที่ทำเครื่องหมายว่ามีการเปลี่ยนแปลง
• การพิมพ์แผนผังการกำหนดค่ามีไว้เพื่อความสะดวกในการดูการกำหนดค่าทั้งหมดเท่านั้น

เนื้อหานี้มีคำแนะนำโดยละเอียดสำหรับการตั้งค่าการแลกเปลี่ยน RIB สำหรับ 1C:Enterprise 8 และปัญหาที่ผู้เขียนพบ

1. การสร้างโหนด
เราสร้างโหนดใหม่ (หลักและทาส): ในโหมดผู้ใช้ "ปฏิบัติการ / แผนการแลกเปลี่ยน / เต็ม"
เรามาเลือกแผนการแลกเปลี่ยน "เต็ม" กัน
เราสร้างสองบันทึก:
- เรียกบันทึกแรกว่า "CB" (โหนดหลัก) ระบุรหัส "CB"
- เรียกรายการที่สองว่า "โหนดย่อย" ระบุรหัส "PU"
ไอคอนที่มีวงกลมสีเขียว - "CB" (โหนดหลัก)

สำหรับโหนดทาสให้คลิกที่ไอคอน "สร้างภาพเริ่มต้น" (ต้องมีการเข้าถึงพิเศษ)
สร้างภาพเริ่มต้น
ถัดไปในหน้าต่างที่เปิดขึ้น ให้กรอกพารามิเตอร์ของฐานข้อมูลใหม่ เมื่อเสร็จแล้วให้คลิกปุ่ม "เสร็จสิ้น"
การสร้างอิมเมจความปลอดภัยของข้อมูลเบื้องต้น
การสร้างอิมเมจเริ่มต้นของโหนดทาสของฐานข้อมูลแบบกระจายจะเริ่มขึ้น และเมื่อเสร็จสิ้น ข้อความ “การสร้างอิมเมจเริ่มต้นเสร็จสมบูรณ์แล้ว” จะปรากฏขึ้น คลิกปุ่ม "ตกลง"
เราเพิ่มฐานของโหนดทาสลงในรายการฐานและเปิดใช้งาน
ในฐานข้อมูลรองนี้ เราเปิดแผนการแลกเปลี่ยนแบบเต็ม - ไอคอน "CB" เป็นสีแดง ซึ่งหมายความว่าโหนดนี้เป็นโหนดหลักสำหรับฐานข้อมูลที่เราตั้งอยู่

2. การตั้งค่าคำนำหน้า
สำหรับแต่ละฐานข้อมูลในการตั้งค่าพารามิเตอร์การบัญชี (ใน UPP "พารามิเตอร์บริการ / การบัญชี") บนแท็บ "การแลกเปลี่ยนข้อมูล" เราตั้งค่าคำนำหน้า ทำเช่นนี้เพื่อไม่ให้เกิดความขัดแย้งในตัวเลขและรหัสของเอกสารและไดเร็กทอรีที่สร้างในสองฐานข้อมูล
สำหรับการแลกเปลี่ยนอัตโนมัติ ให้เลือกช่อง "ใช้กลไกการแลกเปลี่ยนอัตโนมัติ..."
แท็บ "การแลกเปลี่ยนข้อมูล"

3. เพิ่มการตั้งค่าสำหรับการแลกเปลี่ยนข้อมูลระหว่างโหนด
เปิด: "Service\Distributed Information Base (RIB)\Configure RIB nodes"
คลิก "เพิ่ม" และหน้าต่าง "การตั้งค่าการแลกเปลี่ยนข้อมูล" จะเปิดขึ้น
การตั้งค่าการแลกเปลี่ยนข้อมูล

คลิกที่ไอคอน "แลกเปลี่ยนตามการตั้งค่าปัจจุบัน"
ดำเนินการแลกเปลี่ยนตามการตั้งค่าปัจจุบัน

ตอนนี้เกี่ยวกับข้อผิดพลาด
1. การแลกเปลี่ยนข้อมูลสามารถดำเนินการได้โดยอัตโนมัติและสามารถเริ่มต้นได้ในกรณีต่อไปนี้:
* เมื่อเริ่มโปรแกรม การแลกเปลี่ยนจะดำเนินการเมื่อโปรแกรมเริ่มต้น
* เมื่อใช้งานโปรแกรมเสร็จแล้ว การแลกเปลี่ยนจะดำเนินการก่อนที่ผู้ใช้จะเสร็จสิ้นการทำงานกับโปรแกรม
* เมื่อแค็ตตาล็อกปรากฏขึ้น การแลกเปลี่ยนจะดำเนินการก็ต่อเมื่อไดเรกทอรีที่ระบุโดยผู้ใช้ไม่ปรากฏให้เห็น แต่ตอนนี้ปรากฏให้เห็นแล้ว การตั้งค่านี้สามารถใช้เพื่อดำเนินการแลกเปลี่ยนอัตโนมัติเมื่อเชื่อมต่อกับเครือข่ายท้องถิ่นหรือแฟลชการ์ด โปรแกรมจะตรวจสอบการมองเห็นของไดเร็กทอรีที่ระบุในการตั้งค่าเป็นระยะและบันทึกสถานะปัจจุบัน
* เมื่อไฟล์ปรากฏขึ้น ขอแนะนำให้ใช้โหมดข้อมูลเมื่อคุณต้องการแลกเปลี่ยนหากไฟล์การแลกเปลี่ยนข้อมูลขาเข้าปรากฏขึ้น ในกรณีนี้ การระบุเส้นทางแบบเต็มไปยังไฟล์การแลกเปลี่ยนข้อมูลขาเข้าก็เพียงพอแล้ว โปรแกรมวิเคราะห์การมีอยู่ของไฟล์เป็นระยะและทันทีที่ปรากฏการแลกเปลี่ยนจะดำเนินการและหลังจากการแลกเปลี่ยนไฟล์นี้จะถูกลบออกโดยการบังคับ (ซึ่งทำเพื่อไม่ให้ขั้นตอนการแลกเปลี่ยนดำเนินการอย่างต่อเนื่อง)
* การแลกเปลี่ยนข้อมูลเป็นระยะ การแลกเปลี่ยนจะดำเนินการตามการตั้งค่าสำหรับการแลกเปลี่ยนข้อมูลเป็นระยะ หากฐานข้อมูลทำงานในโหมดไฟล์เซิร์ฟเวอร์ การแลกเปลี่ยนเป็นระยะจะดำเนินการเฉพาะสำหรับผู้ใช้ที่ระบุไว้ในการตั้งค่านโยบายการบัญชีเป็น “ผู้ใช้สำหรับงานประจำในโหมดไฟล์” ในเวอร์ชันไคลเอ็นต์-เซิร์ฟเวอร์ การแลกเปลี่ยนจะดำเนินการบนเซิร์ฟเวอร์ 1C:Enterprise

ฉันมีตัวเลือกไคลเอ็นต์-เซิร์ฟเวอร์ - เพื่อให้การแลกเปลี่ยนอัตโนมัติตามปกติทำงานได้ ฉันต้องโอเวอร์โหลดเซิร์ฟเวอร์

2. การเข้ารหัสวินโดวส์
การแลกเปลี่ยนถูกขัดจังหวะด้วยข้อผิดพลาดเนื่องจากไฟล์ไม่ได้รับการบีบอัด นี่เป็นเพราะข้อผิดพลาด Cyrillic ในบรรทัดคำสั่งระหว่างการบีบอัด
สามารถรักษาได้โดยการแก้ไขการเข้ารหัสในรีจิสทรี
ตัวอย่างเช่น สำหรับ Windows Server 2008 -
รหัส

Regedit4
"1250"="c_1251.nls"
"1251"="c_1251.nls"
"1252"="c_1251.nls"
"1253"="c_1251.nls"
"1254"="c_1251.nls"
"1255"="c_1251.nls"

3. เมื่อสร้างสำเนาของฐานข้อมูล (เช่น สำหรับการแก้ไข) ในเวอร์ชันไคลเอ็นต์-เซิร์ฟเวอร์ จำเป็นที่งานประจำของสำเนาของฐานข้อมูลจะถูกปิด การบล็อกงานประจำสำหรับการคัดลอก ON

หากไม่ถูกบล็อก สำเนาจะทำการแลกเปลี่ยนตามกำหนดเวลาเดียวกันกับฐานข้อมูลหลัก ซึ่งหมายความว่าข้อความบางส่วนไปยังโหนดระยะไกลจะถูกสร้างขึ้นจากฐานข้อมูลที่ทำงาน และบางส่วนมาจากสำเนา ซึ่งจะนำไปสู่การยกเลิกการซิงโครไนซ์การกำหนดค่า