Add documentation for plugin, module development, advanced development to extend Elsa

[adamfisher]

I find myself wanting to create lots of different activities and potentially contribute them to NuGet for various things like strongly-typed third party services like HubSpot, YouTube, WordPress, etc. and providing rich autocomplete for various fields based on a connected connection for my HubSpot instance for example.

I also want to create custom functionality in Elsa studio to add new pages for things specific to me and then adding them to the sidebar as a menu option. There is so much abstraction around these various tasks.

So this ticket is an ask to expand the documentation for Elsa V3 for more advanced scenarios like:

• Extending Elsa studio sidebar menu to include additional links/pages
• adding additional pages with custom endpoints into Elsa's infrastructure that are custom to my business. Perhaps I want to we'll start my own workflow definitions table with some tweaks or modify the existing one that ships with Elsa.
• How to hook into the plug-in/module system. Right now it's a bit abstract even when trying to follow along with another activity that's doing something similar to what you're trying to accomplish.
• how to add cascading auto completion in Elsa. I know there was an example floating around out on stack overflow for V2 but for V3 it's unclear how to do this. It feels like 90% of the frustration around using activities is that they don't have rich auto completion so that when I select from a drop down it's actually going out and hitting an API for that custom activity to list out the options to ensure we're always putting in the right values.

[adamfisher]

I think the main value would be having the ability to allow other developers to easily extend the Elsa ecosystem with additional activities and functionality for Elsa studio. Personally I've been wanting to build out several custom activities for those third party services I mentioned like Google docs and YouTube and whatnot. Knowing how to create those cascading dropdowns so that you can select a YouTube channel connected to your Google account and then input information about the video for example.

Lead me to the water and I will drink 🙃

[sfmskywalker]

That's very good feedback and a fair ask. I agree, having that level of documentation could open a floodgate with developers.

Speaking of third party service integration, your contributions would find a really nice home in elsa-integrations. It's empty at the moment, but once we have a few in there, hopefully it might serve as good examples while we're without good documentation.

And, speaking of things like connections (to HubSpot, SQL Server, OneDrive, etc.), there are open PRs by @jdevillard that will soon be merged. This Connections module wil lallow activity developers to easily specify connection parameter structures, while allowing the user of Elsa Studio to define the actual secret values from the UI.

[adamfisher]

This Connections module wil lallow activity developers to easily specify connection parameter structures, while allowing the user of Elsa Studio to define the actual secret values from the UI.

This sounds eerily like the connection abstraction I described in #6361. Great minds think alike! I've been trying to work out how to properly manage multiple connection instances of the same service (multiple OneDrive accounts for example) and using .NET Core's keyed service capability was one area I was exploring or something with the configuration pipeline.

your contributions would find a really nice home in elsa-integrations

I will definitely check that out. I see you are already setting something up for Azure so maybe I can follow along with that for some of the ones I want to create. I will start by thinking of the activities I need and then opening tickets in that project as a proposal and if they look good to you I will claim them and work on them.

One thing I'm curious about is if you have a standard for the network requests? Do they need to be straight HttpClient instances whenever there is no SDK to integrate as is the case with Azure? I ask because I prefer Flurl as a modern alternative for integrating REST APIs (again, only when an SDK/package is not already available) because it keeps requests super minimal/clean and also very testable (as opposed to RestSharp or HttpClient directly). Standardizing on Flurl would be a nice improvement I think but I defer to your expertise.