During our visit to one of the GE Orchestrate conferences, we had a talk with a customer about Gremlins in their database. Immediately picturing the relentless destruction by the creatures from the atypical 80’s Christmas movie, we knew that this customer was in a tough spot.

After asking the more technical questions, we learned that parts of the network data would be thrown back in time whenever an engineer posted a design. Not always, but sometimes, and only very regional. The customer was able to cope with this with a lot of manual interventions, but it is far from ideal. And Smallworld’s proven mechanism for handling alternatives and versions should make this very easy and reliable, so what is going on?

 

Scary Gremlin

A Gremlin from the identically named 1984 movie (https://www.gremlns.com/)

We helped this customer by giving visibility on the design conflict resolution process.

This was the battle plan:

  1. Make a Magik code definition of a Gremlin attack (a network component that is thrown back in time)
  2. Observe all conflict resolutions in the Electric Office production system with Diagnostics monitoring
  3. When an attack happens on the database, analyze the monitoring data to see what caused it

{pre_merge} / {post_merge}

This methodical approach combined with the power of Diagnostics for harvesting enormous amounts of monitoring data revealed where the Gremlins came from. A crucial part of the conflict resolution mechanism revolves around the {pre_merge} and {post_merge} checkpoints. Sometimes these checkpoints were removed by accident, effectively skipping the conflict resolution step. This would only become apparent when the design was posted, causing the manual interventions at that time.

With this insight at hand, the fix became very easy. Just 2 lines of Magik code needed to be changed to stop the Gremlins from multiplying themselves ever again. From now on onwards, Gremlins is just a quirky movie again, and not a real-life nightmare!