DigitalState / Services

The DigitalState Services Microservice
MIT License
13 stars 5 forks source link

Camunda Function as a Service Endpoints #42

Open StephenOTT opened 6 years ago

StephenOTT commented 6 years ago

Ability to call Functions as a service that active a camunda process.

Todos:


Design Notes

  1. Support POST (GET with a body is not supported by all http clients.)
  2. Body should be transformed into Camunda Variables. Use same format as Camunda Variables object
  3. Camunda variablesInReturn property should configure the returned API response
    1. Body
    2. Status Code
    3. headers
  4. Ability to call a BPMN based on key and based on ID. This configuration should be in the Service Type configuration. You should not be able to call any process you wish. Only processes that are exposed as a FaaS.
  5. BU owner of a FaaS service will be what controls the security access.

Use Cases

  1. First use case will be the ability for Formio forms to make requests to FaaS service for server side validations. Look into whether this should be a function call that is activated by Formio or by the Service Microservice.

Endpoint Examples:

POST /faas/key/:key POST /faas/id/:id

{
  "varName1": {"value":"the Value 1", "type":"String"},
  "varName2": {"value":true, "type":"Boolean"}
}

Endpoint Styles

  1. faas
  2. func
  3. function
  4. camunda

Response handling

  1. When Camunda throws an error: If Camunda returns a error then it should be logged and the FaaS API returns a internal server error 500 response.
  2. Camunda will return the following:
    1. body
    2. status_code
    3. Headers? (json object?)

FaaS service type will convert this into a proper response.

All processing should be optimized for speed over elegance. Speed of response is priority.

If Camunda does not return the proper variables that Services Microservice will return a Internal Error


Considerations

  1. How should multiple validations be returned?
    1. body will have array of "errors" will be returned and be the list of errors.
  2. When complex logging should occur about errors, have the logging occur async after the response has been returned
  3. The Service MS will have to parse stringified json objects into proper json.
  4. question: should there be a debug mode (activated through query param) that returns full variable data / the raw response from Camunda?
  5. Status codes will have to be converted to proper format.

Samples

Variables in Camunda process:

response_body = [] or = {} (is valid JSON)
response_headers = [{"key": "value"}]
response_status_code = integer

For multiple errors:

The response_body would be a SPIN Json array, and each error would append to the array. For single error response scenarios, the json could return any style defined in the bpmn.

If Function/Process cannot be found then Function not found error response is returned


All other variables that would be returned by Camunda would be ignored.


Data Flow

  1. Validations should occur:
    1. Before Form Load,
    2. Before Form Submit or
    3. After Formio Validations.

This should occur as part of a configuration of the BPM Service.

  1. Only Next step is continued if proper status code is returned

example of Usage for:

Before Form Load:

  1. Check if user is currently to load this form

Before Form Submit:

  1. The user can see the form, but are they allowed to submit the form regardless of formio validations

After Formio Validation:

  1. Validate specific data in the form using server side validations beyond that of Formio

Before Form Load, Before Form Submit and After Formio Validation configurations should allow multiple processes to be called. and support weight/order to which they are called. OR at least allow all three options to be implemented. So that a single service can have a Before Load, Before Submit and After Formio processes.

StephenOTT commented 6 years ago

related context: https://forum.camunda.org/t/replacing-http-connector-with-jsoup-usage/5291/3?u=stephenott

StephenOTT commented 6 years ago

Camunda History Time to Live

Note that History Time to list should likely be set to 1 day as it will take up lots of DB data for all of the transactions

Rate limiting

Also look rate limiting implementations to ensure the API is not abused

StephenOTT commented 6 years ago

Initial Notes:

  1. Every variable is returned as a string? or should be do type sensing?

User Case:

Allow Email approval with a link

StephenOTT commented 6 years ago

confirmation link scenario

StephenOTT commented 6 years ago
StephenOTT commented 6 years ago

Function Example:

title Camunda Function as a Service

Client->+Proxy: Function Request
Proxy->+Services: Function Request
Services->Services: Process Client Request
Services->Proxy: Camunda Process Activation
Proxy->+Camunda: Camunda Process Activation
Camunda->Camunda: Process Script(s)
Camunda->+Carto.com: GIS/Web Query
Carto.com->-Camunda: GIS Response
Camunda->Camunda: Process GIS Response
Camunda->-Proxy: Camunda Response
Proxy->Services: Camunda Response
Services->Services: Process Camunda Response

Services->-Proxy: Processed Response
Proxy->-Client: Processed Response

function with proxy