Hi,
I am curious if someone else faces this problem/bug. I installed vRealize Orchestrator 7.0.0 Applicance.
When I select "Predefined list of elements" in the Presentation tab and select the purple puzzle symbol to link an action the popup remains empty - It just does not show any action to select.
In Orchestrator 5.5. (Windows) I can verify it is working.
Hmm... I am seeing the same thing. Gonna poke around a bit more.
I'd go further and say that its just broken for me anytime I try to pull up the action list with any of the options. Nothing is listed but I have zillions of actions available.
Tried it on my 7.0.0 appliance; seems to work fine.
What is the type of the input parameter? Are you sure you have actions with return type suitable for predefined list of elements of this input type?
What happens if you mouse click into Field edit box and press Enter, or type/remove some characters?
Also, could you check if there is something in log files? Maybe some error is thrown during actions list retrieval (not very likely, but still...)
I was testing in a string field. I have tons of actions that return an array of strings. I clicked the "Show Any" check box on and off. Typed stuff in. Deleted it back to empty. No results. The sceen did seem to kind of blip for a sec at some point. I'll check the logs and get back to you.
I see these errors in the logs:
2016-01-28 23:15:02.073+0000 [http-nio-10.52.130.61-8281-exec-8] ERROR {} [SqlExceptionHelper] Argument data type ntext is invalid for argument 1 of lower function.
2016-01-28 23:15:02.074+0000 [http-nio-10.52.130.61-8281-exec-8] ERROR {} [VcoDelegatingWebFacade] Server Error...
2016-01-28 23:15:02.075+0000 [http-nio-10.52.130.61-8281-exec-8] ERROR {} [VcoFactoryServiceFacadeProxy] ch.dunes.util.DunesServerException: could not extract ResultSet; nested exception is org.hibernate.exception.GenericJDBCException: could not extract ResultSet
I can see the same error in the logs. Could it be related to the database type/version?
My DB is running on Microsoft SQL 2012 Standard 11.0.50.58.0 (Server 2012R2)
OK, I was able to reproduce the error on my 7.0.1 with MSSQL database. Seems to be MSSQL specific issue.
We'll investigate this further.
Appears to be a side effect from another change related to allowing actions to return composite types. As composite types can be quite large, the column in the database storing action return type had its type changed from VARCHAR(100) to NTEXT. It appears that some of SQL functions in MSSQL SQL dialect (lower, and possible others) may have issues when called on a NTEXT fields.
Possible workarounds:
I opened a PR to track this issue for future vRO release.
Before I charge ahead and alter the database and flip it back to varchar can you tell me if we'll still be in a supported configuration? Also, can someone there test this first? I'm fearful this will have other undesirable consequences. We don't support postgres here so that isn't really an option. We'd go ahead and use the embedded database if that was a supported configuration for a production environment but from the documentation it sounds like that is still not the case.
Paul
Can you confirm that making this change does not void support and that it in fact works?
I'm not familiar with official support terms so I cannot say whether manually altering database content/structure voids the support or not.
Technically speaking, this change should be safe enough, but we haven't tested it thoroughly by running official regression test suite on a build with this change in place.
FYI I tested this in my lab today and it works. I really hope this is fixed though in a future release as I really dislike having to tweak the back end database by hand. Either that or update the appliance to support large deployments using the integrated postgres database. Documentation still only says that it is designed for small to medium deployments (although it doesn't give any specifics on what small and medium are). I'd consider most of what we manage in production large but maybe not? Most of our orchestrators are primarily managing vCenter + vRA or vCenter + vCD but I'm not sure if you are basing your sizing on the plugin inventories or on the workflow traffic itself. I'd much prefer to just use the integrated database as that simplifies our deployments greatly.