elsa-workflows / elsa-core

A .NET workflows library
https://v3.elsaworkflows.io/
MIT License
6.35k stars 1.17k forks source link

Open API Activities #2961

Open sfmskywalker opened 2 years ago

sfmskywalker commented 2 years ago

Description

There should be an activity type provider that yields activities based on a given Open API specification. This way, the user would not have to manually configure Send HTTP Request activities manually. Instead, for each Path object in the Open API spec, an activity would be available.

Example

For example, take the following Open API specification:

{
  "/pets": {
    "get": {
      "summary": "Find pets by ID",
      "description": "Returns all pets from the system that the user has access to",
      "responses": {
        "200": {
          "description": "A list of pets.",
          "content": {}
        }
      }
    }
  },
  "parameters": [
    {
      "name": "id",
      "in": "path",
      "description": "ID of pet to use",
      "required": true,
      "schema": {
        "type": "array",
        "items": {
          "type": "string"
        }
      },
      "style": "simple"
    }
  ],
  "post": {
    "summary": "Create a new pet",
    "description": "Create a new pet",
    "responses": {
      "201": {
        "description": "The created pet.",
        "content": {}
      }
    }
  },
  "requestBody": {
    "content": {
      "application/json": {
        "schema": {
          "type": "object",
          "properties": {
            "name": {
              "description": "Name of the pet",
              "type": "string"
            },
            "status": {
              "description": "Status of the pet",
              "type": "string"
            }
          },
          "required": [
            "name",
            "status"
          ]
        }
      }
    }
  }
}

The proposed activity type provider would yield the following two activities:

Each activity would also provide the expected input properties, such as "ID" for "Find pets by ID" and "Name of the pet" for "Create a new pet".

The available outcomes would be determined by the supported HTTP response status codes.

tomy2105 commented 2 years ago

One thing that would be supper, dupper nice.... And yes I know I ask a lot :). If OpenAPI specification endpoint(s) could be used from designer without need to "hardcode" it in C# code. Like SendHTTP request on steroids which would "mutate" based on OpenAPI specification endpoint and method specified :).

mohdali commented 2 years ago

The way I would imagine it would be to have some sort of openapi provider, it can be a simple list in the appsettings.json or a custom provider that gives the list from database.

The provider should be also able to create the required HttpClients with the required configurations like base Url, authentication, etc. So that you could connect to different end points without anything hardcoded.

I think it would be possible with some effort.

tomy2105 commented 2 years ago

@mohdali, yes appsettings.json would be nice idea to avoid hardcoding stuff in code but unfortunately not enough for my uses case where person using only designer determines which API he wants to invoke.

Database approach, provided it has nice "dashboard", possibly usable within designer, might work provided it automatically refreshes activity list when new entries are added or modified......

mohdali commented 2 years ago

Do we have a way forward to implement this? I know NSwag can be used to generate client libraries at compile time. However, I'm not sure how to do it at runtime.

In previous .Net Framework based solution, we used svcutil to generate SOAP client libraries and imported during runtime using Add-Ins. Similar things may be possible in .NET using plugin architecture. However, I'm not sure if that's the best way.

If we can define a framework for this, we can easily do it for SOAP, OpenAPI, gRPC, GraphQL, etc.

rbnswartz commented 1 year ago

I would really like to have this, it would make integrating with external systems much easier