randomname's Posts

randomname · ‎02-12-2020

I would definitely be willing to test that, provided it would be otherwise considered a stable release aside from the issue I am attempting to resolve.

randomname · ‎02-12-2020

Started getting those recently too. Different from the issue of this thread, but vAPI related nonetheless. What I've found is that I'll be able to execute tag related methods for a short while, t...

Started getting those recently too. Different from the issue of this thread, but vAPI related nonetheless. What I've found is that I'll be able to execute tag related methods for a short while, then they all start failing. If I wait a while (5-15 minutes? haven't timed it) sometimes they'll start working again. If I restart the vAPI service on vCenter, they seem to start working temporarily again immediately. I've tried playing with the largely undocumented vAPI service properties, but haven't had much luck. I just ended up taking the lazy, ham fisted way out of putting delayed retry loops in all my tagging actions in vRO. Again, different issue than this thread.

randomname · ‎01-22-2020

All tags I've tried. If the workflow about which I am pulling data has an input parameter of that type with a value assigned, this is the result. What I mean about "used_by," is that back when...

All tags I've tried. If the workflow about which I am pulling data has an input parameter of that type with a value assigned, this is the result. What I mean about "used_by," is that back when things were working, the output had that property populated. I don't know what it is and its value isn't significant to me. It looks like some kind of internal reference. What caught my eye is that in the working output it contained data, while in the error output it doesn't. That just struck me as odd. As if perhaps there is now some missing reference to necessary code somewhere. I've attached a package containing basic workflows illustrating the issue. Code has been stripped down to bare minimum. Run test1 which calls test2. Test2 tries to log itself. Test1 is only there to pass a valid tag to test 2 since you can't pick a tag interactively at run time.

randomname · ‎01-21-2020

One of the things I do as a standard thing in all of my workflows is explicit external logging of attributes and input parameters. Stripping down the code to the bare minimum, it's: var inPar...

One of the things I do as a standard thing in all of my workflows is explicit external logging of attributes and input parameters. Stripping down the code to the bare minimum, it's: var inParamsWf = workflow.currentWorkflow.inParameters; var inParamsWfToken = workflow.getInputParameters(); for (var i = 0; i < inParamsWfToken.keys.length; i++) { for (var j = 0; j < inParamsWfToken.get(inParamsWfToken.keys[i]).length; j++) { var eventMessage = inParamsWfToken.keys[i] + "[" + j + "]=" + inParamsWfToken.get(inParamsWfToken.keys[i])[j]; System.getModule("com.snip.general").newLogEvent(eventMessage,"info",true,null); } } When encountering a tag, this used to properly log to my target like: [11-18-2019 20:53:50 UTC] [INFO] tag=DynamicWrapper (Instance) : [com_vmware_cis_tagging_tag__model]-[class com.vmware.o11n.plugin.vapi.model.VapiObjectWrapper] -- VALUE : com.vmware.o11n.plugin.vapi.model.VapiObjectWrapper@734331fa[{category_id=urn:vmomi:InventoryServiceCategory:92911c61-ea01-4a3a-8bfe-5db733aa835d:GLOBAL, name=snip, description=, id=urn:vmomi:InventoryServiceTag:09480590-db58-4636-a77b-d7c59a623ce0:GLOBAL, used_by=[Ljava.lang.Object;@69f1b6b8}] At some point in the past couple of months something changed which resulted in this code breaking when the input parameter encountered is of type com_vmware_cis_tagging_tag__model. I have not done enough testing to see if it extends to other tag related objects or other objects provided by vAPI. Now the default vRO logging throws: [2020-01-21 09:05:36.222] [E] Cannot create com_vmware_cis_tagging_tag__model object : java.lang.NullPointerException [2020-01-21 09:05:36.231] [E] Workflow execution stack: *** item: 'New workflow27/item1', state: 'failed', business state: 'null', exception: 'Cannot create com_vmware_cis_tagging_tag__model object : java.lang.NullPointerException' workflow: 'get tag loop' (56cfb3e4-43f7-4eff-997a-6badbb3a6788) | 'attribute': name=uri type=string value=https://snip/api | 'attribute': name=val type=string value=01083 | 'attribute': name=cat type=string value=Loc.Id | 'attribute': name=tag type=VAPI:com_vmware_cis_tagging_tag__model value={"@class":"com_vmware_cis_tagging_tag__model","category_id":"urn:vmomi:InventoryServiceCategory:46f42579-a698-42d4-9c24-1e91232bd9ed:GLOBAL","name":"01083","description":"","id":"urn:vmomi:InventoryServiceTag:54a85756-3c1a-498e-bc35-5e8339c73f12:GLOBAL","used_by":[]} | 'attribute': name=counter type=number value=0.0 | 'input': name=loop type=boolean value=false | 'input': name=loops type=number value=1.0 | 'input': name=wait type=number value=1.0 | 'no outputs' --workflow: 'New workflow27' (692f9b87-334f-47b1-b93e-c417f2be8887) | 'input': name=arg_in_0 type=VAPI:com_vmware_cis_tagging_tag__model value={"@class":"com_vmware_cis_tagging_tag__model","category_id":"urn:vmomi:InventoryServiceCategory:46f42579-a698-42d4-9c24-1e91232bd9ed:GLOBAL","name":"01083","description":"","id":"urn:vmomi:InventoryServiceTag:54a85756-3c1a-498e-bc35-5e8339c73f12:GLOBAL","used_by":[]} | 'no outputs' | 'no attributes' *** End of execution stack. Since the last time it worked, vCenter, the vSphere plugin for vRO, and vRO itself have all been updated, so I'm not sure to which it is related. Current vCenter verison is 6.5.0.30000-14389939. Current vRO vSphere plugin version is 6.5.0.15225986. Current vRO version is 7.4.0.15273518. vAPI plugin is 7.4.0.7235596, which is what came with vRO. I do not recall the previous versions of each when everything was working, though vCenter was 6.5.something and vRO was 7.4.something. Are there any known issues between the aforementioned components which may result in this type of behavior? Just from looking at the proper logging versus the error, I see that "used_by" parameter is populated in the good log and absent in the error. And it refers to Java, which is the error being thrown by vRO. For now I can probably add exceptions to my logging action based on the parameter type, but I don't know how many different types I could end up finding which behave this way now, so it could just go on and on and on.

randomname · ‎11-08-2019

Probably the same people who looked at the C# client and said, "Hey, you know what would make this better? Adobe Flash!"

randomname · ‎06-14-2019

Thanks! I should have thought to look at the server side too.

randomname · ‎06-13-2019

What is the maximum attachment size when using the EmailMessage class to send messages, and is it configurable? Recently I've been getting "552 5.3.4 Error: message file too big" when calling Ema...

What is the maximum attachment size when using the EmailMessage class to send messages, and is it configurable? Recently I've been getting "552 5.3.4 Error: message file too big" when calling EmailMessage.sendMessage() with subjectively large-ish attachments.

randomname · ‎06-06-2019

VMware has decided to remove the ability to delegate workflow execution to non-administrators. Your choices are now: 1. Make everyone in your company an administrator of vCenter and any other ...

VMware has decided to remove the ability to delegate workflow execution to non-administrators. Your choices are now: 1. Make everyone in your company an administrator of vCenter and any other external system vRO was calling and tell them to spend hours or days doing manually all the stuff your workflows used to do in minutes. 2. Make everyone in your company an administrator of vRO. 3. Give VMware millions of dollars for vRA just so non-administrators can run workflows like they have been for years after only paying for vCenter, and still lose the ability for those non-administrators to run workflows from vCenter with context sensitivity.

randomname · ‎05-31-2019

I also noticed that in the release notes recently, installed 7.6 to check it out, and noticed that permissions management is missing from the vRO thick client. The options are simply not in the m...

I also noticed that in the release notes recently, installed 7.6 to check it out, and noticed that permissions management is missing from the vRO thick client. The options are simply not in the menus anymore. I've been meaning to ask our TAM about this because it just doesn't seem right. I thought I had to be misunderstanding something or missing a feature somewhere. This leads me to believe that the effect is that it is now not possible to delegate the ability to execute vRO workflows from vCenter. As in, it is 100% impossible to grant a user read (or any other role) in vCenter, grant that user permission to a workflow, and allow that user to execute the workflow from vCenter, whether through context menu action or from the vRO plugin from the home screen. If I'm understanding things correctly and that is really what was done, then this ranks slightly below vRAM licensing as one of VMware's dumbest blunders to date. In fact, this would be so stupid that I could hardly believe such a direction would be approved for the product suite. Please tell me I'm wrong about this. Delegating workflow execution and vRO/vCenter integration with context sensitivity has been the "killer app" for vRO since its inception. It's quite literally the only reason we use vRO. If I can't present workflows to users, what's the point of having workflows in the first place?

randomname · ‎05-16-2019

Gave up on this for a while, but am trying again. Anyone know how to get a principal HoK token from SSO with PowerShell? Still can't seem to find anyone on the Internet who has done it.

randomname · ‎11-26-2018

I figured it out. While poking around the control center, I noticed that Trusted Certificates conspicuously took about 10 seconds to open. This is about the same amount of time as the VAPI method...

I figured it out. While poking around the control center, I noticed that Trusted Certificates conspicuously took about 10 seconds to open. This is about the same amount of time as the VAPI method call took. Thinking that perhaps the method was trying to create a secure connection to vCenter, and perhaps was referencing the same certificate store to validate that connection, and perhaps was then suffering the same performance hit trying to enumerate the store, I created a workflow to clean up all the certificates I didn't immediately need. Those being the hundreds of certificates of devices left over from workflows which add them during execution because they're all self signed and needed for the runtime connection. Now the VAPI method completes almost immediately. So I'll just have to update all my actions which add certificates to remove each respective certificate after completion. Not a bad thing to do anyway for good housekeeping. Just never thought of it as necessary before.

randomname · ‎11-23-2018

Thanks for taking a look. The account being used is an administrator of both vCenter and Orchestrator. Subsequent methods called on objects from an existing VAPI client object do not seem t...

Thanks for taking a look. The account being used is an administrator of both vCenter and Orchestrator. Subsequent methods called on objects from an existing VAPI client object do not seem to exhibit the delay. If I create a new VAPI client object, then calling list() from a tagging category object created from that new client object does exhibit the delay. All executions of getting the endpoints, creating the client object, and creating the tagging category object all complete nearly instantly. It is only when I'm calling methods from objects created from the client that the delay is observed. System.log("get endpoint start"); var vapiEndpoint = VAPIManager.getAllEndpoints()[0]; System.log("get endpoint end"); System.log("create client start 1"); var vapiClient = vapiEndpoint.client(); System.log("create client end 1"); System.log("create tag cat cis obj start 1"); var cisTagCat = new com_vmware_cis_tagging_category(vapiClient); System.log("create tag cat cis obj end 1"); System.log("get cats start 1"); var tagCats = cisTagCat.list(); System.log("get cats end 1"); System.log("get cats start 2"); var tagCats = cisTagCat.list(); System.log("get cats end 2"); System.log("create client start 2"); var vapiClient = vapiEndpoint.client(); System.log("create client end 2"); System.log("create tag cat cis obj start 2"); var cisTagCat = new com_vmware_cis_tagging_category(vapiClient); System.log("create tag cat cis obj end 2"); System.log("get cats start 3"); var tagCats = cisTagCat.list(); System.log("get cats end 3"); vapiClient.close() [2018-11-23 08:35:43.581] [I] get endpoint start [2018-11-23 08:35:43.586] [I] get endpoint end [2018-11-23 08:35:43.587] [I] create client start 1 [2018-11-23 08:35:43.588] [I] create client end 1 [2018-11-23 08:35:43.590] [I] create tag cat cis obj start 1 [2018-11-23 08:35:43.591] [I] create tag cat cis obj end 1 [2018-11-23 08:35:43.593] [I] get cats start 1 [2018-11-23 08:35:52.598] [I] get cats end 1 [2018-11-23 08:35:52.604] [I] get cats start 2 [2018-11-23 08:35:52.638] [I] get cats end 2 [2018-11-23 08:35:52.640] [I] create client start 2 [2018-11-23 08:35:52.641] [I] create client end 2 [2018-11-23 08:35:52.643] [I] create tag cat cis obj start 2 [2018-11-23 08:35:52.644] [I] create tag cat cis obj end 2 [2018-11-23 08:35:52.645] [I] get cats start 3 [2018-11-23 08:36:01.721] [I] get cats end 3 I've gone through the VAPI logs on vCenter and the logs on Orchestrator. I can see entries for some of the operations (getting a token and creating a session in VAPI log), but there doesn't seem to be any explicit logging of the actual method calls. None of the entries that are logged look abnormal. I don't see this kind of issue going anywhere with a support incident, so I guess I'm left rewriting everything I've been doing with the VAPI plugin with raw REST code instead. At least all my tagging code, which is high volume and high frequency due to the quantity of objects being tagged.

randomname · ‎11-21-2018

I've noticed that running (some) code through the VAPI plugin is extremely slow. For example, a single call to the list() method of a com_vmware_cis_tagging_category object takes nearly 10 second...

I've noticed that running (some) code through the VAPI plugin is extremely slow. For example, a single call to the list() method of a com_vmware_cis_tagging_category object takes nearly 10 seconds. This time seems to increase exponentially when I'm running many calls in parallel. When running a few as 10 parallel workflows, the same list call can take in excess of 10 minutes for the first few workflows, which slowly reduces as running workflows complete. Comparatively, doing it in PowerShell with a Cis server connection by getting the com.vmware.cis.tagging.category service and calling its list() method returns results in a few milliseconds. In this environment, there are only 10 categories and a few hundred tags. In vRO with VAPI plugin: var vapiEndpoint = VAPIManager.getAllEndpoints()[0]; var vapiClient = vapiEndpoint.client(); var cisTagCat = new com_vmware_cis_tagging_category(vapiClient); System.log("get cats start"); var tagCats = cisTagCat.list(); System.log("get cats end"); [2018-11-21 08:05:18.754] [I] get cats start [2018-11-21 08:05:28.144] [I] get cats end In PowerShell: $cisObjTagCatSvc = Get-CisService -Name "com.vmware.cis.tagging.category" -Server $viObjCisServer (Measure-Command -Expression {$cisObjTagCats = $cisObjTagCatSvc.list()}).TotalSeconds 0.0340482 Even if I measure from the initial connections, it's still much faster in PowerShell than the VAPI plugin. (Measure-Command -Expression {$viObjCisServer = Connect-CisServer -Server "<myVc>" -Credential $cred $cisObjTagCatSvc = Get-CisService -Name "com.vmware.cis.tagging.category" -Server $viObjCisServer $cisObjTagCats = $cisObjTagCatSvc.list()}).TotalSeconds 2.6297053 And in vRO as straight REST call in a script item: var uri = "https://<myVc>/rest/com/vmware/cis/tagging/category"; var restHost = RESTHostManager.createHost("DynamicRequest"); var transientHost = RESTHostManager.createTransientHostFrom(restHost); transientHost.url = uri; var request = transientHost.createRequest("GET",uri,""); request.setHeader("vmware-api-session-id",sessionKey); System.log("request start"); var response = request.execute(); System.log("request end"); [2018-11-21 08:12:58.891] [I] request start [2018-11-21 08:12:59.000] [I] request end Any ideas what is going on here? Is this expected for the VAPI plugin? Are improvements in the pipeline? vRO is 7.4, VAPI plugin is whatever version is the latest posted in this forum's "Documents" page as of today.

randomname · ‎04-27-2018

I find the auto version increase very helpful for workflows. I am sorry to hear it is not possible for other element types. Of course, robust "code repository" type features like merging multi...

I find the auto version increase very helpful for workflows. I am sorry to hear it is not possible for other element types. Of course, robust "code repository" type features like merging multi-user updates, check in/out, multi-level branching version management, and so on would be fantastic, but they sound like difficult changes which would require a major redesign of the product.

randomname · ‎04-24-2018

Is there any way to enable automatic version increases when saving actions, configurations, and resources?

randomname · ‎11-12-2017

Additional information from vpxd.log also points to my hypothesis being correct. --> (vmodl.KeyAnyValue) { --> key = "<whateverkeyname>", --> value = (string) [...

Additional information from vpxd.log also points to my hypothesis being correct. --> (vmodl.KeyAnyValue) { --> key = "<whateverkeyname>", --> value = (string) [ --> "val1", --> "val2" --> ] --> }, Above is what vCenter puts in vpxd.log for a VcKeyAnyValue object which has an array of strings for its value when the VcKeyAnyValue object has not been modified by vCO. That is, it is just the output from a get method which is then sent back as part of a larger object hierarchy. This works and vCenter views it as valid. --> (vmodl.KeyAnyValue) { --> key = "<whateverkeyname>", --> value = (anyType) [ --> "val1", --> "val2" --> ] --> } Above is what vCenter puts in vpxd.log for the same VcKeyAnyValue object which has the same array of strings for its value if the value property of the VcKeyAnyValue's object was created as an array inside vCO. This is when vCenter rejects it as an invalid type. Despite the value property of a VcKeyAnyValue returned from a get method being listed as having the same standard array constructor as an array created in a vCO scriptable task, the returned object has no methods typical of an array. There's no push, pop, splice, slice, or anything. Nor do attempts to force new values at appropriate numerical indices have any effect on the elements of the array. So there is no way I have found to modify the values, and no way I have found to get vCenter to accept a new supposedly equivalent and valid object in its place.

randomname · ‎11-10-2017

vCenter returns the error "Invalid type for <whatever>" when calling the method which takes the object's hierarchy as its argument. For example, updating a host profile in which the VcKeyAnyVa...

vCenter returns the error "Invalid type for <whatever>" when calling the method which takes the object's hierarchy as its argument. For example, updating a host profile in which the VcKeyAnyValue objects are members of a VcProfilePolicy's parameter array. If the VcKeyAnyValue's value is a single string, and that's what vCenter expects for the parameter with that key, it works. If the expected value is an array of one or more strings, vCenter rejects the array as an invalid type. Per the XML of the actual host profile and the previously linked article, if VcKeyAnyValue's value is an array, and only if it is an array, an explicit type must be specified when submitting to the API in addition to the actual value's data. Based on my test with PowerShell, I suspect vCO isn't sending that extra type definition when the value is an array. vRO is 7.3. vCenter plugin in 6.5.0.7037717.

randomname · ‎11-10-2017

Prior to a recent update to the vCenter plugin, it was not possible to set any value of the value property of VcKeyAnyValue objects. Since the fix, I can now set values, however if the value is a...

Prior to a recent update to the vCenter plugin, it was not possible to set any value of the value property of VcKeyAnyValue objects. Since the fix, I can now set values, however if the value is an array, it is always rejected by vCenter as being an invalid type, when it definitely *should* be valid. I have tried a dozen different ways of instantiating both the array and its members used to populate the value, but the result is always the same. I suspect the issue is similar to what is documented at https://kb.vmware.com/s/article/1029155 and vCO is not explicitly specifying "ArrayOfString" when it is interacting with vCenter at the SOAP layer. Similar behavior is evident in PowerShell for an array of strings if the array's type is "String." However if the array's type is "String[]," it works. I have been unable to figure out any way to create a similar "strong typed" array in vCO's JavaScript which is accepted by vCenter. Has anyone successfully modified any managed object property of type VcKeyAnyValue when the value is an array?

randomname · ‎09-18-2017

LucD, https://my.vmware.com/group/vmware/get-download?downloadGroup=VS-MGMT-SDK65

randomname · ‎09-15-2017

So SamlTokenHelper is a class defined in SDK\ssoclient\dotnet\cs\samples\VMware.Binding.WsTrust. Trying to figure out what it's doing now.

All

randomname's Posts

Re: vAPI issues

Re: vAPI issues

Re: vAPI issues

vAPI issues

Re: vRO HTML5 Interface Needs Folders

Re: Maximum attachment size when using EmailMessage class.

Maximum attachment size when using EmailMessage class.

Re: Tab 'Permissions' missing in vRO 7.6 client

Re: No Roles Management at Administration

Re: Obtaining holder-of-key token from SSO.

Re: Performance of VAPI plugin

Re: Performance of VAPI plugin

Performance of VAPI plugin

Re: Versioning

Versioning

Re: VcKeyAnyValue still not working?

Re: VcKeyAnyValue still not working?

VcKeyAnyValue still not working?

Re: Obtaining holder-of-key token from SSO.

Re: Obtaining holder-of-key token from SSO.