Operational Defect Database
BugZero updated this defect 31 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
VMware | 97761
Action execution returns status code of 200 with an empty response when triggered through Service Broker
Last update date:
4/18/2024
Affected products:
Aria Automation Orchestrator
Aria Automation
Affected releases:
8.148.x8.168.13
Fixed releases:
No fixed releases provided.
Description:
Symptoms
In a custom form, Orchestrator actions that are bound to a field are not executed or return empty data as a result. This is most typically seen in drop-down fields, whose value list is populated by an Orchestrator action. In this case the action is ran, but returns an empty array as a result.In previous versions of the product (or non-patched versions in cases where the you have just applied a patch) the action returns a non-empty result given the same input values.
Cause
This behavior was introduced with the necessary changes implemented through VMSA-2024-0001.If a custom form field uses an Orchestrator action with the following behavior: retrieves some data.has inputs that are bound to form fields which are marked as required. The action will not execute until all of those required fields have non-empty values.
Impact / Risks
Some of your custom form fields may remain empty when they would normally be expected to be populated with data loaded via an Orchestrator action.However, if the end users provide values to these required fields (where possible should be most use cases), the user should be able to request the form normally. In this case, the form designer most likely did not put the form fields in the most optimal order.
Resolution
You must rework the custom forms. Please follow the below guidance: Remove the required constraint on the field altogether Example: A user has set almost all fields in their custom form to mandatory because they want users to provide values for all of these fields. However, this form has a chained design. When a user provides a value for field A, it is used as an input to an action which returns a value for field B, which is then used as input which returns a value for field C and so on.Recommended Change: In this case, the form designer needs only to set the last field as mandatory. When set this way, the requesting user would still need to populate all fields prior thus making them required. Provide default values to required fields Example: Many use cases include required fields to have some expected value, but not all form designers set it.Recommended Change: Where possible, the custom form designer should set a default value for required fields. Inspect the form field dependency chains and re-order them accordingly Example: If field B is required in a form that is placed after field A which uses field B as an input to an Orchestrator action, then field A would most likely be empty because the end user has not supplied a value to field B, yet.Recommended Change: In this case, re-order the fields in such a way that for any field X, all fields that are used as inputs to an action and provide a value to said action, are placed before field X; No input field should be after it.
