Thực đơn
trang chủTiểu sử

Kiểm tra các dịch vụ web. Nắm vững việc kiểm tra API SOAP. Sử dụng các dịch vụ SOAP bên ngoài

Sử dụng Công cụ xác thực dịch vụ web cho WSDL và SOAP

Có vẻ như với sự ra đời của các công nghệ và tiêu chuẩn mới như XML và HTTP, các dịch vụ Web đã đảm bảo được vị trí của mình trong đền thờ đổi mới Internet. Nhưng sự đổi mới này diễn ra như thế nào?

Khái niệm cơ bản về dịch vụ Web có thể bắt nguồn từ giữa những năm 1960 tại Hoa Kỳ. Ví dụ, trong ngành vận tải, ở các công ty đường sắt và vận tải biển, một khái niệm mới về trao đổi dữ liệu điện tử giữa các máy tính đã được đưa ra, khái niệm này sau đó đã phát triển thành công nghệ EDI (Trao đổi dữ liệu điện tử). Lần đầu tiên tôi nghe về EDI từ một giáo sư trường kinh doanh vào năm 1980.

Năm 1996, Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ đã công bố tiêu chuẩn cho EDI trong Ấn phẩm Tiêu chuẩn Xử lý Thông tin Liên bang (FIPS PUB 161-2). Theo thông số kỹ thuật đã được công bố, EDI là một tiêu chuẩn để trao đổi các tin nhắn có định dạng chặt chẽ giữa các máy tính. Các tin nhắn đã nhận chỉ được xử lý bởi máy tính và những tin nhắn này thường không nhằm mục đích giải thích cho con người. Đó chính xác là những gì các dịch vụ Web làm, ngoại trừ việc XML, Internet và World Wide Web chưa tồn tại vào giữa những năm 1960.

Đối với những ai chưa hiểu rõ lắm về các dịch vụ Web, tôi sẽ ôn lại ngắn gọn các định nghĩa và các thành phần chính của dịch vụ Web.

Dịch vụ web là gì

Dịch vụ Web là một hệ thống phần mềm được thiết kế để hỗ trợ các tương tác giữa máy với máy giữa các tài nguyên máy tính qua mạng và sử dụng các thông báo SOAP (Giao thức truy cập đối tượng đơn giản) do World Wide Web Consortium xác định.

Giao thức truy cập đối tượng đơn giản (SOAP) là một giao thức đơn giản, có thể mở rộng để trao đổi các tin nhắn có cấu trúc và được nhập trong môi trường mạng phân tán, phi tập trung. Thông báo SOAP được viết bằng Ngôn ngữ đánh dấu mở rộng (XML), một định dạng văn bản đơn giản và linh hoạt bắt nguồn từ Ngôn ngữ đánh dấu tổng quát tiêu chuẩn (SGML), được phát triển bởi Tổ chức tiêu chuẩn hóa quốc tế (ISO 8879:1986).

Ngôn ngữ mô tả dịch vụ web (WSDL) là ngôn ngữ dựa trên XML mô tả giao diện của các dịch vụ web.

Điều gì xảy ra khi các tin nhắn SOAP không hợp lệ được trao đổi? Điều gì sẽ xảy ra nếu một thông báo SOAP sai được xử lý mà không có cảnh báo và thậm chí được sử dụng để tạo ra thông tin ra quyết định?

Trong thực tế, không thể biết dữ liệu trong thông báo SOAP là đúng hay sai. Tuy nhiên, bạn có thể kiểm tra xem thông báo SOAP có chính xác hay không bằng cách xem định nghĩa giao diện hoặc WSDL của nó.

Trong thực tế, việc gỡ lỗi trong các thông báo SOAP là rất khó khăn. Nếu có bất kỳ lỗi nào trong thông báo SOAP, mã phản hồi HTTP 500 sẽ được nhận từ máy chủ dịch vụ Web không cung cấp thông tin chi tiết về phần nào của thông báo SOAP có vấn đề. Bạn có thể gặp phải tình huống thậm chí còn tồi tệ hơn khi nhận được phản hồi SOAP hợp lệ từ máy chủ dịch vụ Web mà không có bất kỳ thông báo lỗi nào và cả bạn cũng như máy chủ dịch vụ Web của bạn đều không thể hiểu được vấn đề trong các yêu cầu và phản hồi SOAP của bạn. Ví dụ: bạn muốn yêu cầu báo giá cổ phiếu hiện tại cho Công ty B, nhưng bạn đã gửi một thông báo SOAP có thẻ được ghi không chính xác tới máy chủ dịch vụ Web. Máy chủ dịch vụ Web có thể bỏ qua các thẻ không chính xác và cung cấp một giá trị mặc định trong thông báo phản hồi SOAP, chẳng hạn như giá cổ phiếu của Công ty A. Nếu điều này không bị phát hiện, hậu quả có thể rất thảm khốc.

Bạn có thể chủ động ngăn chặn những loại sự cố này bằng cách sử dụng Công cụ xác thực dịch vụ web cho WSDL và SOAP. Nó cho phép bạn xác thực các thông báo SOAP bằng Ngôn ngữ định nghĩa dịch vụ web (WSDL) trước khi triển khai các ứng dụng sử dụng dịch vụ Web. Chương trình phân tích cú pháp và tính chính xác của các thông báo SOAP của bạn với WSDL và gắn cờ các vấn đề bằng cách báo cáo lỗi và số dòng một cách chi tiết. Kết quả là bạn không còn nhận được các tin nhắn HTTP 500 gây phiền nhiễu nữa. Các tin nhắn SOAP của bạn có được mã hóa không? Không có gì. Chương trình sẽ giải mã chúng và kiểm tra tính chính xác của các thông báo SOAP được giải mã.

Chương trình này được tạo ra để giúp nhân viên hỗ trợ Dịch vụ Web của IBM giải quyết các vấn đề liên quan đến dịch vụ Web trên Máy chủ Ứng dụng WebSphere của IBM® được khách hàng trên toàn thế giới báo cáo. Chương trình được thiết kế để kiểm tra tính chính xác của các thông báo SOAP. Nếu thông báo SOAP có chữ ký điện tử thì chương trình cũng sẽ kiểm tra điều đó. Với Công cụ xác thực dịch vụ web cho WSDL và SOAP, bạn thậm chí có thể gửi tin nhắn SOAP đến máy chủ dịch vụ web và nhận tin nhắn phản hồi SOAP. Chương trình được tạo ra nhằm loại bỏ các vấn đề trong quá trình vận hành công nghiệp bằng cách sử dụng nó trong giai đoạn phát triển ban đầu, cũng như giảm thời gian giải quyết các vấn đề phát sinh trong quá trình vận hành.

Chúng ta sẽ tạo một dịch vụ Web rất đơn giản. Đầu tiên chúng ta sẽ tạo một ứng dụng Java™ đơn giản. Sau khi thử nghiệm ứng dụng Java, chúng ta sẽ sử dụng IBM Rational® Application Developer cho Phần mềm WebSphere® để tạo ra một dịch vụ Web. Tiếp theo chúng ta sẽ thực hiện một số thay đổi đối với dịch vụ Web được tạo ra. Cuối cùng, chúng tôi sử dụng Công cụ xác thực dịch vụ web cho WSDL và SOAP để tạo, xác thực, gửi và nhận các thông báo SOAP.

Bạn có thể tạo một dịch vụ Web đơn giản bằng cách sử dụng IBM Rational Application Developer cho Phần mềm WebSphere. Dịch vụ web có thể được tạo theo hai cách:

  1. Phát triển từ trên xuống là sự phát triển trong đó các lớp Java triển khai các dịch vụ Web được tạo ra từ WSDL.
  2. Phát triển từ dưới lên, trong đó một dịch vụ Web được tạo ra từ một hạt Java hoặc một hạt Java doanh nghiệp.

Trong ví dụ sau, chúng tôi triển khai một dịch vụ Web bằng phương pháp phát triển từ dưới lên. Đầu tiên chúng ta sẽ tạo một ứng dụng Java đơn giản. Tiếp theo, chúng ta sẽ tạo một hạt dịch vụ Web Java từ một ứng dụng Java bằng cách sử dụng IBM Rational Application Developer cho Phần mềm WebSphere.

Tạo một ứng dụng Java

Đầu tiên chúng ta sẽ tạo một ứng dụng Java đưa ra lời chào. Nếu không có tên nào được chỉ định, ứng dụng sẽ trả về dòng chữ "Xin chào, bạn!" Nếu một tên được cung cấp, ứng dụng sẽ trả về dòng chữ "Xin chào", theo sau là tên đó. Dưới đây là mã cho ứng dụng Java DemoWebService có trong gói demo. Phương thức hello() trả về một chuỗi tùy thuộc vào tên.

Liệt kê 1. DemoWebService.java
/* * @author: Jinwoo Hwang * Copyright 2010 IBM Corporation */ gói demo; public class DemoWebService ( public String hello(String name) ( if (name == null) return "Xin chào, bạn thân!"; ngược lại return "Xin chào, " + name + "!"; ) )

Kiểm thử một ứng dụng Java

Điều rất quan trọng là phải kiểm tra một ứng dụng Java trước khi tạo một dịch vụ Web từ nó. Để chạy ứng dụng, bạn có thể viết một lớp bằng phương thức main(). Bạn cũng có thể sử dụng chức năng Universal Test Client do IBM Rational Application Developer v7 cung cấp để kiểm tra nhanh mà không cần viết mã kiểm tra. Chỉ cần chọn Máy khách thử nghiệm phổ quát từ menu ngữ cảnh của lớp Java để khởi chạy Máy khách thử nghiệm.

  1. Trong Universal Test Client, hãy mở rộng Đối tượng > DemoWebService.
  2. Chọn phương pháp Xin chào.
  3. Nhập một chuỗi hoặc tên của bạn vào trường Giá trị và nhấn nút Gọi.

Bạn cũng có thể chạy thử nghiệm với tham số null và xem điều gì sẽ xảy ra. Nếu một tham số null được truyền vào phương thức hello() thì chuỗi "Xin chào, bạn thân!" sẽ được trả về như mong đợi.


Tạo một dịch vụ web

Cho đến nay mọi thứ đang hoạt động tốt. Hãy bắt đầu tạo một dịch vụ Web từ một lớp Java bằng cách sử dụng phương pháp phát triển dịch vụ Web từ dưới lên.

  1. Chọn ứng dụng Java DemoWebService và tạo một dịch vụ Web mới từ IBM Rational Application Developer.

  1. Vì chúng ta đã tạo một lớp Java nên hãy chọn Dịch vụ web Java Bean từ dưới lên trong danh sách loại dịch vụ Web. Lựa chọn Bắt đầu ứng dụng khách và nhấn nút Hoàn thành. Nếu chúng ta có một lớp EJB, chúng ta cũng có thể viết một EJB (Java Enterprise Bean) để tạo ra một dịch vụ Web.

Nếu mọi thứ đều ổn, bạn sẽ thấy DemoWebServiceDelegate.java được tạo trong Tài nguyên Java bên cạnh DemoWebService.java.


Khi xem DemoWebServiceDelegate.java, bạn có thể tìm thấy chú thích dịch vụ Web Java @javax.jws.WebService, chú thích này chỉ định targetNamespace, serviceName và portName trong lớp DemoWebServiceDelegate. Một phiên bản của DemoWebService được tạo và một phương thức hello() khác được tạo từ phương thức DemoWebService hello(). Nếu bạn muốn tìm hiểu thêm về chú thích dịch vụ Web Java, hãy xem Yêu cầu đặc tả Java (JSR) 181: Siêu dữ liệu dịch vụ web cho nền tảng Java.

Liệt kê 2. DemoWebServiceDelegate.java
/* * @author: Jinwoo Hwang * Copyright 2010 IBM Corporation */ gói demo; @javax.jws.WebService(targetNamespace = "http://demo/", serviceName = "DemoWebServiceService", portName = "DemoWebServicePort") lớp công khai DemoWebServiceDelegate ( demo.DemoWebService _demoWebService = new demo.DemoWebService(); public String xin chào( Tên chuỗi) ( return _demoWebService.hello(name); ) )

Tạo WSDL

Trong dự án chương trình máy khách, bạn cũng có thể nhận thấy rằng các tệp DemoWebServiceService.wsdl và DemoWebServiceService_schema1.xsd đã được tạo. DemoWebServiceService.wsdl chứa thông tin bằng Ngôn ngữ định nghĩa dịch vụ web mô tả các dịch vụ mạng cho ứng dụng Java mà bạn đã tạo trước đó. DemoWebServiceService_schema1.xsd chứa một lược đồ XML mô tả cấu trúc của các kiểu dữ liệu được sử dụng trong các thông báo SOAP.


Khi nhìn vào tệp DemoWebServiceService.wsdl, bạn có thể thấy rằng nó có một tập hợp các phần tử định nghĩa ở gốc. Phần tử định nghĩa có 6 phần tử:

  • các loại (loại);
  • tin nhắn (tin nhắn);
  • portType(loại cổng);
  • ràng buộc;
  • dịch vụ (dịch vụ);
  • cổng (cảng).

Các loại xác định các loại dữ liệu được sử dụng trong trao đổi tin nhắn. Trong DemoWebServiceService.wsdl, chúng tôi nhập DemoWebServiceService_schema1.xsd thay vì xác định các kiểu dữ liệu trong tệp WSDL.

Tin nhắn xác định các thông điệp được trao đổi. Chúng tôi có 2 tin nhắn: "hello" và "helloResponse". Tin nhắn xin chào có một phần gọi là "tham số". Phần này có phần tử "tns:hello". Tin nhắn helloResponse có một phần gọi là "tham số" tương tự như hello. Phần này có phần tử "tns:helloResponse". Các phần tử hello và helloResponse được xác định trong tệp DemoWebServiceService_schema1.xsd. Chúng tôi sẽ xem xét chúng ngay sau đây.

Loại cổng– các hoạt động được hỗ trợ bởi các điểm cuối. Mỗi hoạt động cung cấp một thông báo đầu vào và đầu ra. Hoạt động "hello" của chúng tôi bao gồm thông báo đầu vào "tns:hello" và thông báo đầu ra "tns:helloResponse". Các hoạt động này tương ứng với một trao đổi yêu cầu-phản hồi. WSDL cung cấp 4 nguyên tắc trao đổi khác nhau cho điểm cuối:

  • một chiều (một chiều);
  • request-response (yêu cầu-phản hồi);
  • gạ gẫm đáp ứng (demand-response);
  • thông báo.

Trong trao đổi một chiều, điểm cuối chỉ nhận được tin nhắn. Trong trao đổi yêu cầu-phản hồi, điểm cuối nhận được tin nhắn và gửi tin nhắn tương ứng. Trong trao đổi yêu cầu-phản hồi, điểm cuối sẽ gửi tin nhắn và nhận tin nhắn tương ứng. Trong trao đổi "thông báo", điểm cuối chỉ gửi tin nhắn.

Ràng buộc xác định chi tiết giao thức và thông số kỹ thuật định dạng thông báo cho các hoạt động và thông báo dành riêng cho loại cổng. Đối với thuộc tính style, chúng tôi sử dụng giá trị tài liệu. Thuộc tính style cung cấp 2 kiểu thông báo khác nhau: rpc và document. Theo kiểu rpc, tin nhắn chứa tham số và giá trị trả về. Trong kiểu tài liệu, tin nhắn chứa tài liệu. Thuộc tính vận chuyển chỉ định URI cho việc vận chuyển SOAP. Giá trị được chỉ định http://schemas.xmlsoap.org/soap/http có nghĩa là đặc tả SOAP sẽ sử dụng liên kết HTTP. URI cho tiêu đề HTTP SOAPAction cho liên kết HTTP SOAP được chỉ định trong thuộc tính SoapAction. Vì liên kết HTTP SOAP được sử dụng nên giá trị của thuộc tính SoapAction là bắt buộc. Đối với thuộc tính SoapAction, chúng tôi sử dụng chuỗi trống "". Phần tử xà phòng: nội dung xác định cách sắp xếp các phần thông báo trong phần tử nội dung của thông báo SOAP. Thuộc tính use cung cấp 2 tùy chọn khác nhau: bằng chữ và được mã hóa. Chúng tôi sử dụng nghĩa đen. Điều này có nghĩa là chúng ta đã chọn xác định một lược đồ cụ thể bằng cách sử dụng thuộc tính type hoặc phần tử. Khi sử dụng tùy chọn được mã hóa, một loại trừu tượng có quy tắc mã hóa sẽ được sử dụng.

Dịch vụ xác định tập hợp các cổng sẽ sử dụng.

Hải cảng xác định điểm cuối giao tiếp bằng cách chỉ định địa chỉ mạng để liên kết.

địa chỉ mạng để ràng buộc. Trong trường hợp của chúng tôi, địa chỉ điểm cuối SOAP là http://localhost:9081/HelloWorldWSProject/DemoWebServiceService.

Liệt kê 3. DemoWebServiceService.wsdl

Tạo một lược đồ

Chúng tôi nhập DemoWebServiceService_schema1.xsd từ DemoWebServiceService.wsdl. Hãy xem tệp DemoWebServiceService_schema1.xsd. Nó được viết bằng ngôn ngữ định nghĩa Lược đồ XML để mô tả các ràng buộc về cấu trúc và nội dung của các tài liệu XML. Chúng ta có 2 phần tử: hello và helloResponse. Mỗi phần tử có một loại. Kiểu hello có phần tử "arg0" là một chuỗi. Phần tử "arg0" là tùy chọn vì giá trị của thuộc tính minOccurs trong phần khai báo của nó là 0. Nếu thuộc tính minOccurs được đặt thành 1 hoặc lớn hơn thì phần tử này phải được chỉ định. Điều tương tự cũng xảy ra với phần tử "return" trong loại helloResponse.

Liệt kê 4. DemoWebServiceService_schema1.xsd

Bắt đầu với Công cụ xác thực dịch vụ web cho WSDL và SOAP

Cho đến nay chúng ta đã xem xét WSDL và lược đồ. Chúng ta hãy khởi động máy chủ dịch vụ Web để có thể kích hoạt dịch vụ Web từ Công cụ xác thực dịch vụ web cho WSDL và SOAP.

Việc chạy Công cụ xác thực dịch vụ web cho WSDL và SOAP yêu cầu thời gian chạy Java 6 (hoặc cao hơn) và API mã hóa và giải mã kỹ thuật số XML tuân thủ các thông số kỹ thuật "Xử lý và cú pháp mã hóa XML" của World Wide Web Consortium (http://www. w3.org/TR/xmlenc-core/).

IBM Java 6 cung cấp cách triển khai JSR 106: API mã hóa kỹ thuật số XML. Nếu bạn đã cài đặt IBM Java 6 thì mọi thứ đã sẵn sàng hoạt động và bạn không cần phải cài đặt bất kỳ thứ gì khác.

Nếu môi trường thời gian chạy Java 6 của bạn, chẳng hạn như Sun Microsystems™ Java 6, không có API Mã hóa Kỹ thuật số XML, thì bạn phải cài đặt các thư viện triển khai JSR 106 hoặc gói Apache™ XML Security phiên bản 1.4.3, có thể tải xuống từ http: / /santuario.apache.org/. Chỉ cần tải xuống bản phân phối nhị phân, giải nén nó vào một thư mục và cho chương trình công cụ biết vị trí của thư mục đó bằng cách sử dụng các tùy chọn dòng lệnh -vmargs và -DAXS.

Theo văn bản này, Công cụ xác thực dịch vụ web cho WSDL và SOAP hỗ trợ JSR 106 và Apache XML Security phiên bản 1.4.3 để mã hóa và giải mã kỹ thuật số XML. Nếu bạn muốn xác minh chữ ký số trong thông báo SOAP, bạn cần các thư viện triển khai JSR 105: API chữ ký số XML. May mắn thay, các máy ảo Java 6 của Sun Microsystems và IBM cung cấp các triển khai JSR 105. Đây là lý do tại sao Java 6 được chọn làm yêu cầu tối thiểu cho môi trường thời gian chạy Java. Nếu môi trường Java 6 của bạn không cung cấp các thư viện triển khai JSR 105, bạn sẽ cần tìm chúng.

Bạn có thể tải xuống miễn phí Công cụ xác thực dịch vụ web cho WSDL và SOAP tại đây. Việc cài đặt nó rất đơn giản. Giải nén gói vào một thư mục và chạy wsvt.exe. Nếu Máy ảo Java mặc định của bạn không phải là môi trường Java 6 hỗ trợ chữ ký số XML cũng như mã hóa và giải mã kỹ thuật số, bạn phải chỉ định vị trí Java 6 bằng tùy chọn -vm, ví dụ:

wsvt –vm c:\IBMjava6\bin\java.exe

Một lần nữa, nếu bạn có IBM Java 6, bạn không cần cài đặt bất cứ thứ gì khác. Mọi thứ bạn cần đều đã có trong IBM Java 6. Nếu bạn đang sử dụng Java 6 từ Sun Microsystems, bạn phải trỏ chương trình đến vị trí của Apache XML Security để giải mã các thông báo SOAP được mã hóa.

Ví dụ: lệnh sau sẽ chạy một chương trình với thư viện Sun Java 6 và Apache XML Security phiên bản 1.4.3 nằm trong thư mục C:\xml-security-1_4_3\libs:

wsvt –vm c:\SUNjava6\bin\java.exe –vmargs –DAXS=C:\xml-security-1_4_3\libs

Dưới đây là danh sách các tệp thư viện bảo mật XML của Apache thực sự được Công cụ xác thực dịch vụ web sử dụng cho WSDL và SOAP, mặc dù phiên bản bảo mật XML của Apache 1.4.3 có 9 tệp jar:
commons-logging.jar;
serializer.jar;
xalan.jar;
xmlsec-1.4.3.jar.

Công cụ xác thực dịch vụ web cho WSDL và MANIFEST.MF của chương trình SOAP chứa thông tin sau:
Chính sách kích hoạt gói: lười
Bundle-ClassPath: .,
bên ngoài:$AXS$/commons-logging.jar,
bên ngoài:$AXS$/serializer.jar,
bên ngoài:$AXS$/xalan.jar,
bên ngoài:$AXS$/xmlsec-1.4.3.jar

Đây là lý do tại sao cần phải chỉ định –vmargs –DAXS=C:\xml-security-1_4_3\libs để Sun Java 6 giải mã các thông báo SOAP được mã hóa.

Tôi đã dành khá nhiều thời gian để khắc phục sự cố xung đột và không tương thích khi tải lớp giữa các lớp liên quan đến XML được tìm thấy trong thời gian chạy Sun Java, Apache XML Security và một số plugin Eclipse. Việc thiết lập thời gian chạy IBM Java thật dễ dàng vì thời gian chạy đi kèm với triển khai JSR 106 và không yêu cầu Bảo mật XML của Apache.

Tạo một dự án

Bây giờ, sau khi thiết lập và chạy chương trình công cụ, bạn có thể tạo một dự án mới. Một dự án có thể chứa tệp WSDL, nhiều tệp lược đồ được liên kết với tệp WSDL và các thông báo SOAP trong tệp XML. Nếu có nhiều tệp WSDL trong một dự án thì chỉ một trong số chúng được sử dụng và những tệp khác sẽ bị bỏ qua khi xác thực tệp XML thông báo SOAP. Để sử dụng tệp WSDL khác, bạn phải tạo một dự án riêng. Mọi thông báo SOAP phải được chứa trong một tệp có phần mở rộng .xml, nếu không nó sẽ không được coi là thông báo SOAP.

  1. Nhấp chuột phải và chọn Mới > Dự án.

  1. Lựa chọn Dự án V. Tổng quan.

  1. Nhập "Dự án thử nghiệm" vào trường Tên dự án và nhấn nút Hoàn thành.

Nhập WSDL và Lược đồ

Chúng tôi đã tạo ra "Dự án thử nghiệm". Bây giờ bạn có thể nhập WSDL và XSD vào đó.

  1. Chọn dự án và sau đó từ menu ngữ cảnh chọn Nhập khẩu.

  1. Lựa chọn Hệ thống tập tin V. Tổng quan.

  1. Chọn thư mục lưu trữ WSDL và XSD.
  2. Chọn 2 file (DemoWebServiceService.wsdl và DemoWebServiceService_schema1.xsd) rồi nhấn nút Hoàn thành.

Tổng quan về WSDL và Lược đồ

Bây giờ chúng tôi có một dự án với WSDL và XSD. Bạn có thể nhấp đúp vào nút chuột trái trên WSDL để xem WSDL ở chế độ Thiết kế và Nguồn. Trong chế độ Thiết kế, bạn có thể trực quan hóa một dịch vụ Web với dữ liệu đầu vào và đầu ra.


Ở chế độ Nguồn, bạn có thể xem và chỉnh sửa WSDL trong trình soạn thảo văn bản.


Nếu không thể mở tệp XSD trong trình soạn thảo XSD, chúng có thể được mở trong trình soạn thảo XML bằng cách chọn Mở bằng > Trình soạn thảo XML trong menu ngữ cảnh của tệp XSD này.


Chúng tôi đã mở DemoWebServiceService_schema1.xsd trong trình soạn thảo XML.


Tạo thông báo SOAP

Vì vậy, bây giờ chúng ta đã có WSDL và lược đồ sẵn sàng để xác thực các thông báo SOAP. Hãy bắt đầu thử nghiệm Công cụ xác thực dịch vụ web cho chương trình WSDL và SOAP bằng thông báo SOAP. Bạn phải đưa thông báo SOAP vào dự án của mình. Thông báo SOAP phải được chứa trong một tệp có phần mở rộng .xml để có thể xác minh tính chính xác của nó.

  1. Lựa chọn Mới > XMLđể tạo một thông báo SOAP trong một dự án.

  1. Lựa chọn Dự án thử nghiệm cho thư mục mẹ của thông báo SOAP mới. Nếu tệp chưa được chọn, hãy nhập "DemoSOAPMessage.xml" vào trường Tên tập tin và nhấn nút Hoàn thành.

Chương trình tự động gọi trình soạn thảo XML bằng một tệp XML mới. Không có gì trong đó ngoại trừ một dòng có mã hóa phiên bản và xml. Thật tốt khi chúng ta có ít nhất thứ gì đó trước khi bắt đầu tạo thông báo SOAP từ đầu. Bạn có biết cách soạn tin nhắn SOAP không? Đừng lo. Trong phần tiếp theo, chúng ta sẽ thực hiện các bước để tạo một tài khoản.


Để tạo tin nhắn SOAP, bạn có thể kích hoạt "xin chào" của dịch vụ bằng cách sử dụng tham số "tham số" có tên của tôi - "Jinwoo". Tất nhiên, bạn có thể sử dụng tên riêng của bạn. Không gian tên được sử dụng là http://demo/. Hãy cẩn thận - nó được viết là http://demo/, không phải http://demo, điều này rất quan trọng.

Liệt kê 5. HelloWorldSOAPmessage.xml
Jinwoo

Bạn có thấy bất kỳ vấn đề nào với thông báo SOAP này không? Nếu có, đừng lo lắng. Chúng ta sẽ giải quyết vấn đề này sau.


Gửi tin nhắn SOAP

Bạn đã sẵn sàng gửi tin nhắn tới máy chủ dịch vụ Web chưa?

  1. Chọn tin nhắn SOAP và chọn

  1. Trong cửa sổ Truyền yêu cầu SOAP và Nhận phản hồi SOAP, bạn có thể điền vào Địa chỉ dịch vụ, SOAPHành động Và Loại nội dung. Trong ứng dụng này, chúng tôi không cần chỉ định SOAPAction vì chúng tôi đã sử dụng chuỗi trống "" cho thuộc tính SoapAction trong phần liên kết của tệp DemoWebServiceService.wsdl.
  2. Nhập http://localhost:9081/HelloWorldWSProject/DemoWebServiceService vào trường Địa chỉ dịch vụ, nếu máy chủ đang chạy trên máy tính cục bộ trên cổng localhost:9081. Nếu không, bạn phải nhập địa chỉ thực nơi có dịch vụ Web.
  3. Lựa chọn văn bản/html cho lĩnh vực Loại nội dung.
  4. Nhấn vào nút ĐƯỢC RỒIđể gửi tin nhắn SOAP đến máy chủ.

Nhận được tin nhắn SOAP

Nếu máy chủ đang hoạt động, bạn sẽ nhận được phản hồi SOAP. Nếu bạn không nhận được phản hồi, hãy kiểm tra xem địa chỉ và loại nội dung có chính xác không.


Xác thực thông báo SOAP

Tuyệt vời! Chúng tôi đã chấp nhận phản hồi SOAP. Nó cũng được lưu trong dự án. Nhưng chờ đã. Bạn có thấy có điều gì đó không ổn? Chúng tôi nhận được "Xin chào, anh bạn!" thay vì "Xin chào, Jinwoo!" Đã xảy ra lỗi gì đó? Bạn không có manh mối?

Thật không may, máy chủ dịch vụ Web không cho chúng tôi biết điều gì đã xảy ra. Không có cảnh báo. Một tình huống trong đó các phản hồi SOAP không thể đoán trước được gửi đi và máy chủ dịch vụ Web không biết điều gì đang xảy ra có thể rất nguy hiểm. Ngay cả người nhận phản hồi SOAP cũng có thể không nhận thấy vấn đề trong thông báo SOAP được đề cập.

Công cụ xác thực dịch vụ web cho WSDL và SOAP giúp bạn xác định điều gì đang xảy ra.

Liệt kê 6. Phản hồi
Xin chào anh bạn!
  1. Chọn thông báo phản hồi SOAP và nhấp vào nút Xác thực.

Công cụ xác thực dịch vụ web cho WSDL và SOAP đã tìm thấy lỗi trong thông báo SOAP.

Thông báo SOAP không hợp lệ:cvc-complex-type.2.4.a:Đã tìm thấy nội dung không hợp lệ bắt đầu bằng phần tử "tham số". Một trong số "(arg0) được mong đợi.

Chỉnh sửa tin nhắn SOAP

  1. Chương trình phàn nàn về giá trị của "tham số". Thay đổi nó thành arg0 và lưu lại.
Liệt kê 7. Thông báo SOAP đã sửa đổi
Jinwoo
  1. Xác minh rằng thông báo phản hồi SOAP đã sửa đổi là chính xác. Không còn thông báo lỗi nào xuất hiện nữa.

  1. Bây giờ chúng tôi đã sẵn sàng gửi thông báo phản hồi đã sửa đổi đến máy chủ. Chọn thông báo SOAP rồi chọn Truyền yêu cầu SOAP và nhận phản hồi SOAP.

  1. Trong cửa sổ Truyền yêu cầu SOAP và nhận phản hồi SOAP, nhập http://localhost:9081/HelloWorldWSProject/DemoWebServiceService trong Địa chỉ dịch vụ, nếu máy chủ đang chạy trên cổng localhost:9081.
  2. Lựa chọn văn bản/html cho lĩnh vực Loại nội dung và nhấn nút ĐƯỢC RỒI.

Lần này, đúng như dự đoán, câu trả lời chính xác đã đến.


Liệt kê 8. Phản hồi SOAP
Xin chào Jinwoo!

Phát hiện không gian tên không hợp lệ

Điều gì xảy ra nếu bạn gửi tin nhắn có không gian tên sai?

  1. Thay đổi không gian tên thành http://demo2/ và lưu tin nhắn.

Liệt kê 9. Thay đổi không gian tên
Jinwoo
  1. Sau đó bạn có thể gửi yêu cầu đến máy chủ.

Bạn sẽ thấy IOException: Máy chủ trả về mã phản hồi HTTP:500 cho URI: http://localhost:9081/HelloWorldWSProject/DemoWebServiceService .


Máy chủ dịch vụ Web phản hồi với thông tin về IOException, nhưng thông tin này không đủ để phát hiện lỗi. Kiểm tra tính chính xác của thông báo bằng công cụ nếu bạn muốn biết thêm thông tin chi tiết để giải quyết vấn đề.


Chương trình báo cáo: "Thông báo SOAP không hợp lệ:cvc-complex-type.2.4.a:Đã tìm thấy nội dung không hợp lệ bắt đầu bằng phần tử 'ns0:hello". Dự kiến ​​sẽ có một trong số "("http://demo/":hello,"http://demo/":helloResponse)".

Thông báo này cho biết giá trị http://demo/ được mong đợi. Đó là điều chúng ta cần biết, chứ không phải mã phản hồi HTTP 500.


Xác thực các tin nhắn SOAP được mã hóa

Điều gì sẽ xảy ra nếu tin nhắn SOAP của bạn được mã hóa? Không có vấn đề gì nếu bạn có chìa khóa và mật khẩu. Chỉ cần chọn thông báo SOAP và Xác thực giống như bạn làm với bất kỳ tin nhắn SOAP thông thường nào khác. Nếu thông báo SOAP của bạn được mã hóa, bạn sẽ thấy lời nhắc tương tự như trong Hình 35.


Tại thời điểm viết bài này, 3 loại kho khóa được hỗ trợ:

  1. Kho lưu trữ khóa Java (JKS).
  2. Kho lưu trữ khóa mở rộng mật mã Java (JCEKS).
  3. Tiêu chuẩn cú pháp trao đổi thông tin cá nhân (Tiêu chuẩn mã hóa khóa công khai số 12).

Bạn phải cung cấp thông tin về kho khóa của mình: tên tệp, loại tệp và mật khẩu. Nếu thông tin chính xác, bạn phải chọn khóa và mật khẩu. Bạn cũng có thể tìm thông tin về kho khóa của mình cũng như danh sách khóa và chứng chỉ trong kho khóa, chẳng hạn như loại kho khóa, tên nhà cung cấp, phiên bản nhà cung cấp, thông tin nhà cung cấp, loại khóa, ngày tạo, loại chứng chỉ, thuật toán và định dạng.


Nếu tất cả thông tin đều chính xác, chương trình sẽ tạo thông báo SOAP được giải mã và kiểm tra tính chính xác của nó.


Các thuật toán mã hóa sau hiện được hỗ trợ:

  • Tiêu chuẩn mã hóa nâng cao (AES) ở chế độ Chuỗi khối mật mã (CBC) với vectơ khởi tạo (128/192/256 bit).
  • Mã hóa khóa theo tiêu chuẩn mã hóa nâng cao (AES) (128/192/256 bit).
  • Thuật toán mã hóa dữ liệu ba Phương thức hoạt động (triple-DES) Mã hóa khóa.
  • Thuật toán mã hóa dữ liệu ba chế độ hoạt động (triple-DES) Mã hóa khóa trong chế độ Chuỗi khối mã hóa (CBC).
  • Thông số kỹ thuật mật mã RSA Phiên bản 1.5.
  • Đệm mã hóa bất đối xứng tối ưu RSA (OAEP) là một phương pháp có chức năng tạo mặt nạ.

Xác thực các tin nhắn SOAP được ký điện tử

Điều gì xảy ra nếu tin nhắn SOAP của bạn được ký điện tử? Chỉ cần chọn thông báo SOAP và sau đó chọn Xác minh chữ ký số của tin nhắn SOAP.


Nếu chữ ký số đúng, bạn sẽ thấy màn hình sau:


Nếu không chương trình sẽ báo lỗi chữ ký. Các thông số kỹ thuật và thuật toán chữ ký số sau đây hiện được hỗ trợ:

  • Thuật toán băm an toàn 1 (SHA-1)
  • Mã xác thực tin nhắn băm (HMAC)
  • Thuật toán chữ ký số (DSA)
  • Tiêu chuẩn mật mã khóa công khai (PKCS #1)
  • Thuật toán mã hóa RSA với thuật toán băm an toàn (SHA-1)
  • Phiên bản XML chuẩn 1.0 và 1.1
  • Chuyển đổi XSL (XSLT) Phiên bản 1.0
  • Ngôn ngữ đường dẫn XML (XPath) Phiên bản 1.0
  • cơ sở64

Truy cập dịch vụ Cục Thời tiết Quốc gia Hoa Kỳ bằng tin nhắn SOAP

Dịch vụ Web đơn giản mà chúng tôi tạo và thử nghiệm hoạt động tốt. Chương trình này có thể được sử dụng trong môi trường "thực" không? Bạn có thể thử làm việc với dịch vụ Web thực tế của Cục Thời tiết Quốc gia Hoa Kỳ do Hoa Kỳ cung cấp. Cơ quan Khí quyển và Đại dương Quốc gia (NOAA).

  1. Tạo một dự án.

  1. Tạo XML thông báo SOAP.


Cục Thời tiết Quốc gia Hoa Kỳ cung cấp nhiều dịch vụ Web khác nhau. Bạn có thể thử làm việc với dịch vụ NDFDgenByDay, dịch vụ này cung cấp dự báo thời tiết cho một điểm có vĩ độ và kinh độ nhất định.

Để truy cập NDFDgenByDay, bạn phải cung cấp thông tin sau:

Bảng 1. NDFDgenByDay
Tên dịch vụNDFDgenByDay
Điểm cuốihttp://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php
SoapAction (Hành động SOAP)http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay
EncodingStyle (kiểu mã hóa)http://schemas.xmlsoap.org/soap/encoding/
Không gian tênhttp://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl
vĩ độ (vĩ độ)Số thập phân
kinh độ (kinh độ)Số thập phân
ngày bắt đầu (ngày bắt đầu)ngày
numNgày (số ngày)số nguyên
định dạngĐường kẻ

Trong ví dụ này, chúng tôi muốn tạo một yêu cầu SOAP để nhận dự báo hàng tuần cho một khu vực có tọa độ (LAT38.9,LON-77.01), bắt đầu từ 23/07/2010 ở định dạng 24 giờ:

Liệt kê 10. Yêu cầu SOAP
38.99 -77.01 2010-07-23 7 24 giờ

Chúng tôi không chỉ định vùng chứa tên vì dịch vụ hoạt động mà không có vùng chứa tên đó. Nếu bạn có bất kỳ vấn đề nào với không gian tên, hãy hỏi nó.


Chọn một tin nhắn và Truyền yêu cầu SOAP và nhận phản hồi SOAP trong Công cụ xác thực dịch vụ web cho WSDL và SOAP.

Bảng 2. Yêu cầu thông tin
TênNghĩa
Điểm cuốihttp://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php
SoapAction (Hành động SOAP)http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay
Loại nội dungvăn bản/xml; bộ ký tự=utf-8

Giờ đây, dữ liệu dự báo đã trở nên dễ đọc hơn nhiều.


Nếu lời khuyên này có vẻ không thuận tiện cho bạn, bạn có thể sử dụng phương pháp định dạng HTML của riêng mình. Hầu hết các dịch vụ Web đều cung cấp kết quả ở định dạng XML, do đó bạn sẽ không phải lúc nào cũng phải sử dụng đến kỹ thuật này.

Phần kết luận

Chúng tôi đã tạo, chuyển đổi, chấp nhận và xác thực các thông báo SOAP bằng Công cụ xác thực dịch vụ web cho WSDL và SOAP. Chương trình này cho phép bạn xác định chính xác các vấn đề mà hầu hết các máy chủ dịch vụ Web thậm chí không thể phát hiện ra, điều này có thể dẫn đến hậu quả nghiêm trọng trong đời thực. Sử dụng chương trình này ở giai đoạn phát triển cho phép bạn giảm thời gian khắc phục sự cố trong quá trình vận hành.

SOAP (Giao thức truy cập đối tượng đơn giản) là một giao thức được tiêu chuẩn hóa để truyền tin nhắn giữa máy khách và máy chủ. Nó thường được sử dụng cùng với HTTP(S), nhưng cũng có thể hoạt động với các giao thức lớp ứng dụng khác (chẳng hạn như SMTP và FTP).
Kiểm thử SOAP từ quan điểm kỹ thuật kiểm thử về cơ bản không khác gì làm việc với các API khác, nhưng nó đòi hỏi sự chuẩn bị sơ bộ (về mặt lý thuyết giao thức) và các công cụ kiểm thử đặc biệt. Trong bài viết này, tôi muốn xây dựng một danh sách kiểm tra nhỏ về kiến ​​thức và kỹ năng cần thiết, sẽ hữu ích như nhau cho cả người kiểm tra SOAP (người thường không biết phải nắm lấy gì sau khi đặt nhiệm vụ) và cho người quản lý. buộc phải đánh giá kiến ​​thức của người thử nghiệm và xây dựng kế hoạch đào tạo.

Cơ sở lý thuyết

Thực tế rằng SOAP là một giao thức có rất nhiều ý nghĩa đối với việc thử nghiệm: bạn cần nghiên cứu bản thân giao thức đó, các tiêu chuẩn và giao thức "chính" mà nó dựa trên đó và (nếu cần) các phần mở rộng hiện có.

XML
XML là một ngôn ngữ đánh dấu tương tự như HTML. Bất kỳ tin nhắn nào được gửi/nhận qua SOAP đều là một tài liệu XML trong đó dữ liệu được cấu trúc thuận tiện và dễ đọc, ví dụ:



Julia
Natasha
Lời nhắc nhở
Đừng quên viết một bài báo!

Bạn có thể tìm hiểu thêm về XML tại w3schools hoặc codenet (bằng tiếng Nga). Hãy nhớ chú ý đến mô tả các không gian tên (một phương pháp giải quyết xung đột khi mô tả các phần tử trong XML) - việc sử dụng chúng là bắt buộc trong SOAP.

XSD
Khi làm việc, sẽ rất thuận tiện nếu có một mô tả chuẩn hóa về các tài liệu XML có thể có và kiểm tra xem chúng có điền chính xác hay không. Có một Định nghĩa Lược đồ XML (hoặc gọi tắt là XSD) cho mục đích này. Hai tính năng chính của XSD dành cho người thử nghiệm là mô tả các loại dữ liệu và áp đặt các hạn chế đối với các giá trị có thể có. Ví dụ: phần tử từ ví dụ trước có thể được đặt thành tùy chọn và giới hạn ở 255 ký tự bằng XSD:

...







...

Tiện ích mở rộng SOAP
Trong công việc của mình, bạn cũng có thể gặp nhiều “phần mở rộng” khác nhau của SOAP - các tiêu chuẩn như WS-*. Một trong những phổ biến nhất là WS-Security, cho phép bạn làm việc với mã hóa và chữ ký điện tử. Thông thường, Chính sách WS được sử dụng cùng với nó, nhờ đó bạn có thể quản lý các quyền sử dụng dịch vụ của mình.

Ví dụ về sử dụng WS-Security:


Alice
6S3P2EWNP3lQf+9VC3emNoT57oQ=
YF6j8V/CAqi+1nRsGLRbuZhi
2008-04-28T10:02:11Z

Tất cả các phần mở rộng này đều là những cấu trúc khá phức tạp không được sử dụng trong mọi dịch vụ SOAP; nghiên cứu chi tiết của họ ở giai đoạn đầu để thành thạo thử nghiệm SOAP dường như không liên quan.

Công cụ

Như bạn đã hiểu, SOAP là một vấn đề nghiêm túc; để làm việc với nó, bạn cần biết lý thuyết và nhiều tiêu chuẩn. Trong thực tế, sự phức tạp như vậy sẽ dẫn đến chi phí lao động rất đáng kể (ví dụ: bạn sẽ phải xem sơ đồ trong sổ tay mỗi lần và gửi yêu cầu có đường cong). Vì vậy, các công cụ đã được tạo ra để làm việc với SOAP dễ dàng hơn.

Trình soạn thảo XML/XSD
Một người thử nghiệm giỏi bắt đầu thử nghiệm ở giai đoạn viết tài liệu, vì vậy sẽ rất thuận tiện khi sử dụng các trình soạn thảo đặc biệt để kiểm tra mạch. Hai cái nổi tiếng nhất là Oxygen (đa nền tảng) và Altova (chỉ dành cho Windows); cả hai đều được trả tiền. Đây là những chương trình rất mạnh mẽ mà các nhà phân tích tích cực sử dụng khi mô tả dịch vụ.

Trong thực tế của tôi, ba tính năng soạn thảo hóa ra lại hữu ích: trực quan hóa XSD, tạo XML dựa trên XSD và xác thực XML dựa trên XSD.

1. Trực quan hóa XSD cần thiết để thể hiện trực quan sơ đồ, cho phép bạn nhanh chóng xác định các thành phần và thuộc tính cần thiết cũng như các hạn chế hiện có. Ví dụ: đối với CheckTextRequest, thành phần văn bản là bắt buộc và cả ba thuộc tính đều là tùy chọn (với thuộc tính tùy chọn có giá trị mặc định là 0).

Việc trực quan hóa là cần thiết khi có nhiều loại và hạn chế trong sơ đồ. Nếu bạn chỉ cần điều này và không muốn trả tiền cho những biên tập viên đặc biệt thì bạn có thể xem xét các lựa chọn thay thế miễn phí (ví dụ: JDeveloper).

2. Tạo XML dựa trên XSD hữu ích khi bạn muốn xem một ví dụ hợp lệ về tin nhắn. Tôi sử dụng nó để nhanh chóng thử nghiệm khả năng hoàn thành tin nhắn và kiểm tra các sắc thái của cách hoạt động của các hạn chế.

3. Sau khi sử dụng tính năng từ điểm 2, sẽ rất hữu ích khi thực hiện Xác thực XML dựa trên XSD– tức là kiểm tra tính chính xác của tin nhắn. Cùng với nhau, tính năng 2 và 3 cho phép bạn phát hiện các lỗi phức tạp trong XSD ngay cả khi bản thân dịch vụ đang được phát triển.

Công cụ kiểm tra – SoapUI

Kiểm thử SOAP hầu như luôn liên quan đến việc sử dụng SoapUI. Bạn có thể đọc về cách sử dụng công cụ này từ nhiều nguồn khác nhau (,), nhưng sẽ hiệu quả nhất nếu đọc tài liệu chính thức. Tôi xác định 8 cấp độ thành thạo SoapUI có điều kiện:

Cấp độ 1 – Tôi có thể gửi yêu cầu
Tìm hiểu cách tạo một dự án dựa trên WSDL. SoapUI có thể tạo tất cả các truy vấn cần thiết cho bạn; Tất cả những gì bạn phải làm là kiểm tra xem chúng đã được điền chính xác chưa và nhấp vào nút “Gửi”. Khi đã phát triển các kỹ năng tạo truy vấn hợp lệ, bạn phải nắm vững nghệ thuật tạo truy vấn không chính xác gây ra lỗi.

Cấp độ 2 - Tôi có thể thực hiện Bộ kiểm thử và Trường hợp kiểm thử
Bắt đầu thực hiện các bài kiểm tra tự động nhỏ. Bộ công cụ kiểm thử và trường hợp kiểm thử cho phép bạn tạo tập lệnh kiểm thử API, chuẩn bị dữ liệu cho các yêu cầu và tự động kiểm tra phản hồi nhận được để đảm bảo phản hồi phù hợp với những gì mong đợi. Lúc đầu, chúng có thể được sử dụng đơn giản như một tập hợp các truy vấn. Ví dụ: nếu bạn đã tạo ra một lỗi và muốn kiểm tra nhanh sau khi sửa nó, bạn có thể phân bổ một bộ kiểm tra riêng dành riêng cho các yêu cầu lỗi.

Cấp độ 3 – Tôi có thể viết Lời khẳng định
Sau khi nắm vững các trường hợp thử nghiệm, sẽ rất hữu ích cho bạn khi tìm hiểu cách làm cho chúng có thể được kiểm chứng một cách tự động. Sau này, bạn sẽ không cần phải tìm kiếm thông tin về câu trả lời bằng mắt nữa: nếu có kiểm tra tự động, các trường hợp sẽ được đánh dấu màu xanh lá cây (nếu kiểm tra thành công) hoặc màu đỏ (nếu không vượt qua). SoapUI cung cấp một tập hợp lớn các xác nhận có thể có, nhưng những xác nhận thuận tiện và đơn giản nhất là Chứa và Không Chứa. Với sự trợ giúp của họ, bạn có thể kiểm tra sự hiện diện của văn bản cụ thể trong phản hồi nhận được. Những kiểm tra này cũng hỗ trợ tìm kiếm biểu thức chính quy.

Cấp độ 4 – sử dụng XPath và/hoặc XQuery trong Xác nhận
Đối với những người đã quen một chút với UI sử dụng Selenium thì ngôn ngữ XPath là một thứ quen thuộc. Nói một cách đại khái, XPath cho phép bạn tìm kiếm các phần tử trong tài liệu XML. XQuery là một công nghệ tương tự có thể sử dụng XPath trong nội bộ; ngôn ngữ này mạnh hơn nhiều, nó giống với SQL. Cả hai ngôn ngữ này đều có thể được sử dụng trong Assertions. Việc kiểm tra với sự trợ giúp của họ sẽ có mục tiêu và ổn định hơn, vì vậy trường hợp của bạn sẽ được đảm bảo hơn.

Cấp độ 5 – Tôi có thể viết các bài kiểm tra phức tạp bằng các bước đặc biệt

Các trường hợp thử nghiệm không chỉ có thể chứa một yêu cầu mà còn có thể chứa nhiều yêu cầu (ví dụ: khi bạn muốn mô phỏng kịch bản người dùng tiêu chuẩn “tạo thực thể” → “thực thể xuất khẩu”). Có thể có các bước đặc biệt khác giữa các yêu cầu, ví dụ:

  • Thuộc tính và Chuyển giao thuộc tính (giúp tái sử dụng dữ liệu và chuyển dữ liệu giữa các yêu cầu);
  • Yêu cầu JDBC (dùng để lấy dữ liệu từ cơ sở dữ liệu);
  • Goto có điều kiện (cho phép bạn tạo các nhánh hoặc vòng lặp trong trường hợp thử nghiệm);
  • Chạy TestCase (giúp đưa một số truy vấn điển hình vào các trường hợp thử nghiệm riêng biệt và gọi chúng khi cần thiết).

Cấp độ 6 – sử dụng tập lệnh Groovy

SoapUI cho phép bạn viết tập lệnh Groovy ở nhiều nơi khác nhau. Trường hợp đơn giản nhất là tạo dữ liệu trong chính truy vấn bằng cách sử dụng phần chèn $(=). Tôi sử dụng những phần chèn này mọi lúc:

  • $(=new Date().format(“yyyy-MM-dd'T'HH:mm:ss"))– để chèn ngày giờ hiện tại theo định dạng được yêu cầu;
  • $(=java.util.UUID.randomUUID())– để chèn GUID ngẫu nhiên được định dạng chính xác.

Các tập lệnh chính thức có thể được sử dụng làm các bước trong trường hợp và kiểm tra. Tại một thời điểm nào đó, bạn sẽ phát hiện ra rằng một số bước đặc biệt từ cấp độ thứ năm có thể được thay thế bằng một tập lệnh.

Cấp độ 7 – sử dụng MockServices
SoapUI dựa trên WSDL có thể tạo các đối tượng Mock. Đối tượng giả là mô phỏng đơn giản nhất của một dịch vụ. Với sự trợ giúp của “mô hình”, bạn có thể bắt đầu viết và gỡ lỗi các trường hợp kiểm thử ngay cả trước khi dịch vụ thực sự có sẵn để thử nghiệm. Chúng cũng có thể được sử dụng làm “sơ khai” cho các dịch vụ tạm thời không khả dụng.

Cấp 8 - Thần SoapUI
Bạn biết sự khác biệt giữa phiên bản SoapUI trả phí và miễn phí và sử dụng API SoapUI trong mã của mình. Bạn sử dụng plugin và chạy các trường hợp thông qua dòng lệnh và/hoặc CI. Các trường hợp thử nghiệm của bạn rất đơn giản và dễ bảo trì. Nói chung là bạn đã "ăn thịt chó" trên nhạc cụ này. Tôi rất muốn nói chuyện với người đã thành thạo SoapUI ở cấp độ này. Nếu bạn là một, hãy đăng ký trong phần bình luận!

Kiểm thử bằng ngôn ngữ lập trình

Dưới đây là ví dụ về giao diện của yêu cầu đối với API YandexSpeller, được thực hiện bằng groovy-wslite:

nhập wslite.soap.*
def client = SOAPClient mới("http://speller.yandex.net/services/spellservice?WSDL")
phản hồi def = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
thân hình (
CheckTextRequest("lang": "ru", "xmlns://speller.yandex.net/services/spellservice") (
văn bản ("lỗi")
}
}
}
khẳng định "lỗi" == reply.CheckTextResponse.SpellResult.error.s.text()
khẳng định "1" == [email được bảo vệ]()

Theo như tôi biết, chưa có framework cấp cao nào (như Rest-asured) để thử nghiệm SOAP, nhưng một công cụ thú vị gần đây đã xuất hiện - karate. Với sự trợ giúp của nó, bạn có thể mô tả các trường hợp thử nghiệm SOAP và REST dưới dạng tập lệnh như Cucumber / Gherkin. Đối với nhiều người thử nghiệm, chuyển sang karate sẽ là một giải pháp lý tưởng, bởi vì những tình huống như vậy, xét về độ phức tạp của việc viết và các trường hợp hỗ trợ, sẽ nằm ở đâu đó giữa việc sử dụng SoapUI và viết khuôn khổ của riêng bạn để thử nghiệm SOAP.

Phần kết luận

Có thể bạn sẽ không muốn thử nghiệm SOAP chỉ cho riêng mình (như bạn có thể làm với REST). Đây là một giao thức hạng nặng được sử dụng trong các giải pháp doanh nghiệp nghiêm túc. Nhưng độ nặng của nó đồng thời là một món quà dành cho người thử nghiệm: tất cả các công nghệ được sử dụng đều được tiêu chuẩn hóa và có các công cụ chất lượng cao để làm việc. Tất cả những gì người thử nghiệm yêu cầu là mong muốn học hỏi và sử dụng chúng.

Chúng ta hãy tập hợp cùng một danh sách kiểm tra các kỹ năng cần thiết cho một người thử nghiệm. Vì vậy, nếu bạn mới bắt đầu thử nghiệm các dịch vụ SOAP, bạn cần biết và có thể sử dụng:

  • WSDL.
  • XÀ BÔNG TẮM.
  • Trình soạn thảo XML/XSD (ở cấp độ trực quan hóa XSD).
  • SoapUI ở cấp 1.

Như bạn có thể thấy, trọng tâm chính là tìm hiểu các tiêu chuẩn; trong SoapUI chỉ cần có thể thực hiện các truy vấn là đủ. Khi đi sâu vào kiểm thử SOAP, bạn sẽ gặp phải các nhiệm vụ đòi hỏi những kỹ năng và kiến ​​thức nghiêm túc hơn, nhưng bạn không nên cố gắng học mọi thứ cùng một lúc. Tính nhất quán trong việc tăng mức độ phức tạp của các nhiệm vụ được thực hiện là quan trọng hơn nhiều. Bằng cách làm theo khuyến nghị này, một ngày nào đó bạn sẽ nhận ra rằng mình đã trở thành một chuyên gia giỏi trong lĩnh vực này!

Ngày nay, rất hiếm khi một ứng dụng hiện đại hoạt động mà không có API. Điều này đúng cho cả một trang web đơn giản và các hệ thống phân tán có tải trọng cao. Kiểm tra API là một trong những nhiệm vụ chính trong quy trình đảm bảo chất lượng. Không có gì đáng ngạc nhiên khi nhu cầu về người thử nghiệm biết cách kiểm tra API ngày càng tăng. Trong khóa học này, bạn sẽ hiểu rõ về các phương pháp, công cụ và cách tiếp cận trong thử nghiệm API, đồng thời có được kiến ​​thức cần thiết, điều này chắc chắn sẽ có tác động tích cực đến giá trị của bạn với tư cách là một chuyên gia thử nghiệm.

Khóa học này sẽ hữu ích cho những sinh viên đã quen với những kiến ​​thức cơ bản về kiểm thử phần mềm, những người muốn phát triển hơn nữa và cải thiện kỹ năng của mình.

Chương trình khóa học:

Bài học 1. Giới thiệu. Giao thức SOAP

  • Sơ lược về giảng viên;
  • Mục tiêu khóa học;
  • API, WS là gì và tại sao chúng cần thiết;
  • Vai trò của thử nghiệm API trong quy trình đảm bảo chất lượng;
  • Đánh giá các công cụ kiểm tra WS;
  • Các phương pháp được sử dụng trong thử nghiệm WS;
  • Lịch sử của SOAP;
  • Thuật ngữ và khái niệm chính (XML, XSD, Endpoint, WSDL).

Bài 2: Giao thức SOAP. Kiến trúc REST

  • Thuật ngữ và khái niệm chính (UDDI, XSLT, XPath, XQuery, phương thức HTTP, trạng thái HTTP);
  • Cấu trúc và các thành phần chính của SOAP;
  • Phạm vi áp dụng;
  • Đặc điểm công việc;
  • Ưu điểm và nhược điểm;
  • Đặc điểm của kiến ​​trúc REST;
  • Thuật ngữ và khái niệm chính (WADL, RESTful, JSON, JSONPath);
  • Nguyên tắc REST;
  • Mã trạng thái và các trạng thái chính;
  • Động từ CRUD;
  • Ưu điểm và nhược điểm.

Bài 3. Giới thiệu SoapUI. Làm việc với dự án REST

  • cài đặt Java;
  • Cài đặt SoapUI;
  • Tổng quan về các thành phần giao diện chính;
  • Kết nối một dự án giáo dục;
  • Xem xét các phương pháp dự án;
  • Gửi yêu cầu và phân tích phản hồi nhận được;
  • Nghiên cứu các dịch vụ web hiện có của dự án;
  • Lập kế hoạch kiểm tra;
  • Viết các trường hợp thử nghiệm;
  • Các phần tử “TestSuite”, “TestCase”, “TestSteps”.

Bài 4. Làm việc với dự án REST (XML)

  • Khối “Khẳng định”;
  • Chạy thử nghiệm ở nhiều cấp độ khác nhau;
  • Yếu tố “Thuộc tính”, khả năng chính;
  • Làm việc với Thuộc tính;
  • Yếu tố “Chuyển giao tài sản”;
  • Làm việc với các xác nhận.

Bài 5. Làm việc với dự án REST (JSON)

  • Điều kiện và chi nhánh;
  • Làm việc với các Xác nhận;
  • TestRunner, tính năng công việc;
  • Khởi chạy TS, TC từ dòng lệnh;
  • Làm việc với Test Runner;
  • Làm việc với tập lệnh Groovy.

Bài 6. Làm việc với tập lệnh Groovy

  • Làm việc với dữ liệu tĩnh và động;
  • Tạo dữ liệu thử nghiệm;
  • Chúng tôi lấy dữ liệu từ “Thuộc tính”;
  • Ghi và truyền dữ liệu;
  • Điều kiện và chi nhánh;
  • Khẳng định kịch bản.

Bài 7. Tính năng bổ sung

  • Kết nối các thư viện bên ngoài và các lớp tùy chỉnh;
  • Dịch vụ giả;
  • Tại sao cần có dịch vụ Mock;
  • Một ví dụ về làm việc với dịch vụ Mock;
  • Còn CI thì sao?
  • Cài đặt Jenkins;
  • Khởi động một dự án trên Jenkins.

Xin chào!

Trong một số bài viết, tôi sẽ nói về khả năng kiểm tra cách hoạt động của các dịch vụ web 1C bằng SoapUI. Tôi cũng sẽ đưa ra ví dụ về việc trả lại tài liệu ở định dạng PDF và các tệp xml phức tạp từ 1C. Một số điều tương tự như ở đây, tuy nhiên tôi sẽ xem xét các ví dụ phức tạp hơn khi làm việc với các dịch vụ web. Nhưng trước tiên, tôi sẽ xem xét từng bước quá trình khởi chạy các dịch vụ web và làm việc với SoapUI để giúp bạn dễ dàng hiểu chức năng của chúng hơn từ đầu.

1. Dịch vụ web đơn giản

Trước tiên, hãy lấy cấu hình wireframe không có dịch vụ web và thực hiện quy trình từng bước tạo chúng.

Hãy thêm một dịch vụ web mới có tên test1 và tạo một thao tác xin chào trong đó với kiểu trả về là chuỗi. Tốt hơn hết bạn nên luôn chỉ định tên của các dịch vụ và hoạt động web bằng tiếng Latinh.

Bạn cũng cần chỉ định URI không gian tên và tên tệp xuất bản:

Khi bạn nhấp vào kính lúp trong trường "Tên thủ tục", mô-đun dịch vụ web sẽ mở và bạn có thể triển khai chức năng xin chào.

Hàm hello() trả về "chuỗi từ dịch vụ web 1c"; Chức năng cuối cùng

2. Xuất bản một dịch vụ web.

Bây giờ, để chức năng kết quả có sẵn qua http, chúng tôi cần xuất bản dịch vụ của mình trên máy chủ web. Apache 2.2 phù hợp cho việc này. Tôi đã đọc các bài viết về cách thiết lập công việc với IIS và đối với tôi nó có vẻ phức tạp hơn nhiều. Sau khi cài đặt và chạy Apache 2.2, bạn cần vào menu Quản trị - Xuất bản lên máy chủ web. Trường thư mục phải được điền và chứa thư mục cài đặt Apache. Hãy nhớ các trường “tên” và “địa chỉ” của dịch vụ web, chúng sẽ hữu ích cho chúng ta trong bước tiếp theo.

3. Thử nghiệm với SoapUI

Để thử nghiệm, chúng tôi sẽ tạo một người dùng WsUser riêng biệt, với mật khẩu đơn giản và cấp cho nó toàn quyền.

Sau đó, cài đặt và khởi chạy SoapUI. Chương trình này rất thuận tiện cho việc thử nghiệm các dịch vụ web; nó có thể nhận mô tả của chúng và gửi yêu cầu tới các dịch vụ.

Đi tới menu Tệp - Dự án SOAP mới, đặt tên dự án hellotest và trong trường WSDL ban đầu viết liên kết sau:

http://localhost/test_ws/ws/test1.1cws?wsdl

Trong đó, phần “test_ws” đã được chỉ định ở giai đoạn trước trong trường “name” và test1.1cws trong trường “address”.

Nhấp vào OK và ở giai đoạn này, bạn sẽ cần đăng nhập bằng cách đăng nhập dưới tên người dùng thử nghiệm WsUser. Một dự án và hai yếu tố ràng buộc sẽ được tạo ra.

Soap12Binding khác biệt ở chỗ nó hoạt động theo phiên bản mới của chuẩn SOAP 1.2. Hãy mở phần tử request1 trong test1Soap12Binding và xem điều này:

SoapUI hiển thị xml nào sẽ được chuyển đến hàm của chúng ta. Còn một sắc thái nữa trước khi chạy thử nghiệm; theo mặc định, SoapUI sẽ yêu cầu ủy quyền cho từng thành phần Yêu cầu riêng lẻ. Do đó, để không thiết lập nó mọi lúc, bạn cần nhấp chuột phải vào testSoap12Binding, chọn Hiển thị chế độ xem giao diện và trong cửa sổ mở ra, trên tab “Điểm cuối dịch vụ”, đặt tên người dùng và mật khẩu dịch vụ web:

Nếu điều này không được thực hiện thì đối với mỗi Yêu cầu, bạn sẽ cần đặt ủy quyền bằng nút Xác thực ở bảng dưới cùng.

Bây giờ, cuối cùng bạn cũng có thể đưa ra yêu cầu tới hàm hello và xem phản hồi:

Tuyệt vời, mọi thứ đều hiệu quả!

4. Truyền các tham số đơn giản cho hàm.

Bây giờ chúng ta sẽ tạo một hàm mới với các tham số, ví dụ: chúng ta sẽ kiểm tra công việc theo ngày tháng, chúng ta sẽ tạo hàm getSaleDocNumbersByDate, hàm này sẽ chấp nhận ngày của tài liệu (hóa đơn) và trả về số tài liệu cho ngày này dưới dạng một chuỗi . Hãy thêm một tham số ngày có loại dateTime vào thao tác:

mã là như thế này:

Hàm getSaleDocNumbersByDate(date) // Ngày bắt đầu = startDay(date); Ngày kết thúc = ngày kết thúc(ngày); lựa chọnDocuments = tài liệu.Consumable.Select(Ngày bắt đầu, Ngày kết thúc); số=""; trong khi lựa chọn Documents.Next() số chu kỳ = số+" №"+lựa chọn Số tài liệu+";"; kết thúc chu kỳ; trả về số; Chức năng cuối cùng

Bây giờ trong SoapUI, nhấp chuột phải vào phần tử testSoap12Binding và chọn Cập nhật định nghĩa. Sau đó, hàm getSaleDocNumbersByDate và Yêu cầu tạo sẵn cho nó sẽ xuất hiện trong dự án. Để điền ngày, bạn cần sử dụng định dạng "YYYY-MM-DDThh:mm:ss" (bạn có thể xem w3schools và tôi thực sự khuyên bạn nên sử dụng trang này để hiểu cách làm việc với xml)

Sau đó, bạn sẽ nhận được yêu cầu và phản hồi sau:

5. Gói XDTO

Nếu chúng ta cần chuyển các tham số phức tạp hơn cho các hàm (ví dụ: xml với một số trường) hoặc nhận xml có cấu trúc phức tạp để phản hồi, thì chúng ta không thể thực hiện nếu không có gói XDTO.

Làm việc với XDTO được thảo luận rất chi tiết trong một loạt bài viết. Về cơ bản, gói này xác định cấu trúc và loại trường của tệp xml được sử dụng.

Tôi sẽ xem xét một ví dụ về gửi và nhận tệp xml, loại tệp này được xác định trong gói

Tôi cũng sẽ xem xét các ví dụ trong các bài viết sau:

  • chuyển sang 1c của tệp xml không được mô tả trong gói, ở định dạng base64
  • nhận tài liệu pdf ở định dạng base64 từ 1c và giải mã nó
  • lấy từ 1C một tệp xml có cấu trúc các phần tử lồng nhau và xác định số lượng của chúng

6. Chuyển sang 1c trong tham số tệp xml, loại tham số này được xác định trong gói.

Nhiệm vụ sẽ là: tìm tài liệu hóa đơn bằng cách sử dụng số và ngày được chỉ định trong xml đến và trả lại tài liệu đã tìm thấy. Nó cũng phải được trả lại ở dạng xml kèm theo số, ngày, đối tác và mã của nó cũng như phần dạng bảng của hàng hóa.

Hãy tạo một gói packet1 với không gian tên packet1_ns. Đối với tệp xml đến, chúng tôi sẽ xác định loại đối tượng InDocSaleQuery với trường số thuộc loại chuỗi và trường ngày thuộc loại dateTime. Đối với tệp đầu ra, trước tiên chúng ta xác định loại cho một hàng của phần dạng bảng của sản phẩm: SaleItem với các trường tên loại chuỗi, tổng giá, số lượng loại thập phân. Và bản thân tài liệu SaleDoc sẽ thuộc loại tổng hợp: các trường số, ngày, tên đối tác và trường SaleItems, sẽ có loại SaleItem và số lượng tối đa là -1. Chính trường này có nghĩa là nó có thể chứa một mảng gồm nhiều phần tử. Đây là những gì nó trông giống như trong bộ cấu hình:

Đầu tiên tôi sẽ minh họa mã chức năng, sau đó tôi sẽ giải thích điều gì đang xảy ra.

Mã số:

Hàm getSaleDoc(incomingXML)DocNumber = incomingXML.number; DateDoc = XML.date gửi đến; yêu cầu = yêu cầu mới; request.Text = "SELECT | ConsumableProducts.Nomenclature.Name dưới dạng tên, | ConsumableProducts.Giá dưới dạng giá, | ConsumableProducts.Số lượng dưới dạng số lượng, | ConsumableProducts.Số tiền dưới dạng tổng, | ConsumableProducts.Link |FROM | Document.Consumable.Products AS ConsumableProducts |WHERE |ConsumableProducts.Link.Number = &Number |And ConsumableProducts.Link.Date = &DataDoc"; request.SetParameter("Số",Số tài liệu); request.SetParameter("DataDoc",DataDoc); lấy = request.Run().Select(); nếu lựa chọn.Quantity()=0 thì //trả về lỗi Loại tài liệu = FactoryXDTO.Type("packet1_ns", "SaleDoc"); DocumentBatch = FactoryXDTO.Create(DocumentType); DocumentPack.number = "Không tìm thấy tài liệu!"; Trả lại gói tài liệu; nếu không thì //tạo typeDocumentType = FactoryXDTO.Type("packet1_ns", "SaleDoc"); TablePartType = FactoryXDTO.Type("packet1_ns", "SaleItem"); DocumentBatch = FactoryXDTO.Create(DocumentType); //chọn từ phần dạng bảng сч=0; while vòng lặp Selection.Next() nếu count=0 thì //điền chi tiết tài liệu doc ​​= Selection.link; DocumentPack.number = doc.Number; DocumentBatch.date = doc.Date; DocumentPackage.partnerName = string(doc.Party); cuối cùng; //điền vào phần bảng PackageTablePart = FactoryXDTO.Create(TablePartType); FillPropertyValues(TablePartPackage, Selection); //thêm nó vào tài liệu Document Package.SaleItems.Add(TablePart Package); sch=sch+1; kết thúc chu kỳ; Trả lại gói tài liệu; cuối cùng; Chức năng cuối cùng

Có hai sắc thái chính ở đây. Đầu tiên: vì loại tham số đến đã được chỉ định XML đến và loại này đã được mô tả trong gói nên có thể truy cập ngay vào các trường của xml đến này. Thứ hai: làm việc với nhà máy XDTO. Từ đó, loại cho các tham số đầu ra kết quả đã được lấy và Giá trị XDTO của loại này được tạo, với các trường cần thiết được điền vào. Cũng cần lưu ý rằng ở loại SaleDoc bạn nên nhập một trường riêng cho lỗi, tuy nhiên với mục đích kiểm tra các lỗi sẽ được ghi vào trường số.

Đây là kết quả của truy vấn này trong SoapUI:

Như bạn có thể thấy, mọi thứ đều hoạt động nhưng vẫn còn chỗ cần cải thiện - ví dụ: tôi muốn biết chúng tôi có bao nhiêu phần tử SaleItems trong tài liệu của mình.

Tôi sẽ nói về điều này và những ví dụ phức tạp hơn trong bài viết tiếp theo.

Kho lưu trữ đính kèm chứa bản tải xuống cơ sở thông tin và dự án SoapUI.

Dịch vụ web trong 1C

Bài viết này sẽ thảo luận về việc tích hợp 1C với các dịch vụ web hiện có và việc sử dụng chính 1C làm dịch vụ web.

Trong trường hợp này, các dịch vụ web sẽ được hiểu là các hệ thống hoạt động trên Internet và cung cấp sự tương tác với chúng không chỉ thông qua SOAP (chính xác là một dịch vụ web) mà còn theo những cách khác, bao gồm cả các yêu cầu HTTP(S) thông thường.


Rủi ro khi sử dụng dịch vụ web 1C

Nền tảng 1C81 giới thiệu việc triển khai các dịch vụ web.

Nhưng việc sử dụng chúng có nhiều rủi ro:

  1. 1C8 không hoạt động tốt qua HTTPS, không có công cụ chẩn đoán nên đôi khi không thể hiểu tại sao dù có chứng chỉ nhưng dịch vụ lại không muốn hoạt động qua HTTPS. Giải pháp là triển khai các dịch vụ web thông qua CURL hoặc tạo đường hầm HTTPS.
  2. 1C8 tuân thủ các quy tắc của nó để xác thực các lược đồ WSDL. Đôi khi, vì những lý do không thể giải thích được, lược đồ WSDL không muốn được tải vào liên kết WS. Bạn chỉ có thể tìm hiểu lý do trên diễn đàn đối tác từ một chuyên gia. Không có công cụ chẩn đoán lược đồ WSDL nào, thậm chí không chỉ ra lý do hoặc dòng khiến việc tải lược đồ bị gián đoạn.

Quy định xây dựng dịch vụ bán hàng

Khách hàng chỉ được cấp chứng từ bán hàng (biên lai) nếu giao dịch dịch vụ thành công. Nếu không, có thể xảy ra tình huống khi khách hàng nhận được séc và tin chắc rằng mình đã nhận được dịch vụ, nhưng thực tế thì không.

Sử dụng các dịch vụ SOAP bên ngoài

Các dịch vụ web SOAP sử dụng các lược đồ WSDL và các đối tượng XDTO để biểu diễn dữ liệu.

Đang tải WSDL

Để sử dụng một dịch vụ bên ngoài, bạn cần tải xuống lược đồ WSDL của dịch vụ đó.

Kiểm tra tính hợp lệ của lược đồ WSDL

Đôi khi lược đồ WSDL không tải vào 1C. Bạn có thể kiểm tra tính hợp lệ (tính chính xác) của lược đồ bằng cách sử dụng bất kỳ trình xác thực lược đồ WSDL nào, ví dụ: http://www.validwsdl.com/.

Bạn cần tải lược đồ lên một số trang http (bạn có thể sử dụng ftp) và cho biết địa chỉ của tệp mà lược đồ được tải:

Tính năng tải WSDL trong 1C

Điểm đặc biệt của việc tải WSDL trong 1C là các lược đồ hợp lệ có thể không được tải. Không có trình xác thực tích hợp, vì vậy bạn phải tìm kiếm lỗi bằng cách sử dụng phân tích phá hủy, liên tục giảm số lượng phần tử trong mạch. Ví dụ: bạn có thể xóa mô tả dịch vụ web.

Xử lý để thử nghiệm một dịch vụ web bên ngoài đang chạy

Để kiểm tra một dịch vụ web bên ngoài đang hoạt động, hãy sử dụng quy trình xử lý “Kiểm tra ArbitraryWebService.epf” từ gói dành cho bài viết này.

Việc kiểm tra có thể được sử dụng bằng cách sử dụng ví dụ về dịch vụ Morpher, dịch vụ này từ chối tên (địa chỉ dịch vụ http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):

Bằng cách này, bạn có thể kiểm tra bất kỳ dịch vụ nào có điểm vào đơn giản chứa các tham số thuộc loại đơn giản: số, ngày, chuỗi.

Trong quá trình xử lý, bạn cũng có thể chỉ định thông tin đăng nhập và mật khẩu được yêu cầu để cấp quyền truy cập vào dịch vụ web.

Công cụ tiêu chuẩn cho dịch vụ gỡ lỗi

Để gỡ lỗi, bạn có thể sử dụng chương trình SoapUI, chương trình này có thể gửi yêu cầu tùy ý đến dịch vụ web và nhận phản hồi từ dịch vụ đó.

SOAP và HTTPS

Thật không may, SOAP trong 1C hoạt động khá thất thường khi làm việc thông qua giao thức HTTPS; thực tế cho thấy rằng không thể đạt được kết nối HTTPS, mặc dù khả năng này đã được khai báo trong nền tảng. Việc thiếu các công cụ chẩn đoán và gỡ lỗi để tìm ra lý do tại sao kết nối không được thiết lập đang gây ra hậu quả. Vì vậy, việc sử dụng SOAP qua CURL sẽ rất thuận tiện.

Cơ chế tích hợp để sử dụng HTTPS ngụ ý rằng tất cả các chứng chỉ phải được xuất bản trong một tệp pem chung trong thư mục chương trình 1C.

Sử dụng 1C làm dịch vụ

Quy tắc phát triển dịch vụ dựa trên 1C

Hoạt động xin chào

Quy tắc hình thức tốt là tạo ra một thao tác trong dịch vụ để thông báo rằng dịch vụ đó có sẵn. Điều này làm cho cuộc sống của các nhà tích hợp trở nên dễ dàng hơn; họ sẽ dễ dàng kiểm tra xem liệu giao tiếp với dịch vụ có được thiết lập hay không.

Ví dụ: bạn có thể sử dụng thao tác Hello mà không cần tham số, thao tác này chỉ trả về giá trị Boolean True.

Xuất bản một dịch vụ web

Quy trình này được mô tả rõ ràng trong tài liệu: file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634:

Nhiệm vụ xuất bản các dịch vụ Web bao gồm việc đặt các tệp cấu hình *.1cws của các dịch vụ Web vào thư mục thích hợp của máy chủ web với các cài đặt thích hợp cho máy chủ web. Để xuất bản các dịch vụ Web, bạn nên thực thi lệnh menu “Quản trị | Xuất bản các dịch vụ Web."

Kết quả của việc thực thi lệnh này là cửa sổ xuất bản dịch vụ Web sẽ mở ra.

Cửa sổ xuất bản dịch vụ Web chứa đường dẫn đến máy chủ web và hai danh sách:

  • “Dịch vụ web” - danh sách các dịch vụ web cấu hình;
  • “Ấn phẩm” - danh sách các dịch vụ Web được xuất bản trên máy chủ web được chỉ định.

Sử dụng nút "Kết nối...", bạn nên chỉ định máy chủ web mà bạn muốn xuất bản các dịch vụ Web trên đó.

Cửa sổ chọn đường dẫn máy chủ web cho phép bạn chỉ định đường dẫn theo hai cách:

  • trên tab “Tệp” - phương pháp này được sử dụng khi việc xuất bản được thực hiện trên cùng một máy tính đã cài đặt máy chủ web. Đường dẫn là một thư mục cục bộ tương ứng với trang Internet mà máy chủ Web đã xuất bản sẽ được gọi từ đó;
  • trên tab “Trang FTP” - phương pháp này được sử dụng khi bạn cần xuất bản dịch vụ Web trên máy tính từ xa. Để xuất bản, bạn phải chỉ định các tham số của kết nối FTP tới máy tính từ xa và thư mục mà dịch vụ Web sẽ được xuất bản.

Dịch vụ Web đã chọn được xuất bản bằng nút “Xuất bản”

Để hủy xuất bản một dịch vụ Web, hãy sử dụng nút “Xóa”.

Bạn có thể xuất bản lên một thư mục cục bộ hoặc qua FTP. Bạn cũng có thể xuất bản lên máy chủ từ xa thông qua đường dẫn UNC nếu máy chủ từ xa là một phần của mạng cục bộ.

Sau khi xuất bản, dịch vụ web có sẵn tại địa chỉ “http://localhost/test.1cws” hoặc “http://xxx.ru/test.1cws”, trong đó xxx.ru là địa chỉ của máy chủ từ xa và localhost là địa chỉ điển hình của máy chủ cục bộ.

Ủy quyền cho dịch vụ web 1C

Để truy cập dịch vụ, bạn cần phải vượt qua xác thực.

Các vấn đề về ủy quyền được giải quyết kỹ lưỡng tại đây: http://www.forum.mista.ru/topic.php?id=341168 và trong tệp tài liệu:///c:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81. htm

Thông thường, một dịch vụ web chạy dưới một người dùng cụ thể (thường là một người dùng được tạo đặc biệt). Bạn có thể “đính kèm” người dùng 1C bằng xác thực Windows với người dùng Windows IUSR_ (vô hiệu hóa ủy quyền 1C cho người dùng). Ngoài ra, bạn có thể xóa danh sách người dùng 1C, khi đó không cần ủy quyền.

Nếu cần có nhiều người dùng, thì bạn có thể tạo một số thông tin đăng nhập cho máy chủ web, chỉ định một người dùng Windows cho mỗi người trong số họ và theo đó, đăng ký quyền truy cập cho người dùng Windows trong 1C.

Trong thuộc tính Người dùng và Mật khẩu của đối tượng WSProxy, thông tin đăng nhập 1C không được sử dụng mà là thông tin đăng nhập của người dùng máy chủ web.

Kiểm tra dịch vụ web 1C

Để kiểm tra 1C dưới dạng dịch vụ web, hãy sử dụng quy trình xử lý “Kiểm tra ArbitraryWebService.epf”, như được mô tả trong phần “Thử nghiệm dịch vụ web bên ngoài đang chạy”.

Tệp 1cws là mô tả WSDL của dịch vụ web 1C.

Sử dụng dịch vụ trong Bán lẻ

Thông thường, các dịch vụ bán lẻ được sử dụng để cung cấp các dịch vụ khác nhau cho người dân - chấp nhận thanh toán, trả nợ, chuyển tiền, mua phần mềm, v.v.

Trong trường hợp này, biên nhận được tạo ở dạng 1C cho dịch vụ được cung cấp, trong đó các tham số giao dịch được lưu. Sau đó, biên nhận này sẽ được in cho khách hàng với thông tin chi tiết về dịch vụ được cung cấp. Có thể in séc sơ bộ để khách hàng xác nhận dữ liệu đã nhập từ lời nói của mình bằng chữ ký của mình.

Dịch vụ này có thể được tích hợp theo nhiều cách khác nhau vào chương trình bán lẻ được viết bằng ngôn ngữ 1C (UT, Bán lẻ và các chương trình khác):

  1. Việc xử lý hoặc mã có thể được viết bằng ngôn ngữ 1C, ngôn ngữ này thực hiện tất cả công việc với dịch vụ.
  2. Một chương trình có thể được sử dụng để hoạt động với dịch vụ và trong 1C chỉ truyền thông tin để kiểm tra đột xuất.

Tổ chức dữ liệu dịch vụ trong 1C

Để lưu trữ thông tin về giao dịch trong biên lai, bạn cần tạo thêm phần dạng bảng “Bán hàng phức tạp” với các chi tiết:

  • Danh pháp - liên kết đến danh pháp của séc.
  • Tham số - liên kết tới sách tham khảo “Bán hàng phức tạp: Tham số”.
  • Giá trị - giá trị của tham số, một loại phức tạp. Chuỗi trình bày phải khá dài (1024 ký tự) để chứa văn bản kiểm tra.

Thư mục “Bán hàng phức tạp: Thông số” chứa danh sách các thông số giao dịch.

Sẽ có lợi hơn khi sử dụng phần bảng biểu hơn là sử dụng một tập hợp các chi tiết, bởi vì một giao dịch có thể có rất nhiều thông tin trong số đó và trong các lần kiểm tra khác không liên quan đến dịch vụ, những chi tiết này sẽ không được sử dụng và sẽ chiếm thêm dung lượng. Ngoài ra, giải pháp như vậy có tính phổ biến cho mọi dịch vụ và không yêu cầu cơ cấu lại dữ liệu sau khi triển khai dịch vụ mới.

Người bán được cấp một dấu trang riêng (hoặc dạng in để không thay đổi cấu hình), trong đó anh ta có thể xem bảng chi tiết giao dịch để kiểm tra.

Sử dụng xử lý bằng ngôn ngữ 1C

Hãy xem ví dụ về dịch vụ có điều kiện Paym cho cấu hình “Bán lẻ”.

  1. Hãy tạo một phần tử được xác định trước của thư mục danh pháp “Paym” trong 1C. Ở chế độ 1C:Enterprise, sau khi cập nhật cấu hình, nó cần được gán loại sản phẩm “Dịch vụ”.
  2. Trong quy trình “Thêm mục vào bảng. một phần" của mô-đun biểu mẫu "Đăng ký bán hàng", chúng tôi gọi việc xử lý công việc với dịch vụ, được viết bằng ngôn ngữ 1C. Nếu thanh toán thành công, chúng tôi ghi lại và gửi séc:
Nếu (Danh pháp = Thư mục.Danh mục.Paym) VÀ (Loại giao dịch chuyển khoản. Loại hoạt động Kiểm tra KKM. Trả lại) Thì Xử lý thanh toán = Chức năng cung cấp Xử lý bên ngoài ("Thanh toán"); PaymentForm = PaymentProcessing.GetForm(); Kết quả = PaymentForm.OpenModal(); Nếu Kết quả = Không xác định thì Trả về; endIf; ThisObject.Write(DocumentWriteMode.Post); endIf;
  1. Quá trình xử lý phải in biên lai sơ bộ (nếu được yêu cầu), điền vào phần bảng của doanh số bán hàng phức tạp và chuẩn bị văn bản in séc trong thuộc tính “PaymCheckText” được xác định trước.
  2. Trong quy trình “Đăng và in biên nhận” của mô-đun biên nhận, chúng tôi thay thế tên của sản phẩm bằng tên được lưu trong chi tiết của biên nhận. Văn bản chỉ được thay thế khi bán hàng; khi trả lại, chỉ cần in tên của dịch vụ, như thường lệ.
Mặt khácNếu loại giao dịch chuyển khoản.Các loại hoạt độngKiểm tra KKM.Trả lại và lựa chọn.NomenclatureLink = Directory.Nomenclature.Paym Then //Osipov PaymMaster ComplexSales Line = ComplexSales.Find(Directories.ComplexSalesParameters.PaymReceiptText, "Properties"); Nếu Dòng bán hàng phức tạp không được xác định thì Product.Name = LP viết tắt(Dòng bán hàng phức tạp. Giá trị); endIf;

Một câu hỏi riêng là làm thế nào để đảm bảo hoàn thành giao dịch. Những thứ kia. Nếu giao dịch diễn ra trong dịch vụ thì làm sao đảm bảo nó không bị mất trong 1C. Cách tối ưu nhất là đối chiếu các sổ đăng ký. Nhưng đây là một chủ đề để xem xét riêng biệt.

Sử dụng các chương trình tích hợp với 1C

XDTO

XDTO thường được sử dụng trong các dịch vụ web. Dưới đây là những mẹo và công thức quan trọng nhất để sử dụng XDTO trong 1C.

XDTO trong nền tảng 1C

Các gói XDTO, được mô tả trong nhánh “Đối tượng XDTO” của cấu hình, có sẵn để tạo các loại và đối tượng trong nhà máy toàn cầu XDTO Factory. Điều này không rõ ràng ngay lập tức.

Một số loại trong lược đồ không có tên; để có được chúng, bạn cần phải xem qua hệ thống phân cấp loại.

Ví dụ mô tả danh sách Hệ thống chứa cấu trúc XDTO. Để tự tạo cấu trúc, bạn phải lấy kiểu của nó như thế này:

Loại = Factory.Type("urn:my.ru:MasterData:Business", "Business").Properties.Get("System").Type;

Các vấn đề thường gặp với XDTO

Các định dạng lược đồ XSD khác nhau

Trong một số định dạng, thẻ được gọi là xs:, trong một số xsd:, nhưng 1C hiểu cả hai định dạng một cách an toàn. Đã từng xảy ra trường hợp XSD được nhập vào 1C bình thường mà không có lỗi nhưng lại không tạo được một gói nào. Lý do là thiếu thuộc tính không gian tên mục tiêu tại thẻ, theo đó, 1C không biết nên đặt sơ đồ vào gói nào nhưng không phát sinh lỗi.

Hỗ trợ dịch vụ

Xét rằng dịch vụ là sự kết hợp của hai hệ thống - 1C và bên ngoài, lỗi có thể xảy ra ở cả hai hệ thống, làm giảm độ tin cậy chung của hoạt động.

Để dễ hiểu hơn về nguyên nhân gây ra lỗi dịch vụ, nên sử dụng một bộ biện pháp.

Yêu cầu ghi nhật ký

Liên kết

  • XDTO
    • Mô tả hay về XDTO http://pro1c.org.ua/index.php?showtopic=214
  • Các dịch vụ web thú vị miễn phí:
    • Aeroflot - thông tin về lịch trình máy bay
    • Morpher - cách viết tắt của tên http://www.morpher.ru/WebServices/Morpher.aspx
  • Chưa lắp ráp:
    • Cài đặt và sử dụng các dịch vụ Web
      • v8: làm cách nào để thay đổi tệp cấu hình Apache?
      • v8: tiếp tục chủ đề với các dịch vụ web - Tôi không thể kết nối dịch vụ web
      • v8: Tôi tiếp tục thu thập thông tin qua các dịch vụ web - Tôi không thể tạo proxy...
      • Sách Kiến thức: v8: Sử dụng dịch vụ web bên ngoài trong 1C:Enterprise 8;