Basic Monitoring and Administration for the Integration Developer (3/3)
In this blog, we shall explore the logs available for the integration developer.
Part 3: Understanding the logs in HCI-PI
As an integration developer, you have access to the following two logs that can help you debug message processing and artifact deployment issues.
- Message monitoring log
- Tail log
Understanding the Message Monitoring Log
Let me take an example of a “failed” message to explain this log.
Consider the following integration flow. The Integration flow is triggered on a particular schedule, followed by a content modifier (where I have inserted text in the body of the payload); followed by a multicast message that sends the message to two different branches and to two different receivers. In the monitoring view, I get a failed message processing.
First step – click on the message and in the Properties View, you can view the message monitoring log.
It is a very detailed log and it can appear confusing at first. However, once you understand the structure of the log it becomes easier.
Tip: The default view includes leading spaces in the logs. If you choose to read in a more linear top-down fashion, you can remove the leading spaces. The option is provided in the menu.
The first block of the log contains an overview. If provides the overall status and also the time taken to complete the message processing.
After the overview information block, each processing step is included. In our example, the first step is a scheduled timer start. So, the scheduler starts with the “Children” block. A unique processing ID is created for the timer and you can see that it has successfully completed.
After the Timer step, it goes to the Content Modifier step. This is also executed correctly. However, the step after content modifier, the multicast step, shows an error. And the processing has failed for branch 1 of the multicast.
On scrolling to the right and reading the complete line, it shows that the error is related to connecting to the SFTP server connected to this branch. That helps us in isolating the problem.
Since it is a parallel multicast message, the second branch has executed successfully and it could send the message to the receiver.
The log also provides useful information on how much time each processing step has taken.
There you go; that is how you should interpret the message monitoring log. Let us move on to the next log.
Understanding the Tail Log
The tail log would be typically checked if you have an error in the deployment of the integration flow. Again, with an example – I am deploying an integration flow with the name SF_RCM_TO_SHL_Assessment
On deployment, I find that the component monitor shows an Error status.
Go to the Tail Log view of the Worker Node and check for the detailed error.
- Navigate to the Tail Log view in the Integration Operations perspective.
- Enter a log size (100 KB would do checking the logs of a recent activity, else increase it and check)
- Tip: Enter the name of the integration flow in the search box and click on the next button.
- Check the reasons for the error.
The error is interpreted as the system.jks file not been deployed to the tenant. So, the developer might have just forgotten to deploy the system.jks file, which contains the tenant certificates, to the tenant.
just FYI – In the previous example of the Message monitoring log, the log is also stored in the Tail log. But we need not come to the Tail log to interpret the error. It is easier in the Message monitoring log.
Spoiler [ 😉 ]: To debug this error, you need not go to the Tail logs view. You can obtain it from the Component Monitor view itself. In the context menu of the message, click on Show Error Details. It would provide the error details in the pop-up window. Never-the-less, this example is a good showcase on when to use the Tail Logs.
Hope you have gained a perspective of how to use the monitoring and administration for your development requirements.
Let me know your feedback or suggestions on improving this blog.