There are times where Sage X3 web services will not work, or will stop working. Below are some useful tips that can be followed to troubleshoot, and get web services up and running again.
X3 Menu – Development > SCRIPT DICTIONARY > Scripts > Web services
If any changes are made to the Entry Transaction, Screen, Object or Windows associated with an object published as a web service, each of the changed entities (entry transaction, screen, object, window) must be re-validated, and the web service must be republished. When a change is made, the "Save" button will be enabled when the web service is pulled up, as shown below, and the web service will likely not be functional.
The value under "Number of Web service child processes must be at least 1.
X3 Menu – Administration > ADMINISTRTION > Servers > Hosts
A web service alias must be created for each endpoint that is consuming web services. The alias name is normally, but not always, the same as the endpoint name.
X3 Menu – Administration > ADMINISTRATION > Web Services > Classic SOAP pools configuration
In versions 8 and earlier, web service setup is done through the SAFE X3 Configuration console, which can be accessed by logging into the X3 server. The icon for the SAGE X3 Console is normally on the desktop, but may not be visible/available to all users.
The console is shown below.
Click "Safe X3 Webservice and ADC Server" to expand the web services section.
Click the "Webservices" icon. The example below shows that the SEED endpoint is set up for web services. Notice the (1) below the "X3PU8 – SEED". This indicates that the pool is up and running.
If the web services pool appears with a red asterisk next to it, there is an issue with one or more of the web service Parameters. Typically, the issue is with the X3 user/password or the OS user/password.
Click on the "X3PU8 – SEED – localhost" to view the details for this endpoint. Any of the values can be changed by double-clicking on the Value cell.
Pool.def.userid and pool.def.password – these both refer to the X3 user being used for the web services calls.
Pool.def.osuserid and pool.def.ospassword – these both refer to the Windows user ID and password.
The X3 user that the web services are running under must be set up to allow web services connection.
X3 Menu – Setup > USERS > Users
The web service can be tested by using the web service tester.
X3 Menu – Administration > ADMINISTRATION > Web Services > Classic SOAP Web services
After finding a published web service to test (Development > SCRIPT DICTIONARY > Scripts > Web services), go to the web services tester. In this example, the YSOH web service, which is published against the SOH object, is used.
Below is an example for testing an object-based web service.
Click the "CAdxWebServiceXmlCC link.
Click the down arrow to display the operations options.
Click "query" (object web services only).
Enter the Language, Pool alias and Public name (Web Service Name). Enter a list size > 0. Click "Invoke".
If data is returned in the Response tab, the web services are configured and running correctly.
For versions of X3 prior to PU9, the web services tester is accessed from the browser, using the following URL, substituting the X3 server name for x3server.domain. The web services tester must be run from Internet Explorer using the following website http:x3server.domain:28880/root
When the URL is entered, a Windows Security window appears.
The following user/password should be used:
User: sage
Pwd: sage
Select the WebService tester.
Select the Context tab, and enter the Pool entry Group, User id, Password and Language, then "Save Context".
Note: The user password in versions prior to 9 is not always the same as the X3 user password. By default, this value is either "admin" or blank.
Below is an example for testing an object-based web service.
If everything is set up properly, the results should appear below.
In X3 versions prior to update 9, web service licenses must be installed. 2 licenses are available for free, but are not installed by default. The licenses must be obtained from Sage and installed. If more than 2 licenses are required for these older versions, they must be purchased. 1 license is consumed for each endpoint defined, so if more than 2 endpoints are used for web services, or multiple pools need to be set up for one or more endpoints, more licenses would have to be purchased. The number of licenses installed can also affect whether the web service pools are running in older versions of X3.
From the X3 server, go to the Services, and make sure the SageX3_WEB services are running.
In some cases, the web services may be set up correctly, and work in the web services tester, but they are still not responding to the outside application. This is sometimes related to firewall settings which are preventing the inbound traffic to X3, using web services.
There are also some blog posts related to web services:
Web Services Series Part 1 - Setting up Web Services
Consuming X3 Web Services in PU9 and Later
Testing X3 Web Services in PU9 and Later
Contact us if you want to learn more about Sage ERP X3 Web Services features.
Want all 5 days in one comprehensive guide that you can download and take with you?
Leave your name below and we'll send you a copy of our Ultimate Guide to Sage X3 Web Services. This 38-page how-to manual provides everything you need to know about using X3 web services with screenshots, step-by-step instructions, and insider tips from our expert consultants.
[si-contact-form form='9']