วิธีทดสอบ SOAP และ WSDL เว็บเซอร์วิสใน Apidog

คุณได้รับ SOAP endpoint มาใช้งาน อาจเป็นตัวแปลงสกุลเงินแบบเก่าที่ทีมบัญชีของคุณยังคงต้องพึ่งพา หรือเว็บเซอร์วิสสำหรับการจัดการคำสั่งซื้อที่พาร์ทเนอร์ใช้งานบน .NET คุณจำเป็นต้องเรียกใช้ ยืนยันว่ามันคืนค่าตามที่สัญญากำหนดไว้ และพิสูจน์ว่ามันยังคงถูกต้องเมื่อโค้ดรอบๆ เปลี่ยนแปลงไป เครื่องมือ REST ไม่เหมาะสมนัก เพราะ SOAP ต้องการ XML envelope แบบเต็ม, Content-Type ที่เฉพาะเจาะจง และ WSDL ที่อธิบายทุกการดำเนินการ

Apidog รองรับคำขอ SOAP และ WebService ควบคู่ไปกับ REST, GraphQL และ gRPC ดังนั้นคุณจึงไม่จำเป็นต้องมีแอปแยกต่างหากสำหรับบริการเก่าๆ เพียงบริการเดียวในระบบของคุณ คู่มือนี้จะแนะนำทั้งสองวิธีที่ระบุไว้: การส่งคำขอ SOAP ด้วยตนเอง และการนำเข้า WSDL เพื่อให้ Apidog สร้างสภาพแวดล้อมและ Endpoint ให้คุณ หากคุณต้องการภาพรวมของโปรโตคอลในวงกว้างก่อน การเปรียบเทียบระหว่าง REST, GraphQL, gRPC และ SOAP ของเราจะอธิบายว่าแต่ละโปรโตคอลมีประโยชน์อย่างไร สำหรับคำจำกัดความอย่างเป็นทางการของโครงสร้าง Envelope ข้อกำหนด SOAP ของ W3C คือแหล่งข้อมูลที่เชื่อถือได้

SOAP คืออะไร และทำไมจึงต้องมีการจัดการที่แตกต่างออกไป

Apidog อธิบายว่า SOAP คือ Simple Object Access Protocol ซึ่งเป็นโปรโตคอลการสื่อสารแบบ XML ที่ช่วยให้แพลตฟอร์มและภาษาโปรแกรมที่หลากหลายสามารถสื่อสารกันได้ แนวคิดนี้อธิบายได้ว่าทำไมองค์กรจำนวนมากยังคงใช้งานอยู่ ไคลเอนต์ Java และบริการ .NET สามารถสื่อสารกันได้ผ่านสัญญาเดียวกันโดยไม่ต้องสนใจรายละเอียดภายในของกันและกัน

มีสามคุณสมบัติสำคัญเมื่อคุณทดสอบมัน SOAP ใช้ XML สำหรับการจัดรูปแบบข้อความ ดังนั้นทุกคำขอและคำตอบจะเป็นเอกสารที่มีโครงสร้าง ไม่ใช่ JSON blob ที่ไม่เป็นระเบียบ หากคุณไม่คุ้นเคยกับ XML เอกสารอ้างอิง XML ของ MDN เป็นแหล่งข้อมูลเบื้องต้นที่ดีสำหรับไวยากรณ์ที่คุณจะต้องอ่านและเขียน โดยปกติแล้วจะส่งผ่าน HTTP หรือ HTTPS แม้ว่าโปรโตคอลจะรองรับโปรโตคอลอื่น ๆ ก็ตาม และเป็นไปตามมาตรฐาน W3C สำหรับการสื่อสารที่มีโครงสร้างและเชื่อถือได้ ซึ่งเป็นเหตุผลว่าทำไมรูปร่างของข้อความจึงเข้มงวดและกฎการตรวจสอบจึงเคร่งครัด

ความเข้มงวดนั้นเป็นเหตุผลว่าทำไม SOAP endpoint จึงยังคงถูกใช้งานสำหรับการรวมระบบข้ามแพลตฟอร์ม, การเชื่อมต่อระบบเก่ากับระบบใหม่, และการทำธุรกรรมที่ปลอดภัยโดยใช้ WS-Security สำหรับการเข้ารหัสข้อความและการยืนยันตัวตน นอกจากนี้ยังเป็นเหตุผลว่าทำไมคุณไม่สามารถยิงคำขอแบบ REST ไปยัง SOAP ได้ คุณต้องมี Header ที่ถูกต้อง, XML body ที่ห่อหุ้มใน SOAP envelope และวิธีการอ่าน XML ที่ตอบกลับมา หากคุณต้องการดูรายละเอียดเพิ่มเติมว่า envelope และ body ส่งข้อมูลอย่างไร โปรดดูการวิเคราะห์ SOAP API และ XML ของเรา

ก่อนเริ่มต้น

ข้อกำหนดที่สำคัญข้อหนึ่งมีผลกับทุกสิ่งที่กล่าวมาด้านล่างนี้ ในการส่งคำขอ SOAP หรือ WebService, Apidog จะต้องเป็นเวอร์ชัน 2.1.31 หรือสูงกว่า เวอร์ชันเก่ากว่าไม่รองรับ เปิด Apidog ตรวจสอบเวอร์ชันของคุณ และอัปเดตหากคุณใช้เวอร์ชันที่เก่ากว่า ทุกส่วนที่เหลือในคู่มือนี้ถือว่าคุณใช้เวอร์ชัน 2.1.31 หรือใหม่กว่า

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

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

วิธี A: ส่งคำขอ SOAP ด้วยตนเอง

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

ขั้นตอนที่ 1: ตั้งค่า Content-Type header ด้วยตนเอง

คำขอ SOAP ไม่ได้อนุมาน Header ของตัวเอง คุณต้องตั้งค่า Content-Type ด้วยตนเอง และมีสองค่าที่ถูกต้อง:

• text/xml; charset=utf-8
• application/soap+xml

ค่าใดที่ถูกต้องขึ้นอยู่กับบริการ โดยทั่วไป SOAP 1.1 endpoint จะคาดหวัง text/xml; charset=utf-8 ในขณะที่ SOAP 1.2 endpoint มักจะต้องการ application/soap+xml หากคุณไม่แน่ใจ ให้ตรวจสอบ WSDL หรือเอกสารประกอบบริการ และหากค่าแรกส่งกลับข้อผิดพลาดเกี่ยวกับ Content-Type ให้เปลี่ยนไปใช้อีกค่าหนึ่ง เพิ่ม Header ในส่วน Headers ของคำขอก่อนที่คุณจะส่ง

ขั้นตอนที่ 2: ตั้งค่ารูปแบบ Body เป็น XML และวาง Envelope

ตั้งค่ารูปแบบ Body ของคำขอเป็น xml จากนั้นวาง SOAP envelope Envelope คือเอกสารที่มีการประกาศ Namespace และมีองค์ประกอบ Body ที่เก็บการดำเนินการที่คุณกำลังเรียกใช้ พร้อมด้วยพารามิเตอร์ใดๆ ที่ซ้อนอยู่ภายใน

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

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:web="http://www.dataaccess.com/webservicesserver/">
  <soap:Body>
    <web:NumberToWords>
      <web:ubiNum>1234</web:ubiNum>
    </web:NumberToWords>
  </soap:Body>
</soap:Envelope>

Namespace บนการดำเนินการจะต้องตรงกับที่บริการคาดหวัง ซึ่งเป็นเหตุผลว่าทำไมคุณควรอ่านจาก WSDL แทนที่จะเดา soap:Body ห่อหุ้มการเรียกใช้จริง; web:NumberToWords คือการดำเนินการ; web:ubiNum คืออินพุต

ขั้นตอนที่ 3: ส่งและอ่านการตอบกลับ XML

ส่งคำขอ การตอบกลับจะกลับมาในรูปแบบ XML ในฐานะ SOAP envelope ที่มี Body บรรจุการดำเนินการตอบกลับ สำหรับการเรียกข้างต้น คุณจะได้รับ NumberToWordsResponse โดยมีผลลัพธ์ซ้อนอยู่ภายใน:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
      <m:NumberToWordsResult>one thousand two hundred and thirty four</m:NumberToWordsResult>
    </m:NumberToWordsResponse>
  </soap:Body>
</soap:Envelope>

การตอบกลับสะท้อนคำขอ: ชื่อการดำเนินการจะได้รับคำต่อท้าย Response และค่าจะอยู่ในองค์ประกอบผลลัพธ์ การสะท้อนกลับนี้คือสิ่งที่คุณยืนยัน คุณยืนยันว่า envelope กลับมา, มีโหนด NumberToWordsResponse และผลลัพธ์ตรงกับที่คุณคาดหวัง เอกสารประกอบ WebService เฉพาะของ Apidog ที่ webservice.apidog.io มีข้อมูลอ้างอิงการกำหนดค่าฉบับเต็มและตัวอย่าง envelope เพิ่มเติม หากคุณต้องการตัวอย่างที่ใช้งานได้จริงอีกตัวอย่างหนึ่ง

กรณีใช้งานจริงก็เป็นไปตามสามขั้นตอนเดียวกันนี้ แทนที่ NumberToWords ด้วยการดำเนินการ ConvertCurrency บนบริการอัตราแลกเปลี่ยนแบบเก่า ส่ง fromCurrency, toCurrency และ amount เป็นองค์ประกอบที่ซ้อนกัน และอ่านตัวเลขที่แปลงแล้วออกจาก response envelope หรือเรียกใช้การดำเนินการ GetOrderStatus บนเว็บเซอร์วิสคำสั่งซื้อ ส่ง orderId และยืนยันโหนดสถานะที่ส่งคืน กลไกไม่เคยเปลี่ยน: header, XML body, ส่ง, อ่าน envelope

วิธี B: นำเข้า WSDL เพื่อสร้าง Endpoint

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

นี่คือขั้นตอนการคลิกที่แน่นอน:

1. ไปที่ Settings, จากนั้น Import Data
2. เลือก WSDL
3. อัปโหลดไฟล์ .wsdl หรือ .xml ของคุณ
4. ตรวจสอบพรีวิวของ API endpoint ที่ Apidog แยกวิเคราะห์จากไฟล์
5. เปิดแท็บ Environments และตรวจสอบว่าที่อยู่บริการถูกต้อง
6. คลิก Confirm สภาพแวดล้อมที่นำเข้าจะถูกสร้างขึ้นโดยอัตโนมัติ
7. เลือกสภาพแวดล้อมที่นำเข้าจากมุมขวาบน
8. ส่งคำขอ Base URL จะถูกนำไปใช้โดยอัตโนมัติจากสภาพแวดล้อมนั้น

สองขั้นตอนในรายการนั้นเป็นสิ่งที่ผู้คนมักจะข้ามไปแล้วเสียใจภายหลัง

ขั้นตอนที่ 5 มีความสำคัญเนื่องจากที่อยู่บริการใน WSDL คือ endpoint ที่คำขอที่นำเข้าทุกรายการจะส่งไปถึง หากมันชี้ไปที่โฮสต์การทดสอบ หรือ URL ชั่วคราวที่ผู้เขียน WSDL ไม่เคยอัปเดต คำขอของคุณจะส่งไปยังที่ที่ไม่ถูกต้อง ตรวจสอบในแท็บ Environments ก่อนที่คุณจะคลิก Confirm ไม่ใช่หลังจากนั้น

ขั้นตอนที่ 7 มีความสำคัญเนื่องจาก Base URL อยู่ในสภาพแวดล้อมที่สร้างขึ้นโดยอัตโนมัตินั้น หากคุณไม่เลือกสภาพแวดล้อมที่นำเข้าจากมุมขวาบน คำขอของคุณจะไม่มีที่อยู่พื้นฐานและจะล้มเหลว เลือกก่อน แล้วจึงส่ง

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

ข้อจำกัดที่สำคัญอย่างหนึ่งคือ: การนำเข้า WSDL ได้รับการบันทึกไว้สำหรับการอัปโหลดไฟล์ .wsdl และ .xml การนำเข้า WSDL ด้วย URL หรือการวางเนื้อหาไม่ได้มีการระบุไว้ในเอกสาร ดังนั้นให้อัปโหลดไฟล์แทนที่จะคาดหวังช่องสำหรับ URL

จาก SoapUI

หากการทดสอบ SOAP ของคุณอยู่ใน SoapUI อยู่แล้ว คุณไม่จำเป็นต้องสร้างใหม่ตั้งแต่ต้น ส่งออกหรือเก็บ WSDL ของคุณไว้ จากนั้นนำเข้าลงใน Apidog ด้วยวิธี B และคุณจะได้รับการดำเนินการเดียวกันเป็น endpoint ที่เรียกใช้ได้ภายใน Workspace ที่รองรับการออกแบบ, การจำลอง (mocking) และเอกสารประกอบด้วย ประโยชน์ที่ได้คือการรวมศูนย์: โปรเจกต์เดียวสามารถเก็บบริการ SOAP, REST endpoint และสถานการณ์ทดสอบของคุณได้ แทนที่จะกระจายไปในเครื่องมือที่แยกจากกัน การเปรียบเทียบ Apidog กับ SoapUI ของเราจะอธิบายว่าอะไรที่สามารถถ่ายโอนได้และขั้นตอนการทำงานแตกต่างกันอย่างไร

การยืนยันและการปรับเปลี่ยน

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

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

