SAP Fiori和WebClient UI的有狀態和無狀態行為設計原理

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? There are documentation in  SAP help about stateful and stateless BSP application. It is mentioned there:

Stateless

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

Stateful

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.

How does ABAP HTTP framework treat this flag set in BSP application?

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.

(1) Buffer check in CL_HTTP_SERVER~EXECUTE_REQUEST ( red diamond )

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.

(2) CL_HTTP_EXT_BSP~HANDLE_REQUEST

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 c_context->m_app_stateful:

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.

(3) CL_BSP_RUNTIME~ON_REQUEST_LEAVE 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.

(4) buffer insertion 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:

Further reading

So far this blog discusses the difference of Stateful and Stateless handling done in server side. For different behavior in client side, please refer to this blog:  Stateless and Stateful – Different behavior in application side.

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":