[Question] Deserializing events from a Message Bus about commercetools-dotnet-core-sdk-v2 HOT 21 CLOSED

If the event holds a Message the notificationType will be of type Message and the ISubscriptionDelivery will be deserialized correctly as a https://github.com/commercetools/commercetools-dotnet-core-sdk-v2/blob/master/commercetools.Sdk/commercetools.Sdk.Api/Generated/Models/Subscriptions/IMessageDelivery.cs

See also

from commercetools-dotnet-core-sdk-v2.

Yes and it will be an instance of these classes:

But you also can pattern match on the Interfaces

from commercetools-dotnet-core-sdk-v2.

Released 2.1.1 with the fix. Should be available in some minutes

from commercetools-dotnet-core-sdk-v2.

Hi,

once you setup the subscriptions at commercetools. The platform will sent messages or events to your ServiceBus. If you configured it using the CloudEvents format you can deserialize the payload using any CloudEvents library for dotnet. If you have choosen platform format you should use the SDK Serializer to deserialize the payload to https://github.com/commercetools/commercetools-dotnet-core-sdk-v2/blob/master/commercetools.Sdk/commercetools.Sdk.Api/Generated/Models/Subscriptions/ISubscriptionDelivery.cs

More info about the delivery payload can be found here https://docs.commercetools.com/api/projects/subscriptions#delivery

from commercetools-dotnet-core-sdk-v2.

In case you only need the serializerservice you can use the UseCommercetoolsApiSerialization method:

https://github.com/commercetools/commercetools-dotnet-core-sdk-v2/blob/master/commercetools.Sdk/commercetools.Sdk.Api/DependencyInjectionSetup.cs#L61

And then the ServiceProvider to retrieve a SerializerService instance

from commercetools-dotnet-core-sdk-v2.

Thank you, any chance to have a sample using your tools (ie SDK Serializer) to consume events ? I'm not familiar with this approach

from commercetools-dotnet-core-sdk-v2.

Please see

to register the SerializationService to the ServiceProvider and

How to deserialize the payload

from commercetools-dotnet-core-sdk-v2.

Thank you for the sample/integration test.

I guess I misunderstood something, looking at the the "Resources/Messages/ResourceCreatedPayload.json" content and the ResourceCreatedDelivery/ResourceUpdatedDelivery/ResourceDeletedDelivery, the event doesn't transport data from the event itself (ie ECST), let's say a ProductCreatedMessage with its productProjection ?

Then is the recommandation to :

• trigger on event consumption, deserialize as ResourceCreatedDelivery/ResourceDeleteDelivery/ResourceUpdatedDelivery object
• detect wich entity is concerned by an action, then query it using the Messages Query HTTP API let's say using it's ID ?
• the returned object is strongly typed ? (ie ProductCreatedMessage)

Am I right ?

from commercetools-dotnet-core-sdk-v2.

If the event holds a Message the notificationType will be of type Message ...

I was missing this part, it's realy clear then. I guess we can apply pattern matching on

from commercetools-dotnet-core-sdk-v2.

Ok ! I guess it will be easier to deal with it once we'll have events to play with on the Bus.

Thank you very much for your time and explanations. If further questions come to me, do I have to reach the another communication channel (Jira, support email ...) ? or Github issue is fine ?

from commercetools-dotnet-core-sdk-v2.

Questions regarding the SDK itself are fine to be asked at Github :)

from commercetools-dotnet-core-sdk-v2.

Thank you, I close the issue then. Have a good day

from commercetools-dotnet-core-sdk-v2.

@jenschude I'm sorry to bother you again, but I played a bit with the tests from the lib to have a better understanding of how does it works, this part is critical for our own integration, so I have few more questions :

Correct me if I'm wrong, but as I understood, in the following test :

On the other hand deserializing str payload as IMessage (or as List<IMessage>) allows to access strongly typed messages without any extra deserialization

Example with a mixed json ("notificationType": "Message" and "notificationType" != "Message")

1. Considering a raw string consumed from the bus, am I supposed to try both ISubscriptionDelivery and IMessage deserializations to get my strongly typed event ? Or the subscribers to the bus expect to have filtered events coming in, then we can safely try to deserialize as ISubscriptionDelivery or as IMessage only as we will always receive the same kind of events from a subscriber perspective ?

