The webservices of Exact Synergy Enterprise(ESE) are a
series of IIS hosted webservices that run in the same application pool as the
Synergy website that the services are related to. They are used to Create,
Retrieve, Update and Delete data and manipulate the workflow of requests within
an ESE database by software that is developed either by Exact as a separate
module running outside of EGN, or a 3rd party as part of their
solution.
Sometimes calls to the web services malfunction, resulting
either in error messages, or incorrect data being created. The steps outlined
below will help in determining if this behavior is caused by installation
problems or a bug in either the services, ESE or the external solution.
1. Check if Synergy is running
Because the web services are hosted by the exact same
process as ESE, operation of the process can be checked by functionally opening
ESE. In most cases, if ESE runs properly, so will the web services, and if the
web services malfunction, so will ESE. This can also be the easiest way to test
if the credentials that are to be used by the web service client are sufficient
to access ESE. If ESE itself is malfunctioning, follow one of the
troubleshooting guides for ESE itself, or contact Support.
2. Check if the service is listening on the
administration’s address.
In a few cases, ESE will work properly while the web
services fail to respond. The easiest way to test if the services themselves
are responsive is to open one of the endpoints related to Metadata. Because
these endpoints bade their behavior on XML files in the ESE installation rather
than the database, these are less likely to be affected by rights or
configuration issues.
To test if the services are responsive, open your web
browser on the client machine, and browse to services/Exact.Metadata.svc,
on the URL of your Synergy installation. If the service is listening, you
should get a help page similar to the one below.

The REST based endpoint can be tested by browsing to Exact.Entity.REST.svc,
which should give a response similar to the one shown below:

The request flow service can be tested by browsing to
Exact.RequestFlow.REST.svc. It should give a response as shown below:

3. Check if SVC handler mappings are defined.
One of the most common reasons why the web services
malfunction while ESE itself works is due to missing handler mappings. While
these mappings are automatically added by installing the .NET frameworks
mentioned in the system requirements of ESE, it is possible to remove them,
which will prevent the web services from being activated.
To check if SVC handler mappings are defined, open the IIS
manager on the web server go to the server properties, and under the IIS
section, to Handler mappings. If properly definied, the list should look
something like this:

If these are missing, the easiest way to re apply them is to
re install or repair the .NET framework.
5. Check if WCF Data services are installed.
In order for the REST based endpoints to work, it is
necessary to have WCF Data services 5.0 (OData v3) installed. This can be
checked in Programs and Features and if missing needs to be installed
separately from the MSDN website of Microsoft.
6. Make sure SQL Server is running in Mixed
authentication mode.
Due to some limitations with impersonation, the web services
will always use the built in standard account to authenticate with SQL server.
The supplied windows credentials are then used for authorization within the
administration. This only works if the database server is configured to support
mixed authentication. This can be verified by logging into the SQL server with
SQL Server Management Studio, opening the properties of the server itself, and
going to the Security tab. Make sure both Windows and SQL Server Authentication
are enabled as shown below.

7. Make sure the user baco exists.
Because the web services of ESE and EGN share the same
framework, both are set up to use the same standard user, baco, to access the
database. This user is automatically created the first time a database is
created on a database server instance, but when the ESE database has since been
migrated to a new server instance, it is possible this user is no longer
present. This can be checked in the SQL Server Management studio. If it is
missing, please contact Support for instructions on how to re create it.
8. Test the behavior of the service using a thin test
application
If the services are accessible, but the problem is related
to their behavior when data is entered or requested (Outside of workstation
authorization as mentioned above), it will be necessary to test the behavior of
the services by performing requests with a program that contains as little
solution specific logic as possible. This prevents unnecessary clutter where it
is unclear if the behavior is caused by a problem in the business logic of the
web services itself, or caused by a business logic glitch in the solution.
Within Exact, most issues regarding the web services are tested using a
dedicated test application called ConnectivityClient.exe. A copy of this tool is attached to document 27.578.963. While that document is geared toward Globe, the tool can also be used to test the SOAP web service of ESE.
If it is needed to test the REST based endpoint or the
RequestFlow service, the best tool to do this is SOAPUI, an open source test
client made by SmartBear. It can be downloaded from https://www.soapui.org/.