on 04-20-2007 10:41 AM
Hi, at the moment I face an interesting monitoring requirement. See below. I hope you experts can help me out? Many thanks for all your feedback
REQUIREMENT
<u>Users want to view the status of the message as it flows through the Sender, Hub(s) and Receiver(s).</u>
Preferably without opening any other applications (nice-to-have)
1 central (monitoring) application
Drill-down to the state of the message in the process pipeline (nice-to-have)
Preferably near realtime (nice-to-have)
Solution must be as generic and cheap/easy as possible, meaning costs:benefits effective. Pretty obvious, we don't want huge developments...
BACKGROUND
<u>SAP and non-SAP applications are involved in message exchange.
Only SOAP, IDoc and XI Adapters are used.
SAP PI, version 7.00, is the message Hub (1 Integration Server + Central AE).</u>
POSSIBLE SOLUTIONS
<u>PMI (end-2-end monitoring in RWB, package SPI) seems the most promising (http://help.sap.com/saphelp_nw2004s/helpdata/en/a8/a81b0b6473cb49bc34effad6eab13b/content.htm) .
</u>
Only covers PMI-enabled SAP-components (IE, ALE, AF, Java?),
<i>What about non-SAP applications?</i> It looks complicated, and there is no documented API.
User-unfriendly GUI (via the RWB), although it is centrally located
<i>Is drilling down into a message possible?</i> For example going to an IDoc in a backend system as with BD87.
Not really realtime (a lot of jobs required: agents, aggregation)
<u>Alert Management (http://help.sap.com/saphelp_nw2004s/helpdata/en/3f/81023cfa699508e10000000a11402f/content.htm )</u>
Usually reserved for error situations.
Alerts can be raised easily by other applications (especially ABAP)
ccBPM can be used (only for the XI part of the message exchange)
OR the pipeline definition can be enhanced. <i>Has anyone experience with this?</i> Implementing a ZCL_PLSRV* class plus modifying the SXMSPIPEEL, SXMSPLSRV, etc. tables.
Aggregating Alerts that all refer to 1 message exchange (1 process) is difficult. <i>Has anyone experience with this?</i>
Drill down to the actual message not possible, must use other tools
<u>Acknowledgements (especially application acks)</u> SOAP (and other AF) Adapters cant handle app acks.
This might be bypassed by providing a generic (web)service that accepts messages that can be routed via the <pipeline>_BACK to the original message (comparable to the ALEAUD IDoc). <i>Has anyone done this before?</i> For Senders using the SOAP Adapter the message header could be enhanced to request app acks (pos/neg). <i>Can this be done via a Java Module?</i> Or the IS pipeline definition could be enhanced later on. <i>Has anyone experience with this?</i> Implementing a ZCL_PLSRV* class plus modifying the SXMSPIPEEL, SXMSPLSRV, etc. tables.
Standard acks are linked to the sending message, but usually dont give very helpful information. <i>Where can this be enhanced?</i> For ALEAUD we can modify the IDoc processing (outbound/inbound).
<i>When are acks (application and system, positive and negative) actually raised? Can this be configured/adapted anywhere?</i>
Not 1 place wherefrom the message exchanges can be monitored, but in multiple Senders.
Too bad, but it was a nice-to-have.
Drill down only possible in Sender (probably), must use other tools
<u>CCMS</u>
I dont see that CCMS can be enhanced to cover this requirement. <i>Anyone who has a different idea?</i> Feel free to post all your opinions, how exotic these may sound (initially).
<u> Other ...</u>
Maybe I took a wrong turn somewhere. If you have a very elegant but different solution, please point me in that direction. Im quite curious
Hi,
as explined above Alerts are not only from ccBPM,
Actually alerts from SAP Alert management.
See the below links
Triggering XI Alerts from a User Defined Function - /people/bhavesh.kantilal/blog/2006/07/25/triggering-xi-alerts-from-a-user-defined-function
blogs for alerts
https://www.sdn.sap.com/irj/sdn/advancedsearch?query=alerts&cat=sdn_weblog
http://help.sap.com/saphelp_nw2004s/helpdata/en/2b/d925bf4b8a11d1894c0000e8323c4f/content.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/9c/34193cb4f5131de10000000a11405a/content.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/8a/3e2d4105f8d92be10000000a1550b0/content.htm
/people/michal.krawczyk2/blog/2005/09/09/xi-alerts--step-by-step - Alert Configuration
/people/michal.krawczyk2/blog/2005/09/09/xi-alerts--troubleshooting-guide - Trouble shoot alert config
/people/aravindh.prasanna/blog/2005/12/23/configuring-scenario-specific-e-mail-alerts-in-xi-ccms-part--1 -- ccms alerts - 1
/people/aravindh.prasanna/blog/2005/12/24/configuring-scenario-specific-e-mail-alerts-in-xi-ccms-part-2 -- ccms alerts -- 2
/people/aravindh.prasanna/blog/2006/02/20/configuring-scenario-specific-e-mail-alerts-in-xi-ccms-part-3 -- ccms alerts --- 3
Regards
Chilla
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
All,
<b>Alerting would solve this issue,
if Alerts could also be raised in SAP and non-SAP apps,</b>
=> indeed, ABAP can easily trigger Alerts. Non-SAP apps should be adapted to raise Alerts.
<b>if successful (not just erroneous) processing could trigger Alerts (not just from ccBPM),</b>
=> you have to determine "points in the process pipeline" (Sender app, hub (XI), Receiver) where to raise Alerts (successes/errors). It could mean adapting the Pipeline Definition.
<b>and if Alerts on 1 message could be aggregated in one place (I ignore the Drilldown part).</b>
=> An email client covers the "one place"-req. But it's quite obtrusive, especially if a flood of Alerts reporting successes appear in the user's inbox.
The AlertInbox itself might be a good option, if you could aggregate all Alerts referencing 1 message (exchange), like the SAP:RefToMessageId element in the XI Header. Which brings me to disadvantages of Alerts: they are very text based (AFAIK) without any fields. Also, some Alerts should be escalated via email/sms, while most will be "process monitoring alerts". This is something I cannot personalize in my Alert Inbox...
Actually, PMI is more promising, and by having PMI SAP recognizes this requirement. But, the implementation by SAP is ugly (as usual) and limited in scope. So you might take a look at PMI or the other options I mentioned.
Hi Wout,
<i>
Users want to view the status of the message as it flows through the Sender, Hub(s) and Receiver(s).
Preferably without opening any other applications (nice-to-have)
1 central (monitoring) application
Drill-down to the state of the message in the process pipeline (nice-to-have)</i> - For this use PMI(end-to-end monitoring in RWB).......
Configure alerts for CCMS, adapter engine so that if any of SOAP, IDoc and XI Adapters are in error, then your users will get an alert mail in their alert inbox with the alert description.........
So by this your monitoring req may be covered........
Thanks,
Rajeev Gupta
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
> <u>Alert Management
> (http://help.sap.com/saphelp_nw2004s/helpdata/en/3f/81
> 023cfa699508e10000000a11402f/content.htm )</u>
> Usually reserved for error situations.
> Alerts can be raised easily by other applications
> s (especially ABAP)
> ccBPM can be used (only for the XI part of the
> he message exchange)
> OR the pipeline definition can be enhanced. <i>Has
> as anyone experience with this?</i> Implementing a
> ZCL_PLSRV* class plus modifying the SXMSPIPEEL,
> SXMSPLSRV, etc. tables.
> Aggregating Alerts that all refer to 1 message
> e exchange (1 process) is difficult. <i>Has anyone
> experience with this?</i>
> Drill down to the actual message not possible, must
> use other tools
XI alerts can be used for non BPM solutions as well. Any error in XI can trigger a Alert and this can be forwarded as an EMail .
Take a look at blog no 2328 --> XI alerts step by step.
Regards
Bhavesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Bhavesh, thanks for your feedback.
The requirement is more elaborate. Alerting would solve this issue, if Alerts could also be raised in SAP and non-SAP apps, if successful (not just erroneous) processing could trigger Alerts (not just from ccBPM), and if Alerts on 1 message could be aggregated in one place (I ignore the Drilldown part).
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.