VMware Cloud Community
gbuser
Contributor
Contributor

Bug? "Call Action" from Presentation remains empty (v7.0.0)

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.

Tags (1)
12 Replies
qc4vmware
Virtuoso
Virtuoso

Hmm... I am seeing the same thing.  Gonna poke around a bit more.

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

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.

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee

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...)

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

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.

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

I see these errors in the logs:

2016-01-28 23:15:02.073+0000 [http-nio-10.52.130.61-8281-exec-8] WARN {} [SqlExceptionHelper] SQL Error: 8116, SQLState: S1000

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

Reply
0 Kudos
gbuser
Contributor
Contributor

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)

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee

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.

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee

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:

  • Ask you DB administrator to alter the vRO database and change the type of column returnType in table VMO_ScriptModule from NTEXT to VARCHAR(100) , or if you are using large composite types, to VARCHAR(X) where X is a number big enough to store the largest composite type.
  • Instead of selecting action from the action chooser window, you can manually write the action call expression. A bit error prone, but should be doable.
  • Consider switching to another database type eg. PostgreSQL.

I opened a PR to track this issue for future vRO release.

qc4vmware
Virtuoso
Virtuoso

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

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

Can you confirm that making this change does not void support and that it in fact works?

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee

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.

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

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.

Reply
0 Kudos