WDA is a Stateful application

[Former Member]

Hi,

SAP -

Stateful applications are supported u2013 that is, if the page is changed and the required data remains intact so that you can access it at any time throughout the entire application context.

Note that stateless applications are not possible.

As per the above statement, the application context is saved. "Where I can see this context/Access this context".

How can we justify this application context is retained or not. where exactly I can see it.

What is the meanging of the above statement.

If have some nodes in my context when I switch between views I have an option to clear my node information.

How is the state of the application saved...

Regards,

Lekha.

Edited by: Lekha on May 4, 2011 7:15 PM

[Former Member · Accepted solution]

    As per the above statement, the application context is saved. "Where I can see this context/Access this context".
How can we justify this application context is retained or not. where exactly I can see it.   

Outside the session, there is now way to access the Context. In the same session, u can access the data in methods .

Data specified by the user during the application execution or data determined by the application itself is available potentially throughout the entire execution duration of the session.

If have some nodes in my context when I switch between views I have an option to clear my node information.
How is the state of the application saved...

• Data is retaining in the Context, even when your switching between the nodes, this means that your Context is alive.

==> Stateful ness of the application is achieved. The framework is retaining your data until you clear the information.

Data(small amount) is being saved in HTTP Cookies. In HTML Hiddenfields and XML tags as below

  <input type=hidden name="customerID" value="4711">  

In genreal... the session state storage is as follows

      
All data that needs to be available to the application across different requests within the same session is called session state or session state data. Examples for such data are shopping bas-ket content, intermediary results of database queries, as well as authorization state informa-tion.  For storing such data between requests, there are in general two possibilities:
-	Sending the state information back to the client. With the next request the current state is transmitted to the server again.
-	Keeping the necessary data structures on the server. No session data (except the ref-erencing identifier) is transmitted to the client.
Sending the session state data back to the client is generally not recommended. From a secu-rity perspective, the main problem is that the session state can easily be manipulated on the client side if it is not protected appropriately.
In scenarios where session state information must be transmitted back to the client, it is gen-erally possible to sign all transmitted session state information in order to prevent changes on the client side. When the server receives session state information within requests from the client, it can check the signature in order to verify that the data was not altered.
A functional drawback is that the size of the information that can be stored by round-tripping it to the client side is limited through the available bandwidth. For session state data that consists of only a few bytes this does not matter. However, in scenarios with larger ses-sion state data structures, re-transmitting them with each request becomes impractical.
Keeping the session state strictly on the server is the recommended solution. Whether the session state is stored in the server RAM or whether it is serialized and written to a persistent storage is irrelevant from a session management security point of view. Independent of the chosen mechanism for storing session state data, it is important to ensure that the session state information is sufficiently protected against illegal access on the server side.

See the Next post ...to get better Understanding

Thanks,

Anil Danda

[Former Member]

In SAP, It is as

5.1	SAP NetWeaver Application Server
The SAP NetWeaver Application Server provides session handling facilities as part of its framework services. Stateful applications only request this feature but do not have to imple-ment it on their own.
These services also include abilities to store session related information internally with the session object.
There are different kinds of SAP session identifiers used to uniquely identify user sessions residing on either the SAP NetWeaver AS ABAP or JAVA system on a specific application server. 
Session identifiers can be represented in the HTTP header as cookies or as part of the URL in order to enable stateful sessions without cookies (URL-rewriting scheme). If cookies are used, the cookies will be created with the domain attribute set to the hostname contained in the client request.
Sessions will only be created if a user does access a stateful application.
Sessions will expire automatically after a configurable period of time. The default timeout value is 30 minutes.
In addition SAP NetWeaver application servers may use additional tokens to support load-balancing. More information about SAP NetWeaver session identifiers can be found in the SAP online help system [15].


5.1.1	SAP NetWeaver Application Server ABAP
On the SAP NetWeaver AS ABAP, the session identifier is called sap-contextid. The sap-contextid is created using the following template:
<sap-abap-sid> = URL-encode( SID:ANON:<sap-server-name> :<internal-id>-<mode> ) 
<sap-server-name> = <host-name> _<sap-system-id> _<sap-instance-number>
The internal id of the context id is based on a random value and a time value to guarantee the uniqueness of the create session identifier.
The session timeout can be controlled by maintaining the parameter rdisp/plugin_auto_logout.


5.1.1.1	Session Identifier as Cookie
If using cookies for session tracking the cookie contains the following:
Cookie: sap-contextid=<sap-abap-sid>


5.1.1.2	Session Identifier in URL
As opposed to standard J2EE URL-rewriting, the ABAP session IDs, when part of the URL, are represented in a proprietary encoding scheme (SAP URI parameter encoding) basically consisting of a Url64-encoded list of name-value pairs (each value itself URL-encoded) en-closed in parentheses (u201C()u201D) embedded between URL-path segments, based on the template shown here:
<uri-path-segment> u201C(u201C <Url64-encoded-name-value-pairs> u201C)u201D u201C/u201Du2026 
<Url64-encoded-name-value-pairs> = Url64-Encode( <name-value-pairs> )

where <name-value-pairs> is a list of ampersand-separated name-value-pairs analo-gous to the standard HTTP query parameters (following the question mark (u201C?u201D) at the end of the URL) in the form <name>=URL-Encode(<value>). See also RFC 2396; sec-tion 3.4 u201CQuery Componentu201D.
/sap(bD1lbmcmcz1NWVNJRA==)/myapplications/foo/bar
Where the Url64-encoded string bD1lbmcmcz1NWVNJRA== translates to the following list of name-value-pairs (in general, the u201Cvalueu201D-part of each pair is URL encoded):
l=eng&s=MYSID
The name of the name-value-pair denoting the session identifier is s. There may be other name-value-pairs present such as l (for sap-language). Only single-character names are used in order to save space when the strings are included into the URL.
The format of the session identifier itself is not changed.


5.1.2	SAP NetWeaver Application Server Java
The session identifier on the SAP NetWeaver AS Java is named JSESSIONID. 
The general format of the JSESSIONID is:
(<sapservername>)ID<internal_id>End
<sap-server-name> = <host-name> _<sap-system-id> _<sap-instance-number>
The internal id consists of a time based value and random value and is URL encoded.
Just like the SAP NetWeaver AS ABAP both cookies and URL rewriting may be used. In the case of URL rewriting, the session id will be appended to the URL, like shown below:
/test/myapp.html;JSESSIONID=<sessionid>
The default session timeout is 30 minutes but can be changed per application by maintaining appropriate values in the web.xml of the application.

Hope these two Posts will help U..

Thanks,

Anil Danda