SQS Inbound connector Correlation key (payload)

Camunda 8 Topics
,
1

Hi,

For some reason I cannot make SQS Inbound connector work. I have an SQS intermediate catch event configured to listen to the queue. I’m wondering what is the correct format for Correlation key (payload)?

I want connector to look for correlation key in message attributes. Documentation here says

For example, given that your correlation key is defined with myCorrelationKey process variable, and the request body contains "messageAttributes":{"key":{"stringValue":"value"}}, your correlation key settings will look like this:

  • Correlation key (process): =myCorrelationKey
  • Correlation key (payload): =body.messageAttributes.key.stringValue

But it’s am SQS message, it doesn’t have “request body”. Value in example doesn’t work, I’m not sure sqs message has “body.messageAttributes”

Can anyone give me a bit of advice please? What is the correct format for Correlation key (payload)?

2

Hi @Sergey, welcome to the forums! I admit I have not used the SQS Inbound Connector yet, so this is some guesswork. The data sent to the Connector is returned in a variable called body. So if the message you are receiving is { "a": 1, "b": { "c": 2 } }, the FEEL expression to set the correlation key to the value of c would be =body.b.c. Give that a try and let me know if it works!

3

Hi @nathan.loding. Thank you for your reply.
Unfortunately it didn’t work. I tried different combinations:

to get correlation key from message body

  • body.body
  • body.Body

to get correlation key from message attributes (“key” is the name of attribute)

  • body.messageAttributes.key.stringValue
  • body.MessageAttributes.key.stringValue
  • body.MessageAttributes.key.StringValue

I also tried SNS topic with SQS subscription with the same result.

I wonder if this can be related to that I’m using localstack instead of real SQS query for local testing. It doesn’t show any errors, just stuck on a step:
image

However, SQS outbound connector works with localstack and I can see message in queue.

4

@Sergey - it all depends on what data is contained in the SQS message. Did you set a message attribute named stringValue? The correlation key is something you control, not Camunda or SQS, so it must be a value that you set in the message.

I think the first thing to do is find out exactly what data SQS is sending to the Connector. Can you see the value inside Operate?

5

Yes, I understand that. To send message to queue I use AWS cli, like this:

aws sqs send-message --queue-url http://localhost:4566/000000000000/camunda-connector-in --message-attributes '{"key":{"StringValue":"key_value","DataType":"String"}}' --message-body 'Hello, I am body'

I just cannot get the mapping scheme that connector runtime use.
From SQS connector source code I can see that it parses SQS message to Java object. But how it maps FEEL expression to properties of this object is a mystery for me. Examples from documentation don’t work, so my guess is that connector doesn’t read from queue at all. Again, perhaps because it is localstack. Seems like testing with real SQS queue is inevitable in my case

I think the first thing to do is find out exactly what data SQS is sending to the Connector. Can you see the value inside Operate?

Is it possible to see raw message coming from queue in Operate? I don’t have any links\buttons\logs for this. Do you have a screenshot or something? It would be extremely helpful

UPD: doesn’t work with real SQS as well. I’m doing something wrong for sure

6

Hi @Sergey - I think you should be able to view the message inside Operate in the “Instance History” pane. I have not tested this with the SQS Connector, but that is the first place I would check.

image
image2494×492 58.8 KB

7

@nathan.loding I may have found the issue.

Seems like inbound connectors don’t work without Operate API authentication, which is disabled in variables for local deployment. I don’t have identity component installed. Seems like I need to adjust my helm chart variables and redeploy.

I tried with:

connectors:
  enabled: true
  inbound:
    mode: credentials

but now my “connectors” pod cannot start. I must be missing something

8

@Sergey - I should have asked if you were using Self-Managed or SaaS! Oops! Yes, you are correct, inbound connections require Operate and Identity (outbound connectors are essentially fancy job workers, so they don’t need additional infrastructure outside of starting the Connector Runtime; inbound has several additional needs that can’t be provided by the process engine alone).

What errors are you getting with the Connectors pod? Can you share the events and/or logs? Also, if you could share your Helm chart values configuration, that would help diagnose the issue too (be sure to remove any sensitive information that might be in it!)

9

Hi @Sergey

Welcome to the Camunda Forum! Could you try please messageAttributes.myKey.stringValue? (without body)

10

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.