Processing request with some simple logic

🧩 Low-Code Development
#1

Hi,

Here is my challenge: I have a module named “AgreementsNumbers” with two fields “name” and “currentNumber”. What I am trying to achieve:

  • external service is calling my Corteza endpoint with and passing the “name” value (for example ABC)
  • system reads the currentNamber value for the record where name = ABC
  • systems increases the currentNumber value (newValue = currentValue +1)
  • system saves the newValue as the new currentValue (where name = ABC)
  • system returns newValue within the HTTP response

After studying the documentation I can see three routes, but I am not sure which will be the best:
A) Integration Gateway → Payload processing: this one gets, the request (so I can get the name) and allows for defining the response (so I can pass the newValue), but I have no idea how to get to my modules from here

B) Integration gateway → Workload Processing: I know how to access modules and perform all operations, but according to the spec, I should use the System-> onManual trigger, so I have no idea where I will get the request from and how to return the response

C) Sink Routes: I have a feeling that this gives me everything (all actions can be executed within the workflow and at the same time I have access to the request and response, but as it looks like the most technical to set up (signature??) I hope that A) or B) will allow me for doing it :wink:

I have a feeling that soon I will get to the top of the list “Those guys took the most of our time”, but at the same time, to give it back just a bit to you, I am working on some simple improvements to the spec in places where I am finding some difficulties (first one already in the pull request)

Automation Scripts in Local Installation
#2

if having control over what the HTTP response looks like you will need to use sink routes.
To use sink routes you will need to do the following:

  1. Setup the Corredor container and configure it and this,
  2. generate a sink signature
  3. write an automation script which is a server script and has a sink trigger (here is an example of it).

If you do decide to go this route, I can write down some more docs on it but I think you should be able to figure it out from the above.

The request comes from the integration gateway that invoked it and the response is not defined and can’t currently be explicitly specified.
The initial Integration gateway implementation was designed as an asynchronous webhook maker since that is what we needed at the time.

Further improvements, such as defining how responses look like, are in the works.

The most technical thing here is you need to set up another container, configure the system, and then run a CLI command to generate a signature.
It is the more primitive/low-level system we defined for running automation.

If you don’t care what the HTTP response looks like (or your external application allows you to do another request to figure it out after the request) you should use Integration gateway.
If that doesn’t apply, you’ll need to write an automation script.

1 Like