Automate Development Workflow through Rails Console?


I create automation methods, instances, state machines, etc as part of my CloudForms-related job duties. The only workflow I know of is to use the automate section to create my classes, and instances then use the built-in editor to create my code. The testing step involves triggering the code somehow (button, service creation, vm provision, or API call) and waiting while the entire automation routine executes. Once my code is reached, it inevitably fails the first few times so I must repeat the long and tedious cycle.

My question is, is there a way of simulating/creating a full automation context within a rails console session? I’m aware of setting up a basic $evm context:

$evm =

This is great but I’m looking more for simulating a full blown $evm.root object complete with miq_request, miq_request_task, service_request_task, or whatever else I might be trying to work with (my question stems from not having a complete understanding for how this all gets populated during an automation request). I’m essentially looking for a better workflow for writing my automation code without having to manually trigger something within the UI and wait for the entire state machine(s) to execute before my code is hit. Is anyone aware if this is possible? If so, how? I will gladly draft some sort of documentation here once I have the answer(s).

Thanks in advance!

1 Like

To just test Automate Methods which take in parameters like a VM, Host etc, you can use the Simulation under Automate.

If you want to test a specific method instance you can use the following

In the Simulation Page:

Object Details
(1) System/Process/ Change this to Request
(2) Message Leave as default
(3) Request Call_Instance

Object Attribute
Type Pick a VM/Host/…

Simulation Parameters
Execute Methods Should be Enabled (Checked on)

Attribute/Value Pairs
namespace Your Domain/namespace
class Your classname
instance Your method instance name
MiqRequest::var1 Id of Request

You can add other attribute value pairs they would all be present in the $evm.root object when your method runs. In the above example MiqRequest is the Model name and the value would be the ID. In the automate object it would be accessible as $evm.root[‘var1’]

mkanoor, thanks for the reply. Unfortunately, whether it’s my lack of understanding on how Simulation is supposed to work or perhaps how my automation code works, I’ve never found Simulation to be very useful. When I run the Simulation, the data returned to me doesn’t allow me to really work through my automation code. If I could somehow incorporate the rails console into my automation development workflow, I could experiment with object attributes “live”, validate that my code works as expected, etc.

I think what I’m really looking for is to understand how the $evm.root object is create/setup once automation has started. I’ve begun digging through the source to piece this together myself but any outside assistance/explanations would be huge.

Thanks again,

There isn’t a simple way to debug thru an Automate Method, since the Automate methods run via Drb as a client/server, where the Automation Engine acts as a Server and the ruby method acts like a client. The Objects that are provided to the client (the automate method) are not the real Active Record objects they are shielded by Service Models which control which attributes/methods from Active record objects are exposed to the Automate methods.
The simulation approach works well for methods as long as you are willing to look at the automation.log and passing in the parameters and objects to the methods.

Our rails app has the object models stored as Active Record objects, when we provision some of the model code is invoked from the UI to start Provision work for VM’s, Cloud Instances, Services and each of these model code pass specific Active Record objects to the Automate Engine

The Automate Engine along with the Automate Object model allows for extending the workflow to add additional steps specific to a customers environment.

The Automate Engine gets passed in a URL, with the name of the Automate model instance to invoke along with the required attributes, the root object is typically the object that was built first based on the incoming attributes augmented by the attributes defined in the model as relationships are traversed and attributes collected. The Automate methods can be called at many different points as the engine traverses the Automate model.

If you know what kind of attributes you are expecting to see in your automate method you might be able to test some portions of the logic externally in the rails console by wrapping the Active Record objects using the Service Model objects.
For example to get the VM wrapped as a service model you could do the following


You might be able to wrap other objects in this fashion from the rails console.


Thanks again for the response. This info is VERY helpful. I had begun piecing some of this flow together but you’ve filled in a lot of gaps for me. I think I have enough understanding now to do some exploration. I will post here if I come up with anything useful or have any further questions.



I wonder did you managed to improve using rails console for testing automation scripts since this comment?

@borisk We did recently add a helper method for Rails console … New helper for setting up $evm