Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
jegathees_waran
Active Participant

Background


In any SAP PI implementation / support project there may be a requirement to process particular interface message (proxy messages) in a separate queue. Normally all inbound messages in ABAP Stack are processed in XBTR* queue. XBTR* queues are normal EO queues to process inbound messages in application system. If business critical messages are processed in a normal queue i.e XBTR*, it may take time to process the message or the message could not be processed.  Assume that if the messages from other interface and critical interface messages are processed in a same queue, if the first message is successful, then only the second message will be processed. If the first message is failed, then this critical interface message will not be processed. If the first message takes a very long time due to payload size/processing critical, then this critical message needs to wait. In some cases, if the critical message processing takes time and it stops/delays other interface message processing.

Business do not want this kind of situation. And it expects this critical interface processing should not be disturbed others like the situation above. In these cases we configure Queue Prioritization to process this/these critical interface messages in a separate queue other than normal queue. (XBTR*).  In PI dual stack, we did this through SXMB_ADM since it has ABAP Stack. In Single Stack, we can’t control to process the messages in application systems like ECC, BW, SRM.

Requirement

In our project, we had a requirement to process a particular interface (HR data) message in a separate queue in ECC. And another requirement we had when we deliver messages to ECC, it needs to split the messages and send to ECC. The reason is that the input text file size is around 25 MB and it has 1 lakh records normally, and frequency is daily. If we don’t split, it is hard to deliver the whole XML message to ECC (In PI, sometimes it gives error HttpException: Connect timed out) and in ECC it will take time around 12 hrs – 14 hrs to process this single message.

Solution

We have one critical interface; business wants to process the messages of this interface in a separate queue in ECC i.e application system.

The input file is a pipe delimited text file and each record in the file is a flat record. There is no like Header, Detail – hierarchical records. We use FCC in the channel to convert to XML.

To achieve split, we set the following two parameters in the Sender File Channel.

Recordset Structure: <RecordSet>,20000

Recordsets per Message: 1


If the input file has 125630 records, then there will be 7 messages in PO. (First six message – each will have 20000 records, and 7th message will have 5630 records.

We select XTZ* queue to process this interface message in ECC.

And at the same time we wanted to increase the inbound queues than the default no. of queues in ECC. Purpose is to run the messages in parallel.  For this we set the following TUNING parameter in SXMB_ADM.

Category: TUNING

Parameter: EO_INBOUND_PARALLEL

Sub-Parameter: RECEIVER

Current Value : 100

We have increased the total number of inbound queues from default value to 100. This parameter is applicable to all inbound queues (not only for XBTZ*)

Note: This parameter we set based on number of application servers in ECC i.e instances and number of Dialog Work Processes in ECC. While message processing, the system picks the available application servers. We have 16 application servers in ECC.

Now, we need to create Sender and Receiver ID in SXMB_ADM.

Step 1: Create Sender and Receiver ID.

In ECC, Go to SXMB_ADM ---> Integration Engine --> Configuration --> Sender/Receiver ID

Sender ID:

Created a following Sender ID

The component in Sender id should be the Business Component/Business System which is configured in the ICO.

Interface Name and Interface Namespace should be ‘*” since sender component is considered once the message reaches ECC .

Save the Sender Id.

Now, it needs to create the Receiver ID.

Receiver ID:


The following should be filled when create Receiver ID: Agency, Schema, Receiver Component, Interface Name, Interface Namespace.

The Agency and Schema, you can find from SXMB_MONI, Main attributes.


Component, Interface Name, Interface Namespace you can find either from SXMB_MONI or from ICO.



Now save the Receiver id.


Step 2: Configure Filter for Queue Prioritization


Now, select ‘Configure Filter for Queue Prioritization’ in SXMB_ADM

In the main screen, click on Add icon (+), and in the coming popup window, select ‘Exactly Once’.

After this selection, it will give information message ‘Sender Interface Name and Interface Namespace will be ignored”. Select ok.


Now in the following window, choose XBTZ* queue, select Sender ID, Receiver ID from Popup enter description and save.



It is saved.

It appears in the menu as below.

Finally activate this filter by select active icon in the menu bar.

Once it is active, when this interface messages reaches ECC, those are processed in XBTZ* queue.

Note:

1. Initially this queue prioritization was not working. Then, we checked with SAP, they found it is a program error in  ECC. Then, they released the Note 2095982 on Nov 17, 2014. After implement this notes, it was started working. (

2. You can configure n number of critical interfaces message processing in a specific queue.

3. If you have created Large Volume Messages queue in SXMB_ADM and if it belongs to the critical interface message and processed in example XBTZ* queue, XBTZ* will take the precedence first.

I thank to my leads Vinay & Suddha to explore this.

4 Comments
Labels in this area