In the first blog of our 5 Days of Web Services Series, we mentioned the importance of using web services, how they can provide real-time interfaces between your Sage X3 instance and external third-party or customer applications, and how to create a SOAP pool. The second blog focused on creating and publishing web services by exposing objects and creating subprograms. Today, we'll test the web services we created and published in the previous two blogs.
5 Days of Web Services Series:
- Day 1 - Creating a SOAP Pool
- Day 2 - Creating and Publishing Web Services
- Day 4- Consuming Web Services in .NET
- Day 5 - Consuming X3 Subprogram Web Services from .Net
Day 3 - Testing Your Published Web Services
Navigating to the Web Services Tester
Sage X3 Web Services can be tested in an interactive mode. The web service tester in Version 12 resides within the X3 menu and allows users to view the call parameters, make test calls, and view the results.
Once logged in to your Sage X3 web client, navigate to Administration > Administration > Web Services > Classic SOAP Web services.
The picture below is the initial screen for the web services tester. Click on the highlighted link ("CAdxWebServiceXmlCC") to display the STUB.
There is a field called “Url”. This URL will be used to consume the SOAP web services. Right-click on the URL and select "Copy link address" to get the full URL link for the X3 instance.
Return to the "Classic SOAP Web services" page by clicking the "Back" icon in the browser. Then select the "Down Arrow" icon located on the left.
Once again, select the "Down Arrow" icon located on the left to expand the list of operations.
As you can see in the picture below, there are twelve operations that you can choose from. The six most commonly used operations for subprograms web services and object-based web services are:
- Sub-program web services:
- Run: run a sub-program based web service.
- Object-based web services:
- Save: create a new record associated with an X3 object (i.e. Sales Order, Customer, etc.)
- Delete: delete an existing record associated with an X3 object.
- Read: read an object by record key.
- Query: query an object left list.
- Modify: modify/update an existing record associated with an X3 object (i.e. Sales Order, Customer, etc.)
Using the Web Service getDescription Operation
While in the SOAP generic web services operations panel, click on the "getDescription" link. This will open the window to get the web service description.
Although Public name is the only field required to call the web service test, we highly suggest filling in the language code, and pool alias fields as well. I'll define their purpose and the information I've entered in the example below:
- Language code: the language code for the web service
- Example: ENG
- Pool alias: the web service pool
- Example: DENISE
- Public name: the web service name
- Example: YWSCUSTLIS.
Once you've finished entering the information, navigate to the "Actions" button in the right-hand corner and select "Invoke" to display the web services XML description. 
The web services XML description can provide useful information for consuming the web service.
Calling an Object-Based Web Service from the tester
Several different operations can be called when using an object-based web service. The most commonly used operations are query, read, save, and modify.
Using the Web Service Query Operation
The Query operation allows you to query and return the left list of an object, which is the selection list on the left portion of an object window.
While in the SOAP generic web services operations panel, click on the "query" link. This will open the window to run a query from your objects list. 
Although Public name and List size are the only two fields required to run a query, we highly suggest filling in the Language code and Pool alias (and object keys if needed) fields as well. I'll define their purpose and the information I've entered in the example below:
- Language code: the language code for the web service
- Example: ENG
- Pool alias: the web service pool
- Example: DENISE
- Public name: the web service name
- Example: YWSSOH
- Object keys: this can be used to filter the results based on the left list values
- BPCORD = ‘FR004’ – returns all orders for customer FR004
- List size: this should be used to specify the number of items to be returned in the list
- Example: 10
Once you've finished entering the information, navigate to the "Actions" button in the right-hand corner and select "Invoke" to display the web services XML query results.
The web services XML query operation can provide useful information for consuming the web service. Below is a subset of the results. 
Using the Web Service Read Operation
The Read operation allows you to read an object by record key. It returns all of the fields you would normally see on the object window in an XML format.
While in the SOAP generic web services operations panel, click on the "read" link. This will open the window to run an object.
Although Publication name is the only field required to read an object, we highly suggest filling in the language code, pool alias and object keys fields as well. I'll define their purpose and the information I've entered in the example below:
- Language code: the language code for the web service
- Example: ENG
- Pool alias: the web service pool
- Example: DENISE
- Public name: the web service name
- Example: YWSSOH
- Object keys: this must be used to specify the key value for the object that is being read.
- Example: the Key is SOHNUM and the Value is SOWFR0110005.
Once you've finished entering the information, navigate to the "Actions" button in the right-hand corner and select "Invoke" to run the results.
This web services XML result can provide useful information for consuming the web service if you're looking to read an object by record key. (The GRP IDs in the XML represent the Screen IDs in Sage X3.)
Using the Web Service Save Operation
The save operation allows you to create a new record based on an object.
While in the SOAP generic web services operations panel, click on the "save" link. This will open the window to create a new record.
Although Public name and Object Xml are the only two fields required to create a new record, we highly suggest filling in the language code and pool alias fields as well. I'll define their purpose and the information I've entered in the example below:
- Language code: the language code for the web service
- Example: ENG
- Pool alias: the web service pool
- Example: DENISE
- Public name: the web service name
- Example: YWSSOH
- Object xml: this is the XML payload to create the record. Below is the full XML sent in this example.
Once you've finished entering the information, navigate to the "Actions" button in the right-hand corner and select "Invoke" to create the record.
The web services XML result will be displayed. When creating a new record, the new SOHNUM will be included in the result XML. Below is a subset of the results.
Using the Web Service Modify Operation
The modify operation allows you to modify an existing record based on an object.
While in the SOAP generic web services operations panel, click on the "modify" link. This will open the window to update a record.
Although Public name and Object Xml are the only two fields required to modify an existing record, we highly suggest filling in the language code, pool alias, and object keys fields as well. I'll define their purpose and the information I've entered in the example below:
- Language code: the language code for the web service
- Example: ENG
- Pool alias: the web service pool
- Example: DENISE
- Public name: the web service name
- Example: YWSSOH
- Object keys: when modifying an existing record, the primary object key(s) must be provided.
- Example: the Key is SOHNUM and the Value is SOWFR0110007.
- Object Xml: this is the XML payload to update the record. Below is the full XML sent in this example.
Once you've finished entering the information, navigate to the "Actions" button in the right-hand corner and select "Invoke" to modify the record.
The web services XML result can provide useful information for consuming the web service.
Calling a Sub-program Web Service from the Tester
While in the SOAP generic web services operations panel, click on the "run" link. This will open the window to run a sub program.
Although Public name and Input XML/JSON are the only two fields required to run a sub-program, we highly suggest filling in the language code and pool alias fields as well. I'll define their purpose and the information I've entered in the example below:
- Language code: the language code for the web service
- Example: ENG
- Pool alias: the web service pool
- Example: DENISE
- Public name: the web service name
- Example: YWSCUSTLIS
- Input XML/JSON: this is the formatted XML payload for the specific web service call.
- Notice that the NAM value corresponds to the input parameter in the subprogram. 1825 represents 5 years, so the past 5 years of customer additions and changes will be returned in the list.
Once you've finished entering the information, navigate to the "Actions" button in the right-hand corner and select "Invoke" to display the web services XML result.
The web services XML result will be displayed. Below is a subset of the results.
You have now learned how to use the web services tester to test both object-based and subprogram-based web services. This information is useful to ensure that the web services are working and also to test the XML payload and results of the web services, which is helpful when calling the web services from code such as .Net, Java and PHP.
Want More Sage X3 Features & Functions?
For some Sage X3 videos, head over to our YouTube page and subscribe to stay up-to-date with the latest insights and tutorials. Our channel is dedicated to providing valuable resources for businesses looking to optimize their financial management with Sage X3.
5 Days of Web Services Series:
Day 1 - Creating a SOAP PoolDay 2 - Creating and Publishing Web Services
Day 4- Consuming Web Services in .NET
Day 5 - Consuming X3 Subprogram Web Services from .Net
