WATS offers 2 main hosting options, as a SaaS cloud or an On Premises installation. The SaaS Cloud service is maintained by Virinco and hosted in Microsoft Azure (multiple sites). The On Premises version is installed at the customers server environment (customers cloud or on premises servers).
Both options are an application that offers functionality for handling test and repair data. Data is stored centralized in a database/lake/warehouse.
Online dependencies may apply for both options and may be affected by hosting environment, network issues, software bugs, etc.
Writing and reading data to and from WATS is performed in 2 main ways, using the WATS Client or using the rest API.
The Rest API is commonly used to integrate WATS with other server applications (ERP, PLM, PDM, MES, etc.), other reporting applications (PowerBI, Tablou, Minitab, etc.) or to read/write reports (Test or Repair).
When using the rest API, the user may read and/or write data to WATS. The user must use 3rd party application that connects securely with the rest API and handles the communication. As an example, if you try to upload a report to WATS and the connection or transfer fails, the 3rd party application must handle error scenarios and retransmits.
The WATS Client (Client) has a rich API used to communicate with the WATS Server application. The API is split in 2 main sections: TDM and MES. TDM mainly handles the Test (UUT) and Repair (UUR) reports. MES mainly handles meta data like Unit information, Software Distribution, Asset, Workflow, etc.
Most commonly, the WATS Client handles upload of test and repair reports from 3rd party test applications securely to the WATS Server. The Client has built in robustness for handling poor network connections and offline support.
Functions may be used to read or write data to WATS and require an online connection. As an example, you may search and download a UUT report from WATS to use in your test application. This may be useful to get measured values from previous processes or to get status of a UUT report.
Making your application dependent to an online connection
Using the rest API, or certain functions in the Client in your (test) application, will make the application dependent to an online connection to WATS.
This is often not unique to WATS, as your application may relay on connection to multiple resources during execution.
It is a substantial decision to make this dependency, as there is always a risk that your application cannot connect to the server application, either caused by network issues, hosting issues or software issues.
When it works as expected, it may offer great value-add to your application. When it doesn’t work, it may stop testing and production completely.
WATS take measures to reduce the risk as listed in the next section, but you as the user and developer should also consider adding some functionality to reduce that risk:
- Have a “disaster plan” if connection fails. Normally you use data from WATS to improve testing, process, production or process. If your application is depending on a WATS connection, consider implementing a “fail over” switch to allow “offline” execution to continue testing.
- Even though many WATS features have built in robustness, consider adding additional robustness to your code (reconnect, retry, etc.)
- If possible, make options to allow a human or operator to add information or amend a process manually if needed.
How WATS reduces risk of online dependencies
WATS has several features and methods to reduce the risk of online dependencies, as listed below:
- WATS Cloud is hosted in a professional and modern way using Microsoft Azure and many of its features to ensure robustness and maximize uptime.
- WATS Cloud offers hosting in several regions globally to bring the data closer to your site.
- The WATS Client has methods to support offline functionality, like buffering reports to upload, download serial numbers/mac addresses to a local storage, allow execution of software packages locally, add Asset data to UUT reports, etc.
- WATS Cloud offers Regional Servers. This is a second cloud account that is a synchronized “slave” to the master account. As example, your master account may be hosted in central Europa, and you have a connected WATS Regional Server in East Asia to serve your connected stations and factories in Asia for faster connection. This also allow separate user access to different accounts.
- WATS offer Local Servers. As above, a WATS Local Server is a synchronized “slave” to the master server, but installed on the factory network. The benefit is that all clients are connected to the local server and do not need 24/7 online connection to the master server. The disadvantage is the effort maintaining the server.
Thanks for taking the request seriously. I think the easiest way for us as a user, is to build some retry in our test code. or add the server connection check at the initialization in the test programmes.
But I would also like to look into the option of the local server, which will probably offer a bit more flexibility on our application. Of course, this will require some maintenance to be done regularly at the sites.
Please sign in to leave a comment.