As is almost known to us all, Fiori ( at least deployed in Netweaver having ABAP as backend ) has stateless behavior and CRM WebClient UI is a set of Stateful application. Physically both are running on ABAP Netweaver using ABAP Bsp Application. How are this different behavior implemented?
Fiori and CRM WebClient UI – Stateless and Stateful, but how?
There are documentation in SAP help about stateful and stateless BSP application.
It is mentioned there:
In the stateless case, the context is created each time that a request is received. The context is always destroyed when the response is sent.
For the BSP runtime stateless means: runtime->keep_context = 0
In the stateful case, the context is held by gone request to the next.
For the BSP runtime stateful means: runtime->keep_context = 1
As a Fiori/CRM Webclient UI developer, the above mentioned difference is taken care by framework and completely transparent to me. The only point I need to be careful is that when I am developing service in the backend for stateful application, I can consider introducing some session buffer for performance improvement which will not work in stateless scenario.
Nevertheless I am still curious how framework treats these two kinds of application differently.
PRD01 is a CRM Webclient UI component which I am responsible for. In SE80 the checkbox “Stateful” is marked as true.
CRM_OPPRTNTY is for CRM Fiori application “My Opportunity”, where “Stateful” is false.
I debug the HTTP process implementation against a HelloWorld BSP application with stateful checkbox marked with true and draw the following diagram:
The stateful related evaluation and handling are involved in the following framework process steps.
The buffer is maintained in internal table http_ext_instances of CL_HTTP_SERVER.
When the index.html of BSP application is initially opened, no handler is created so buffer table is empty, create instance for the first time:
The instantiation of CL_HTTP_EXT_BSP will call CONSTRUCTOR of CL_BSP_RUNTIME and CL_BSP_CONTEXT, as displayed in the diagram.
Once BSP handler CL_HTTP_EXT_BSP is initialized, its method HANDLE_REQUEST is called. Inside this method, method ANALYZE_URL ( green block in diagram ) of CL_BSP_RUNTIME is called to evaluate the accessed BSP application is stateful or stateless.
From the source code below we can know that the Stateful checkbox value for a given BSP application is stored in table o2appl, field stateful:
This stateful checkbox value will be filled to
And c_context->m_app_stateful will be used to fill if_bsp_runtime~keep_context:
Notice that before method ON_REQUEST_LEAVE is entered, its field KEEP_CONTEXT has value 1, which is consistent as what SAP help mentions.
In ON_REQUEST_LEAVE ( purple in diagram ), since keep_context is and server->stateful is 0 ( default value ), so IF branch starting from line 42 is executed.
Here cookie field sap-contextid is set, and server->stateful is set as 1. This flag will be evaluated in the last step.
If flag server->stateful set in previous step has value 1, currently instance of CL_HTTP_EXT_BSP is buffered.
Later when other requests from the same BSP application is raised, EXECUTE_REQUEST will be called again and this time the buffered BSP handler instance is used to serve the request:
So far we have gone through all branches in my diagram.
The relationship among CL_HTTP_EXT_BSP, CL_BSP_RUNTIME, CL_BSP_CONTEXT could be found from below picture: