Skip to Content
Author's profile photo Michal Krawczyk

XI: SXMB_MONI – controlling access to message display

There where a few posts on the XI forum in which some of us had problems/questions
about how we can control access to message display. This weblogs shows
how you can use the authorization concept to restrict access to message payload
by using standard authorization object.

Let’s start from the beggining:

From SAP Note 742324 – New authorization concept

we can learn that in order to use authorization concept for XI message monitoring
we should use S_XMB_MONI authorization object instead of S_XMB_DSP .

As a start we can copy standard role SAP_XI_MONITOR_ABAP for displaying XML messages (TCODE – PFCG):


Now we can delete both objects for XML message display:


Once we delete those objects we can Manually add object S_XMB_MONI.

In this exercise we’ll try to give full access to the following activities (descriptions from object’s S_XMB_MONI documentation):

02 = Change the SOAP header/body of an XML message

03 = Display the SOAP header/body of an XML messag

16 = Reschedule failed XML message

A3 = Change the status of an XML message manually

we’ll just restrict access to:

29 = Display the payload of an XML message


We can also tell exactly which interface/service/namespace can be used:

SXMBPARTY= Communication Party

SXMBPRTAG= Issuing Agency

SXMBPRTTYP= Identification Scheme


SXMBIFNS = Interface Namespace

Once we fill those we can generate the role and add it to one of our users.

The user will now be able to use SXMB_MONI but when he tries to see the message payload he’ll see:


You can use standard report: RSUSR070 to see which roles have S_XMB_MONI object assigned.

I hope this weblog will help to understand how message display can be restricted to some non basis XI developers.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Hi Michael,


      I took a shot at the same topic in the following techincal document


      Author's profile photo Michal Krawczyk
      Michal Krawczyk
      Blog Post Author
      Hi Naveen,

      I see but since you've described the older authorization object now we have both of them 🙂


      Author's profile photo Former Member
      Former Member
      Hi Michal,

      again a really good blog from you.

      One question though: Did you test, if this also works on archived messages? Meaning if i try to read a message from the archive, where i should not be able to see the payload, will it also deny access?

      Best regards

      Author's profile photo David Ruiz
      David Ruiz
      Hi Michal,

      One question, does it works if we access from

      David Ruiz

      Author's profile photo Former Member
      Former Member
      Hi Michal,

      Can you please tell if the same rules apply to payload in Runtime workbench. I mean if I restrict a user using SX_MB_MONI object does it also restrict when access from RWB in message monitoring and end-to-end monitoring.


      Author's profile photo Former Member
      Former Member
      Hi Michal,
            Nice Blog, Your blog says that particular user cant display the message payloads in moni,i have a doubt,Is it possible hide the same message in Moni.


      Author's profile photo Krishnakumar Ramamoorthy
      Krishnakumar Ramamoorthy
      For the readers of this blog, just wanted to add that there is a bug in the code if S_XMB_MONI is to be used in ECC (specially for inbound interfaces) and is resolved using note 1174305.


      Author's profile photo Former Member
      Former Member

      Hello Michal,

         I know this is a very old blog, but from my point of view it's a bit tricky.

      I need to restrict the payload for one or two specific interfaces and let the payload visible for every other interface (500+).

      How can I accomplish this?

      Do I need an entry with ACTVT 29 with the list of all 500+ interfaces except those one or two interfaces that I want to restrict?

      And for every new interface I will have to update this list ?? That's not pretty.

      Author's profile photo Vijayashankar Konam
      Vijayashankar Konam

      Hi Federico,

      Did you manage to come up with a solution for your case? I am looking exactly for such a solution. Kindly message me back, if you found one. Your response is much appreciated.



      Author's profile photo Former Member
      Former Member

      Hi VJ,

        sadly there was no simple solution for my case. The project didnt advance...

      If you want to restrict payload for some specific interfaces you need to do the opposite. Default should be "restrict payload view for all" and then add the interfaces with payload visible.

      Author's profile photo Ricardo Tavares
      Ricardo Tavares


      I have the requirement for limiting access for users, depending on the company field that is part of the message.

      After reading this post:

      I've performed the implementation of the authorization object S_XMB_MONI  defining all parameters as required. In PI, as we aren't making use of a party in the integration builder, I've set the parameters party, agency and scheme on the receiver agreement trough the option "Header mapping", making use of data that is filled in the payload. When the message is integrated in PI, when openning the message the authority check fails since the fields SXMBPARTY, SXMBPRTAG and SXMBPRTTYP are not filled.

      Can you please advise in which moment PI fills this parameters?

      Many thanks