DEV Community

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

Posted on • Originally published at apidog.com

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

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

ลองใช้ Apidog วันนี้

Apidog รองรับ SOAP และ WebService ควบคู่กับ REST, GraphQL และ gRPC จึงจัดการบริการเก่าและ API สมัยใหม่ใน Workspace เดียวได้ บทความนี้ครอบคลุม 2 วิธี:

  1. ส่ง SOAP request ด้วยตนเอง
  2. นำเข้า WSDL เพื่อสร้าง endpoint และ environment อัตโนมัติ

หากต้องการเปรียบเทียบโปรโตคอลก่อนเริ่ม อ่าน REST, GraphQL, gRPC และ SOAP และดูโครงสร้างมาตรฐานได้จาก ข้อกำหนด SOAP ของ W3C

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

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

เมื่อทดสอบ SOAP ให้โฟกัส 3 จุด:

  • รูปแบบข้อความเป็น XML — ทั้ง request และ response เป็นเอกสาร XML ที่มีโครงสร้าง
  • มักส่งผ่าน HTTP/HTTPS — แต่ SOAP รองรับ transport อื่นได้เช่นกัน
  • โครงสร้างเข้มงวด — namespace, envelope, header และ body ต้องตรงตามสัญญาของบริการ

หากต้องการทบทวน XML ดู เอกสาร XML ของ MDN ได้

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

อ่านรายละเอียดเพิ่มเติมเกี่ยวกับ envelope และ XML ได้ที่ SOAP API และ XML

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

ก่อนส่ง SOAP หรือ WebService request ให้ตรวจสอบว่า Apidog เป็นเวอร์ชัน 2.1.31 หรือใหม่กว่า เพราะเวอร์ชันก่อนหน้านี้ไม่รองรับ

เตรียมข้อมูลต่อไปนี้ให้พร้อม:

  • URL ของ endpoint
  • ชื่อ operation ที่ต้องการเรียก
  • พารามิเตอร์ของ operation
  • ไฟล์ WSDL หากบริการมีให้

WSDL อธิบาย operation, input, binding และ service address ของบริการ SOAP ดูโครงสร้างมาตรฐานได้ที่ WSDL 2.0

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

ใช้วิธีนี้เมื่อคุณมี endpoint อยู่แล้ว และทราบ operation กับพารามิเตอร์ที่ต้องเรียก

ขั้นตอนที่ 1: ตั้งค่า Content-Type

SOAP ไม่อนุมาน header ให้เอง จึงต้องกำหนด Content-Type ในแท็บ Headers ของ request ด้วยตนเอง

ค่าที่พบบ่อยมี 2 แบบ:

text/xml; charset=utf-8
Enter fullscreen mode Exit fullscreen mode
application/soap+xml
Enter fullscreen mode Exit fullscreen mode

โดยทั่วไป:

เวอร์ชัน SOAP Content-Type ที่มักใช้
SOAP 1.1 text/xml; charset=utf-8
SOAP 1.2 application/soap+xml

ตรวจสอบ WSDL หรือเอกสารของบริการก่อน หากส่งแล้วได้ข้อผิดพลาดเกี่ยวกับ Content-Type ให้ตรวจสอบว่า endpoint ต้องการ SOAP เวอร์ชันใด

ขั้นตอนที่ 2: ตั้งค่า Body เป็น XML และวาง SOAP envelope

เลือก Body type เป็น xml แล้ววาง SOAP envelope ที่ประกอบด้วย:

  • Envelope สำหรับกำหนด namespace
  • Body สำหรับห่อ operation
  • element ของ operation และพารามิเตอร์

ตัวอย่างต่อไปนี้เรียก operation 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>
Enter fullscreen mode Exit fullscreen mode

จุดที่ต้องตรวจสอบ:

  • namespace xmlns:web ต้องตรงกับที่บริการกำหนด
  • ชื่อ operation ต้องตรงกับ WSDL
  • ชื่อและลำดับของพารามิเตอร์ต้องตรงกับสัญญา
  • soap:Body ต้องห่อ operation ทั้งหมด

อย่าเดา namespace เอง หากมี WSDL ให้ใช้ค่า namespace จาก WSDL เสมอ

ขั้นตอนที่ 3: ส่ง request และตรวจสอบ XML response

เมื่อส่ง request สำเร็จ response จะกลับมาเป็น SOAP envelope เช่น:

<?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>
Enter fullscreen mode Exit fullscreen mode

ตรวจสอบอย่างน้อย 3 อย่าง:

  1. response มี soap:Envelope และ soap:Body
  2. มี node response ของ operation เช่น NumberToWordsResponse
  3. ค่าใน result ตรงตามที่คาดหวัง เช่น NumberToWordsResult

รูปแบบเดียวกันนี้ใช้กับบริการอื่นได้ ตัวอย่างเช่น:

  • ConvertCurrency ส่ง fromCurrency, toCurrency, amount
  • GetOrderStatus ส่ง orderId
  • ตรวจสอบค่าที่คืนมาใน response node ของ operation นั้น

กลไกหลักไม่เปลี่ยน:

กำหนด Header → วาง XML envelope → ส่ง request → ตรวจสอบ response envelope
Enter fullscreen mode Exit fullscreen mode

ดูตัวอย่าง envelope และการตั้งค่าเพิ่มเติมได้ที่ webservice.apidog.io

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

หากบริการมี operation จำนวนมาก การพิมพ์ envelope ทีละรายการไม่ใช่วิธีที่เหมาะสม ให้ import WSDL เพื่อให้ Apidog อ่าน operation, input และ service address จากไฟล์

ทำตามขั้นตอนนี้:

  1. ไปที่ Settings
  2. เลือก Import Data
  3. เลือก WSDL
  4. อัปโหลดไฟล์ .wsdl หรือ .xml
  5. ตรวจสอบ preview ของ endpoint ที่ Apidog แยกวิเคราะห์
  6. เปิดแท็บ Environments และตรวจสอบ service address
  7. คลิก Confirm
  8. เลือก environment ที่นำเข้าจากมุมขวาบน
  9. ส่ง request

ตรวจสอบ service address ก่อนกด Confirm

ขั้นตอนนี้สำคัญ เพราะ service address ใน WSDL จะกลายเป็น Base URL ของ request ที่นำเข้า

หาก WSDL ชี้ไปยัง:

  • test server
  • staging server
  • host เก่าที่ไม่ได้ใช้งานแล้ว
  • URL ชั่วคราว

request ทั้งหมดอาจถูกส่งไปผิดปลายทาง ตรวจสอบค่าในแท็บ Environments ก่อนคลิก Confirm

เลือก environment ที่นำเข้าแล้วก่อนส่ง request

หลัง import แล้ว Apidog จะสร้าง environment ให้อัตโนมัติ และ Base URL จะถูกผูกไว้กับ environment นี้

หากไม่เลือก environment จากมุมขวาบน request อาจไม่มี Base URL และล้มเหลวได้

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

หากกำลังย้ายโปรเจกต์ SOAP ทั้งหมด อ่าน คู่มือนำเข้าโปรเจกต์ SOAP

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

ย้ายจาก SoapUI

หากมี SOAP test อยู่ใน SoapUI แล้ว ไม่จำเป็นต้องสร้างใหม่ทั้งหมด ให้เก็บหรือ export WSDL แล้ว import เข้า Apidog ด้วยวิธี B

ผลลัพธ์คือ operation เดิมจะกลายเป็น endpoint ที่เรียกใช้ได้ใน Workspace เดียวกับ:

  • REST endpoint
  • GraphQL request
  • mock
  • เอกสาร API
  • test scenario

อ่านรายละเอียดการย้ายและความแตกต่างของ workflow ได้ที่ Apidog กับ SoapUI

เพิ่มการยืนยันผลลัพธ์และสร้าง test scenario

การเรียกสำเร็จหนึ่งครั้งเพียงพิสูจน์ว่า endpoint ตอบกลับได้ แต่ยังไม่ยืนยันว่าผลลัพธ์ถูกต้องตามสัญญา

สำหรับ SOAP response ให้เพิ่มการตรวจสอบที่ระดับ response envelope:

  • ตรวจสอบว่ามี response node ที่คาดหวัง
  • ดึงค่า result node
  • เปรียบเทียบค่ากับ expected value หรือเงื่อนไขที่ยอมรับได้

ตัวอย่างเงื่อนไขที่ควรทดสอบ:

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

จากนั้นสร้าง test scenario ที่เชื่อม request หลายรายการเข้าด้วยกัน เช่น:

CreateOrder → เก็บ orderId → GetOrderStatus → ตรวจสอบสถานะ
Enter fullscreen mode Exit fullscreen mode

อ่านวิธีส่งค่าจาก request หนึ่งไปยังอีก request ได้ที่ เขียนสถานการณ์ทดสอบด้วย Apidog

รูปแบบนี้ไม่ขึ้นกับโปรโตคอล คุณจึงสามารถผสม SOAP call กับ REST endpoint ใน scenario เดียวกันได้

กรณีใช้ WS-Security

SOAP endpoint ที่มีการรักษาความปลอดภัยมักใช้ WS-Security สำหรับการยืนยันตัวตนหรือเข้ารหัสข้อความ

ในกรณีนี้ ให้เพิ่ม block wsse ลงใน SOAP Header ของ XML envelope ตัวอย่างโครงสร้างคือ:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <!-- wsse security block -->
  </soap:Header>
  <soap:Body>
    <!-- operation -->
  </soap:Body>
</soap:Envelope>
Enter fullscreen mode Exit fullscreen mode

