ขั้นตอนการดีบักเซิร์ฟเวอร์ (1Cv82) ขั้นตอนการดีบักเซิร์ฟเวอร์ (1Cv82) การระบุฐานข้อมูล

วิธีเริ่มการดีบักบนเซิร์ฟเวอร์ 1C...

ตามค่าเริ่มต้น เมื่อใช้สถาปัตยกรรมไคลเอ็นต์-เซิร์ฟเวอร์ 1C:Enterprise โหมดการแก้ไขโค้ด 1C จะทำงานเฉพาะในฝั่งไคลเอ็นต์เท่านั้น ขั้นตอนและฟังก์ชันของเซิร์ฟเวอร์ไม่สามารถมองเห็นได้ในเครื่องไคลเอ็นต์

หากต้องการเปิดใช้งานการดีบักบนเซิร์ฟเวอร์ 1C คุณต้องทำตามขั้นตอนต่อไปนี้:

1. ค้นหาและหยุดบริการ “1C:Enterprise Server Agent 8.3” ในตัวจัดการบริการ (สำหรับเวอร์ชัน 8.3)

สถาปัตยกรรมใหม่

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

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

แอปพลิเคชั่นมือถือ

การใช้โปรโตคอล HTTP ทำให้สามารถดีบักข้อมูลเซิร์ฟเวอร์ ข้อมูลไคลเอ็นต์ และแอปพลิเคชันได้แล้ว

การเปลี่ยนแปลงอื่นๆ

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

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

ดีบักเกอร์ในเครื่องมือการพัฒนา

การโต้ตอบกับขั้นตอนใหม่จะดำเนินการในอินเทอร์เฟซซอฟต์แวร์สากลที่พัฒนาขึ้นเป็นพิเศษ ในด้านหนึ่ง อินเทอร์เฟซนี้ถูกใช้โดย Configurator ในทางกลับกัน มันถูกนำไปใช้ในสภาพแวดล้อม 1C:Enterprise Development Tools ใหม่

ตอนนี้มันดูเป็นยังไงบ้าง

หลังจากเปลี่ยนโปรแกรมแล้ว ขั้นตอนจะเกิดขึ้นตามสถานการณ์ต่อไปนี้:


ตอนนี้ไม่เพียงแต่เกี่ยวข้องกับดีบักเกอร์และไอเท็มต่างๆ ดังที่เคยเป็นมา ขณะนี้มีการแนะนำองค์ประกอบเพิ่มเติมในเชน - เซิร์ฟเวอร์

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

และเนื่องจากการแลกเปลี่ยนนี้ดำเนินการผ่านโปรโตคอล HTTP ตอนนี้จึงไม่สำคัญว่าข้อมูลจะอยู่ที่ใด

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

เปิดใช้งานการดีบักในสถานการณ์ต่างๆ

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

มาดูว่าจะเกิดอะไรขึ้นเมื่อโหมดเริ่มต้นหากเราเลือกหนึ่งในสองสถานการณ์

ไฟล์สคริปต์

ที่จุดเริ่มต้นของเวอร์ชันไฟล์คุณต้องระบุในการตั้งค่าการกำหนดค่าการใช้กลไกใหม่ - "การดีบักผ่านโปรโตคอล HTTP"

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


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

กลไกที่เปิดใช้งานจะเปิดเซิร์ฟเวอร์ดีบักเกอร์ซึ่งเป็นแอปพลิเคชันพิเศษ dbgs.exe โดยอัตโนมัติ ปรากฏในหน้าต่างตัวจัดการงาน

ค่าของพารามิเตอร์ ownPID จะสอดคล้องกับ ID ของแอปพลิเคชันที่ผูกไว้

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


หากเปิดใช้งานโปรแกรม 1C โดยไม่มีกลไกใหม่ คุณจะต้องเปิดใช้งานการดีบักบนเซิร์ฟเวอร์ 1C ด้วยตนเอง ตอนนี้คุณจะต้องระบุที่อยู่เซิร์ฟเวอร์:


ไปที่บริการ - ตัวเลือก

ตั้งอยู่ในการตั้งค่ารายการ:


