Blog series on my CPI + Camel learning journey - Part5 - MPL custom app

[alex_myakinkii]

Link back to index: https://community.sap.com/t5/technology-blogs-by-members/blog-series-on-my-cpi-camel-learning-journe...

Ok, in this one we will cover Message Processing Log (MPL) and APIs we have for it so that we could build ourselves something more "lightweight" in terms of performance on one side but also pro-code and camel oriented on another.

Motivation and a little bit of API and entities we use.

My main motivation was - "oh god, the standard app is such a mess, I'll make myself a better one..." after I first had to really troubleshoot some pre-packaged iflow.

But of course, there is a good reason for this - like low-code visual mapping of RunSteps to iflow bpmn etc.

Anyway, after I implemented this one, I completely abandoned the official cpi MPL app.

So, what do we have there in terms of API and entities exposed by it?

Yeah, right.. and in terms of actual OData entities the "entry point" is indeed this guy: MessageProcessingLogs

And one important thing to mention about this guy is it does not support orderby... meaning you either need to fetch all the dataset you filtered to sort it on frontend side, OR you have entries sorted somehow (not even by guid). So in my implementation I decided to keep OData top/skip pagination in place for the sake of performance, so you only have entries sorted in descending order if result set is less than 50 messages.

But what the original diagram does NOT mention the most interesting relation we have there - and use in our app actually - Runs nav property that leads to MessageProcessingLogRuns

And this is where things get interesting, so I will make another diagram to show you actual relations my app uses:

Btw if  you prefer to play with API, I have some mpl requests in test/requests folder

So, what do we have there?

Comparing to the original app which uses Master-Detail layout with all the stuff mixed on the Detail page (coming from god knows where and leading you also somewhere if you manage to find the right link to press), we just use FCL layout (Master-Detail-Detail) to follow (almost) exactly the relationship between entities we identified earlier.

Therefore:

• Master (List Report) is indeed MessageProcessingLogs
• Detail is single MessageProcessingLogs (which I kinda "blended" with artifact this message belonged to) + to-many relation to MessageProcessingLogRuns (though I haven't see the case with more than one Run per message yet) + in case of an error we display  MessageProcessingLogErrorInformations content (which is binary but text)
• Detail-Detail is basically just all  MessageProcessingLogRunSteps within that Run (plus some additional stuff and some magic on frontend side)

What it gives us is consistency of our UX with no dependency on the Log Level settings.

So, in short it looks like this:

Basically, only List Report page with filters and Detail-Detail with actual Steps are of any significance, cuz the middle one is just a place to put some links (to cpi) and buttons (to set log level)

And yes, this one is a freestyle app rather than fiori elements + fpm - if it tells you something - and it was really nice to finally recall some stuff I enjoyed implementing back in the good old days 🙂

Ironically, it was only later that I discovered similar screen in standard app with steps and Activities.

You can compare it to screenshots above - we just display all that stuff at one place (and much faster!).

Ok, but where is Camel?

Well, it turns out that RunSteps could be more or less mapped to elements of our iflows, where Activities within those steps would be our camel processors.

Let's check out this table with screenshots from Detail-Detail screen of our simple Basics_Exception_Subprocess flow with End event (handled exception) and compare it with our blueprint.

Basically, what happens here is we just see the "path our route followed and steps involved" (and in more complicated iflows we would see choices and loops of course).

This is, I believe, the reason why they had to add "Integration Flow Model" tab - to display correlation between run steps and bpmn representation of iflow (we are low-code, right?).

But for us - who only care about camel representation of our iflows - this is completely unnecessary, and this is where our app gains a lot in terms of performance (ok, I also fetch all the steps info at once, so it helps a lot)!

And here's our iflow just for the reference (to compare with steps in the table above)

About UX consistency across Log Levels

In short, this is what we get based on Log Level settings (in order of increasing verbosity):

Log  Level	Behaviour
None	No entry in MPL
Error	ONLY Failed messages get entry in MPL (but MPL Attachments are NOT created automatically for faulty processors)
Info	Run Steps ONLY for Failed messages (WITH MPL Attachments from faulty processors)
Debug	Run Steps for all messages
Trace	On top of Debug we now have TraceMessages (with Message Body and Headers + Exchange Properties) that expire after some time.

So, one final thing before the demo (where we will see all this in action) is to repeat again that our UX stays the same (Master-Detail-Detail) in all cases, the only difference being that sometimes we don't get Run Steps, therefore cannot see anything on Detail-Detail, and obviously, when log level is set to None, we dont't have messages in Master list at all, while in Trace mode we have extra stuff in Run Steps (as links).

Another minor thing is we always display an Error on our Detail page if there was one at some steps, because we still have some data in related MessageProcessingLogErrorInformations (it feels to me that it's just the last Error/Exception happened during processing). So I decided to keep it (kinda as an indicator that there were some exceptions thrown in the flow), while in the original app they hide it for Completed messages.

Demo part

Here we will play with our friend Basics_Exception_Subprocess iflow again while changing log levels and error/end termination events.

00:00 Intro and motivation

01:07 Difference in UX between the original mpl app and new one (Master-Detail vs FCL)

02:58 Some hints on sorting of log items (and pagination) and list report conveniences (like click to filter)

04:33 Scenario1 - Escalation end + TRACE log level

10:55 Mysterious publishAlertInfo step from sap-alert component

11:35 Regarding Trace Messages expiration

13:28 Scenario2 - Escalation end + DEBUG log level

16:58 Scenario3 - End Message end + DEBUG log level

20:24 Scenario4 - End Message end + INFO log level

21:35 Scenario5 - Error end + INFO log level

26:17 Scenario6 - Error end + ERROR log level

27:25 NONE log level + outro

P.S.

As we saw, the app does not cover all the possible relations to entities from original diagram (like storage part) and of course, I will add some features once I encounter it myself, but any feedback regarding missing features based on your typical flow would be highly appreciated!

Cuz I believe this thing alone could be easily made deployable to CF as a part of "CPI companion suite", and maybe I will write a blog about it later.