Janus Web Legacy XML Support: Difference between revisions
Line 8: | Line 8: | ||
<li>In a [[JANUS WEB SCREEN]] rule for a port/URL combination.</li> | <li>In a [[JANUS WEB SCREEN]] rule for a port/URL combination.</li> | ||
<li>Via the [[$Web_Screen]] function.</li> | <li>Via the [[$Web_Screen]] function.</li> | ||
<ul> | </ul> | ||
When <var>XMLSCREEN</var> processing is set, a 3270 screen read is converted into non-HTML XML that contains the names and values of all named fields on the 3270 screen. For example, the first page of the <var>SUBSYSMGMT</var> subsystem might be sent as: | When <var>XMLSCREEN</var> processing is set, a 3270 screen read is converted into non-HTML XML that contains the names and values of all named fields on the 3270 screen. For example, the first page of the <var>SUBSYSMGMT</var> subsystem might be sent as: | ||
<p class="code"><screenOutput sequence="1" cursorField="OPTION"> | <p class="code"><screenOutput sequence="1" cursorField="OPTION"> | ||
Line 24: | Line 24: | ||
</screenOutput> | </screenOutput> | ||
</p> | </p> | ||
==Sessions and program flow== | ==Sessions and program flow== | ||
<var class="product">Janus Web Legacy XML Support</var> maps 3270 screens to XML for HTTP (web) requests. But, while 3270 applications are typically conversational, involving multiple interactions between the client (or end-user) and the server, HTTP is a stateless request-response protocol. As such <var class="product">Janus Web Legacy XML Support</var> requires that state be maintained on <var class="product">Janus Web</var> threads and that consecutive HTTP requests for a simulated 3270 session be associated with the correct conversation. | <var class="product">Janus Web Legacy XML Support</var> maps 3270 screens to XML for HTTP (web) requests. But, while 3270 applications are typically conversational, involving multiple interactions between the client (or end-user) and the server, HTTP is a stateless request-response protocol. As such <var class="product">Janus Web Legacy XML Support</var> requires that state be maintained on <var class="product">Janus Web</var> threads and that consecutive HTTP requests for a simulated 3270 session be associated with the correct conversation. |
Revision as of 22:50, 11 November 2012
Janus Web Legacy XML Support is a variant of Janus Web Legacy Support that is intended to facilitate programmatic access to legacy Model 204 3270 applications. This is accomplished by converting 3270 screens into XML that contains the names and values of the screen fields, and accepting updates to these screens as XML that contains the names and updated values of the screen fields. Because screen field names are used for screen retrieval and update, programs that access 3270 screens via Janus Web Legacy XML Support are not vulnerable to cosmetic changes to pages and so are much more robust (and easier to develop) than traditional screen scraping and web scraping applications. And, delivery of 3270 screens over an HTTP connections means that they can be access via any of a large number of HTTP APIs available in most modern programming environments.
Getting Started
Janus Web Legacy XML Support is part of Janus Web Legacy Support and much of what is required to configure one is required for the other. As such, it's probably worth looking at getting started with Janus Web Legacy support. Conceptually, Janus Web Legacy Support is quite simple — when a 3270 Read Screen is issued on a Janus Web thread, that screen is automatically converted to XHTML.
To have the screen be converted instead to more program-friendly XML, the XMLSCREEN setting must be enabled on the thread on which the 3270 Read Screen was issued. This can be done a number of ways:
- On the JANUS DEFINE command for a port.
- In a JANUS WEB SCREEN rule for a port/URL combination.
- Via the $Web_Screen function.
When XMLSCREEN processing is set, a 3270 screen read is converted into non-HTML XML that contains the names and values of all named fields on the 3270 screen. For example, the first page of the SUBSYSMGMT subsystem might be sent as:
<screenOutput sequence="1" cursorField="OPTION"> <field name="TITLE" value="SUBSYSMGMT Subsystem Management Facility VER 3 REL 2.0I "/> <field name="OPTION" value="_"/> <field name="ADMIN" value="10. ADMIN"/> <field name="NAME" value=""/> <field name="SFROM" value=""/> <field name="CNAME" value=""/> <field name="CFROM" value=""/> <field name="USERS" value="N"/> <field name="CMD" value=""/> <field name="MSG" value=""/> <field name="SCLASS" value="6=SYSclass"/> </screenOutput>
Sessions and program flow
Janus Web Legacy XML Support maps 3270 screens to XML for HTTP (web) requests. But, while 3270 applications are typically conversational, involving multiple interactions between the client (or end-user) and the server, HTTP is a stateless request-response protocol. As such Janus Web Legacy XML Support requires that state be maintained on Janus Web threads and that consecutive HTTP requests for a simulated 3270 session be associated with the correct conversation.
This is accomplished by maintaining a "session" where in Model 204 a session's state is maintained in a Model 204 thread that remains logged on between HTTP requests. The basic code flow for a Janus Web Legacy XML Support session is:
- An initial HTTP Get request establishes a session.
- The response to the initial Get is an XML document that describes the first 3270 screen in the session. This would be in a User Language Read Screen statement.
- The thread that issued the Read Screen and then sent the XML HTTP response back to the client, then waits for a response (screen input) for the 3270 screen.
- A subsequent HTTP Post to the server is matched with the session's thread. The Post content must be XML that describes inputs to the last 3270 screen on the thread.
- The thread that issued the original Read Screen processes the input XML, using it to set screen inputs, including the action key (Enter or a PF key).
- If another screen read is done on the thread, an XML document that describes that screen is sent to the client and the thread associated with the session goes back to step 3.
- If no Read Screen is done, a final HTTP response is sent to the client (its contents depend completely on the server application) and the session is terminated.