ไปที่การเชื่อมต่อ - การตั้งค่า

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


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

สถานการณ์จำลองไคลเอ็นต์-เซิร์ฟเวอร์

การดีบักบนเซิร์ฟเวอร์ 1C โดยใช้สถานการณ์ไคลเอนต์ - เซิร์ฟเวอร์ดังเช่นในกรณีก่อนหน้านี้เริ่มต้นด้วยการเปิดโหมด นี่เป็นการระบุการใช้กลไก HTTP ใหม่ ทำได้ดังนี้:

ragent.exe - ดีบัก -http

เมื่อเริ่มต้น ดีบักเกอร์จะเริ่มทำงานด้านหลังโดยอัตโนมัติ

ค่าของพารามิเตอร์ OwnerPID จะสอดคล้องกับหมายเลขประจำตัวของตัวจัดการคลัสเตอร์ 1C

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

ในอนาคตทุกอย่างจะเป็นเหมือนไฟล์สคริปต์ เมื่อเริ่มต้น Server Base Configurator เท่านั้น เซิร์ฟเวอร์ท้องถิ่น- ดีบักเกอร์จะไม่เริ่มทำงานอีกต่อไป

เราหวังว่าสิ่งพิมพ์ของเราจะช่วยให้คุณทราบปัญหาในการเปิดใช้งานการดีบักบนเซิร์ฟเวอร์ 1C

ถามคำถาม แบ่งปันประสบการณ์ของคุณ แสดงความคิดเห็น

   

จะเปิดใช้งานการดีบักแอปพลิเคชัน 1C บนเซิร์ฟเวอร์ได้อย่างไร

เพื่อเปิดใช้งานการดีบักบนเซิร์ฟเวอร์ 1C 8.1คุณจะต้องรีสตาร์ทแอปพลิเคชันเซิร์ฟเวอร์และเข้าสู่รีจิสทรี กล่าวคือ

"เส้นทางรูปภาพ"=

ค่าเริ่มต้น:
"C:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -พอร์ต 1540 -ช่วง 1560:1591 -d "C:\Program Files\1cv81\server"
แต่คุณต้อง:
"C:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -พอร์ต 1540 -ช่วง 1560:1591 -debug -d "C:\Program Files\1cv81\server"

ลำดับของการกระทำ 1C 8.2:
1. หยุดบริการ 1C: ตัวแทนเซิร์ฟเวอร์ Enterprise 8.2
2. ในทะเบียนในสาขา HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\1C:ตัวแทนเซิร์ฟเวอร์ 8.2 ขององค์กร\สำหรับพารามิเตอร์ ImagePathเพิ่ม -debugและบันทึก ปรากฎดังนี้: "C:\Program Files\1cv82\8.2.10.82\bin\ragent.exe" -srvc -agent -regport 1541 -พอร์ต 1540 -ช่วง 1560:1591 -d "C:\Program Files\1cv82\srvinfo" -debug
3. บันทึกและเริ่มให้บริการ

ก่อนอื่นฉันพลาดช่องว่างก่อน -debug สิ่งที่ฉันสามารถพูดได้: ผลลัพธ์นั้นยอดเยี่ยม - ไม่พบฐานข้อมูลเดียวองค์กรไม่ได้เริ่มต้น แต่อย่างใด

คุณอาจจะสนใจด้วย

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

การใช้โปรโตคอลใหม่

ดีบักเกอร์ก่อนหน้านี้ ซึ่งนำไปใช้ในเวอร์ชันก่อนหน้า ไคลเอ็นต์ที่ได้รับการจัดการ และ แอปพลิเคชันเซิร์ฟเวอร์โดยใช้โปรโตคอล TCP/IP

ปัจจุบันการใช้โปรโตคอลดังกล่าวได้เริ่มจำกัดการเข้าถึงโปรแกรม 1C: Enterprise ไปยังอินเทอร์เน็ต และได้สร้างความไม่สะดวกในการทำงาน แอปพลิเคชันมือถือ.

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

สถาปัตยกรรมใหม่

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

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

