Skip to Content
Author's profile photo Michal Krawczyk

XI: BAM – Episode II – Simple Proactive monitor

Did you ever wanted to have any proactive monitoring on your XI server?
Did you manage to implement it? Was it difficult and time consuming?

On many XI presentaion slides you can see that XI offers a full message error
handling from sender to the receiver. This is true to some extent. Have a look at the picture below.


Exchange Infrastructure can handle different types of errors only when the message leaves
the Legacy system. What if messages don’t leave it – meaning that the outbound adapter
doesn’t even know that something should arrive. It can be an error in the Legacy system’s
middleware but do we need to know about it? Of course we do, as if the messages
don’t reach the Exchange Infrastructure the ERP, R/3 system will not get the necessary business data
and the sales order (or any other business documents) may be stopped.
What can we do with such a situation if the Exchange Infrastructure doesn’t even know that
something should come? We can make XI aware of the fact that something should arrive.

How can we do it?

We can use light event messages and standard XI collect patterns for example.
Since we can easily send an event message after Sales Order creation in the ERP, R3 system
as shown in XI: BAM – Episode I – Introduction
we can use an XI collect pattern to check if a certain (or any) number of messages
reached the XI server.


More about the collect pattern on: Example: Collecting and Bundling Messages – One Interface

What can be done to implement the proactive monitor:

– we can define a deadline branch (timeout branch) which will
be executed after a few hours – if the loop won’t be executed
a number of times (let’s say 500 as we expect 500 Sales Orders per day)
during the time defined in the deadline branch you will get an alert message
that too few Sales Orders arrived today and probably there might be an error
on the legacy system side.

– you can start the BPM every morning via a dummy message – scheduled abap report (RFC, PROXY)
and this way you can check if any sales order message arrived to the BPM
to start the loop – if none at all, it will also invoke the deadline branch

These are just a few ideas how you can implement a simple proactive monitor
but before you do it you need to take into consideration a few things:

– can you allow do have a running BPM instance with the collect pattern
(even though you will use a very light event messages – with only a few fields)
this might not be appropriate if your XI server is under very heavy load.

– you need to think how you want to start your BPM (via additional message,
with the Sales Oders only) and what will be be the ending conditions
(deadline branch, other scheduled message) and also what to do with days if no SO should arrive.


I hope this weblog will be a good start for a simple proactive monitor conversation at your companies
as many of you will probably sooner or later want to develop something similar
that will allow you to monitor messages that never reached your XI servers.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Hi Michal,
      I've been thinking about BAM since I first became involved with XI, and noticed that it was essentially missing from the standard product but could be built from the delivered funtionality. In the last year I've been looking at Event Management in a number on contexts, including as a tool which could be central to a  BAM solution, along with say, BI. The Events could be triggered in a variety of ways, including Alerts or Events messages, the Event API.

      I haven't had the opportunity to put the whole thing together yet, so it all exists only on paper. I know that you've been looking at EM, like me, in the context of AII.

      I'm fully expecting SAP to move its Event Management component out of SCM and into NetWeaver, perhaps in the next major NW release. It can already be installed stand-alone, and has such powerful generic functionality that even though the existing GUI is still clunky IMO, if used as a back-end engine I can see a lot of use for it.

      What do you think?


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

      I'm sure that events will become more popular
      as SAP mentions them on many SOA slides

      I agree tat it would be nice to have stand alone
      so all apps coulc connect to it more easily but I don't know if this is the direction that SAP will go...

      in cotext of new applications (like AII)
      it's even more important as you can create
      many generic event scenarios very quickly
      and not wait for the standard to appear 🙂
      and they can be easily used later on 

      thank for sharing your thoughts Tony 🙂

      Hope to see a weblog from you when you will
      gather your thoughts 🙂


      Author's profile photo Former Member
      Former Member
      Michal, In the technique you suggest , the trigger/dummy message origninates from target system(R/3). Now, In order to have a proactive monitor for source system availability, there is a dependency on the target system being up(to trigger the dummy message). Now, this external dependency and using BPM is an overhead rite for having a monitor.
      But then it is a good idea you have discussed in your blog, the technique is cumbersome i beleive. I had file/ftp based interfaces in one of my XI assignments and we had scheduled cron jobs in XI box to execute shell script(SCP) to move files from sFTP site to XI box. Now this itself brings lot of failure points, source legacy system being one, cron daemon to be up and running being second(whenever box is brought down for maintenance) & availability of sFTP site being third and so on. We did have a need for effective tracing of messages and alerting when systems are down, i could not find any readymade.
      But for outbound idocs from R/3, we logged each idoc number & the corresponding filename in a ztable in XI abap stack, then exposed a RFC that can be called from r/3 system(R/3 support team uses this) to check if all idocs are gone to the target system/BP. This is not BAM , since it has to be real time, but then atleast we had some reporting feature.


      Author's profile photo Michal Krawczyk
      Michal Krawczyk
      Blog Post Author
      hi Saravana 🙂

      first tof all thank you!
      I wrote this weblog to start a conversation
      about proactive monitors (how they can be create,
      what are the concequences). I'm aware of many issues you've brought up (and I update the weblog
      as maybe I didn't mention all of them). also thank you for sharing another ideas of such monitors. I'm sure there are many more out there
      and I just wish more people would comment on that... 

      once more thank you very much Saravana 🙂


      Author's profile photo Michal Krawczyk
      Michal Krawczyk
      Blog Post Author
      one more thing:

      >>>>that can be called from r/3 system(R/3 support team uses this) to check if all idocs are gone to the target system/BP. This is not BAM ,

      what if you have the SAP only at the receiver
      and you cannot monitor the sender system
      (only XI or receiver)
      there are many question you need to rethink
      but that's the beauty of this I guess:)


      Author's profile photo Matt Harding
      Matt Harding
      We've gone with a slightly different approach which involves regularly checking the main XI message table for number of messages of a certain type in the last x hours.  I find this quite a heavy load on the system due to the large number of messages in our system so I quite like the idea of this more specific message monitoring approach.  That said, one benefit of our approach is that this does allow us to easily configure additional interfaces doing the same thing if required.

      Note - From a triggering perspective, it seems a common approach we've also adopted is to establish an application client independent of the integration client but on the same instance.  This way, a scheduled job in the app client can then kick off an ABAP Proxy to the XI client to start your collection ccBPM.


      Author's profile photo Michal Krawczyk
      Michal Krawczyk
      Blog Post Author
      hi Matt,

      thanks for sharing your ideas and solutions too 🙂