Janus Web Legacy XML Support: Difference between revisions
m (misc cleanup) |
|||
| Line 1: | Line 1: | ||
<var class="product">Janus Web Legacy XML Support</var> is a variant of <var class="product">[[Janus Web Legacy Support]]</var> that is intended to facilitate programmatic access to legacy <var class="product">Model 204</var> 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 <var class="product">Janus Web Legacy XML Support</var> are not vulnerable to cosmetic changes to pages and so are much more robust (and easier to develop) than traditional [http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping screen scraping] and [http://en.wikipedia.org/wiki/Web_scraping web scraping] applications. And, delivery of 3270 screens over an HTTP | <var class="product">Janus Web Legacy XML Support</var> is a variant of <var class="product">[[Janus Web Legacy Support]]</var> that is intended to facilitate programmatic access to legacy <var class="product">Model 204</var> 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 <var class="product">Janus Web Legacy XML Support</var> are not vulnerable to cosmetic changes to pages and so are much more robust (and easier to develop) than traditional [http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping screen scraping] and [http://en.wikipedia.org/wiki/Web_scraping web scraping] applications. And, delivery of 3270 screens over an HTTP connection means that they can be accessed by any of a large number of HTTP APIs available in most modern programming environments. | ||
==Getting Started== | ==Getting Started== | ||
<var class="product">Janus Web Legacy XML Support</var> is part of <var class="product">[[Janus Web Legacy Support]]</var> and much of what is required to configure one is required for the other. As such, it's probably worth looking at [[Janus Web Legacy Support#Getting_started|getting started with Janus Web Legacy support]]. Conceptually, <var class="product">Janus Web Legacy Support</var> is quite simple — when a 3270 Read Screen is issued on a Janus Web thread, that screen is automatically converted to XHTML. | <var class="product">Janus Web Legacy XML Support</var> is part of <var class="product">[[Janus Web Legacy Support]]</var>, and much of what is required to configure one is required for the other. As such, it's probably worth looking at [[Janus Web Legacy Support#Getting_started|getting started with Janus Web Legacy support]]. Conceptually, <var class="product">Janus Web Legacy Support</var> is quite simple — when a 3270 <var>Read Screen</var> 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: | To have the screen be converted instead to more program-friendly XML, the <var>XMLSCREEN</var> setting must be enabled on the thread on which the 3270 <var>Read Screen</var> was issued. This can be done a number of ways: | ||
<ul> | <ul> | ||
<li>On the [[JANUS DEFINE]] command for a port.</li> | <li>On the <var>[[JANUS DEFINE]]</var> command for a port.</li> | ||
<li>In a [[JANUS WEB SCREEN]] rule for a port/URL combination.</li> | <li>In a <var>[[JANUS WEB SCREEN]]</var> rule for a port/URL combination.</li> | ||
<li>Via the [[$Web_Screen]] function.</li> | <li>Via the <var>[[$Web_Screen]]</var> 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 < | 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 <code>SUBSYSMGMT</code> subsystem might be sent as: | ||
<p class="code"><screenOutput sequence="1" cursorField="OPTION"> | <p class="code"><screenOutput sequence="1" cursorField="OPTION"> | ||
<field name="TITLE" value="SUBSYSMGMT Subsystem Management Facility VER 3 REL 2.0I "/> | <field name="TITLE" value="SUBSYSMGMT Subsystem Management Facility VER 3 REL 2.0I "/> | ||
| Line 31: | Line 32: | ||
<ol> | <ol> | ||
<li>An initial HTTP Get request establishes a session.</li> | <li>An initial HTTP Get request establishes a session.</li> | ||
<li>The response to the initial Get is an XML document that describes the first 3270 screen in the session. This would be in a <var | |||
<li>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.</li> | <li>The response to the initial Get is an XML document that describes the first 3270 screen in the session. This would be in a <var class="product">SOUL</var> <var>Read Screen</var> statement.</li> | ||
<li>The thread that issued the <var>Read Screen</var> and then sent the XML HTTP response back to the client, then waits for a response (screen input) for the 3270 screen.</li> | |||
<li>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.</li> | <li>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.</li> | ||
<li>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). | |||
<li>The thread that issued the original <var>Read Screen</var> processes the input XML, using it to set screen inputs, including the action key (Enter or a PF key). | |||
<li>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. | <li>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. | ||
<li>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.</li> | |||
<li>If no <var>Read Screen</var> is done, a final HTTP response is sent to the client (its contents depend completely on the server application) and the session is terminated.</li> | |||
</ol> | </ol> | ||
[[Category:Janus Web Server]] | |||
Revision as of 16:18, 24 February 2015
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 connection means that they can be accessed by 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 SOUL 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.