How to know the size of a message

Message size is message-class-specific, so there is no single universal “size” property for every message type. For HL7 messages, you can use the FullSize property in SQL. Example queries shown in the retrieved material are: SELECT ID FROM EnsLib_HL7.Message WHERE FullSize > ? and SELECT M.FullSize FROM Ens.MessageHeader H JOIN EnsLib_HL7.Message M ON H.MessageBodyId=M.ID Where H.MessageBodyClassName='EnsLib.HL7.Message'. [1]

If your SDA messages are stored as some class other than EnsLib.HL7.Message, you need to know that body class and check whether it exposes a size-related property; the retrieved material explicitly says there is no single property that works for all message classes. [1]

For estimating how much disk was used in the last 24 hours, the retrieved material points to Ensemble activity volume statistics, which can capture message activity statistics every 10 seconds, every hour, and every day into tables. It also says you are encouraged to use those statistics tables to create your own dashboards and reports, and another retrieved item gives an example of querying Ens_Activity_Data.Days by TimeSlot for a specific day. [2][3]

If your main concern is PDF/stream storage growth, one suggestion in the retrieved material is to store links to files instead of storing the files themselves in the database, so the database size stays small. Another comment mentions using external file streams for PDFs, with the tradeoff that those files are not part of the database/journal storage in the same way. [4]

The retrieved material also mentions a framework that captures database file size used, journal file size used, journal space used, and global growth before and after interface activity and after purge, specifically to help estimate space usage and growth rates. [5]

One more point from the retrieved material: monitoring disk space should include both the disks where productions store messages and the journal disks. [2]

Sources: