Hello!
In several articles, I will talk about the possibilities to test how 1C web services work using SoapUI. I will also give examples of returning documents from 1C in PDF format and complex xml files. Some of the things are similar, but I'll go over more complex examples of working with web services. But first, I will go through the steps of starting web services and working with SoapUI step by step, so that it is easier to understand their functioning from scratch.
1. Simple web service
First, let's take a skeleton configuration without web services and walk through the process of creating them.
Let's add a new web service named test1 and create a hello operation in it with a return type of string. It is better to always specify the names of web services and operations in the Latin alphabet.
You also need to set the namespace URI and the name of the publication file:
When you click on the magnifying glass in the "Procedure name" field, the web service module will open and you can implement the hello function.
Hello () function return "string from web service 1c"; EndFunction
2. Publishing a web service.
Now, in order for the resulting function to be available via http, we need to publish our service on a web server. Apache 2.2 is suitable for this. I read articles on how you can set up work with IIS and it seemed to me much more difficult. After installing and running Apache 2.2, you need to go to the Administration - Publishing on a web server menu. The directory field must be filled in and contain the directory for your Apache installation. Remember the fields "name" and "address" of the web service, they will be useful to us in the next step.
3. Testing with SoapUI
For testing, let's create a separate WsUser user with a simple password and give it full rights.
After that, install and run SoapUI. This program is very convenient for testing web services, it can get their description and make post-requests to the services.
Go to the File - New SOAP project menu, set the project name to hellotest, and in the Initial WSDL field, add the following link:
http: //localhost/test_ws/ws/test1.1cws? wsdl
In it, the "test_ws" part was specified at the last stage in the "name" field and test1.1cws in the "address" field.
Click OK and at this stage you will need to log in by logging in as a test user WsUser. The project will be created and two bindings will be created.
Soap12Binding differs in that it works according to the new version of the SOAP 1.2 standard. Let's open the Request1 element in test1Soap12Binding and see this:
SoapUI shows which xml will be passed to our function. Before starting the test, there is one more nuance, by default SoapUI will require authorization for each individual Request element. Therefore, in order not to set it every time, you need to right-click on testSoap12Binding, select Show interface view and, in the window that opens, on the "Service Endpoint" tab, set the name and password of the web services user:
If this is not done, then for each Request you will need to specify authorization, in the lower panel by the Auth button.
Now we can finally execute a request to the hello function and see the response:
Great, it all worked!
4. Passing simple parameters to a function.
Now we will make a new function with parameters, for example, we will check the work with dates, we will make the getSaleDocNumbersByDate function, which will accept the date of the document (invoice) and return the document numbers for this date as a string. Add the date parameter with the dateTime type to the operation:
the code is like this:
GetSaleDocNumbersByDate (date) function // Start date = Day start (date); dateEnd = endDay (date); SelectionDocuments = documents.Invoice.Choose (Start date, End date); numbers = ""; while fetchingDocuments.Next () cycle of numbers = numbers + "No." + fetchingDocuments.Number + ";"; end of the cycle; number return; EndFunction
Now in SoapUI, right-click on the testSoap12Binding element and select Update Definition. After that, the getSaleDocNumbersByDate function and a ready Request for it will appear in the project. To fill in the date, you need to use the format "YYYY-MM-DDThh: mm: ss" (you can look at w3schools and I VERY recommend using this site to understand how to work with xml)
Then you get the following request and response:
5. XDTO packages
If it is necessary to pass more complex parameters to functions (for example, xml with several fields), or receive xml that are complex in structure in response, then we cannot do without XDTO packages.
Working with XDTO is discussed in great detail in a series of articles. In fact, the package defines the structure and type of fields for the xml files used.
I will go through an example of transferring and receiving an xml file, the type of which is defined in the package
And also in the following articles I will consider examples:
- transfer in 1c xml-file not described in the package, in base64 format
- getting from 1c a pdf document in base64 format and decoding it
- getting an xml file from a 1c file with a nested structure of elements and determining their number
6. Transfer in 1s in the parameter of the xml-file, the type of which is defined in the package.
The task will be as follows: find the document of the invoice according to the number and date specified in the incoming xml and return the found document. You also need to return it in the form of xml with the number, date, counterparty and its code and the tabular part of the goods.
Let's create packet1 with the packet1_ns namespace. For the incoming xml file, let's define the type of the InDocSaleQuery object with the number field of the string type and the date field of the dateTime type. For the output file, we first define the type for one line of the tabular section of goods: SaleItem with fields name of type string, price sum, quantity of type decimal. And the SaleDoc document itself will be of a composite type: the fields number, date, partnerName and the SaleItems field, which will have the SaleItem type and the maximum number of -1. It is such a field that means that an array of several elements can be present in it. This is how it all looks in the configurator:
First, I will demonstrate the function code, and only then I will explain what is happening.
Code:
GetSaleDoc function (incomingXML) NumberDoc = incomingXML.number; DateDoc = incomingXML.date; request = new request; request.Text = "SELECT | ConsumableProducts.Nomenclature.Name as name, | ConsumableProducts.Price as price, | ConsumableProducts.Quantity as quantity, | ConsumableProducts.Total as sum, | ConsumableProducts.Ref | FROM | Document.Expendable.Products AS ConsumableProducts. | WHERE | ConsumableProducts.Ref.Number = & Number | And ConsumableProducts.Link.Date = & DateDoc "; request.SetParameter ("Number", numberDoc); request.SetParameter ("DateDoc", DateDoc); fetch = query.Run (). select (); if sample.Number () = 0 then // return the error DocumentType = FactoryXDTO.Type ("packet1_ns", "SaleDoc"); DocumentBatch = XDTOFactory.Create (DocumentType); DocumentBatch.number = "No documents found!"; Return of PackageDocument; otherwise // create types DocumentType = FactoryXDTO.Type ("packet1_ns", "SaleDoc"); TabularSectionType = XDTOFactory.Type ("packet1_ns", "SaleItem"); DocumentBatch = XDTOFactory.Create (DocumentType); // select from the tabular section cs = 0; while sampling.Next () cycle if n = 0 then // fill in the document details doc = sampling.link; DocumentBatch.number = doc.Number; DocumentPacket.date = doc.Date; DocumentPackage.partnerName = string (doc.partner); end if; // fill in the tabular section TabularSection Package = XDTOFactory.Create (TabularSection Type); FillPropertyValues (TabularSection Package, selection); // add it to the document DocumentPackage.SaleItems.Add (TabularSection Package); mid = mid + 1; end of the cycle; Return of PackageDocument; end if; EndFunction
There are two main nuances here. First: since the type of the incoming parameter incomingXML was set and it was described by this type in the package, it is immediately possible to access the fields of this incoming xml. Second: working with the XDTO factory. From it, the type for the resulting output parameters was obtained and an XDTO Value of this type was created, in which the required fields were filled. It is also worth noting that a separate field for the error should be entered in the SaleDoc type, but for testing purposes, errors will be recorded in the number field.
This is what the result of this query looks like in SoapUI:
As you can see, everything works, but there is still something to improve - for example, I would like to know how many SaleItems we have in the document.
I will talk about this and more complex examples in the next article.
The attached archive contains the unloading of the infobase and the SoapUI project.
Using the Web Services Validation Tool for WSDL and SOAP
Apparently, with the advent of new technologies and standards such as XML and HTTP, Web services have secured their place in the pantheon of Internet innovation. But how did this innovation come about?
The basic concept of Web services can be traced back to the mid-1960s in the United States. In the transport industry, for example, in the railway and shipping companies, a new concept for the exchange of electronic data between computers was introduced, which further developed into the technology EDI (Electronic Data Interchange). I first heard about EDI from a business school professor in 1980.
In 1996, the US National Institute of Standards and Technology announced a standard for EDI in the Federal Information Processing Standards Publications (FIPS PUB 161-2). According to the published specification, EDI is a standard for the exchange of strictly formatted messages between computers. The processing of received messages is carried out only by the computer, and these messages are usually not intended for human interpretation. This is exactly what Web services do, except that XML, the Internet, and the World Wide Web did not exist in the mid-1960s.
For those who are not very familiar with Web services, I'll briefly go over the definitions and basic components of Web services.
What are Web Services
A web service is a software system designed to support machine-to-machine communications between computing resources over a network and uses Simple Object Access Protocol (SOAP) messages as defined by the World Wide Web Consortium.
The Simple Object Access Protocol (SOAP) is a simple, extensible protocol over which structured and typed messages are exchanged in a decentralized, distributed network environment. SOAP messages are written in the Extensible Markup Language (XML) format, a simple and flexible text format derived from the Standard Generalized Markup Language (SGML), which was developed by the International Organization for Standardization (ISO 8879: 1986).
Web Services Description Language (WSDL) is an XML-based language that describes the interface of Web services.
What happens when a faulty SOAP message is exchanged? What would happen if the erroneous SOAP message was processed without warning, and even used to generate decision information?
In practice, it is impossible to tell whether the data in the SOAP message is correct or not. However, you can test the SOAP message for correctness by looking at its interface definition or WSDL.
In real life, it is very difficult to debug problems in SOAP messages. If there is any error in the SOAP message, an HTTP response code of 500 is received from the Web services server. Web services servers do not provide detailed information about which part of the SOAP message has a problem. You might run into an even worse situation where correct SOAP responses are received from the web services server without any error messages, and neither you nor your web service servers can understand the problems in your SOAP requests and responses. For example, suppose you wanted to query the current stock price of Company B, but you sent a SOAP message with misspelled tags to the Web services server. The web services server can ignore the incorrect tags and provide a default value in the SOAP response message, such as the stock price of Company A. If this goes unnoticed, the consequences can be catastrophic.
These types of problems can be prevented proactively by using the Web Services Validation Tool for WSDL and SOAP. It allows you to validate the correctness of SOAP messages using the Web Service Definition Language (WSDL), even before deploying applications that use the Web service. The program parses the syntax and correctness of your SOAP messages with WSDL and indicates problems, detailing errors and line numbers. As a result, you no longer receive annoying HTTP 500 messages. Are your SOAP messages encrypted? No problem. The program will decrypt them and check the correctness of the decrypted SOAP messages for you.
This program was created to help IBM Web Services support staff resolve Web services-related issues on IBM® WebSphere Application Server reported by customers around the world. The program is designed to check the correctness of SOAP messages. If the SOAP message is digitally signed, the program will verify that as well. With the Web Services Validation Tool for WSDL and SOAP, you can even send SOAP messages to Web service servers and receive SOAP response messages. The program was created in order to eliminate problems during industrial operation by using it in the early stages of development, as well as to reduce the time for solving problems that arise during operation.
We will create a very simple web service. First, we will create a simple Java ™ application. After verifying that the Java application is working, we will use IBM Rational® Application Developer for WebSphere® Software to generate a Web service. Then we'll make some changes to the generated web service. Finally, we use the Web Services Validation Tool for WSDL and SOAP to create, validate, send, and receive SOAP messages.
A simple Web service can be created using IBM Rational Application Developer for WebSphere Software. Web services can be created in two ways:
- Top-down development development in which Java classes that implement Web services are generated from WSDL.
- Bottom-up development, in which a Web service is generated from a Java bean or an enterprise Java bean.
In the following example, we will implement a Web service using a bottom-up development approach. First, we will create a simple Java application. Next, we will generate a Java bean Web service from a Java application using the IBM Rational Application Developer for WebSphere Software.
Creating a Java Application
First, we will create a Java application that issues a greeting. If no name is specified, the application will return the text "Hello, buddy!" If a name is specified, the application will return the text "Hello," followed by that name. Below is the code for the DemoWebService Java application included in the demo package. The hello () method returns a string depending on the name.
Listing 1. DemoWebService.java
/ * * @author: Jinwoo Hwang * Copyright 2010 IBM Corporation * / package demo; public class DemoWebService (public String hello (String name) (if (name == null) return "Hello, buddy!"; else return "Hello," + name + "!";))Testing a Java Application
It is very important to test your Java application before creating a Web service from it. To run the application, you can write a class with a main () method. You can also use the Universal Test Client functionality provided by IBM Rational Application Developer v7 for quick testing without writing test code. Simply select Universal Test Client from the Java class context menu to launch the Test Client.
- In Universal Test Client, expand Objects> DemoWebService.
- Choose method hello.
- Enter a string or your name in the field Value and press the button Invoke.
You can also run the test with the null parameter and see what happens. If null is passed to hello (), the string "Hello, buddy!" Is returned as expected.
Creating a web service
So far, everything has been working well. Let's start generating a Web service from a Java class using the bottom-up Web services development method.
- Select the DemoWebService Java application and create a new Web service from IBM Rational Application Developer.
- Since we have created a Java class, choose Bottom up Java bean Web service in the Web service type list. Please select Start client and press the button Finish... If we had an EJB class, we could also write an EJB (Java Enterprise bean) to generate the Web service.
If everything went well, you will see the generated DemoWebServiceDelegate.java in Java Resources next to DemoWebService.java.
Looking at DemoWebServiceDelegate.java, you can find the @ javax.jws.WebService Java Web service annotation that specifies the targetNamespace, serviceName, and portName in the DemoWebServiceDelegate class. An instance of DemoWebService is created and another hello () method is created from the hello () method of the DemoWebService. For more information on Java Web services annotations, see Java Specification Request (JSR) 181. Web services metadata for the Java platform.
Listing 2. DemoWebServiceDelegate.java
/ * * @author: Jinwoo Hwang * Copyright 2010 IBM Corporation * / package demo; @ javax.jws.WebService (targetNamespace = "http: // demo /", serviceName = "DemoWebServiceService", portName = "DemoWebServicePort") public class DemoWebServiceDelegate (demo.DemoWebService _demoWebSermo) (StringService) String name) (return _demoWebService.hello (name);))Creating WSDL
In the client program project, you may also find that the DemoWebServiceService.wsdl and DemoWebServiceService_schema1.xsd files have been generated. DemoWebServiceService.wsdl contains Web Service Definition Language information describing network services for a previously created Java application. DemoWebServiceService_schema1.xsd contains an XML schema that describes the structure of the data types used in SOAP messages.
When you look at the DemoWebServiceService.wsdl file, you can see that it has a set of definitions elements at its root. There are 6 elements in a definition element:
- types (types);
- message (message);
- portType (port type);
- binding (binding);
- service (service);
- port (port).
Types defines the data types used in messaging. In DemoWebServiceService.wsdl, we import DemoWebServiceService_schema1.xsd instead of defining data types in the WSDL file.
Message defines the messages exchanged. We have 2 messages: "hello" and "helloResponse". The hello message has a part called "parameters". This part has a "tns: hello" element. The helloResponse message has a part called "parameters" which is similar to hello. This part has a "tns: helloResponse" element. The hello and helloResponse elements are defined in the DemoWebServiceService_schema1.xsd file. We'll cover them shortly.
Port Type- operations supported by endpoints. Each operation provides an input and output message. Our hello operation consists of a tns: hello input message and a tns: helloResponse output message. These operations correspond to a request-response exchange. WSDL provides 4 different endpoint exchange primitives:
- one-way
- request-response
- solicit-response (request-response);
- notification
In a unidirectional exchange, the endpoint only receives the message. In a challenge-response exchange, the endpoint receives the message and sends the appropriate message. In a request-response exchange, an endpoint sends a message and receives a corresponding message. In a notification exchange, the endpoint only sends the message.
Binding defines the protocol details and message format specifications for operations and messages defined by the port type. For the style attribute, we use the value document. The style attribute provides 2 different message styles: rpc and document. Rpc-style messages contain parameters and return values. In the document style, messages contain documents. The transport attribute specifies the URI for the SOAP transport. The specified value http://schemas.xmlsoap.org/soap/http means that HTTP binding will be used in the SOAP specification. The URI for the SOAPAction HTTP header for a SOAP HTTP bind is specified in the soapAction attribute. Because the SOAP HTTP binding is used, the soapAction attribute is required. We use the empty string "" for the soapAction attribute. The soap: body element defines how the message parts are assembled within the body element of the SOAP message. The use attribute provides 2 different options: literal and encoded. We are using literal. This means that we have chosen to define a specific schema using either the type attribute or the element. When using the encoded variant, the type is abstract with encoding rules.
Service defines the set of used ports.
Port defines the endpoint of a communication by specifying the network address to bind.
network address to bind. In our case, the SOAP endpoint address is http: // localhost: 9081 / HelloWorldWSProject / DemoWebServiceService.
Listing 3. DemoWebServiceService.wsdl
Create a schema
We are importing DemoWebServiceService_schema1.xsd from DemoWebServiceService.wsdl. Consider the DemoWebServiceService_schema1.xsd file. It is written in the XML Schema definition language to describe the structure and content constraints of XML documents. We have 2 elements: hello and helloResponse. Each element has a type. The hello type has an element "arg0" which is a string. The "arg0" element is optional because the value of the minOccurs attribute in its declaration is 0. If the minOccurs attribute is set to 1 or greater, the element must be specified. The same goes for the "return" element of type helloResponse.
Listing 4. DemoWebServiceService_schema1.xsd
Getting Started with the Web Services Validation Tool for WSDL and SOAP
So we've covered WSDL and schema. Let's start the web services server so that we can invoke the web service from the Web Services Validation Tool for WSDL and SOAP.
To run the Web Services Validation Tool for WSDL and SOAP, you need a Java 6 (or higher) runtime and an XML digital encoding and decoding API that conforms to the World Wide Web Consortium's "XML Encryption Syntax and processing" specifications (http: // www. w3.org/TR/xmlenc-core/).
IBM Java 6 provides an implementation of JSR 106: XML Digital Encryption APIs. If you have IBM Java 6 installed, then everything is ready to work and you do not need to install anything else.
If your Java 6 runtime, such as Sun Microsystems ™ Java 6, does not have XML Digital Encryption APIs, you need to install libraries that implement JSR 106 or the Apache ™ XML Security package version 1.4.3, which can be downloaded from http: / /santuario.apache.org/. Simply download the binary distribution, unzip it into a directory, and tell the toolkit where that directory is using the -vmargs and -DAXS command line options.
At the time of this writing, the Web Services Validation Tool for WSDL and SOAP supports JSR 106 and Apache XML Security version 1.4.3 for XML Digital Encryption and Decryption. If you want to verify digital signatures in SOAP messages, you need libraries that implement JSR 105: XML Digital Signature APIs. Fortunately, Java 6 VMs from Sun Microsystems and IBM provide implementations of JSR 105. This is why Java 6 was chosen as the minimum Java runtime environment requirement. If your Java 6 environment does not provide libraries that implement JSR 105, you need to find them.
You can download the Web Services Validation Tool for WSDL and SOAP from here for free. Installation is very simple. Unzip the package to a directory and run wsvt.exe. If your default Java virtual machine is not a Java 6 environment that supports XML digital signatures and digital encryption and decryption, you must specify the Java 6 location with the -vm parameter, for example:
wsvt –vm c: \ IBMjava6 \ bin \ java.exe
Again, if you have IBM Java 6, you don't need to install anything else. Everything you need is already included in IBM Java 6. If you are using Java 6 from Sun Microsystems, you need to tell the program the location of Apache XML Security to decrypt the encrypted SOAP messages.
For example, the following command will run a program with Sun Java 6 and Apache XML Security library version 1.4.3 located in the C: \ xml-security-1_4_3 \ libs directory:
wsvt –vm c: \ SUNjava6 \ bin \ java.exe –vmargs –DAXS = C: \ xml-security-1_4_3 \ libs
Below is a list of Apache XML security library files actually used by the Web Services Validation Tool for WSDL and SOAP, although Apache XML security version 1.4.3 ships with 9 jars:
commons-logging.jar;
serializer.jar;
xalan.jar;
xmlsec-1.4.3.jar.
The MANIFEST.MF of the Web Services Validation Tool for WSDL and SOAP contains the following information:
Bundle-ActivationPolicy: lazy
Bundle-ClassPath: .,
external: $ AXS $ / commons-logging.jar,
external: $ AXS $ / serializer.jar,
external: $ AXS $ / xalan.jar,
external: $ AXS $ / xmlsec-1.4.3.jar
This is why you had to specify –vmargs –DAXS = C: \ xml-security-1_4_3 \ libs for Sun Java 6 to decrypt encrypted SOAP messages.
I've spent quite some time resolving class loading conflicts and incompatibilities among XML-related classes found in the Sun Java runtime, Apache XML Security, and some Eclipse plugins. Setting up the IBM Java runtime was straightforward because it ships with the JSR 106 implementation and does not require Apache XML Security.
Project creation
Now that you have set up and run the tool, you can create a new project. A project can contain a WSDL file, multiple schema files associated with a WSDL file, and SOAP messages in XML files. If there are multiple WSDL files in the project, only one of them is used and the others are ignored when validating the XML SOAP message file. To use a different WSDL file, you must create a separate project. Each SOAP message must be contained in a .xml file or it will not be treated as a SOAP message.
- Right click and select New> Project.
- Please select Project v General.
- Enter "Test Project" in the field Project name and press the button Finish.
Importing WSDL and Schema
We have created a "Test Project" project. Now you can import WSDL and XSD into it.
- Select the project and then from the context menu select Import.
- Please select File System v General.
- Select the directory where WSDL and XSD are stored.
- Select 2 files (DemoWebServiceService.wsdl and DemoWebServiceService_schema1.xsd) and click the button Finish.
WSDL and schema overview
We now have a project with WSDL and XSD. You can double-click the left mouse button on the WSDL to view the WSDL in Design and Source mode. In Design mode, you can render a Web service with inputs and outputs.
In Source mode, you can view and edit the WSDL in a text editor.
If the XSD files cannot be opened in the XSD editor, they can be opened in the XML editor by choosing Open With> XML Editor in the context menu of that XSD file.
We have opened DemoWebServiceService_schema1.xsd in an XML editor.
Creating a SOAP message
So we have the WSDL and schema ready to validate the correctness of SOAP messages. Let's start testing the Web Services Validation Tool for WSDL and SOAP with a SOAP message. You need to include the SOAP message in your project. The SOAP message must be contained in a .xml file to be validated.
- Please select New> XML to create a SOAP message in the project.
- Please select Test Project for the parent folder of the new SOAP message. If the file is not already selected, enter "DemoSOAPMessage.xml" in the File name and press the button Finish.
The program automatically invokes the XML editor with the new XML file. It contains nothing but a string with the version and xml encoding. It's good that we have at least something before starting to create a SOAP message from scratch. Do you know how to compose a SOAP message? Do not worry. In the next section, we'll walk you through the steps to create one.
To create a SOAP message, you can invoke the "hello" service using the "parameters" parameter with my name, "Jinwoo". You can of course use your own name. The namespace is http: // demo /. Be careful - it is written as http: // demo /, not http: // demo, this is essential.
Listing 5. HelloWorldSOAPmessage.xml
Do you see problems in this SOAP message? If so, don't worry. We'll deal with this later.
SOAP message transmission
Are you ready to send a message to the web services server?
- Select SOAP message and select
- In the Transmit SOAP Request and Receive SOAP Response window, you can fill in Service Address, SOAPAction and Content-Type... In this application, we do not need to specify a SOAPAction because we used an empty string "" for the soapAction attribute in the bind section of the DemoWebServiceService.wsdl file.
- Enter http: // localhost: 9081 / HelloWorldWSProject / DemoWebServiceService in the box Service Address if the server is running on the local computer on port localhost: 9081. Otherwise, you must enter the real address where the Web service is available.
- Please select text / html for the field Content-Type.
- Click the button OK to send the SOAP message to the server.
Receiving a SOAP message
If the server is up and running, you should receive a SOAP response. If you don't receive a response, check that the address and content type are correct.
Validating the correctness of a SOAP message
Fine! We have accepted a SOAP response. It is also saved in the project. But wait. Do you see something is wrong? We got "Hello, buddy!" instead of "Hello, Jinwoo!" Something went wrong? Have no idea?
Unfortunately, the web services server didn't let us know what was wrong. No warnings. A situation where unpredictable SOAP responses are sent and the web services server has no idea what is going wrong can be very dangerous. Even recipients of SOAP responses may not notice the problems in the SOAP message in question.
The Web Services Validation Tool for WSDL and SOAP helps you determine what is going wrong.
Listing 6. Answer
- Select the SOAP reply message and click Validate.
The Web Services Validation Tool for WSDL and SOAP found an error in the SOAP message.
Invalid SOAP message: cvc-complex-type.2.4.a: Invalid content was found starting with element "parameters". One of "(arg0) is expected.
Editing a SOAP message
- The program complains about the value of "parameters". Change it to arg0 and save.
Listing 7. Modified SOAP message
- Check the correctness of the modified SOAP response message. No more error messages appear.
- We are now ready to send the modified reply message to the server. Select SOAP message and then select Transmit SOAP Request and Receive SOAP Response.
- In the Transmit SOAP Request and Receive SOAP Response window, enter http: // localhost: 9081 / HelloWorldWSProject / DemoWebServiceService in the Service Address if the server is running on port localhost: 9081.
- Please select text / html for the field Content-Type and press the button OK.
This time, as expected, the correct answer arrives.
Listing 8. SOAP response
Invalid namespace detection
What happens if you send a message with the wrong namespace?
- Change the namespace to http: // demo2 / and save the post.
Listing 9. Changing the namespace
- Then you can send the request to the server.
You will see IOException: Server returned HTTP response code: 500 for URI: http: // localhost: 9081 / HelloWorldWSProject / DemoWebServiceService.
The web services server returned IOException information in its response, but the information was insufficient to detect the error. Check the correctness of the message using the toolkit if you want more detailed information to solve the problem.
The program says: "Invalid SOAP message: cvc-complex-type.2.4.a: Invalid content was found starting with element 'ns0: hello". One of "(" http: // demo / ": hello," http: // demo / ": helloResponse)" is expected ".
This message indicates that http: // demo / is expected. This is what we need to find out, not the HTTP 500 response code.
Validating the correctness of encrypted SOAP messages
What if your SOAP messages are encrypted? No problem if you have keys and passwords. Just select the SOAP message and Validate just like it is done for any other regular SOAP message. If your SOAP message is encrypted, a prompt similar to the one shown in Figure 35 will appear on the screen.
At the time of this writing, 3 types of keystores are supported:
- Java Key Store (JKS).
- Java Cryptography Extension Key Store (JCEKS).
- Personal Information Exchange Syntax Standard (Public Key Cryptography Standards # 12).
You need to provide information about your keystore: file name, file type and password. If the information is correct, you must choose a key and password. You can also find information about your keystores and the list of keys and certificates in the keystore, such as keystore type, provider name, provider version, provider information, key type, creation date, certificate type, algorithm, and format.
If all information is correct, the program will generate a decrypted SOAP message and check its correctness.
The following encryption algorithms are currently supported:
- Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) mode with initialization vector (128/192/256 bits).
- Advanced Encryption Standard (AES) Key Encryption (128/192/256 bits).
- Triple Data Encryption Algorithm Modes of Operation (triple-DES) Key Encryption.
- Triple Data Encryption Algorithm Modes of Operation (triple-DES) Key Encryption in Cipher Block Chaining (CBC) mode.
- RSA Cryptography Specifications Version 1.5.
- RSA Optimal Asymmetric Encryption Padding (OAEP) is a method with a mask generation function.
Validating Digitally Signed SOAP Messages
What if your SOAP message is digitally signed? Just select SOAP message and then select SOAP Message Digital Signature Verification.
If the digital signature is correct, you will see the following screen:
Otherwise, the program will report an error in the signature. The following digital signature specifications and algorithms are currently supported:
- Secure Hash Algorithm 1 (SHA-1)
- Hash Message Authentication Code (HMAC)
- Digital Signature Algorithm (DSA)
- Public-Key Cryptography Standards (PKCS # 1)
- RSA Encryption Algorithm with Secure Hash Algorithm (SHA-1)
- Canonical XML Version 1.0 and 1.1
- XSL Transformations (XSLT) Version 1.0
- XML Path Language (XPath) Version 1.0
- Base64
Access to the US National Weather Bureau service using a SOAP message
The simple web service we've created and tested works fine. Can this program be used in a "real" environment? You can try using a real U.S. National Weather Bureau Web service provided by the U.S. National Oceanic and Atmospheric Administration (NOAA).
- Create a project.
- Create the XML for the SOAP message.
The US National Weather Bureau provides many different Web services. You can try working with the NDFDgenByDay service, which provides weather forecasts for a point with a given latitude and longitude.
To access NDFDgenByDay, you need to provide the following information:
Table 1. NDFDgenByDay
| Service Name | NDFDgenByDay |
|---|---|
| Endpoint | http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php |
| SoapAction (SOAP Action) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay |
| encodingStyle (encoding style) | http://schemas.xmlsoap.org/soap/encoding/ |
| Namespace | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl |
| latitude | Decimal |
| longitude | Decimal |
| startDate (start date) | date |
| numDays (number of days) | Integer |
| format | Line |
In this example, we want to create a SOAP request to get a weekly forecast for a location with coordinates (LAT38.9, LON-77.01) starting from 2010-07-23 in a 24-hour format:
Listing 10. SOAP request
We did not specify a namespace because the service worked without it. If you run into any problems with the namespace, please set it up.
Select a message and Transmit SOAP Request and Receive SOAP Response For more information, see the Web Services Validation Tool for WSDL and SOAP.
Table 2. Request for information
| Name | Meaning |
|---|---|
| Endpoint | http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php |
| SoapAction (SOAP Action) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay |
| Content-type | text / xml; charset = utf-8 |
The forecast data is now much easier to read.
If you find this tip uncomfortable, you can use your own HTML formatting method. Most Web services offer results in XML format, so you don't have to do this all the time.
Conclusion
We created, transformed, received, and validated SOAP messages using the Web Services Validation Tool for WSDL and SOAP. It can pinpoint problems that most Web services servers cannot even detect, which can have serious consequences in real life. Using this program during the development phase allows you to reduce the time to troubleshoot problems during operation.
Web services in 1C
This article will consider the integration of 1C with existing web services and the use of 1C itself as a web service.
In this case, web services will mean systems operating on the Internet and providing interaction with them not only via SOAP (which is exactly a web service), but also in other ways, including ordinary HTTP (S) requests.
Risks of using 1C web services
Implementation of web services appeared in the 1C81 platform.
But their use is fraught with risks:
- 1C8 does not work well over HTTPS, there are no diagnostic tools, so it is sometimes impossible to understand why, with a certificate, the service does not want to work over HTTPS. Exit - implementation of web services via CURL or setting up an HTTPS tunnel.
- 1C8 adheres to its own rules for validating WSDL schemas. Sometimes, for some unexplained reason, the WSDL schema does not want to be loaded into the WS link. You can find out the reason only on the partner forum from one specialist. There are no diagnostic tools for the WSDL schema, nor is there even a reason or line at which schema loading is interrupted.
Rules for building sales services
The client is issued a sales document (check) only if the service transaction was successful. Otherwise, a situation is possible when the client receives a check and will be confident that he received the service, but in fact it is not.
Using external SOAP services
SOAP web services use WSDL schemas and XDTO objects to represent data.
Loading WSDL
In order to use an external service, you need to load its WSDL schema.
Checking the validity of the WSDL schema
Sometimes the WSDL schema is not loaded into 1C. You can check the validity (correctness) of a schema with any WSDL schema validator, for example http://www.validwsdl.com/.
You need to upload the schema to some http site (you can use ftp) and specify the address of the file into which the schema is loaded:
Features of loading WSDL in 1C
The peculiarity of loading WSDL in 1C is that valid schemes may not be loaded. There is no built-in validator, so you have to look for an error using the destructive analysis method, sequentially reducing the number of elements in the circuit. You can, for example, delete the description of a web service.
Processing for testing a running external web service
To test a working external web service, use the "ArbitraryWebService.epf" processing from the package for this article.
Testing can be used as an example of the Morpher service that declines names (the service address is http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):
In this way, you can test any service that has simple entry points containing parameters of simple types: number, date, string.
In processing, you can also specify the login and password that are required to authorize access to the web service.
Standard Service Debugging Tools
For debugging, you can use the SoapUI program, which can send an arbitrary request to a web service and receive a response from it.
SOAP and HTTPS
Unfortunately, SOAP in 1C behaves quite capriciously when working through the HTTPS protocol, practice shows that it is impossible to achieve an HTTPS connection, although the possibility is declared in the platform. Affected by the lack of diagnostic and debugging tools to find out the reasons for which the connection is not established. Therefore it is convenient to use SOAP over CURL.
The built-in mechanism for using HTTPS implies that all certificates must be published in a common pem file in the 1C program directory.
Using 1C as a service
Rules for developing a service based on 1C
Operation "Hello"
It is good practice to create an operation in the service that informs that the service is available. This makes life easier for integrators, it will be easier for them to check if the connection with the service is established.
For example, you can use the no-parameter Hello operation that simply returns the boolean value True.
Publishing a web service
The procedure is well described in the documentation: file: /// C: /Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634:
The task of publishing Web services is reduced to placing the configuration files * .1cws of Web services in the appropriate directory of the web server with the appropriate settings for the web server. In order to publish Web services, execute the menu command “Administration | Publishing Web Services ".
This command will open the Web Services Publishing window.
The Web Services Publishing Window contains the path to the web server and two lists:
- "Web services" - a list of configuration Web services;
- "Publish" is a list of web services published on the specified web server.
Using the "Connect ..." button, you should specify the web server on which you want to publish the web services.
The window for selecting the path to the web server allows you to specify the path in two ways:
- on the "Files" tab - this method is used when publishing is performed on the same computer on which the web server is installed. The path is the local directory corresponding to the Internet page from which the published Web server will be called;
- on the "FTP site" tab - this method is used when you need to publish a Web service on a remote computer. To publish, you need to specify the parameters of the FTP connection with the remote computer and the directory in which the Web service will be published.
The publication of the selected Web service is carried out using the "Publish" button
To unpublish a Web service, use the Delete button.
You can publish to a local directory or via FTP. You can also publish to a remote server using a UNC path if the remote server is part of the local network.
After publication, the web service is available at the address "http: //localhost/test.1cws" or "http://xxx.ru/test.1cws", where xxx.ru is the address of the remote server and localhost is the typical address of the local server.
Authorization to the 1C web service
To access the service, you need to authenticate.
Authorization issues are well covered here: http://www.forum.mista.ru/topic.php?id=341168 and in the documentation file: /// c: /Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm
Usually, a web service operates under one specific user (more often, a specially created one). You can "attach" the 1C user by means of Windows authentication to the Windows user IUSR_ (disable 1C authorization for the user). Alternatively, you can clear the list of 1C users, then authorization is not required.
If several users are required, then you can create several logins for the web server, bind a Windows user to each of them and, accordingly, register access to Windows users in 1C.
In the properties User and Password of the WSProxy object, not the 1C login is used, but the login of the web server user.
1C web service testing
To test 1C as a web service, use the "TestAbinaryWebService.epf" processing as described in the "Testing a working external web service" section.
The 1cws file is the WSDL description of the 1C web service.
Use of services in Retail
Typically, retail services are used to provide various services to the population - accepting payments, repaying loans, money transfers, purchasing software, etc.
At the same time, a check is generated for the service provided in 1C, in which the transaction parameters are saved. After that, this check is printed to the client with detailed information about the service provided. It is possible to print a preliminary check in order for the client to confirm the data entered from his words with his signature.
The service can be integrated in various ways into a retail program written in the 1C language (UT, Retail and others):
- Processing or code can be written in the 1C language that does all the work with the service.
- A program can be used that works with the service, and in 1C it transmits only information for breaking through checks.
Organization of service data in 1C
To store information about a transaction in a receipt, you need to create an additional tabular section "Complicated sales" with the following details:
- Nomenclature - binding to the check nomenclature.
- Parameter - a link to the "Complex sales: Parameters" reference book.
- Value - the value of the parameter, complex type. The string representation must be quite long (1024 characters) to accommodate the receipt text.
Reference book "Complex sales: Parameters" contains a list of transaction parameters.
The tabular part is more profitable to use than a set of attributes, since a transaction can have a lot of them, and in other receipts not related to the service, these details will not be used and will take up extra space. In addition, such a solution is universal for any service and does not require data restructuring after the introduction of a new service.
A separate bookmark is made for the seller (or a printed form, so as not to change the configuration), in which he can see the plate of the transaction details for the check.
Using processing in 1C language
Let's take a look at the example of a conditional Paym service for the "Retail" configuration.
- Let's add a predefined item "Paym" to 1C. In 1C: Enterprise mode, after updating the configuration, he needs to assign the product type "Service".
- In the procedure "Add an item to tab. part "of the" Registration of sales "form module, we call the processing of work with the service, written in the 1C language. In case of successful payment, write down and post the check:
- The processing should print the ancestors (if required), fill in the tabular section of complex sales and prepare the text for printing the receipt in the predefined "PaymCheckText" variable.
- In the procedure "Post and print a check" of the check module, we replace the name of the product with the one saved in the requisite for the check. The text is substituted only for the sale, for the return, just the name of the service is printed, as usual.
A separate question is how to ensure the completeness of the transaction. Those. if the transaction went through the service, how to make sure that it is not lost in 1C. The most optimal way is to reconcile registries. But this is a subject for separate consideration.
Using programs integrated with 1C
XDTO
XDTO is often used in web services. Here are the most important tips and recipes for using XDTO in 1C.
XDTO in 1C platform
XDTO packages described in the "XDTO objects" branch of the configuration are available for creating types and objects in the global XDTO Factory factory. This is not immediately apparent.
Some types in the schema do not have a name; to get them, you have to walk through the type hierarchy.
The example described the System list containing XDTO structures. To create the structure itself, it was necessary to get its type in the same way:
Type = Factory.Type ("urn: my.ru: MasterData: Business", "Business"). Properties.Get ("System"). Type;
Frequent problems with XDTO
Different XSD Schema Formats
In some formats, tags are called xs :, in some xsd :, but 1C successfully understands both formats. Once there was a situation that XSD was normally imported into 1C without errors, but did not create a single package. The reason was the absence of the attribute targetNamespace at the tag, respectively, 1C did not know in which package to place the scheme, but it did not give any errors.
Maintenance of services
Considering that a service is a combination of two systems - 1C and an external one, errors can be in both systems, which reduces the overall reliability of work.
In order to make it easier to understand the reasons for service failures, it is recommended to use a set of measures.
Logging requests
Links
- XDTO
- Good description of XDTO http://pro1c.org.ua/index.php?showtopic=214
- Free interesting web services:
- Aeroflot - information about the flight schedule
- Morfer - name declension http://www.morpher.ru/WebServices/Morpher.aspx
- Unassembled:
- Installing and using Web services
- v8: how to change the apache config file?
- v8: continuation of the topic with web services - I can not connect the web service
- v8: further I crawl through web services - I cannot create a proxy ...
- Knowledge book: v8: Using external web services in 1C: Enterprise 8;
- Installing and using Web services
Nowadays, it is rare for a modern application to do without an API. This is true both for a simple site and for highly loaded distributed systems. API testing is one of the main tasks in the quality assurance process. Unsurprisingly, the demand for testers who can test APIs is increasing day by day. In this course, you will gain an understanding of the methods, tools and approaches in API testing, acquire the necessary knowledge, which will undoubtedly have a beneficial effect on your cost as a testing specialist.
This course will be useful for students familiar with the basics of software testing who want to grow further and improve their skills.
Course program:
Lesson 1. Introductory. SOAP protocol
- Briefly about the lecturer;
- Objectives of the course;
- What are API, WS and why are they needed;
- The role of API testing in the quality assurance process;
- Review of WS Testing Toolkit;
- Methods used in testing WS;
- SOAP history;
- Terminology and main concepts (XML, XSD, Endpoint, WSDL).
Lesson 2: SOAP Protocol. REST architecture
- Terminology and basic concepts (UDDI, XSLT, XPath, XQuery, HTTP methods, HTTP statuses);
- SOAP structure and main components;
- Scope of application;
- Features of work;
- Advantages and disadvantages;
- Features of REST architecture;
- Terminology and main concepts (WADL, RESTful, JSON, JSONPath);
- REST principles;
- Status code and main statuses;
- CRUD verbs;
- Advantages and disadvantages.
Lesson 3. Acquaintance with SoapUI. Working with a REST project
- Java installation;
- Installing SoapUI;
- Overview of the main elements of the interface;
- Connection of a training project;
- Review of project methods;
- Sending a request and analyzing the received response;
- Study of the available web services of the project;
- Drawing up a test plan;
- Writing test cases;
- Elements “TestSuite”, “TestCase”, “TestSteps”.
Lesson 4. Working with a REST Project (XML)
- Block "Assertions";
- Running tests at different levels;
- Element “Properties”, basic features;
- Working with Properties;
- Element “Property Transfer”;
- Working with Assertions.
Lesson 5. Working with a REST Project (JSON)
- Conditions and Branches;
- Working with Assertions;
- TestRunner, features of work;
- Running TS, TC from the command line;
- Working with Test runner;
- Working with Groovy scripts.
Lesson 6. Working with Groovy Scripts
- Working with static and dynamic data;
- We generate test data;
- We get data from “Properties”;
- Data recording and transfer;
- Conditions and Branches;
- Script Assertion.
Lesson 7. Additional features
- Connecting external libraries and custom classes;
- Mock services;
- Why do we need Mock services;
- An example of working with a Mock service;
- What about CI?
- Install Jenkins;
- Running a Jenkins project.
SOAP (Simple Object Access Protocol) is a standardized protocol for transferring messages between a client and a server. It is usually used in conjunction with HTTP (S), but it can work with other application layer protocols (for example, SMTP and FTP).
SOAP testing from the point of view of testing techniques is not fundamentally different from working with other APIs, but it requires preliminary preparation (in terms of protocol theory) and special testing tools. In this article, I would like to formulate a small checklist of necessary knowledge and skills, which will be equally useful for both a SOAP tester (who often does not know "what to grasp" after setting a problem), and a manager who is forced to evaluate the knowledge of testers and develop plans for training.
Theoretical basis
The fact that SOAP is a protocol is important for testing: you need to study the protocol itself, the "primary" standards and protocols on which it is based, and (as needed) existing extensions.
XML
XML is a markup language similar to HTML. Any message sent / received via SOAP is an XML document in which the data is conveniently structured and easy to read, for example:
Don't forget to write an article!
More details about XML can be found at w3schools or codenet (in Russian). Be sure to pay attention to the description of namespaces (a method of resolving conflicts when describing elements in XML) - their use is necessary in SOAP.
XSD
When working, it is always convenient to have a standardized description of possible XML documents and check them for correct filling. For this, there is an XML Schema Definition (or XSD for short). The two main features of XSD for a tester are the description of data types and the imposition of restrictions on possible values. For example, the element from the previous example can be made optional and limited to 255 characters using XSD:
...
...
SOAP extensions
You may also come across various SOAP “extensions” in your work — standards like WS- *. One of the most common is WS-Security, which allows you to work with encryption and electronic signatures. Often, WS-Policy is used along with it, with which you can manage the rights to use your service.
Example using WS-Security:
All of these extensions are quite complex constructs that are not used in every SOAP service; Studying them in detail at the initial stage of learning SOAP testing is unlikely to be relevant.
Instruments
As you already understood, SOAP is a serious business, to work with it you need to know the theory and numerous standards. In practice, this complexity would lead to very noticeable labor costs (for example, it would be necessary to look at the diagram in a notebook every time and send requests with curl). Therefore, tools have been created to make it easier to work with SOAP.
XML / XSD Editors
A good tester starts testing at the stage of writing the documentation, so it is convenient to use special editors to check the circuits. The two most famous are Oxygen (cross-platform) and Altova (Windows only); both of them are paid. These are very powerful programs that analysts actively use when describing services.
In my practice, three features of the editors turned out to be useful: XSD visualization, XML generation from XSD, and XML validation against XSD.
1. XSD visualization is needed for a visual representation of the scheme, which allows you to quickly isolate the required elements and attributes, as well as existing restrictions. For example, for a CheckTextRequest, the text element is required, and all three attributes are optional (with the options attribute set to zero by default).
Visualization is necessary when there are many types and constraints in the schema. If you just want this and don't want to pay for custom editors, then you can consider free alternatives (like JDeveloper).
2. Generating XML based on XSD useful when you want to see a valid example of a message. I use it to quickly experiment with the possible filling of the message and check the nuances of how constraints work.
3. After using the feature from point 2, it is useful to conduct XML validation against XSD- that is, check the message for correctness. Together, features 2 and 3 allow you to catch tricky defects in the XSD even when the service itself is under development.
Testing tool - SoapUI
SOAP testing almost always means using SoapUI. You can read about the use of this tool in different sources (,), but the most effective way is to familiarize yourself with the official documentation. I distinguish 8 conditional levels of SoapUI proficiency:
Level 1 - I can send requests
Learn to create a WSDL based project. SoapUI can generate all the necessary queries for you; you just have to check the correctness of their filling and press the "Send" button. Once you have developed the skills to create correct queries, you should master the art of forming incorrect queries that cause errors.
Level 2 - I can do Test Suites and Test Cases
Start doing mini-autotests. Test suites and test cases allow you to create API test scripts, prepare data for requests, and automatically check the received response against what is expected. At first, they can be used simply as collections of queries. For example, if you have introduced a defect and want to quickly check it after fixing, you can select a separate test kit specifically for defect requests.
Level 3 - can write Assertions
After mastering the test cases, it will be useful for you to learn how to make them automatically checkable. After that, you will no longer need to look for information about the answer with your “eyes”: if there is an automatic check, the cases will be marked green (if the check is passed) or red (if it is not passed). SoapUI provides a large set of possible assertions, but the most convenient and simple ones are Contains and Not Contains. With their help, you can check the presence of a specific text in the received response. These checks also support regular expression searches.
Level 4 - using XPath and / or XQuery in Assertions
For those who are a little familiar with UI using Selenium, XPath is a familiar thing. Roughly speaking, XPath allows you to search for elements in an XML document. XQuery is a similar technology that can use XPath internally; this language is much more powerful, it resembles SQL. Both of these languages can be used in Assertions. Checks with their help are more targeted and stable, so your cases will be more trusted.
Level 5 - can write complex tests using special steps
Test cases can contain not only one request, but also several (for example, when you want to emulate a standard user scenario “create an entity” → “export an entity”). There may be other special steps in between requests, for example:
- Properties and Property Transfer (help to reuse data and transfer it between requests);
- JDBC Request (used to get data from the database);
- Conditional Goto (allows you to make branches or loops in a test case);
- Run TestCase (helps to bring some typical queries into separate test cases and call them where needed).
Level 6 - using Groovy scripts
SoapUI allows you to write Groovy scripts in a variety of places. The simplest case is generating data in the query itself using $ (=) inserts. I use inserts like this all the time:
- $ (= new Date (). format ("yyyy-MM-dd'T'HH: mm: ss"))- to insert the current date and time in the required format;
- $ (= java.util.UUID.randomUUID ())- to insert a correctly formed random GUID.
Complete scripts can be used as steps in cases and checks. At some point, you will find that several special steps from the fifth level can be replaced with one script at once.
Level 7 - using MockServices
SoapUI based on WSDL can generate Mock objects. A mock is the simplest simulation of a service. With the help of "mocks", you can start writing and debugging test cases even before the service is actually available for testing. They can also be used as "stubs" for temporarily unavailable services.
Level 8 - God SoapUI
You know the difference between the paid and free versions of SoapUI and use the SoapUI API in your code. You use plugins and run cases through the command line and / or CI. Your test cases are simple and easy to maintain. In general, you "ate the dog" on this instrument. I would be happy to talk to someone who has mastered SoapUI at this level. If you are such - unsubscribe in the comments!
Testing with programming languages
I will give an example of how a request to the YandexSpeller API looks like, made using groovy-wslite:
import wslite.soap. *
def client = new SOAPClient ("http://speller.yandex.net/services/spellservice?WSDL")
def response = client.send (SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
body (
CheckTextRequest ("lang": "ru", "xmlns": "http://speller.yandex.net/services/spellservice") (
text ("thorn")
}
}
}
assert "error" == response.CheckTextResponse.SpellResult.error.s.text ()
assert "1" == [email protected]()
As far as I know, there are no high-level frameworks (like Rest-assured) for testing SOAP yet, but an interesting tool has recently appeared - karate. It can be used to describe cases for SOAP and REST testing in the form of scripts like Cucumber / Gherkin. For many testers, turning to karate will be an ideal solution, because such scenarios in terms of the complexity of writing and maintaining cases will lie somewhere in the middle between using SoapUI and writing your own SOAP testing framework.
Conclusion
You probably won't ever want to test SOAP for yourself (as you might with REST). It is a heavyweight protocol used in serious enterprise solutions. But its heaviness is at the same time a gift to the tester: all the technologies used are standardized, there are high-quality tools for work. All that is required of the tester is the desire to learn and use them.
Let's put together that checklist of necessary skills for a tester. So, if you are just starting to test SOAP services, you need to know and be able to use:
- WSDL.
- SOAP.
- XML / XSD editors (at the XSD rendering level).
- SoapUI at level 1.
As you can see, the main focus is on the study of standards, in SoapUI it is quite simple to be able to execute queries. As you immerse yourself in SOAP testing, you will be faced with tasks that will require more serious skills and knowledge, but you should not try to learn everything at once. Consistency in increasing the level of complexity of the tasks performed is much more important. By following this recommendation, one day you will realize that you have become a good specialist in this field!
