In this blog I will show how to retrieve the data from a HTTP request of an url based transaction launcher.

URL / Transaction launcher definitions.

With the standard you can define parameters in the definition of the URL :

/wp-content/uploads/2015/05/blog1_698444.png

Here I will show how to do more by retrieving the whole HTTP request so there is no need to define parameters.

It is of course possible to define parameters to call the non BSP url but I won’t show it here as I think it is pretty straightforward to use.

Your URL definition should look like this :

/wp-content/uploads/2015/05/blog2_698445.png

Then use the url in the transaction launcher definition :

/wp-content/uploads/2015/05/blog3_698446.png

Handler class.

The handler class need to be adapted after generation :

– In the CLASS_CONSTRUCTOR method you need to make sure attribute  gv_is_return_df_requested is set to abap_true in order to retrieve return data flow.

– In the CONSTRUCTOR method you can eventually change the URL that will be called, for example if you want a dynamic URL or if you want to change it according to the type of system (development, production…).

          Code example if you want to use a different URL ID for each system type :

* Get client customizing
   SELECT SINGLE cccategory FROM t000
      INTO lv_categ
     WHERE mandt EQ symandt.

* Change URL ID
   CASE lv_categ.
     WHEN ‘C’.
       CONCATENATE lc_url_cat ‘_DEV’ INTO me->gs_urlurl_id.
     WHEN ‘T’.
       CONCATENATE lc_url_cat ‘_REC’ INTO me->gs_urlurl_id.
     WHEN ‘P’.
       me->gs_urlurl_id = lc_url_cat.
   ENDCASE.

– In the PREPARE_DATA_FLOW method we need to change the URL parameter ICRETURNADRESS that is sent to the non BSP URL by SAP in order to use our own BSP application instead of the standard one to retrieve the http form.

  An additional coding is also needed to use a new window (does not work with standard coding).

          Here is the code for this method :

METHOD if_crm_ic_action_handler~prepare_data_flow.
   DATA: __gdc    TYPE REF TO if_crm_ui_data_context.

   DATA: lv_active          TYPE REF TO cl_crm_ic_active_actions,
         lv_guid            TYPE string,
         lv_session_context TYPE REF TO if_crm_ui_session_context,
         lv_component_id    TYPE string.

   super->if_crm_ic_action_handler~prepare_data_flow( ).


* Replace return address with our own BSP
   REPLACE ‘uicmp_ltx’ IN gs_urlurl WITH ‘zuicmp_ltx’.
   REPLACE ‘genericltxreturn.htm’ IN gs_urlurl WITH ‘ltxreturn.html’.

   lv_active = cl_crm_ic_active_actions=>get_instance( ).
   lv_guid = lv_active->get_guid_for_handler( me ).

* Special coding if you use a new window for your transaction launcher
   IF lv_active->is_handler_stateful( iv_guid = lv_guid ) EQ abap_true.
     lv_session_context = cl_crm_ui_session_context_srv=>get_instance( ).
     lv_component_id = lv_session_context->get( iv_name = cl_crm_ui_f_workareaviews_impl=>gc_wa_viewset_comp_id ).
     REPLACE gv_view_controller->component_id IN gs_urlurl WITH lv_component_id.
   ENDIF.


   __gdc ?=
   cl_crm_ui_data_context_srv=>get_instance( gv_view_controller ).


   gv_component_id = gv_view_controller->component_id.

   me->add_source_session( ).

* Data flow is complete – set to false if data is missing
   gv_data_flow_complete = abap_true.

ENDMETHOD.

– Then of course PROCESS_RETURN method has to be redefined but first I have to show you the BSP application we need to create (ZUICMP_LTX).

BSP application to process return data.

You can create the new BSP application wih transaction SE80 :

/wp-content/uploads/2015/05/blog4_698504.png

It’s close to the standard one UICMP_LTX, we just need one return page to process the request from the URL application.

Here is the code you need in LTXReturn.html :

<html>

   <head>

     <%@ include file=”ICDomainRelaxing.htm” %>
     <script>
       SAPICdomainrelax( );
     </script>
   </head>
   <body>
     <script>
       parent.document.getElementById(“<%=COMPONENT_ID %>_ReturnFromBOR$btn”).click();
     </script>
   </body>
</html>

Then we need to define the event handler OnRequest :

DATA:     lv_request TYPE xstring.
 
component_id = cl_thtmlb_util=>escape_xss_xml_html( component_id ).

lv_request = request->get_raw_message( ).

CALL METHOD cl_bsp_server_side_cookie=>set_server_cookie
   EXPORTING
     name                  = ‘ugap_ecommerce’
     application_name      = ‘UGAP’
     application_namespace = ‘UGAP’
     username              = syuname
     session_id            =
     data_name             = ‘request’
     data_value            = lv_request
     expiry_time_rel       = 100.

We put the whole request in a server cookie in order to retrieve it afterwards (in the PROCESS_RETURN method).

PROCESS_RETURN method.

And finally, when the BSP application we created is called by the URL application, the process_return method is then called and we can retrieve the data of the request :

CALL METHOD cl_bsp_server_side_cookie=>get_server_cookie
     EXPORTING
       name                  = ‘ugap_ecommerce’
       application_name      = ‘UGAP’
       application_namespace = ‘UGAP’
       username              = syuname
       session_id            =
       data_name             = ‘request’
     CHANGING
       data_value            = lv_request.

   CREATE OBJECT lr_request.
   lr_request->if_http_entity~from_xstring( lv_request ).

   lr_request->if_http_entity~get_form_fields( CHANGING fields = lt_fields ).

You now have all the fields from the html form in your URL application in the internal table lt_fields.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply