Skip to Content
Technical Articles

CPI MPL Custom Header Property Search with SuperEasy

As Santhosh Kumar Vellingiri shared his findings in this blog post about how MPL Custom Header Properties can be used for search with OData APIs. He also encouraged me to add this feature to SuperEasy. Thank you for the challenge, Santhosh! It is a pleasure for me to improve CPI experience! (Thanks again for the APIs & open-minded approach SAP team! The APIs were my dream for years working on PI/PO.)

Note: It is not yet clear if these properties are indexed, so you should only use it for occasional searches.


There is a new menu for MPL Custom Header Property Search. You enter property key, value and click “Search”. You can jump to the standard monitoring screens by clicking “Message” or “Correlation” links.

This is the log “Text View” for the same message:

Update for Wildcard Search(2020-10-12)

Search now supports wildcard! Thanks for the idea, high-quality feedback, and contribution from Raffael Herrmann you can use *(asterisk) anywhere in the value to search.

For example, for the value 12345ABC67890 you can even use *23*ABC*67*

Groovy Example

I have also added the Groovy example & explanation to the CPI Groovy Examples Repository


Example page:

Install Extension

Chrome Extension Install:

Microsoft Edge(Chromium-based) Extension Install:

Thanks for reading!

You must be Logged on to comment or reply to a post.
  • Hi Fatih,

    that is a great feature! Maybe we can bring it even to the next level. What about using wildcards in search? (Sometimes leading zeros or number ranges make search hard, thus wildcards could come in handy.)

    Currently you’re calling the following API url:

    /itspaces/odata/api/v1/MessageProcessingLogCustomHeaderProperties?$filter=Name eq '<FIELDNAME>' and Value eq '<VAL>'&$expand=Log&$format=json

    For wildcard support you could change the urls as follows. (Maybe there are more intelligent solutions, but this is how I would do it right now.)

    Case 1

    Fieldname: Material, Searchpattern: 1234
    Url: Keep as it is implemented right now.

    Case 2

    Fieldname: Material, Searchpattern: *1234

    /itspaces/odata/api/v1/MessageProcessingLogCustomHeaderProperties?$filter=Name eq 'MATERIAL' and endswith(Value,'1234')&$expand=Log&$format=json

    Case 3

    Fieldname: Material, Searchpattern: 1234*

    /itspaces/odata/api/v1/MessageProcessingLogCustomHeaderProperties?$filter=Name eq 'MATERIAL' and startswith(Value,'1234')&$expand=Log&$format=json

    Case 4

    Fieldname: Material, Searchpattern: *1234*

    /itspaces/odata/api/v1/MessageProcessingLogCustomHeaderProperties?$filter=Name eq 'MATERIAL' and substringof('1234', Value)&$expand=Log&$format=json


    So basically, if pattern starts with *, then remove * from pattern use “endswith”-style url. If pattern ends with *, then remove * from pattern use “startswith”-style url. If pattern starts and ends with *, then remove * from pattern use “substringof”-style url.

    If pattern contains more then two * or a * inbetween the pattern, I can think of three options:

    1. Show a popup/alert to the plugin user, that wildcards inbetween aren’t allowed
    2. Just take * in between the searchphrase as “string”/part of the searchphrase as any other char
    3. Write a more complex logic, that splits the searchphrase at every * and then build a “combined” filter out of all wildcarded parts of the searchphrase.


    Best regards,

    • Hello Raffael,

      Thank you for the complete and detailed analysis for the feature! It makes sense to provide this option since the first use-case is not even affected. Hopefully, I will try to implement it soon.

      Best regards,