When talking about his Model-T automobiles, Henry Ford once said, "You can have any color you want, as long as it's black."  He had automated the production of automobiles through the use of the assembly line.  

Like Mr. Ford, when we are performing rapid network automation using network performance data, we want to automate the production of data objects that will allow us to quickly and efficiently complete our task.  But what if we want some of the objects to have a color that's something other than "black"?  Here's where cloning of objects comes in handy.  

Since we are talking cars, let's stay within that genre as we look into why cloning is necessary when mass producing them.

Let's start out by creating one car object using IBM's Rapid Network Automation interface.  Our $car object will have a color of "red" and will have two doors.

It can be represented as follows:

Terrific!  We have one car completed.  We can load it into our "cars" array for safe keeping and get working on our next car.

Now, let's create another car ($car1).  Let's re-use the previous $car object when creating our new $car1 object:

Now when we run our automation, we can see that we have two cars created, both with the same values.  This is all great until we want to change the color of $car1.

Let's change $car1's color to "blue".  I can just assign the color to $car1's color property, right?

Let's look at the results.  What happened?  Now both cars are "blue"!  Is this the "Model-T" one-color curse coming to life?

Let's load $car1 into our $cars array:

Now, if we run our automation and view the log, we can see our $cars objects.  We can see our first car ($cars[0]) with its two properties of 'color' and 'doors'.  The second car ($cars[1]), looks rather odd.  Rather than having the expected properties of 'color' and 'doors', it is telling us that it is referencing $cars[0].  $cars[1]'s value is set to a reference pointer in memory of the $cars[0] object that we had copied earlier.  This explains when we modify a property in $cars[1], it is in-effect modifying $cars[0]'s property value instead.  This isn't the behavior we want if we want to preserve the property values on a per-car (per-object) basis.

Enter cloning!  Cloning is the process of copying an object, but instead of just pointing to its memory location, it creates a brand new object with its own memory space, making it possible to uniquely define properties on a per-object basis without overwriting properties of other objects!

To do this, we need to insert a few blocks after we copy our original car object.  There are two JSON action blocks that we can use to first convert the new car object from a memory reference to a string.  It's called "JsonStringify".  You pass your $car1 object into it, and it converts it to a string.  You then pass the result of the "stringification" (I made up that word) into the "JsonParse" action block, which converts the string back into an object -- a unique object with its own unique properties.  Our object has just been cloned!

Now when we run our automation, we get the behavior we want.  $cars[0] is its own glorious original "red" self, and $cars[1] is now colored "blue" without impacting the first car.

You may have noticed that the number of doors has changed for $cars[1].  Once the car object is cloned, you can modify it within the array as follows:

So that's it!  We can add any number of similar objects.  As long as we clone them as we go, the objects will be written to their own memory space, allowing us to modify the property values of one object without impacting the others.  This ensures that you get what you expect at the end of the day.

I hope that this cloning example helped to unmask the mystery of working with objects en-masse while keeping property values unique ("reverse the one-color curse")!