Configuration of Sink Workflows

🧩 Low-Code Development Workflows
#1

Greetings, all!

My team’s use case is bidirectional communication (more precisely, we’re designing two “pushing” REST APIs) between Corteza and a second app that supports REST. On the Corteza side, I’d prefer to use Sink Routes as they’re secured with signatures. We don’t need anything much more sophisticated than that, as this bidirectional communication will be happening server-side.

To test this Corteza functionality, I spun up a v2023.9.8 container (as service server in a Docker Compose config), added myself as a user, and created a completely generic Sink signature with the following CLI call:

docker compose exec server corteza-server sink signature

I then created a workflow that was set to trigger on “onRequest” events of the “System” resource; no constraints. A screen grab of the workflow is below:

image

With all that configured, trying to trigger the Sink with a curl call results in an HTTP 200, but an error message in the resulting JSON:

$ curl -v http://localhost:80/api/system/sink/toyendpoint?__sign=[REDACTED]
*   Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /api/system/sink/toyendpoint?__sign=[REDACTED] HTTP/1.1
> Host: localhost:80
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json
< Vary: Origin
< Vary: Origin
< X-Request-Id: 101cac61107c/SEoisGvJtd-001467
< Date: [REDACTED]
< Content-Length: 51
< 
{"error":{"message":"sink request process error"}}
* Connection #0 to host localhost left intact

And in the Docker Compose log, Corteza server only reports the following:

server-1  | [REDACTED]        DEBUG   actionlog               {"timestamp": [REDACTED], "requestOrigin": "api/rest", "requestID": "101cac61107c/SEoisGvJtd-001467", "actorIPAddr": [REDACTED], "actorID": "0", "resource": "system:sink", "action": "request", "severity": 0, "error": "sink request process error", "description": "", "policy-match": true, "meta": {"sinkParams":null}}

What am I missing from the sink config? As I’ve understood the documentation I’ve read, this workflow should fire on any sink call using the wide-open sink signature.

#2

Honestly hard to say what might be the problem without having access. Do the server logs say anything (make sure you have debug enabled in .env).

Otherwise, another way is to use the Integration Gateway to do the same thing.

#3

I’ve posted the only debug message I’m getting in Corteza’s log in my original post.

I had tried generating my team’s use case in Integration Gateway (or at least the toy version of it), but ran into workflow execution problems there as well. So assuming all things being equal and considering the use case, we’d prefer to use sinks with signatures and (eventually) constraints.

EDIT 1: This is a brand-new deployment of v2023.9.8. The only things changed are the enabled debug logs, the two workflows, & some sink signature generation.

EDIT 2: Details from the trigger:

image
image966×996 74.4 KB

#4

Strange, will try it out on my own to see what happens. I don’t really know what is wrong just from the description of the issue/screenshots.

EDIT: If you try just the trigger and the debug, does it work? Also, make sure your “run as” user has valid permissions.

#5

Thanks for your continued support, @jfortun. I sincerely appreciate your insights!

My “Dan C. Wlodarski” account (the one assigned as the workflow’s “Run as” account & the only account currently on this Corteza deployment) is a super administrator.

Removing the Prompt and the Termination blocks does seem to allow the workflow to execute, but only once. The following curl call results in a log with two messages (immediately after the CLI example):

$ curl -v http://localhost/api/system/sink?__sign=[SIGNATURE REDACTED]

server-1  | 15:07:28.315        DEBUG   workflow.workflow     debug   {"sessionID": "406689199084535809", "stateID": "406689199084601345", "stepID": "19", "scopeKeyCount": 4, "eventType": "onRequest", "eventTypeType": "String", "resourceType": "system:sink", "resourceTypeType": "String", "invoker": "0", "invokerType": "Any", "runner": "405391855571501057", "runnerType": "Any"}
server-1  | 15:07:28.341        DEBUG   actionlog             {"timestamp": "15:07:28.341", "requestOrigin": "api/rest", "requestID": "40f1c6166223/RgSb6j7qHy-000243", "actorIPAddr": "192.168.240.1", "actorID": "0", "resource": "system:sink", "action": "request", "severity": 0, "error": "sink request process error", "description": "", "policy-match": true, "meta": {"sinkParams":null}}

Notice both the workflow.workflow message and the action message. But upon running it again, only an action message is generated:

server-1  | 15:11:47.459        DEBUG   actionlog             {"timestamp": "15:11:47.459", "requestOrigin": "api/rest", "requestID": "40f1c6166223/RgSb6j7qHy-000244", "actorIPAddr": "192.168.240.1", "actorID": "0", "resource": "system:sink", "action": "request", "severity": 0, "error": "sink request process error", "description": "", "policy-match": true, "meta": {"sinkParams":null}}

Re-adding the Termination block results in the workflow.workflow log message appearing with each sink call. Without termination, I’m guessing the last run/instance of the workflow never completes and the next run is blocked/rejected. Is this correct?

Also, is there a way I can fire a notification upon receipt of a sink?