While you can construct a WebSpeed transaction that includes a combination of stateless and state-aware Web objects, practical management of these multiple requests can get tricky. The problem is that each successive Web object usually needs to know something about what occurred in the previous request, and it might not even know which Web object executed in the last request.
You can pass around additional cookies or use the URL to convey this information, but that wastes the advantage of the continuous context established by the WebSpeed transaction. You might, instead, use a single primary Web object that initiates the WebSpeed transaction and use secondary Web objects to provide additional pages in the transaction. This allows the secondary Web objects to share data with the primary Web object or to otherwise communicate through local data in the primary Web object.
A secondary Web object is a Web object that you execute from another Web object that is already servicing a request on the agent. Typically, there is only one primary Web object that handles all requests and initiates the calls to all other secondary Web objects in the transaction.
You cannot use embedded SpeedScript files as primary Web objects because they cannot explicitly make themselves state aware. However, you can use embedded SpeedScript files as secondary Web objects in a state-persistent application. Thus, you must build any primary Web object using a CGI Wrapper Web object or an HTML-mapping Web object.
