Skip to Content

Let us start by defining what strict serialization is – Serialization during message processing is a feature by which messages are delivered to the target in the same sequence as generated by the source via a middleware.

The quality of service defined for the same in EOIO (Exactly Once in Order).

Serialized messages are processed in a specified queue both on the middleware and the target system. In case of a processing error on any particular message in the queue, the message queue gets blocked; all subsequent messages go on a wait state, till the error is resolved.

Some implementations have a unique requirement for Flexible serialization. In this case, there is a need of serialization of messages and in case of error the other messages can continue, staying serialized, ignoring the failed one which can be attended manually at a later point of time.

The following are the advantages of flexible serialization.

1.  The message processing remains serialized in majority of error-free cases.

2.  The message processing for an interface does not halt due to the failure in one message on the queue.

3.  An error notification, informs the support team of the failure and the subsequent manual action can be performed by them.

It should be noted, that Flexible Serialization is implemented only in cases where, the percentage forecast for failures in less, and manual re-conciliation is possible.

SAP PI, like most middleware systems does not support this out of the box.  A simple WATCHER report can be written based on QRFC APIs in PI and connected ABAP Based SAP systems to achieve the same.  The purpose of this watcher program would be to move the error message out of the active LUW SMQ2 to a saved LUW SMQ3 for all queues requiring Flexible serialization.

The following would be the details of the watcher operation.

1.  Watcher to Monitor all specified Serialized queues on SMQ2

2.  The Watcher looks for specific failure statues like SYSFAIL or CPIC

3.  Upon determination of an error the watcher checks for the message depth on SMQ2 (running/active LUW). . The business team can define the active queue depth,  for flexible serialization to work

4.  The watcher also looks at the depth on the saved queue or SMQ3. This would be important to prevent message movement if there is a generic issue on the interface, which can impact every flowing message.

5.  The watcher based on the above parameters would then move the message to SMQ3.

6.  Finally an alert notification should be send out to the respective users, specifying the movement.

The following is a selection screen.



Selection Screen


The following is the code snippet for the same.

 TYPE-POOLS: salrt.

* Get all errored inbound queues
TABLES: trfcqin.

SELECT-OPTIONS: s_qname FOR trfcqin-qname,
                s_eqname FOR trfcqin-qname,
                s_qstate FOR trfcqin-qstate,
                s_iqname FOR trfcqin-qname.

            p_qdepth TYPE int4,
            p_sqdep TYPE int4.

DATA: v_err_qs TYPE sy-tabix,
      v_err_qss TYPE string,
      v_err_msg(200) TYPE c,
      v_msg TYPE string,
      v_trfcmess TYPE t100-text,
      v_qstate TYPE trfcqin-qstate,
      o_cont TYPE  REF TO if_swf_cnt_container,
      o_err TYPE REF TO cx_root,
      w_qin TYPE trfcqin,
      w_qstate TYPE trfcqstate,
      w_tid TYPE arfctid,
      t_no_pdf_cont TYPE soli_tab,
      t_qin TYPE TABLE OF trfcqin,
      t_qstate TYPE TABLE OF trfcqstate,
      v_q_deep TYPE sy-index,
      ls_message TYPE zsca_string,
      lt_message TYPE zttca_string,
      lt_qview TYPE TABLE OF  trfcqview,
      ls_qview LIKE LINE OF lt_qview.



*Identify the queues

      client      = sy-mandt
      with_qstate = ‘X’
      qtable      = t_qin
      qstate      = t_qstate.

  DELETE t_qin WHERE NOT qname IN s_qname.

  IF NOT s_qstate[] IS INITIAL.
    LOOP AT t_qin INTO w_qin.
      CLEAR: v_qstate.
          qname                   = w_qin-qname
          qstate                  = v_qstate
*         QLOCKCNT                =
          qdeep                   = v_q_deep
*         QRESCNT                 =
*         WQNAME                  =
*         ERRMESS                 =
*         INVALID_PARAMETER       = 1
*         OTHERS                  = 2
      IF sy-subrc <> 0.

      IF  v_q_deep < p_qdepth.

        DELETE t_qin.
        CHECK NOT v_qstate IS INITIAL.
        CHECK v_qstate NOT IN s_qstate.



*   * Move the first LUW to the saved queue
  LOOP AT t_qin INTO w_qin.
    CLEAR: w_tid.

        qname  = w_qin-qname
        client = sy-mandt
        qview  = lt_qview.

    READ TABLE lt_qview INDEX 1 INTO ls_qview.

    IF ls_qview-qdeep < p_sqdep.

          qname                   = w_qin-qname
          client                  = sy-mandt
*     NO_READ_LOCK            = ‘ ‘
         tid                     = w_tid
*     QSTATE                  =
*     WQNAME                  =
          errmess                 = v_trfcmess
*     FDATE                   =
*     FTIME                   =
*     FQCOUNT                 =
*     SENDER_ID               =
*     QTABLE                  =
         invalid_parameter       = 1
         OTHERS                  = 2
      IF sy-subrc <> 0.
*        WRITE: / ‘*’, AT 3 W_QIN-QNAME, AT 40 W_TID, AT 70 V_TRFCMESS.
*        CONTINUE.
*      ENDIF.
        SUBMIT rstrfcdk AND RETURN WITH tid = w_tid.
* Activate the QIN scheduler for this queue.
            qname = w_qin-qname.

        WRITE: / w_qin-qname, AT 40 w_tid, AT 70 v_trfcmess.



The above queue movement should be notified to the business user, with the help of any alerting mechanism.

To report this post you need to login first.


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

  1. Gourav Khare
    For case which required flexible serialization then why not use EO instead of EOIO.
    It is dangerous; for ABAP report to decide which message should be moved out of queue due to error, only business can foresee impact and signal to remove message from queue.
    So my suggestion is wherever possible use EO and only in case where EOIO is “really” required, consult business before removing any message from queue.


    1. Abhishek Vinayaka Post author
      The need for Flexible serialization can only be justified for business cases, in which the serialization is desired, percentage forecast for failures in less, and manual re-conciliation is possible. The decision of applying Flexible serialization has to be driven by business.
      From a technical perspective, the watcher program should be configured to consider the a restricted set of serialized queues which meet the above criteria.
    1. Abhishek Vinayaka Post author
      Thanks Nabomita.
      There should not be any additional message processing overhead.
      The program can be run as a batch through either standard SAP schedulers or via external schedulers like Redwood.
      The program runs in an independent/Separate thread.

Leave a Reply