สำหรับ endpoint ที่มีการรักษาความปลอดภัย SOAP มักใช้ WS-Security สำหรับการเข้ารหัสข้อความและการยืนยันตัวตน Header ความปลอดภัยนั้นเป็นส่วนหนึ่งของ SOAP envelope ที่คุณส่งไป ดังนั้นคุณจึงเพิ่มบล็อกความปลอดภัย wsse ภายใน Header ของ envelope ควบคู่ไปกับการดำเนินการของคุณ กลไกการส่งยังคงเหมือนเดิม: ตั้งค่า Content-Type, ใส่ envelope แบบเต็ม รวมถึง Header ความปลอดภัยใน XML body แล้วส่ง

ทำให้ขั้นตอนการทำงานเป็นอัตโนมัติด้วย Apidog CLI

เมื่อคำขอ SOAP หรือ WSDL ที่นำเข้าของคุณถูกบันทึกเป็นสถานการณ์ทดสอบแล้ว Apidog CLI จะเรียกใช้จากบรรทัดคำสั่ง เพื่อให้ Pipeline สามารถดำเนินการได้ทุกครั้งที่มีการ Push ติดตั้งด้วย Node.js v16 หรือใหม่กว่า จากนั้นทำการยืนยันตัวตน:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

เรียกใช้สถานการณ์ที่บันทึกไว้ด้วย ID โดยเทียบกับสภาพแวดล้อมที่ WSDL ของคุณสร้างขึ้น:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

ในที่นี้ -t คือ ID ของสถานการณ์ทดสอบ, -e คือ ID ของสภาพแวดล้อม และ -r คือ Reporter (cli, html หรือ junit โดยคั่นด้วยเครื่องหมายจุลภาคสำหรับหลายตัว) ข้อควรระวังที่สำคัญ: เอกสารยืนยันว่า Runner จะดำเนินการสถานการณ์ทดสอบและชุดทดสอบที่บันทึกไว้ แต่ไม่ได้ระบุว่าสถานการณ์ที่สร้างขึ้นจากขั้นตอน SOAP สามารถทำงานแบบ Headless ได้หรือไม่ ดังนั้นให้ถือว่า CLI เป็นเครื่องมือสำหรับสถานการณ์ HTTP ของโปรเจกต์ และสำหรับการรักษา Endpoint ที่นำเข้าจาก WSDL ให้ซิงค์กันใน CI แทนที่จะสมมติการดำเนินการเฉพาะ SOAP การเชื่อมต่อเข้ากับ Pipeline ครอบคลุมอยู่ใน คู่มือ Apidog CLI CI/CD ของเรา

คำถามที่พบบ่อย

ฉันควรใช้ Content-Type ใดสำหรับคำขอ SOAP? อาจเป็น text/xml; charset=utf-8 หรือ application/soap+xml ค่าที่ถูกต้องขึ้นอยู่กับบริการ: โดยทั่วไป SOAP 1.1 endpoint จะคาดหวังค่าแรก ส่วน SOAP 1.2 endpoint จะคาดหวังค่าที่สอง ตั้งค่าด้วยตนเองใน Header ของคำขอ และหากคุณได้รับข้อผิดพลาดเกี่ยวกับ Content-Type ให้เปลี่ยนไปใช้อีกค่าหนึ่ง

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

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

ฉันจะทดสอบทั้ง SOAP และ REST API ในโปรเจกต์เดียวกันได้อย่างไร? Apidog ถือว่าทั้งสองเป็นประเภทคำขอภายใน Workspace เดียว ดังนั้นโปรเจกต์เดียวสามารถเก็บการดำเนินการ SOAP ควบคู่ไปกับ REST endpoint และแม้กระทั่งการเรียก GraphQL ได้ หากคุณใช้งาน GraphQL ด้วย คู่มือของเราเกี่ยวกับการ ทดสอบ GraphQL API ใน Apidog ครอบคลุมด้านนั้น และสถานการณ์ทดสอบสามารถเชื่อมโยงคำขอทั้งหมดเข้าด้วยกันได้

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

สรุป

การทดสอบ SOAP ไม่จำเป็นต้องหมายถึงการใช้เครื่องมือเก่าที่แยกต่างหาก ใน Apidog คุณสามารถเลือกส่ง envelope ด้วยตนเอง (ตั้งค่า Content-Type, ตั้งค่า Body เป็น xml, วาง envelope, อ่านการตอบกลับ XML) หรือนำเข้า WSDL และให้ Apidog สร้าง endpoint และสภาพแวดล้อมให้คุณ ทั้งสองวิธีนำไปสู่จุดเดียวกัน: การตรวจสอบซ้ำๆ ว่า Web Service ของคุณยังคงปฏิบัติตามสัญญา ดาวน์โหลด Apidog เวอร์ชัน 2.1.31 หรือสูงกว่า นำเข้า WSDL ของคุณ และนำบริการเก่าของคุณไปอยู่ภายใต้การทดสอบเดียวกับส่วนที่เหลือของ API ของคุณ