Support for PowerAutomate "Response" operations

[wifun]

Hi team,

I am working on adding support to some custom "response" type builtins for PAuto for ex. the "Respond to a PowerApp or Flow" action.
This is how it looks in v1

There's 2 pieces needed for this:

1. I need to augment/change the floatingactionmenu editor to support StringEditors (for token picker) for each user-added parameters

   • Currently the editor receives a single ValueSegment Literal of the json (from input defn) that can be parsed to render the editor and textfields
   • If I add tokens to the json the props to the editor becomes a list of ValueSegments. I am looking into using some preexisting helpers in designer-ui to convert the segments back into json string and again back into ValueSegments for the individual StringEditors
   • Feels a bit inefficient, curious if there's a better way here

2. The custom "response" types in v1 have custom serialization for a special statusCode & body property added to the input defn. To make it generic (at least for all response operations):

   • Add a new property to operationManifest to mirror inputs from one location to another (can be compared to 'inputsLocationSwapMap' capability)
   • Always have response operation serialize a statusCode 200 property (or perhaps this can be done with manifest? to supply a default value)
     • have not checked if this is required

I am looking for feedback on these approaches here, thanks!

[Eric-B-Wu]

For 1. will there need to be support for nested objects? Or would it be just a single JSON object which with the keys being the property name and the values being the stringified value?
If this is the case, then instead of doing this logic in Designer-UI, we can parse the objects in libs\designer\src\lib\core\utils\parameters\helper.ts under getParameterEditorProps and each key: string, value: ValueSegment[] in the editorViewModel. The array of valueSegments can be obtained by using the combination of the functions loadParameterValue and convertStringToInputParameter - see toAuthenticationViewModel for example.

For 2. I'm a little unsure what the ask is for. Where would the mirrored input be used? As for defaulting the statusCode property that should be able to be done in the manifest.

[wifun]

I see, this is how I'm thinking of augmenting the input defn used for the editor today.

I don't expect outputValueMap to specify nested objects as values. So if editorViewModel is pretty much a custom object per editor where we can put whatever we want, I can give your suggestion a try.
Questions here:

1. I'm assuming the value corresponding to initialValue the editor receives will still be an unfriendly sequence of json string parts and tokens. After the user has made changes does this mean before the editor calls onChange, the editor will have to serialize the editorViewModel to ValueSegment[] that reflects the changes to initialValue?

For 2. My guess is that PAuto's response operations is really LogicApp's builtin response operation with custom editors. So even though the user makes changes to input.schema in my example, at runtime input.body and input.statusCode are actually used. If you look at the image in this discussion's initial post the values for the StringEditor aren't even under input.schema (the floatingmenueditor). In v1 I'm assuming there's custom logic like "if powerapps_response_operation" for deserialization and serialization.
So I'm proposing adding a new operationManifest capability (a map object) that during node serialization will copy properties from source to destination (ie. inputs.schema.additionalProperties.outputValueMap -> inputs.body)

[Eric-B-Wu]

yeah, so when we update the editor view model, we can serialize it differently. You can view getStringifiedValueFromEditorViewModel under libs\designer\src\lib\core\utils\parameters\helper.ts to see how we do it for a couple of other editors. Alternatively, you can change it so initialValue is never used/updated, but completely off of the editorViewModel, you can follow something of the like of filepicker editor for that.

[wifun]

Ok I just did a test and looks like I may not be able to add whatever I want to input.schema. I believe this is coming from LogicApps backend:
The schema definition for action 'Respond_to_a_PowerApp_or_flow' contains expressions. Expressions are not allowed in schema definition.

Do you have any other suggestions?
(just throwing out ideas here)

1. Was I wrong in assuming each property under input would be handled by a separate editor? Can input.body and input.schema be considered together?
2. OR Can I mark the input.schema as a non-schema object? Is this a thing for any editors today?
3. OR we add a manifest setting to move between source&dest (like input.body -> input.schema for deserialization and input.schema -> input.body for serialization)

[rllyy97]

1. For the most part yes each leaf property under input should be a separate editor
2. I'm confused on what you're asking here
3. Yes this is what inputsLocationSwapMap would be used for, in that case you would specify it as such

inputsLocationSwapMap: [{
    source: ['input', 'schema'],
    target: ['input', 'body'],
}]

[wifun]

It seems like LogicApps backend is classifying input.schema as a schema definition based on the error message. Wasn't sure how that was determined, whether it is hardcoded to use the property name or it is inferred from the object structure. I was wondering if there was a way to change the structure to have LogicApps not classify it as a schema (ie. bypass the backend error on save)

However from your response, it sounds like inputsLocationSwapMap is promising. Because it looks like I need to add token expressions to input.schema to render the floatingactionmenu editor properly but I can't save the serialized workflow definition because the input is classified as a "schema object".
Thanks, will give this a try.

Is there any docs or code comments for the operation manifest definition? It is a bit challenging trying to understand what each property is for from searching code.

[rllyy97]

As far as I know we don't have any docs for the manifest definition properties but that's a good callout!
I'll make a note of that and write something up when I have the time

[wifun]

It doesn't seem like inputsLocationSwapMap is used for deserialization though.

• side question, if it's only for serialization what's the intended purpose of the property?

I'm looking to move input.body inside input.schema on load so it will be handled by a single editor for input.schema. Then I need to move it back out for serialization since LogicApps backend doesn't like input.schema containing expressions at save time.
Will we need a new manifest property to do this?

Stepping back, I'm curious if this is a good design, cause I'm basically trying to combine multiple input leaf properties to get around the Expressions are not allowed in schema definition error. Should we try to work around this another way (that's why I was asking about point #2 in this thread)?

I can temporarily hack it in the host to move input.body inside input.schema before designer load (for response operations), if we're still brainstorming this method. However if it's ultimately a poor design I don't want to start making changes for the editor yet

[wifun]

After following offline it looks like I was wrong about inputsLocationSwapMap. Will try using this for my solution. The value I had to use was:

inputsLocationSwapMap: [{
    source: ['schema'],
    target: ['body'],
}]

[rllyy97]

Responding to the original post, point #2.
Adding a new property like inputsLocationSwapMap that serializes copies of data to different locations would be possible, I can do some investigation to see how much work that would take.
For Always have response operation serialize a statusCode 200 property, this should be possible in the manifest if you just specify a hidden parameter with a default value.

[wifun]

How can I have the editor flag a validation error? For example lets say I want to flag when the title or value fields are empty.

Doing a quick scan, is the best way to add custom check (as in check for editor) within validateJSONParameter like how it has validateConditionalEditor currently?

@Eric-B-Wu @rllyy97

[wifun]

Checked in new editor #3197