I tested this yesterday using the properties object as the type being sent in as an "any" input and was able to duplicate the error you have received. When reviewing a past workflow execution of a manually run workflow with a Properties object sent to an any input, we have the correct format.
Perhaps iiliev can look into this a bit further. My opinion is that this is a bug.
"Any" can be used to transfer object from one scripting box to another, or from scripting box to pass it as input to workflow.
But as far as I remember it was never allowed to provide input parameter of type "Any" for top level workflows.
If you create a workflow with input parameter of type "Any" and try to run it using vRO smart client you will see that it is not editable and you can not provide value for it.
I need to double check it but I would expect that behavior of the REST API is similar( does not accept Any as input)
If you provide a bit more details around your use case we could provide some alternative.
You could also have a workflow accepting your input as type Properties and then delegate the call to Workflow accepting parameter of type "Any"
This approach can be usefull in case you need multiple type safe top level Workflows which delegates the call to another (generic ) workflow accepting input of type "Any" to do the real work.
Thanks for replying!
I have a workflow already defined that accepts an Any input that provisions VM machines for me. I normally call this from another WF, but I have an external system that I'm setting up to call VRO via REST where it makes more sense to call the WF with the Any input directly instead.
I confirmed I can pass in an object of type Composite. This is actually the workaround I'm going to use for now. I just thought it strange that Any did not work, it really seems like it could (and should).
Thanks for taking the time to comment on this.