Flag Monkey (MDC)

Have you ever been in one piece of code and need to alert an unlinked piece of code to what is going on?  This is sometimes very tricky to solve.  Enter Flag Monkey

Problem

I am in a handler function, which calls into a plugin.  The plugin needs to tell the serializer that in certain cases it needs to perform a certain way.  The serializer is not part of the plugin so how can you let it know when it gets to that code, what is going on.

Solution

There is a little-known facility within InsuranceSuite that we can take advantage of that exists across sessions and code boundaries.  This is called MDC, Mapped Diagnostic Context, and is part of the log4j framework.
You can read more about it here.

Using MDC

One of the simplest ways to use MDC is like a property bag.  You can store items at one place and read them in another.  The issue you have is one of threading.  MDC lives across threads so you need to be very careful about setting and reading data.  One way to handle this is to mark the name with enough context for the read to be thread-aware

MDC.put(“ehc-${period.Submission.MasterThreadID}”, ehc)

This translates to reading it back as

MDC.get(“ehc-${threadID}”) as ErrorHandlingContextInstance

Notice that the value side of the equation is an object so it is important to cast it upon retrieval.
This means that the property consumer needs to be aware of the context around the value.
This can and should be encapsulated within the class that uses the MDC so that there is no casting needed beyond the encapsulated class.

Within your class, this can be achieved something like this

static function addErrorContext(period : PolicyPeriod) {
  if (period.Submission.MasterThreadID != null) {
    var ehc = new ErrorHandlingContextInstance()
    MDC.put("ehc-${period.Submission.MasterThreadID}", ehc)
  }
}

static function getErrorContextInstance(threadID : String) : ErrorHandlingContextInstance {
  if (threadID == null) { return null }
  return MDC.get("ehc-${threadID}") as ErrorHandlingContextInstance
}

Another issue that can arise if you are not careful is leaving properties in the bag.  If needed, wrap the use case in a try/finally block to make sure the property is always removed from the MDC.  If you need the value across sessions, maybe for portal, then you would want to put the session ID into the name so it can be distinguished across session boundaries.

Troy Stauffer
Senior Software Architect


Watch or read our other posts at Kimputing Blogs. You’ll find everything from Automated testing to CenterTest, Guidewire knowledge to general interest. We’re trying to help share our knowledge from decades of experience.

Similar Posts