Custom webview displaying workflow not as a dialog

[ukopstechnical]

Hi,

I've created a custom webview for the deployment of some VM's, following the tutorials at vcoteam.info. Everything worked fine, and then I updated vCenter to 4.1 Update 2 [and subsequently Orchestrator to 4.1.2 build 27]. Now, when the workflow components are supposed to be displayed I have an error:

Error in io.bind of vmo.displayWebform: XMLHttpTransport Error: 500 Internal Server Error(type: error)

The 'A' tag in the HMTL file, default.html, that links to the page that displays the workflow is:

<a jwcid="@vco:WorkflowLink" workflow="requestVM" isDialog="false" isSync="false" returnUrl="./requestMade.html">

If I change the isDialog attribute to true then everything works.

I have a theory as to why this originally fails and now works, but it's just a theory. I'd be interested in finding out what anyone else thinks or has experienced.

When I view the source of default.html the link to the page that displays the workflow has been set to:

<a href="./requestVM.html?cmd=execute&amp;workflow=requestVM&amp;returnUrl=.%2FrequestMade.html&amp;cancelUrl=default.html&amp;autostart=false">

The & that would separate the get vars has been encoded to &amp;. If I use firebug to look at the requests of the page that displays the workflow [which displays the error] then I can see the error page that has been sent back to the browser. It leads with:

Webform page error: 'workflow' and 'workflowId' parameters are null. At least one parameter must be definied.

As can been seen above, a workflow parameter has been provided.

And lists the variables provided to it (copied just as displayed):

<tr class="section"><th colspan="2">Parameters</th></tr> <tr class="even"><th>amp;</th><td> </td></tr> <tr class="odd"><th>amp;cancelUrl</th><td>default.html </td></tr> <tr class="even"><th>amp;displayResetButton</th><td>true </td></tr> <tr class="odd"><th>amp;returnUrl</th><td>./requestMade.html </td></tr> <tr class="even"><th>amp;workflow</th><td>requestVM </td></tr> <tr class="odd"><th>cmd</th><td>execute </td></tr> <tr class="even"><th>dojo.preventCache</th><td>1323794873018 </td></tr>

From this my guess is that the name of the var has not been decoded properly (or whatever the correct terminology is) and this has led to it not seeing that there is a variable called workflow. I tried raising this with VMware support but have been told that custom webviews are not supported.

So, that's my problem and my guess is that a bug exists that means that the workflow parameter is not interpreted correctly. Has anyone else experienced this, or have thoughts/opinions on the matter ?

[tschoergez]

Hi!

If General Support does not work: When you have Developer Support, you could try this way :smileysilly: (since custom plugin development is in there, I assume custom webviews are also included...) More info: http://www.vmware.com/support/services/sdk.html

Does it work if you hardcode the link in another html (with just & instead of &amp; ) ?

Otherwise I think you have to share your webview (via PM, if you want), only then we can try to reproduce the issue...

Cheers,

Joerg

[ukopstechnical]

Hi Joerg,

Thanks for the reply ! I didn't think to hardcode the link, my workaround is just to display it in a dialog Thanks for the link to the Developer support, though since all we've got currently is a custom webview for internal use I'm not sure this would a cost-effective direction for us.

I've tried a couple of things; firstly hardcoding the link to the page where the form is embedded. This would be the code:

<a href="./requestVM.html?cmd=execute&workflow=requestVM&returnUrl=requestMade.html&cancelUrl=default.html&autostart=false">Test</a>

This sadly, results in the same error. When I look at the response for the request that generates the 500 Server Error I can see that exactly the same is happening with the parameters - "amp;" is appearing at the start of their names (apart from the 'cmd' parameters which is immediately after the ?).

I looked at the source of this page and pulled out the link for the displayWebform javascript function which, when trimmed, looked similar to (sever name removed):

http://server/vmo/sspdev/system/vmo/partials/webform.html?cmd=execute&workflow=requestVM&cancelUrl=d..."

I put this in a link, clicked it, and a basic, unformatted form was displayed. So I would state that yes, a hardcoded link to the partial webform would work, but a hardcoded link to the page which contains the embedded form does not.

I'm sure I can find a way of sharing a webview, whether it is this one or not, which can reproduce the error.  Might take me a day or two to arrange though.

Many thanks,

Neale

[bbonev]

Hi Neale,

We know about this problem. It is fixed, but the fix will come to you with the next vCO update. Meanwhile I can offer you an workaround. Can you try to put

-Dwebview.raw.enabled=true to your startup vCO server arguments. The server's startup scripts are located in <your install dir>/orchestrator/app-server/bin folder.

Depending how you start the Orchestrator server you have to pick either option (1) or (2).

1. If you are starting the vCO server as a service, then you must edit the file wrapper.conf. Find a row wrapper.java.additional.<X> (X is the number of the last row) and create one more row wrapper.java.additional.<X+1>=-Dwebview.raw.enabled=true
2. Otherwise if you are starting the vCO server from the orchestrator.bat or orchestrator.sh then you must edit them.In the correct file find a row like this: "%JAVA%" %JAVA_OPTS% "-Djava.endorsed.dirs=%JBOSS_ENDORSED_DIRS%" -classpath "%JBOSS_CLASSPATH%" ch.dunes.jboss.Main (it should be at the end of the file) and chabge it to "%JAVA%" %JAVA_OPTS%   -Dwebview.raw.enabled=true "-Djava.endorsed.dirs=%JBOSS_ENDORSED_DIRS%" -classpath "%JBOSS_CLASSPATH%" ch.dunes.jboss.Main

After this save the file and restart your vCO server and there should be no problem with the web views.

Please, let me know if this is not working

Best regards,

Boyan

[ukopstechnical]

Hi Boyan,

Thanks for the reply. I have performed the steps you detailed in option (1) and the webview is now working as expected. I look forward to the update that fixes this

Many thanks,

Neale

[bbonev]

UPDATE:

The easier way to set this property is to add it in vmo.properties file under conf folder in the vCO server. The line that must be added in order to fix the problem is:
com.vmware.o11n.webview.htmlescaping.disabled = true