Technical Specification: Adding HTTP Caller Transition to Workflow

1. Introduction

This technical specification outlines the implementation of a new transition called "http caller" or "worker" within the Workflow. This transition enables the system to call external APIs, facilitating interaction with external services and systems.

2. Transition Table Modification

The transition table should be modified to accommodate the new "http caller" transition. The following columns should be added to the table:

Transition Type: A string value indicating the type of the transition (e.g., "http_call").
API Endpoint: A column to store the URL of the external API to be called.
HTTP Method: Specifies the HTTP method to be used for the API call (e.g., GET, POST, PUT, DELETE).
Request Data: A column for storing data to be sent in the API request (if applicable).

3. Transition Execution

When a Workflow enters a state with an "http caller" transition, the following steps should occur:

The system should extract the API endpoint, HTTP method, and request data from the transition.
An HTTP request should be made to the specified API endpoint using the provided HTTP method.
The response from the API should be recorded in the "Response Data" column, and the HTTP status code should be stored in the "Status Code" column.
The timestamp of the transition execution should be logged in the "Timestamp" column.

4. Error Handling

Proper error handling should be implemented to manage exceptions, network issues, or API errors. Any encountered errors should be logged and appropriately handled, ensuring the stability and reliability of the system.

5. Security

Consider security measures when making external API calls. Implement authentication and authorization mechanisms as required for secure communication with external systems.

6. Documentation

Comprehensive documentation should be provided to guide developers on how to define and use the "http caller" transition within the workflow. This should include details on the transition parameters, error handling, and security considerations.

7. Testing (Postman)

The system undergoes a rigorous testing process using Postman for integration testing. This includes testing API endpoints and integration between system components to ensure reliability, performance, and security.

Conclusion

The addition of the "http caller" transition enhances the capabilities of the workflow, enabling interaction with external APIs and services. Proper modification of the transition table, error handling, security, documentation, and testing are critical for a successful implementation of this feature.

I think we need to make some changes to the definition of transition. @middt

Existing definition is just supporting Zeebe Message triggers.

public class Transition : EntityBaseWithOutId 
{
   ...
   public ZeebeMessage? Flow { get; set; }
   public string? FlowName { get; set; }
   ...
}

It should support multi type triggers

public class Transition : EntityBaseWithOutId 
{
   ...
   public IMessage Flows { get; set; }
    ...
}

public class ZeebeMessage : IMessage {...}
public class N8NMessage : IMessage {...}
public class ServiceMessage : IMessage {...}
public class ApiCallMessage : IMessage {...}

ServiceMessage is the registered Resource item. ApiCallMessage : API definition... But I'm not sure we need to support this, because amoprhie can't run without the resource module, the default approach should be to handle all APIs in the resource module

amorphie / workflow

Adding HTTP Caller Transition to Workflow #43