GraphQL Request action / Html Request response schema setting / OpenApi interregation

[bbarry]

I'm reading through the documentation and playing with the demo and believe there is a significant opportunity for an improvement to the user experience if responses from HtmlRequest actions could drive parameter autocompletion. Here are several ways I could think about doing such a thing:

1. subtype the html request for specifically handling graphql requests and drive the autocompletion of parameters from that response object based on the syntax of the graphql request - this could further be enhanced with stuff like graphql syntax highlighting, query autocompletion and much more
2. add a property to html response containing a json schema or perhaps an example json response and parse that to provide autocompletion - this could also apply to some file read operations
3. add a global setting area to the workflow for storing openapi specification documents and an openapi html request type action which allows the designer to choose which api and action in that api gets called and configures the action based on the specification document - it could be beneficial to centralize various api parameters and calling conventions somewhere like this in other ways for example if a workflow makes repeated calls to salesforce it would be advantageous to centrally configure certain parameters every call to salesforce would share and then use a dynamically generated action type SendToSalesforce instead of HtmlRequest

I apologize if such features already exist, but if they do then the documentation could use some improvement and they are not easily identifiable in the demo.

[shalugin]

@bbarry Thanks for sharing this! We've added it to our backlog, maybe we'll do some of the suggested stuff.

Worklow Engine is quite flexible and you can implement this on the side of your application. See for example https://workflowengine.io/documentation/designer-customization/custom-activity. I realize though that it's nice to have this kind of thing out of the box.

[bbarry]

You are welcome. If we select WE (we are pretty early in discovery, WE being in .NET makes it a pretty good contender in the space of "write our own service to provide this" set) we will very likely go with a plugin route to provide a custom activity implementing a graphql request (we would want to do something anyway so the activity would be pre-configured for the only api it is likely to ever need to deal with).

It is less clear to me from the documentation if there is an ability to add a bounding context to the autocomplete feature such that the temporary parameters produced from the activity results only remain when they are relevant. I admit I haven't looked too deep yet and perhaps an overwhelming explosion of choices is a non-issue.

I'm also uncertain about the extensibility of the designer UI, There appears to be syntax highlighting for json and I was wondering what it would take to add a graphql specific editor box (or better a full IDE like https://chillicream.com/docs/nitro).

[shalugin]

There are several articles on Designer Customization, for example:

• https://workflowengine.io/documentation/designer-customization/appearance-customization
• https://workflowengine.io/documentation/designer-customization/autocomplete-provider
• https://workflowengine.io/documentation/designer-customization/custom-activity

Basically, the Designer interface is built like a set of Vue applications. Each Vue application lies in a separate template file. You can find a set of pre-installed templates on GitHub https://github.com/optimajet/WorkflowEngine.NET/tree/master/Designer/templates.
In fact, you can completely customize Look and Feel designer, and add the functionality you need there.