Semi E139.3

SEMI E139.3 defines the XML/SOAP web-service binding for RaP — the WSDL-defined operations for recipe download, selection, and verification, and the SOAP envelope carrying E139.1's recipe-content XML — as the web-services counterpart to E139.2's SECS-II binding, letting a host manage recipes over the same Interface A infrastructure it already uses for EqSD (E125.1), DCM (E134.1), and equipment-client authentication (E132.1), rather than the classic SECS-II wire protocol. E139.2 gives RaP a binding for the installed base of equipment that speaks SECS-II; E139.3 gives it the matching binding for the growing set of tools and host integrations built around SOAP-based web services instead, so a fab running a modern Interface A stack isn't forced to fall back to the older SECS-II path just to get standardized recipe management.

RaP's lifecycle (E139) and content schema (E139.1) are transport-agnostic
E139.2 already binds them to SECS-II for the classic GEM stack
SEMI E139.3 — XML/SOAP binding for RaPMatching web-services binding alongside E139.2's SECS-II path
Defined WSDL operations for recipe download, select, verify
Same call signature pattern as E125.1/E132.1/E134.1
SOAP envelope carries E139.1's recipe-content XML directly
No re-encoding between the content schema and the transport schema
A fab's SOAP-based Interface A stack manages recipes without a SECS-II fallback
RaP now has one binding for each major transport a fab might run

The reason RaP needed both a SECS-II binding and a SOAP binding, rather than picking just one, is that a fab's actual installed infrastructure is rarely uniform — equipment communicating over classic SECS-II and equipment or host tooling built around the newer SOAP-based Interface A ecosystem routinely coexist in the same facility, and a recipe-management standard that only bound to one transport would leave the other half of the fleet without standardized recipe handling. E139.3 completes RaP's transport coverage by giving the SOAP side of a fab's infrastructure the same recipe download, selection, and verification operations E139.2 already gives the SECS-II side, with both bindings carrying identical underlying recipe content defined by E139.1 — the choice of which to use comes down to which transport a given tool or host integration already runs, not any difference in what RaP itself guarantees.

One Fab Floor, Two Recipe-Management Transports a mixed-transport fab needs recipe management on both paths at once Etch tool installed 2014 speaks SECS-II only Metrology tool installed 2025 SOAP/Interface A only Deposition tool installed 2018 speaks SECS-II only Test cell installed 2025 SOAP/Interface A only E139.2 — SECS-II binding same recipe content, carried over SECS-II remote commands E139.3 — SOAP binding same recipe content, carried over WSDL operations identical E139.1 recipe content either way

E139.3 is what completes RaP's transport coverage for a mixed-infrastructure fab — by giving the SOAP-based Interface A ecosystem the same recipe download, selection, and verification operations E139.2 already provides for classic SECS-II equipment, it means a fab never has to choose between modernizing its host integrations and keeping standardized recipe management, since both transport paths carry the identical E139.1-defined recipe content underneath.

Take SEMI E139.3 further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app