In a previous post, we saw how we can build a utility library to help us with typical logging tasks. However, there is a common problem when trying to represent the state of our processes in logs: it’s complicated to log non-string objects, even if they look like Strings, with .LogMessage() calls. Even simple List instances containing String objects will need some sort of custom processing.

This is where JSON comes in handy. In short, JSON is a way to convert any common data-structure into text, which is something we can log. It's a very well-known format in web-development circles, and it has long replaced XML and most other serialization standards.

Initial Setup

The initial setup is fairly simple: we need to Import the JSON libraries shipped with the product (full reference can be found here). At the very top of our Business Rule, where we list libraries, let's add these 2 rows:

Imports Newtonsoft.Json
Imports Newtonsoft.Json.Linq

Using JSON to log a message

Let's say we have a List of MemberInfo objects, as returned by the well-known GetMembersUsingFilter() function. Here we're getting all Origin members:

Dim OriginList as List(Of MemberInfo) = api.Members.GetMembersUsingFilter( _
       api.Dimensions.GetDim("Origin").DimPk, _
       "O#Top.DescendantsInclusive", _
       Nothing )

Let’s see what we get when we log this list using a “simple” api.LogMessage(). The code would look like this, and it validates:


Let’s look at results:


Ok, we were told the object is a List of MemberInfos, but that’s not very helpful.

Let’s use JSON instead! With JsonConvert.SerializeObject, we can turn anything into a String. It's super simple:

Dim stringObj as String = JsonConvert.SerializeObject( OriginList, Formatting.Indented )
api.LogMessage("OriginList: " & stringObj)

And this is the result:


Now that is more valuable information!

This technique is not limited to Lists; you can log literally anything: a DimPk, a MemberInfo, and even Databuffers look good with JSON (although they have their own .LogDataBuffer method, which might be preferable most of the time).

JSON logging can be a powerful weapon in your arsenal of troubleshooting weapons. Combined with the strategies seen in our previous posts, it should allow you to perform complex diagnostic tasks throughout your OneStream implementations. However, when it comes to logging, the sky is the limit! Did you ever build custom logging systems? Let us know in comments!