>My objects are being transferred between my script elements perfectly,
>until I inserted an User Interaction element in between, how can this be explained?
User Interactions are intended for things like approvals, long running operations on other systems or for calbacks when an external system can call back vCO. That's why using user interactions is one of the best option for achiving scalable solution when long running operations are needed.
Hence, when an User Interaction element is reached during workflow executions, the workflow is suspended, the state is persisted in the database and the resources are released until an answer to this user interaction (either by user or another system) is received.
That's why you see the issue when there is an User Interaction. However, you can't count that this will work from one scripting element to another.
>Is the logic for finding an object in a script element and an User Interaction element somehow different?
No. It is not different. It is working in your case because it is taking the object from a cache for effeciency reasons between the elements. This might not work if the system is heavily loaded and the cache memory needs to be recycled. Then the object will be removed from the cache and when needed again the finder method find(String type, String id) will be called. Also, the state of the workflow is checkpointed (persisted) on every element with the assumption that if the system for some reasons goes down, it will resume the workflows from the place it stopped. Again the find(Stig type, String id) will be used.
As a summary, the contract in order for the system to be high available is for the ojects to be persisted between element transition.
>If I'm to make the PluginFactory find the correct object, I'll probably have to maintain those objects on the server side,
Yes, you need to keep all of your objects on the server side
>just like how the SolarSystem plugin keeps all the celestial body objects in memory,
Yes, but as I mentioned above, the in-memroy storage is just for simplicity example. Production wise, it is recommended to be stored to db/file or some other persistent storage.
>but this doesn't really match my intention.
>My objects are all one-off objects that are created at the start
>of my workflow and should be discarded at the end of the workflow.
The good news is that there is another way for your case ;-).
>I don't want to keep them as permanent objects, which in my opinion,
>would only be necessary if you want to impelment an inventory.
Yes. the finder methods are needed mostly if you want to implement inventory.
>Please correct me if I'm wrong and if there's a solution that doesn't require keeping the objects on the server side, it would be awesome!
There is no solution that will not store the objects on the server side. However, for some of the objects vCO will take care automatically to do that.
Those are all simple objects but we can assume String and Property object (of simple types).
So, in your case I will recommend the use of Property object. Actaully, every javascript object is kind of Property object anyway.
The idea is to have input and ouput arguments of type Property. You can create property object like:
var props = new Property();
props.put("key", "value");
or just
var props = {};
props.key = "value"
or
props["key"] = "value"
or
var props = {key: "value"}.
Hope, this could be helpful in your case.