The first part would show the Message Monitor and the second part would help in understanding the ways to Recover some lost message in Seeburger.
Message Monitor
The EDI files usually constitute one of the most critical Business information exchange for any organization. A very obvious and important feature therefore expected out of Seeburger suite of products is complete monitoring of these files with most ease and comfort.
Seeburger adapters are deployed on adapter engine and hence the messages traversing through them should be monitored when it enters or exits Adapter Engine. For instance, a message flow involving Seeburger at both the end would be as follows: 
Sxmb_moni and Runtime Workbench capabilities provides extensive mechanism for tracing the messages through PI, however, in some cases where some EDI specific monitoring is required, these two options are not sufficient and then Seeburger Message Monitor comes into picture. E.g. Checking whether an MDN (EDI notification message) is received or not.
Note: The version discussed here is Seeburger 1.7 which had some limitations. Some of these limitations may no longer exist in latest versions.
Once the Seeburger Message Monitor is opened from Seeburger Workbench, the first mandatory search criteria encountered would be the type of adapter whose message needs to be checked. It is nowhere mentioned that this is a mandatory field, but neglecting it won't really display anything.
Next selection criteria are usual Date and Time duration which needs no explanation except for the format used. Date - DD.MM.YYYY and Time - HH:MM.
There is an option of searching messages based on PI Message ID. This is very helpful when it comes to monitoring Outbound files or correlating files in Seeburger monitor and PI monitoring tools.
Limitation: The problem with this search criterion for this particular version is that it has to be in Lower case. E.g. Message ID "3C21079A-B436-4AD4-032A-F04722781D8D" won't display any result but the message ID "3c21079a-b436-4ad4-032a-f04722781d8d" will display the required message. This is strange but this is how it works 
With proper selection criteria, once you select the messages, you will have following view. Once you display the messages once, you will have additional search criteria.
Status here provides the Status of messages in Monitor.
Correlation Id is the Message ID of XI message.
Sender & Receiver IDs refers to the partner's ID. E.g. for AS2 messages, it refers to the AS2 ID maintained at Alternative Identifier of Party configuration.
Subject is the Subject of message mentioned in the communication channel based on mutual agreement with the partner.
In/Out refers to the direction of message. The symbol here means that the message is received into Seeburger monitor from outside which would mean that Seeburger Adapter is used at Sender side here.
The details of the messages can be seen if you click on a particular message.
Note here that Message ID is not the actual Message ID of XI. It is specific to Seeburger Adapter. Correlation ID field refers to the XI Message ID. For incoming messages, when the message first enters Seeburger Monitor before PI monitoring, this message ID field remains "null".
This is the place where you may come to know whether requested MDN is received by Seeburger or not. It also shows the type of MDN received (Async or Sync). If MDN is not received, then the status of message won't be green. It would show some message like "Timeout has been reached" or "Waiting for delivery -, receipts -, or both reports".
This is how all Seeburger related communications could be monitored and inspected.
Recovery Monitor
The Seeburger Workbench Recovery Monitor feature would be explained here using one of the Production environment issues faced for a Seeburger related project. There could be cases when suddenly all the messages started accumulating in PI and each and every flow gets stopped. It could be due to numerous reason. Once the problem is resolved, with the automatic restart, the message may start flowing out of PI again and the message flow would seem to start behaving normal again.
However, Business folks then would be the right person to confirm if everything is Really normal. Those messages which have already entered Seeburger at the point of initiation of the problem are not sent automatically outside PI once the all other messages are restarted. These messages remain stuck in the Seeburger and there are two ways of digging out these messages.
First one, checking the messages in Seeburger monitoring and looking for erroneous entry which was displayed as below:
All the fields of monitoring are not shown here however, the most important part here is the symbol "i" on extreme right which occurs under Recovery heading (not shown here). It appears as a link and clicking on it shows the detail of messages.
There are various types of IDs present here but the actual Message ID of PI is the one present in front of "Attachments" option. In order to Recover this specific message, the Recover button shown above should be clicked and the message status would change to green.
Second option available for Recovery was the use of "Recovery Monitor" and using the search criteria to check out the Adapter specific messages under Recovery at particular time interval. This was a better option multiples files have to be monitored and Recovered in one go. The details may be observed in the screenshot below:
Multiple selections option here us very handy for recovering multiple files. The Attachments option here let shows the details of a particular message including the message content. Here again the Attachment ID is the PI Message ID. Using these details we had confirmed the missing files from Business.
Recovery Monitor option hence could make the business team calm down a bit. 
Earlier version of Seeburger Workbench had some problems with this Recovery option. The files were not properly recovered and on few occasions, there were some duplicate file problems. These problems are now taken care in the latest versions and Recovery Monitor behavior is quite stable now.