Using Web Services in the Field

Dan Barad – Senior Application Engineer, Austin TX
Christopher Bode – STC Application Engineer, Austin TX

Introduction and Motivation

This article aims to help field engineers get more value from their FabGuard applications by explaining web services, what web services are offered by FabGuard, how they are used within FabGuard, and how to test before implementing.

The FabGuard Suite of products requires integration with data sources, factory systems, and other FabGuard components. Collection from data sources can use many different protocols (e.g., SECS/GEM, sensors, RV, OPC, Modbus, and NI), but factory systems primarily use SECS/GEM, RV, or web services. Many modern MES, SPC, and other factory systems support web services and publish APIs for using them. FabGuard IPM uses web services to get more logistics and send interdiction alarms from/to the MES. FabGuard Executive has a published web service API and FabGuard eOCAP uses web services extensively to create new and interact with existing eOCAPs and also to provide input to or output from logic trees. FabGuard APC supports the E133 standard, which is a web service call with XML content.

Background

Web Services

Web services are hosted by a machine to serve information or actions to a human or another machine. Usually, we use this as a way to automate machine-to-machine communication using HTTP as a protocol. We use a URL to specify the request as a header and sometimes need to include a body.

HTTP

HTTP (Hypertext Transfer Protocol) is incredibly well used for communication on the World Wide Web and is the protocol of choice for web services. For our purposes, it can be broken into 3 parts:

1. HTTP request method or command
2. URL
3. Body (depends on request method)

1. HTTP request method or command

There are several HTTP commands available. We usually use either GET or POST for getting information via web services.

HTTP GET is meant to be a request for information based only on the URL and what a browser typically uses when a web site address (URL) is typed in. This is also the default in FabGuard I/O (version 8.3+) and frequently includes parameters or query information to specify the information to retrieve. GET never has a body for the request, but usually receives a response message with a body that includes information. In some cases, a GET can be used as a command and the response usually gives the status of the request.

HTTP POST is an option within FabGuard I/O for certain messages (version 8.5.4+) and meant for sending data to a web server.

2. URL

A URL (Uniform Resource Locator) is a URI (Uniform Resource Identifier) for a web resource that determines what protocol is used to call a resource on a given server and port as well as to pass parameters. The generic URL is

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

but for FabGuard, this usually has the form of

http[s]://host[:port]/path?ParameterName1=Value1&
ParameterName2=Value2&ParameterName3=Value3

where:

• Spaces or special characters are not used. Use percent-encoding if spaces or special characters are needed. For example, use %20 (ASCII 0x20) instead of a space.
• The scheme (or protocol) is http (or optionally https) for FabGuard web services.
• The two slashes (//) are required for http and https.
• Authentication is optional and rarely used in plain text. Most web services utilized with FabGuard do not use this.
• The host is either a computer name or IP address. The default http port is 80, but a custom port can optionally be specified by using a colon and port number.
• The path (/path) usually matches a Windows or Linux path to a file, but always uses a forward slash (/) to denote a folder or directory. For FabGuard, we define virtual directories, so http://SERVER/FabGuard/FgWeb.htm actually is \\SERVER\C\Inficon\web\FgWeb.htm.
• Most web services require the passing of parameters in the URL after the path. The question mark (?) separates the path and the parameters. After that, there are one or more pairs of ParameterName and Value (‘ParameterName=Value’), with an ampersand (&) separating each ‘ParameterName=Value’ string.
• Fragments are used as bookmarks in FabGuard Help, but most web services do not use them.

3. Body

HTTP GET does not have a body, so do not try to add one. The only content of the GET is in the URL.

HTTP POST requires a body, which can be of many different forms, such as XML, HTML, JSON, and text. For example, calling a FabGuard APC job would use an HTTP POST command with the appropriate URL and an XML body that has the information for the job.

FabGuard web services in the field

Most FabGuard products host web services for incoming requests from factory systems and which can be used for a number of purposes. Also, FabGuard products can send requests to factory systems with web services or other FabGuard components. The following table summarizes how the FabGuard services can be used.

• Download Excel File: FabGuard web services by component »

Example 1: IPM request for logistics

Here we look at using a web service to get more information to a FabGuard product. In this case, a FabGuard IPM needs to get device specific logistics from the MES that the tool does not have. The factory supplied the URL syntax for the web service to get the logistics from, and a sample of the XML response.

<?xml version="1.0" encoding="utf-8"?>
<LogisticsElem xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <LotId>45454.1</LotId>
  <Tool>DPS1</Tool>
  <Recipe>S8</Recipe>
  <Product>CA26</Product>
  <Technology>T31</Technology>
  <Layer>M3</Layer>
</LogisticsElem>

It is generally bad to put web service calls in secondaries of the main acquisition triggers, since a delay in response or network lag could delay the start of the run. Instead, an additional I/O channel of Logistics Caching Trigger was created with the same Primary information as the Acquisition 1 trigger, (Figure 1.)

Example 2: Get IPM status from FG Executive

Here we look at how a factory system can request information from a FabGuard product. In this case, an external system can request the status of an individual FabGuard IPM from the FabGuard Executive to ensure FabGuard can collect data before tracking in a lot. We use the FabGuard Executive’s web service for “Retrieve automation status as XML” (Figure 2.) Nothing needs to be setup in FabGuard and the only requirement is access to the server on TCP port 80. Refer to “FabGuard_Enterprise_-_Web_Application_Programming_Interface.pdf” in FabGuard Help for the details of the message.

Field testing FabGuard and factory web services

Web browsers, REST clients, and SOAP clients are the most popular applications used to test web services. It is recommended here to use a REST client for most testing. For testing automatically created URLs for human offline viewing, a modern browser (Chrome is preferred) is all that is needed to do the final test.

REST Client

A REST (Representational state transfer) client can test any HTTP method easily, so it can test GET, POST, and any other command that might be needed. Most clients should allow for easy testing of any web service. The main advantages are:

• Creating HTTP messages (GET, POST, PUT, etc.)
• Easy interface for adding/modifying URL parameters and the body of the POST
• Many options for viewing output (XML, raw, HTML, etc.)
• Saves history/projects for future testing
• Test on demand

There are many REST clients available across most every platform imaginable, but our recommendation of an easy to use and free REST client is Postman. This client requires a Google Chrome browser and a Mac (OS X or higher) App that can easily be added to your system by going directly to their web site (Figure 3.)

Testing examples

Test A: Interdiction to Promis HTTP from FabGuard IPM

As of FabGuard 8.5.4, there is an I/O channel connection of Promis HTTP, which allows a FabGuard IPM to send queries and commands to a Promis TP web service. Postman was used with a non-production Promis TP server to troubleshoot syntax, reset the tests, and confirm that Promis TP transitioned as requested by FabGuard IPM. To save space, only the FabGuard IPM I/O channel and Postman results are shown below (Figures 4, 5, and 6.)

Test B: Start a FabGuard eOCAP passing correct logistics

FabGuard eOCAPs are started by using HTTP GET. Testing was first done using Postman to confirm the correct URL and then final testing was performed by copying the URL from Postman and pasting into Chrome. Testing is required to confirm proper display and functionality for the end user.

The eOCAP topic 1000 was created with the first block designed to receive the appropriate logistics (Figure 7.)

Postman was used to help build the URL for test cases by typing in the URL up to the question mark (http://opah/inficon/logicnets.lns) and then adding the key/value information for the parameters in the table. Postman automatically adjusts the URL as the parameter table is edited (Figure 8.) For example, changing the “ToolID” value from “Etch01” to “Etch08” in the table automatically updates the URL.

After the URL was created in Postman, it was copied to Chrome for final testing.

Test C: Running a suite of tests of a controller in FabGuard APC

The FabGuard APC framework integration leverages SEMI E133 standard messages posted to its Sequencer component. Individual controllers are composed of one or more jobs, each of which has a specific definition of the expected information in the request. One or more standard replies are also provided in response to each request. There can be flexible association between requests, the number of jobs initiated by a given request, type, and the number of responses generated. Controller development is straightforward with the ability to create and send requests to the APC framework, as well as parse and validate its responses.

Requests are sent as an HTTP POST specifically to the Sequencer servlet of the APC framework. The XML body needs to match the job definition in terms of structure and context, and will generally be developed per the E133 structure with few caveats or exceptions (Figure 9.)

Each job within a given controller should have a request developed that matches the expected structure and content. Individually, these would then be used to make requests and validate the logic definition and results. Taken together as a Collection, however, these can represent “processing” a lot through the entire control strategy for end-to-end testing (Figure 10.) When further coupled with the capability provided by Postman Runner, a full data-drive control simulation can be executed to simulate control performance.

For data-driven simulation through Runner, one necessary step is to provide a data set and specify the means to inject data into the request. The first step is to create placeholders within the XML body definition that are to be replaced with data, as shown below (Figure 11.)

A data file is provided to Runner to drive simulations, where each line in the file is used once for each request in the given Collection. For an APC simulation, each line can represent one lot passing through each of the controlled operations, and the number of lines in the file represents how many lots will be controlled within the simulation. Pre-request scripts are used to pass the data from the files into environment variables, which then replace the placeholder values in the request (Figure 12.)

Tests are performed on responses to each request, or they can facilitate further capability to update environmental variables. The example simulation checks the response to ensure the controller successfully processed each request, and also updates variables to simulate metrology results given the recommended recipe updates (Figure 13.)

After the XML body placeholders, Pre-request Scripts, and Tests are all configured, the Collection can then be executed in Runner using a provided set of environment variables and data file. One iteration will run each of the requests in the Collection once, in order, using a single line from the configuration file (Figure 14.)

The Results pane shows the results of all of the configured tests for each response, and for each iteration through the Collection. Environment variables can also be persisted between requests and over each iteration, which is leveraged in this example to simulate how metrology results would be different based on recipe updates from the control strategy. The tests results, paired with log results from the controller, can be used to validate the integrity of the control logic and the simulated variability reduction the controller would provide once deployed.

Conclusion

Using web services allows engineers to get more value from their FabGuard application by integrating factory data sources with FabGuard components to get additional logistics, send interdiction alarms from/to the MES, and extend the responsiveness of FabGuard eOCAP.