Try OpenEdge Now
skip to main content
Developing WebSpeed Applications
Controlling WebSpeed Transactions : Primary and secondary Web objects : Running primary and secondary Web objects
 

Running primary and secondary Web objects

The fundamental requirement for a secondary Web object is that it generate or map a Web page so that the client must make the next transaction request back to the primary Web object.
The primary Web object typically sets the time-out period for the WebSpeed transaction. As the primary and secondary Web objects respond to requests from the client, the time-out counts down. The time-out does not reset unless the primary Web object explicitly resets it by calling setWebstate. Note that all secondary Web objects are implicitly state aware by virtue of the primary Web object's being state aware.
The primary Web object typically generates the HTTP header for the Web page. However, for embedded SpeedScript Web objects, the primary Web object must call the setWebstate method procedure to propagate the state-aware cookie for the next request service before calling any embedded SpeedScript Web object.
The following figure shows the relationship among a client, a primary Web object (Web Object A), secondary Web objects (Web Objects X, Y, and Z), and the transaction request cycle (solid arrows) in a state-persistent WebSpeed transaction. In this scenario one might imagine that Web Object A, in addition to controlling the secondary Web objects, defines shared variables that can be referenced by Web Objects X, Y, and Z.
Figure 12. Primary and secondary Web objects in a WebSpeed transaction
The request cycle shown in the figure illustrates these points:
1. The client (browser) only calls the primary Web object (Web Object A) directly. The client can make repeated calls to the primary Web object, until the transaction times out.
2. Primary Web Object A can either:
*Call a secondary Web object (Web Objects X, Y, or Z).
*Return a Web page to the client. Any links or references in the returned Web page point back to Primary Web Object A.
3. A secondary Web object can either:
*Call some other secondary Web object.
*Call the primary Web object.
*Return a Web page to the client. Any links or references in the returned Web page point back to Primary Web Object A.
At some point Web Object A determines that the user is done, unlocks the agent and possibly sends a Web page back to the user telling them that the transaction is terminated.