Significant Onboarding Gaps

[douglasg14b]

There are some significant onboarding gaps I experienced that the docs could alleviate

This is to just list these out.

1. Using postgres as the storage provider needed to ensure:
   1. I had an AppDbContext with a constructor with a generic DbContextOptions and not a non-generic one.
      • Otherwise you get The DbContextOptions passed to the AppDbContext constructor must be a DbContextOptions<AppDbContext>. When registering multiple DbContext types, make sure that the constructor for each context type has a DbContextOptions<TContext> parameter rather than a non-generic DbContextOptions parameter.
   2. The calls to UseEntityFrameworkCore need to ensure they include the ef => ef.UsePostgreSql(appConfig.DbConnectionString) configuration.
2. If you're using Micrososft.EntityFrameworkCore.Design you're going to have problems with the Microsoft.CodeAnalysis.CSharp.Workspaces dependency version because elsa has it pinned as a specific version
3. elsa-workflows/elsa-core#5385 (If I resolve this, I'll add the necessary finagling here)
4. If you use OpenAPI SwaggerGen, it will explode with:
   • fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1] An unhandled exception has occurred while executing the request. Swashbuckle.AspNetCore.SwaggerGen.SwaggerGeneratorException: Failed to generate Operation for action - HTTP: POST /elsa/api/identity/secrets/hash. See inner exception ---> Swashbuckle.AspNetCore.SwaggerGen.SwaggerGeneratorException: Failed to generate schema for type - Elsa. Identity.Endpoints.Secrets.Hash.Request. See inner exception ---> System.InvalidOperationException: Can't use schemaId "$Request" for type "$Elsa.Identity.Endpoints.Secr ets.Hash.Request". The same schemaId is already used for type "$Elsa.Identity.Endpoints.Users.Create.Request"
5. One you do get it running (The Server in asp.net, and the Studio via docker). The documentations recommendation of authentication doesn't work. It logs in, yes, but all requests from Studio to the server result in 401 unauthorized...
   • IDK how to solve this one yet.... Might have to do with the auth schema...? Crap idk.
   • Edit: Day later, still have no idea why the Elsa endpoints refuse auth, I'm going to have to yoink this out unfortunately, I imagine this will be the continued integration experience (Whack-a-mole), the project just isn't ready yet :(
6. If you use Hangfire you're going to have slight pain because the Elsa dependency is pinned to 1.8.6 (Current is 1.8.12). (You'll need to explicitly install the version needed)
   • 
   • The docs don't indicate how to use/install it, or where/how it's used/activated, you have to dig into the source code to figure that out yourself
     • Only use this feature if you are not configuring Hangfire yourself If we are, is there any additional configuration Elsa needs?
   • ⁉ If I don't use the hangfire background activity scheduler, do I not get background activity scheduling? Why hangfire for it vs the default?
7. Integrating to your own auth system seems.... unknown at this point. How to use my own users & permissions? Is there an integration guide/examples for this?

It's been 6h ~11h trying to get this running on an existing application, this is brutal 😰

[sfmskywalker]

Quick question about the Postgres AppDbContext; you should not have to create your own db context (you're free to do it of course); could you maybe elaborate why you've gone down that route? Perhaps a misunderstanding that we should fix in some guide?

[douglasg14b]

Hi!

This is just an existing DbContext in the application.

Elsa isn't configured to use it, Elsa is configured as:

elsa.UseWorkflowManagement(management =>
                management.UseEntityFrameworkCore(ef => ef.UsePostgreSql(appConfig.DbConnectionString)));

elsa.UseWorkflowRuntime(runtime => runtime.UseEntityFrameworkCore(ef =>  
                ef.UsePostgreSql(appConfig.DbConnectionString)));

[sfmskywalker]

Got it. Thank you for the detailed feedback, I really appreciate it!