2. In the second test when
   

   commercetools-dotnet-core-sdk-v2/commercetools.Sdk/Tests/commercetools.Api.Serialization.Tests/MessagesTests.cs

   Line 129 in cdf1935

   var categoryCreatedMessage = serializerService.Deserialize<CategoryCreatedMessage>(serialized);

   
   How can you infer the T type ? Should we inspect the str payload itself ? Or is it for test purpose only and most of the time (always ?) we try to deserialize as IMessage directly ?

3. What is the typical scenario of events beeing produced lets say when a Product is created on commercetools?
   Do we receive both "notificationType": "ResourceCreated" message and "notificationType": "Message" with "type": "ProductCreated" message ?
   Are there scenarii where we don't receive both ?
   As we'll react to these events, especially with data synchronization operations in our downstreams we have to know if we can 'ignore' notificationType" != "Message" for example, only dealing with notificationType" : "Message" or some use cases need to deal with both ?

4. When the payload is not provided (PayloadNotIncluded != null), which API do we have to call to get it from a sync remote call ?

Again, thank you for your time

from commercetools-dotnet-core-sdk-v2.

Hi @jenschude
We plan to start the integration POC next week, we are currenlty following the 'Functional Training Session' (with Calvin and Michael).
Well do I need to switch to a more 'official' channel, as we bought an official licence ? Or is it part of the '.net SDK Training' that I should ask my questions ? Indeed we would like to avoid bad practices and follow your guidelines as much as possible, it'll save us time.
So if you've some time to deal with my questions, many thanks

from commercetools-dotnet-core-sdk-v2.

Oh man I now took a closer look and found a hole in the logic as the Message is not unmarshalled when using the MessageDelivery. Next week we can fix this and also extend the tests with some different use cases. Nevertheless the deserialization depends on the type of the Subscription and can be simplified if necessary

from commercetools-dotnet-core-sdk-v2.

Btw when using Azure you could also use the CloudEvents format instead of the platform format. Especially as Azure already comes with native CloudEvents support. The data payload of the Event would then be the Message and you could use the SerializerService to deserialize it to the respective class instance

from commercetools-dotnet-core-sdk-v2.

@jenschude

Thank you for your feedback (and running PR).
Well with this fix, when do you try to deserizalize the Azure Service Bus raw string as ISubscriptionDelivery rather than IMessage ? Should we inspect the raw string on some existing field to choose ?
We basically need the event carrying data that has been produced from the mutation in CT.

It's not clear to me in which case you use one rather than another

Thank you

from commercetools-dotnet-core-sdk-v2.

This is what the CloudEvent payload for a Message subscription would look like.

To my knowlegde there is a CloudEvent library available from Azure which could be used to deserialize this payload. The data field itself could then be mapped to the IMessage interface, as the delivery related fields are included in the cloud event itself.

           {
             "specversion": "1.0",
             "id" : *any-uuid*,
             "type" : "com.commercetools.product.message.ProductPublished",
             "source" : "/<project-key>/products",
             "subject" : "<product-id>",
             "time" : *any-date-time*,
             "sequence" : "3",
             "sequencetype" : "Integer",
             "dataref": "/<project-key>/messages/<msg-id>",
             "data": {
               "notificationType": "Message",
               "projectKey": "<project-key>",
               "version": 1,
               "sequenceNumber": 3,
               "resource": {
                 "typeId": "product",
                 "id": "<product-id>"
               },
               "resourceUserProvidedIdentifiers": {
                 "key": "subscription-product",
                 "slug": <product-slug>
               },
               "removedImageUrls": [],
               "productProjection": {
                 "id": "<product-id>",
                 "version": 4,
                 "productType": {
                   "typeId": "product-type",
                   "id": "<product-type-id>"
                 },
                 "categories": [],
                 "categoryOrderHints": {},
                 "searchKeywords": {},
                 "hasStagedChanges": false,
                 "published": true
               },
               "resourceVersion": 4,
               "type": "ProductPublished"
             }
           }

from commercetools-dotnet-core-sdk-v2.

Ok we'll try both approachs : raw string and CloudEvent messages and see what best suits our needs.
But both should produces the same deserialized object, doesn't it ?

from commercetools-dotnet-core-sdk-v2.

They should as the json structure is the same.

The nice thing about the CloudEvents format would be, that you could route the events in the Azure Event Grid natively.

from commercetools-dotnet-core-sdk-v2.

Yes, and it gives a formalism.
Well the 'auto routing' events is a great, but my final sink is Kafka :-/

from commercetools-dotnet-core-sdk-v2.