ISubscriptionStorage equivalent for SQS/SNS Transport

Architecture & Design
, ,
1

Hi there,

We’ve recently moved from SQL Transport to SQS. Our existing tests utilize ISubscriptionStorage interface to query subscriptions and invokes GetSubscriberAddressesForMessage method.

We’re unable to access the ISubscriptionStorage interface via reflection anymore since we’ve moved to SQS transport.

Is there an equivalent interface or implementation for sqs/sns to query the subscriptions?

2

@koraybalci,

No, subscriptions are managed through SNS. You can use the SNS SDK to list topics and, for each topic, list subscriptions. That’s the same thing publisher endpoints do (when in hybrid message-driven pub/sub mode) to check who is subscribed to what.

Were you using the ISubscriptionStorage to validate in tests that subscribers’ routing was correctly configured?

3

Hi Mauro,

Thanks for the clarification.

Actually, what we are doing is to do some extra configuration and handling, when we receive a message with Subscribe intent.

So, in our test setup, we invoke our IEndpointInstance derived class with

await endpointInstance.Subscribe<TestRunReSubscribedEvent>();

// and then busy wait via Task.Delay() for a few secs.

During the busy wait, we expect the below Behavior<ITransportReceiveContext> to be invoked.

public override async Task Invoke(ITransportReceiveContext context, Func<Task> next)
{
    var intent = context.Message.Headers[Headers.MessageIntent];
    if (intent == MessageIntentEnum.Subscribe.ToString())
    {
        ... // some magic here..
    }

    await next();
}

This works nicely with sql transport.

So, with sqs/sns transport, can we still expect the above to work? In my case, the behaviour is no more invoked by the nsb pipeline.

4

That will not work anymore. With the transport using SNS for broadcasting events, there are no subscription messages. The publisher creates topics; subscribers create subscriptions to bind topics to their input queues.

A publisher cannot intercept a new subscriber. If you could explain what led you to intercept subscription messages, we could see if there are other options. If you have privacy concerns, email support [at] particular.net; we can handle it from there.

.m

1 Like
5

Hmm, bummer :slight_smile:

We were attempting to subscribe to some Salesforce events and persist that data (configuration) in our db on the fly. However, we have a scheduled job to query the same. So, this path is not really that vital to our solution.

Thanks for the clarification though. I really appreciate it!

1 Like