แอปพลิเคชั่นมือถือ

การใช้โปรโตคอล HTTP ทำให้สามารถดีบักข้อมูลเซิร์ฟเวอร์ ข้อมูลไคลเอ็นต์ และแอปพลิเคชันได้แล้ว

การเปลี่ยนแปลงอื่นๆ

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

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

ดีบักเกอร์ในเครื่องมือการพัฒนา

การโต้ตอบกับขั้นตอนใหม่จะดำเนินการในอินเทอร์เฟซซอฟต์แวร์สากลที่พัฒนาขึ้นเป็นพิเศษ ในด้านหนึ่ง อินเทอร์เฟซนี้ถูกใช้โดย Configurator ในทางกลับกัน มันถูกนำไปใช้ในสภาพแวดล้อม 1C:Enterprise Development Tools ใหม่

ตอนนี้มันดูเป็นยังไงบ้าง

หลังจากเปลี่ยนโปรแกรมแล้ว ขั้นตอนจะเกิดขึ้นตามสถานการณ์ต่อไปนี้:

ตอนนี้ไม่เพียงแต่เกี่ยวข้องกับดีบักเกอร์และไอเท็มต่างๆ ดังที่เคยเป็นมา ขณะนี้มีการแนะนำองค์ประกอบเพิ่มเติมในเชน - เซิร์ฟเวอร์

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

และเนื่องจากการแลกเปลี่ยนนี้ดำเนินการผ่านโปรโตคอล HTTP ตอนนี้จึงไม่สำคัญว่าข้อมูลจะอยู่ที่ใด

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

เปิดใช้งานการดีบักในสถานการณ์ต่างๆ

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

มาดูว่าจะเกิดอะไรขึ้นเมื่อโหมดเริ่มต้นหากเราเลือกหนึ่งในสองสถานการณ์

ไฟล์สคริปต์

ที่จุดเริ่มต้นของเวอร์ชันไฟล์คุณต้องระบุในการตั้งค่าการกำหนดค่าการใช้กลไกใหม่ - "การดีบักผ่านโปรโตคอล HTTP"

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

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

กลไกที่เปิดใช้งานจะเปิดเซิร์ฟเวอร์ดีบักเกอร์ซึ่งเป็นแอปพลิเคชันพิเศษ dbgs.exe โดยอัตโนมัติ ปรากฏในหน้าต่างตัวจัดการงาน

ค่าของพารามิเตอร์ ownPID จะสอดคล้องกับ ID ของแอปพลิเคชันที่ผูกไว้

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

หากเปิดใช้งานโปรแกรม 1C โดยไม่มีกลไกใหม่ คุณจะต้องเปิดใช้งานการดีบักบนเซิร์ฟเวอร์ 1C ด้วยตนเอง ตอนนี้คุณจะต้องระบุที่อยู่เซิร์ฟเวอร์:

ไปที่บริการ - ตัวเลือก

ตั้งอยู่ในการตั้งค่ารายการ:

ไปที่การเชื่อมต่อ - การตั้งค่า

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

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

สถานการณ์จำลองไคลเอ็นต์-เซิร์ฟเวอร์

การดีบักบนเซิร์ฟเวอร์ 1C โดยใช้สถานการณ์ไคลเอนต์ - เซิร์ฟเวอร์ดังเช่นในกรณีก่อนหน้านี้เริ่มต้นด้วยการเปิดโหมด นี่เป็นการระบุการใช้กลไก HTTP ใหม่ ทำได้ดังนี้:

ragent.exe - ดีบัก -http

เมื่อเริ่มต้น ดีบักเกอร์จะเริ่มทำงานด้านหลังโดยอัตโนมัติ

ค่าของพารามิเตอร์ OwnerPID จะสอดคล้องกับหมายเลขประจำตัวของตัวจัดการคลัสเตอร์ 1C

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

ในอนาคตทุกอย่างจะเป็นเหมือนไฟล์สคริปต์ เฉพาะเมื่อคุณเริ่ม Server Database Configurator เท่านั้นที่เซิร์ฟเวอร์ดีบักเกอร์ภายในเครื่องจะไม่เริ่มทำงานอีกต่อไป

