Skip to main content

I received a service bus connection string in the following format:

Endpoint=sb://sb-sb-s-sbb-mastersupa.servicebus.windows.net/;SharedAccessKeyName=Andblablablab;SharedAccessKey=blablablablablablalbablablablabla+blablabla=;EntityPath=moreblablablablablatest

But it gives me an error in FME 2019,2020,2021

Is says: Error: claim is empty or token is invalid.

Should I enter the string in another format?

 

Also: In 2022 and 2023 I get an error: No module named ‘uamqp’. Looks like this module is not available in this Python library set?

Is there any documentation on the AzureServiceBus Connector and a way to debug the message: claim is empty or token is invalid?


Hello @jkr_da 

The No module named ‘uamqp’ error should be resolved between FME 2022.1+ and 2023.x by using the Azure Service Bus FME package version 1.0.2. Are you able to try upgrading the Azure Service Bus package version in Tools > FME Options > FME Packages?

As for the other issue, are you able to connect to the Azure Service Bus outside of FME using the same connection string? Within FME, it is possible more information may be logged if you enable Log Debug messages (Tools > FME Options > Translation > Log Message Filter).


The new update fixes 2023 to the same level as 2021, getting equal error messages.

 

Looks like it is working, a little.

I cannot select a queue when clicking on the ‘…’-icon next to the queue. But if I fill in a queue I can listen to the queue. I cannot do Count Messages on the queue, i get “Manage,EntityRead claims required for this operation.”, so it seems there is a queue but I don't have enough rights.

There are no messages in the queue so it waits for hours keeping the Engine occupied.

So it mostly looks like the other side is being very conservative about rights/permissions.


Hello @jkr_wrk 

I’m glad to hear updating the Azure Service Bus FME package fixes the import error message in 2023.

You can specify ‘batch mode’ for the Receive Mode parameter when Receive from Queue or Receive from Subscription actions are selected in AzureServiceBusConnector. This allows the connection to be closed once a specified number of messages is received and the workspace will finish. However, the job will still occupy an engine until a message is received.

If your concern is a job continuously occupying an engine while waiting for a message, you may want to ask the connection string provider to give permission to count messages. You can then implement logic to process messages if there are messages in the queue or subscription.


I would have liked to be able to get all the new messages every 10min and then end the job. But I guess the count messages should fix that.

Still a bit worried that I do a count messages, get a result of 1 and then do a get messages batch 1 and the message is mysterious gone. And then my FME Flow it waiting for days to get that 1 message that will never appear.

Stream transformers are really bad when you pay for Engines by the hour.


Reply