Skip to Content
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):

image

Now we can delete both objects for XML message display:

image

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

image

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

SXMBPARTY= Communication Party

SXMBPRTAG= Issuing Agency

SXMBPRTTYP= Identification Scheme

SXMBSERV= Service

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:

image

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.

To report this post you need to login first.

10 Comments

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

  1. Anonymous
    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
    Christine

    (0) 
  2. Vlasta Toufar-Vukovic
    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.

    Thanks

    (0) 
  3. Kamal Kumar
    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.

    Thanks,
    Kamal

    (0) 
  4. Krishnakumar Ramamoorthy
    Michal
    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.

    KK

    (0) 
  5. Federico del Bagno

    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.

    (0) 
    1. 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.

      Regards,

      VJ

      (0) 
      1. Federico del Bagno

        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.

        (0) 

Leave a Reply