เราหวังว่าสิ่งพิมพ์ของเราจะช่วยให้คุณทราบปัญหาในการเปิดใช้งานการดีบักบนเซิร์ฟเวอร์ 1C

คำแนะนำ

ศึกษาข้อมูลที่คุณมีเกี่ยวกับเซิร์ฟเวอร์นี้อย่างรอบคอบ ในการสร้างการเชื่อมต่อ คุณจำเป็นต้องทราบที่อยู่ IP และพอร์ตที่จะใช้ในการเชื่อมต่อ สำหรับเซิร์ฟเวอร์ส่วนใหญ่ที่ใช้โปรโตคอล http พอร์ตมาตรฐานคือ 80

พอร์ตอื่นๆ อาจเปิดอยู่บนเซิร์ฟเวอร์ - ทั้งหมดขึ้นอยู่กับบริการที่กำลังทำงานอยู่ ตัวอย่างเช่น ftp - พอร์ต 21, telnet - พอร์ต 23, SMTP (การส่งจดหมาย) - พอร์ต 25, POP (การรับจดหมาย) - พอร์ต 110 เป็นต้น พอร์ตเหล่านี้จำนวนมากอาจเปิดสำหรับการเชื่อมต่อ แต่อาจทำให้คุณต้องป้อนรหัสผ่านเมื่อพยายามสร้างการเชื่อมต่อ

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

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

ในการเชื่อมต่อ คุณจะต้องมีโปรแกรมที่ทำงานร่วมกับบริการเซิร์ฟเวอร์ที่เหมาะสม ตัวอย่างเช่น หากพอร์ต 21 เปิดอยู่ คุณจะต้องมีไคลเอ็นต์ ftp เมื่อเปิด 23 คุณจะต้องใช้เทลเน็ต ด้วยการสแกนพอร์ต คุณจะพบพอร์ตต่างๆ ที่ใช้งานโดยโปรแกรมการดูแลระบบระยะไกล เช่น Anyplace Control, Access Remote PC, DameWare NT Utilities, RemotelyAnywhere, Radmin, VNC เป็นต้น

ได้พบแล้ว เปิดพอร์ตคุณสามารถลองเชื่อมต่อกับมันได้ เป็นไปได้มากว่าคุณจะถูกขอให้ป้อนรหัสผ่าน แต่บางครั้งผู้ดูแลระบบจะไม่เปลี่ยนค่าเริ่มต้น ตัวอย่างเช่น สำหรับโปรแกรม Radmin ยอดนิยม (พอร์ต 4899) รหัสผ่านเริ่มต้นคือ 12345678 หรือ 123456789

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

วิดีโอในหัวข้อ

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

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

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

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

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

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

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

เพื่อให้สามารถดีบักขั้นตอนเซิร์ฟเวอร์ได้ คุณต้องตั้งค่าแฟล็กในรูปแบบ “บริการ -> พารามิเตอร์” ของตัวกำหนดค่า:

การดีบักบนแอปพลิเคชันเซิร์ฟเวอร์

สิ่งนี้อธิบายไว้ในเอกสารประกอบ:

หนังสือ “1C:องค์กร 8.1. การกำหนดค่าและการดูแลระบบ"

บทที่ 18 เครื่องมือกำหนดค่า

การวัดดีบักเกอร์และประสิทธิภาพ

"การแก้ไขโค้ดบนเซิร์ฟเวอร์

หากต้องการติดตั้งโหมดแก้ไขข้อบกพร่อง คุณควรเริ่มเซิร์ฟเวอร์ 1C:Enterprise ด้วยรหัส บรรทัดคำสั่ง/Debug (ragent.exe /debug)"

คีย์การเริ่มต้นตัวแทนเซิร์ฟเวอร์อธิบายไว้ในหนังสือ:

"1C: องค์กร 8.1. ไคลเอนต์เซิร์ฟเวอร์ คุณสมบัติการติดตั้งและการใช้งาน"

"การเรียกใช้ตัวแทนเซิร์ฟเวอร์เป็นบริการ

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

