I have seen several cases that customer configured the UDMS (user defined message search) on Java stack but it des not function as designed, e.g. messages fit search criteria but are not indexed. I did several tests and found out some rules behind the UDMS, which make it works better. The rules are from functional perspective meaning to make UDMS work but not from performance perspective.
Rule 1: UDMS only works for persisted messages.
It is mentioned in the SAP online help (http://help.sap.com/saphelp_nw73ehp1/helpdata/en/48/b2e0186b156ff4e10000000a42189b/content.htm) that UDMS only works for asynchronous message. But actually UDMS works as long as message gets persisted (staged or logged).
When message is persisted, a persist event is triggered. Then the UDMS event listener will capture the message payload and compare with the search criteria in the cache. Since the logging of synchronous message (successful or error) can also be actived in XI Adapter Service property, the UDMS will work for these cases as well.
As of PI 7.31 the staging and logging can be configured on ICO level, which makes the persistence strategy more flexible.
Rule 2: Search filter must be identical to Message Header.
The required fields in the filter is Filter Name, Interface Name (IF), and Namespace (IFNS). However all the other fileds, such as Sender Party (SP), Sender Component (SC), Reciever Party (RP), and Receiver Component (RC) must be the same as the message header which you would like to be indexed. You can check the message header by clicking “Open Message”.
In this example, SC, RC, IF and IFNS are all presented in the messag header. So the filter must contain the ame information. If the filter is configured without RC information as below, the UDMS will not work. If you don’t want to specify the RC, use “*” as a placeholder.
Rule 3: Staging and Logging of processing steps must correspond to the search filter.
The processing step BI and VI happens before a recerver name is assigned to the message header. If both sende rand receiver components name are defined in the search filter, the persisted version of BI and VI will not be indexed. In this case if you only configured stagging or logging for BI/VI step like below, you will not find the message in the search result. If you want to avoid this, use “*” as a placeholder.
Rule 4: The value of extractors are case-sensitive.
When you search the messages in Message Monitoring, remember that the input ins case-sensitive. For exmple, when you search in an XML-IDOC payload, the data in the IDOC will be converted to capital letters automatically. So you have to input capital letters as the value of the extractors. Also a wildcard “*” can be used among any charactors as the search value.
Rule 5: Extractors can be combined with search mode.
You can select AND or OR as search mode. This is good when you want to extend the search area. The comnination can provide a more flexible usage of the extractors.