ขั้นตอนการส่งยังเหมือนเดิม:

  1. กำหนด Content-Type
  2. ตั้ง Body เป็น xml
  3. ใส่ SOAP envelope แบบเต็ม รวม Header ความปลอดภัย
  4. ส่ง request
  5. ตรวจสอบ response หรือ SOAP fault

ทำงานอัตโนมัติด้วย Apidog CLI

เมื่อบันทึก request หรือ scenario แล้ว คุณสามารถใช้ Apidog CLI เรียกใช้งานจาก command line เพื่อเชื่อมต่อกับ pipeline ได้

ติดตั้งด้วย Node.js v16 หรือใหม่กว่า:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Enter fullscreen mode Exit fullscreen mode

รัน test scenario โดยระบุ scenario และ environment:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

ความหมายของ option:

Option ความหมาย
-t ID ของ test scenario
-e ID ของ environment
-r reporter เช่น cli, html, junit

หากต้องการหลาย reporter ให้คั่นด้วยเครื่องหมายจุลภาค

เอกสารยืนยันว่า Runner สามารถรัน test scenario และ test suite ที่บันทึกไว้ได้ อย่างไรก็ตาม เอกสารไม่ได้ระบุชัดเจนว่า scenario ที่สร้างจากขั้นตอน SOAP สามารถทำงานแบบ headless ได้หรือไม่ ดังนั้นควรตรวจสอบกับโปรเจกต์ของคุณก่อนนำไปใช้กับ CI โดยตรง

ดูตัวอย่างการเชื่อมต่อ pipeline ได้ที่ คู่มือ Apidog CLI CI/CD

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

ควรใช้ Content-Type ใดสำหรับ SOAP request?

ใช้ได้ทั้ง:

text/xml; charset=utf-8
Enter fullscreen mode Exit fullscreen mode

และ

application/soap+xml
Enter fullscreen mode Exit fullscreen mode

โดยทั่วไป SOAP 1.1 ใช้ค่าแรก และ SOAP 1.2 ใช้ค่าหลัง ตรวจสอบ WSDL หรือเอกสารของบริการก่อนส่ง request

ต้องใช้แพ็กเกจแบบชำระเงินเพื่อทดสอบ SOAP ใน Apidog หรือไม่?

ข้อกำหนดที่ระบุคือใช้ Apidog เวอร์ชัน 2.1.31 หรือใหม่กว่า ไม่มีข้อจำกัดเรื่องระดับการใช้งานหรือ self-hosting ที่ระบุไว้สำหรับ SOAP หรือ WSDL

นำเข้า WSDL จาก URL ได้หรือไม่?

เอกสารระบุการอัปโหลดไฟล์ .wsdl และ .xml การนำเข้าผ่าน URL หรือการวางเนื้อหา WSDL ไม่ได้ระบุไว้ ดังนั้นควรอัปโหลดไฟล์

จะทดสอบ SOAP และ REST ในโปรเจกต์เดียวกันได้อย่างไร?

Apidog รองรับ request หลายประเภทภายใน Workspace เดียว คุณสามารถเก็บ SOAP operation, REST endpoint และ GraphQL request ไว้ในโปรเจกต์เดียว และเชื่อมทั้งหมดผ่าน test scenario ได้

หากใช้ GraphQL ด้วย อ่าน ทดสอบ GraphQL API ใน Apidog

WSDL ที่นำเข้าทำให้ request ส่งไปยังเซิร์ฟเวอร์ผิดตัว ต้องตรวจสอบอะไร?

ตรวจสอบ 2 จุด:

  1. service address ในแท็บ Environments ถูกต้องก่อนกด Confirm
  2. เลือก environment ที่นำเข้าจากมุมขวาบนก่อนส่ง request

หาก address ใน WSDL ไม่ถูกต้อง ให้แก้ไขและนำเข้าใหม่ หรือปรับค่า environment ให้ชี้ไปยังปลายทางที่ต้องการ

สรุป

การทดสอบ SOAP ไม่จำเป็นต้องใช้เครื่องมือแยกต่างหากเสมอไป ใน Apidog คุณเลือกได้ระหว่าง:

  • ส่ง envelope ด้วยตนเอง: กำหนด Content-Type, ตั้ง Body เป็น xml, วาง envelope และตรวจสอบ XML response
  • นำเข้า WSDL: ให้ Apidog สร้าง endpoint และ environment จากไฟล์

ไม่ว่าจะใช้วิธีใด เป้าหมายคือทำให้การตรวจสอบ Web Service ทำซ้ำได้ และยืนยันได้ว่าบริการยังคงปฏิบัติตามสัญญาเดิม

ดาวน์โหลด Apidog เวอร์ชัน 2.1.31 หรือใหม่กว่า นำเข้า WSDL หรือสร้าง SOAP request แรกของคุณ แล้วรวมการทดสอบบริการเก่าเข้ากับ API workflow เดียวกัน

Top comments (0)