หากมีการติดตั้งเอเจนต์เซิร์ฟเวอร์กลางเป็นแอปพลิเคชัน จะสามารถลงทะเบียนบริการด้วยตนเองแล้วเปิดใช้งานได้

การลงทะเบียนบริการทำได้โดยใช้คำสั่งต่อไปนี้:

Ragent.exe -instsrvc -usr<пользователь>-pwd<пароль>-ท่าเรือ<порт>-พิสัย<диапазоны>-วินาที<уровень>-ดีบั๊ก | -rmsrvc | -เริ่มต้น | -หยุด

Instsrvc – การลงทะเบียนเอเจนต์คลัสเตอร์เป็นบริการ Windows หากเรียกใช้ ragent.exe ด้วยคีย์นี้ ระบบจะลงทะเบียนในรายการบริการ Windows และออก เข้ากันไม่ได้กับสวิตช์ -srvc, -rmsrvc

สหรัฐ<имя пользователя>

พล.อ<пароль пользователя>– ชื่อและรหัสผ่าน ผู้ใช้วินโดวส์ในนามของ ragent.exe ที่ควรเปิดตัวเป็นบริการ Windows สามารถใช้ร่วมกับสวิตช์ -instsrvc เมื่อลงทะเบียน ragent.exe เป็นบริการ Windows เท่านั้น

ท่าเรือ<порт>– หมายเลขพอร์ตหลักของเอเจนต์คลัสเตอร์ พอร์ตนี้ถูกใช้โดยคอนโซลคลัสเตอร์เพื่อเข้าถึงเซิร์ฟเวอร์กลาง พอร์ตเอเจนต์คลัสเตอร์ยังถูกระบุเป็นพอร์ต IP ของเซิร์ฟเวอร์ที่ทำงานด้วย

พิสัย<диапазоны>– ช่วงพอร์ต IP สำหรับการเลือกแบบไดนามิก จากสิ่งเหล่านี้ พอร์ตบริการของกระบวนการคลัสเตอร์จะถูกเลือกหากไม่สามารถเลือกได้จากการตั้งค่าของเซิร์ฟเวอร์ที่ทำงานที่เกี่ยวข้อง ค่าเริ่มต้น: 1560-1591 ค่าตัวอย่าง<диапазоны>: "45:49", "45:67,70:72,77:90";

เซเลฟ<уровень>– ระดับความปลอดภัยของกระบวนการเอเจนต์คลัสเตอร์ กำหนดระดับความปลอดภัยของการเชื่อมต่อที่สร้างด้วยกระบวนการ ragent.exe<уровень>สามารถใช้ค่าต่อไปนี้: 0 (ค่าเริ่มต้น) การเชื่อมต่อไม่ปลอดภัย 1 – การเชื่อมต่อที่ปลอดภัยเฉพาะในช่วงระยะเวลาการตรวจสอบผู้ใช้ 2 – การเชื่อมต่อที่ปลอดภัยอย่างถาวร;

Rmsrvc – ยกเลิกการลงทะเบียนเอเจนต์คลัสเตอร์เป็นบริการ Windows หากเปิดใช้งาน ragent.exe ด้วยคีย์นี้ ระบบจะยกเลิกการลงทะเบียนในรายการบริการ Windows และออก เข้ากันไม่ได้กับสวิตช์ -srvc, -daemon, -instsrvc

เริ่ม - เปิด ragent.exe ที่ลงทะเบียนเป็นบริการ Windows เปิดตัว ragent.exe ซึ่งลงทะเบียนไว้ก่อนหน้านี้เป็นบริการ Windows แล้วออก

หยุด - หยุด ragent.exe ที่ลงทะเบียนและทำงานเป็นบริการ Windows หยุด ragent.exe ที่ลงทะเบียนไว้ก่อนหน้านี้และทำงานเป็นบริการ Windows แล้วออกจากระบบ

ดีบัก - เรียกใช้คลัสเตอร์เซิร์ฟเวอร์ในโหมดดีบักการกำหนดค่า -

