C8Y Notification 2: getting 404 error

Product/components used and version/fix level:

1015.0.455

Detailed explanation of the problem:

I have a microservice that is using Notification 2 API to listen to real-time events. The microservice can run well in APJ environment (ver 1018.0.225), but when I deploy it to our customer env (ver 1015.0.455), I receive 404 error with Notification 2 API.

Error messages / full error message screenshot / log file:

Question related to a free trial, or to a production (customer) instance?

production

From the requirements section here: Notifications 2.0 - Cumulocity IoT Guides

For the shared public cloud instances of the Cumulocity IoT platform, the Messaging Service is enabled by default on release 10.13 and above. For dedicated and self-hosted instances, the Messaging Service and Notifications 2.0 are available for release 10.11 and above, but will need to be explicitly enabled.
Please contact product support to inquire about using the Messaging Service and Notifications 2.0 capabilities in your Cumulocity IoT environment.

So I’d assume messaging service is not enabled on this instance and this is why you’re seeing 404 there.

To outrule any microservice-specific issues, you could try doing a GET request against /notification2/subscriptions. Is it also returning 404?

Yes I think so, I also get 404 while calling this endpoint via POSTMAN /notification2/subscriptions

I thought the Messaging Service is enabled by default since 10.13?

Depends on which type of platform you’re using. It tells to be enabled default since 10.13 on the shared public cloud instances (apj.cumulocity.com is one of them). If you’re having a dedicated platform installation, it needs to be installed/activated by the team that is operating your platform. So I’d recommend to create a support ticket asking to activate it on this environment.

1 Like

Korbinian is 100% correct. Notifications 2.0 is enabled by default in the Cumulocity shared public cloud instances: eu-latest, emea, apj, na and cumulocity.com. Hopefully I didn’t miss any there! We don’t enable it by default (yet) in dedicated instances because of the additional resource costs of the Messaging Service, but as stated in the documentation it can be enabled on request, assuming the environment has sufficient resources - at least 3 K8S workers with sufficient CPU and RAM, and enough persistent storage for expected message backlogs - to support it.

From the beginning, I test it myself, check it and try to solve problems in simple steps! And then if I can’t do it, I contact support!