ดังนั้น หากเซิร์ฟเวอร์ 1C:Enterprise เปิดตัวเป็นบริการ และด้วยเหตุผลบางประการ ควรเปิดใช้งานเป็นบริการในโหมดแก้ไขข้อบกพร่องด้วย คุณต้องยกเลิกการลงทะเบียนบริการก่อน (คีย์ -rmsrvc) จากนั้นจึงลงทะเบียนบริการอีกครั้งด้วย คีย์ -debug

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

ใช้งานได้เฉพาะเมื่อมีการตั้งค่าคีย์ "-debug" ในรีจิสทรี ในกรณีอื่นๆ ทั้งหมด มันไม่ทำงานด้วยเหตุผลบางประการ

"เส้นทางรูปภาพ"=

คือ "F:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "F:\Program Files\1cv81\server"

ตั้งค่า "F:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d "F:\Program Files\1cv81\server"

ใช้งานในเวอร์ชัน 8.3.7.1759

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

ประโยชน์ที่สำคัญ

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

การดีบัก HTTP

กลไกการดีบักก่อนหน้านี้ขึ้นอยู่กับข้อเท็จจริงที่ว่าดีบักเกอร์ที่ใช้งานในตัวกำหนดค่า 1C:Enterprise โต้ตอบโดยตรงกับรายการดีบัก (แอปพลิเคชันไคลเอ็นต์และเซิร์ฟเวอร์) การโต้ตอบนี้ดำเนินการโดยใช้โปรโตคอล TCP/IP

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

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

สถาปัตยกรรมการดีบักสมัยใหม่

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

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

การดีบักแอปพลิเคชันมือถือ

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

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

การดีบักในเครื่องมือการพัฒนา

เมื่อสร้างกลไกการดีบักใหม่ เราได้ใช้อินเทอร์เฟซซอฟต์แวร์สากลใหม่สำหรับการโต้ตอบกับมัน อินเทอร์เฟซนี้ถูกใช้โดยตัวปรับแต่ง 1C:Enterprise และตอนนี้อินเทอร์เฟซเดียวกันก็ถูกใช้โดยสภาพแวดล้อมการพัฒนาใหม่ ดังนั้น ความสามารถในการดีบักทั้งหมดจึงพร้อมใช้งานเมื่อทำงานใน .

สถาปัตยกรรมกระบวนการดีบัก

สถาปัตยกรรมการดีบักใหม่มีลักษณะดังนี้:

การดีบักเกี่ยวข้องกับดีบักเกอร์ รายการการดีบัก และองค์ประกอบใหม่ - เซิร์ฟเวอร์ตรวจแก้จุดบกพร่อง.

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

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

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

ดังนั้นปฏิสัมพันธ์จึงเป็นฝ่ายเดียว ข้อมูลจะถูกถ่ายโอนอย่างต่อเนื่องจากเซิร์ฟเวอร์ดีบักไปยังดีบักเกอร์ และไปยังอ็อบเจ็กต์การดีบัก

การระบุฐานข้อมูล

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

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

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

สถานการณ์การดีบักทั่วไป

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

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

ตัวเลือกไฟล์

ก่อนที่คุณจะเริ่มแก้ไขข้อบกพร่องในเวอร์ชันไฟล์ คุณต้องระบุในการตั้งค่าตัวกำหนดค่าว่าคุณต้องการใช้กลไกการดีบักใหม่ - “ การดีบัก HTTP».

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

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

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

พารามิเตอร์ OwnerPID ระบุตัวระบุของแอปพลิเคชันที่เป็นเจ้าของเซิร์ฟเวอร์การดีบักนี้ ในกรณีนี้ นี่คือตัวกำหนดค่า 1C:Enterprise

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

หากเซสชัน 1C:Enterprise เปิดตัวโดยไม่มีการดีบัก คุณสามารถเชื่อมต่อกับดีบักเกอร์ได้เหมือนเมื่อก่อน ตอนนี้คุณต้องระบุที่อยู่เซิร์ฟเวอร์ดีบักเท่านั้น:

คุณสามารถค้นหาที่อยู่นี้ได้จากการตั้งค่ารายการแก้ไขข้อบกพร่อง:

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

ดังนั้นหากคุณเปิดคอนฟิกูเรเตอร์หลายตัวพร้อมกัน ในการเชื่อมต่อแอปพลิเคชันไคลเอนต์กับดีบักเกอร์คุณต้องเลือกอันที่ถูกต้อง

ตัวเลือกไคลเอนต์เซิร์ฟเวอร์

ก่อนที่คุณจะเริ่มการดีบักในเวอร์ชันไคลเอ็นต์ - เซิร์ฟเวอร์ คุณต้องเริ่มเซิร์ฟเวอร์ 1C: Enterprise ในโหมดดีบั๊กเช่นเคย แต่ระบุว่าจะใช้กลไก HTTP ใหม่สำหรับการดีบั๊ก ตัวอย่างเช่นเช่นนี้:

ragent.exe - ดีบัก -http

เมื่อเซิร์ฟเวอร์เริ่มต้นด้วยวิธีนี้ เซิร์ฟเวอร์การตรวจแก้จุดบกพร่องก็จะเริ่มต้นเช่นกัน

พารามิเตอร์ OwnerPID จะระบุตัวระบุของตัวจัดการคลัสเตอร์ 1C:Enterprise

ขณะนี้อยู่ในการตั้งค่าตัวกำหนดค่าเช่นเดียวกับในกรณีของฐานข้อมูลไฟล์คุณต้องระบุว่าคุณต้องการใช้กลไกการดีบักใหม่ - “ การดีบัก HTTP».

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

การเชื่อมต่อรายการแก้ไขจุดบกพร่อง

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

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

ประการแรก แพลตฟอร์มในขณะนี้เสนอรายการแก้ไขข้อบกพร่องที่เป็นไปได้ทั้งหมดให้คุณเลือก

และประการที่สอง มีวิธีการจัดฉากที่ละเอียดอ่อนยิ่งขึ้นอีกวิธีหนึ่งปรากฏขึ้น นี่คือการใช้ตัวเลือกที่สร้างไว้ล่วงหน้า

คุณสามารถใช้การเลือกดังกล่าวทั้งเมื่อเชื่อมต่อรายการดีบักและดูรายการดีบักที่มีอยู่

ในการเลือก นอกเหนือจากรายการแก้ไขข้อบกพร่องแล้ว คุณสามารถระบุผู้ใช้เฉพาะที่มีเซสชันที่คุณสนใจ และหากใช้การแยกข้อมูล ให้ระบุพื้นที่ของฐานข้อมูลที่จะถูกแก้ไข

การเปลี่ยนแปลงตัวแปร คุณสมบัติของอ็อบเจ็กต์ และการประเมินนิพจน์แบบอะซิงโครนัส

กลไกการดีบักใหม่ช่วยให้คุณเปลี่ยนค่าตัวแปรขณะทำการดีบัก ในกลไกก่อนหน้านี้ไม่มีความเป็นไปได้เช่นนั้น

เพื่อความสะดวกในการดูและเปลี่ยนแปลงตัวแปรท้องถิ่น ซึ่งดูเหมือนจะเป็นงานที่พบบ่อยที่สุด เราได้ดำเนินการ " ตัวแปรท้องถิ่น».

ภายนอกมันคล้ายกับ "กระดานคะแนน" ที่คุณคุ้นเคยมาก แต่ประการแรก หน้าต่างนี้เต็มไปด้วยตัวแปรท้องถิ่นทั้งหมดโดยอัตโนมัติ และประการที่สอง ตอนนี้คุณสามารถเปลี่ยนค่าของตัวแปรได้แล้ว

คุณสามารถเปลี่ยนค่าของประเภทดั้งเดิมได้โดยตรงในเซลล์ " ความหมาย»:

และหากต้องการเปลี่ยนค่าอื่นๆ คุณสามารถใช้หน้าต่างอินพุตนิพจน์ได้:

โบนัสที่ดีก็คือคำแนะนำเครื่องมือตามบริบททำงานได้อย่างสมบูรณ์ในหน้าต่างนี้

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

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