5.6. Migration

For a majority of our users and accounts, we have handled the migration from the previous system on your behalf without impact and there is nothing for you to do. You will see all the new notification menu's and no longer any of the old.

 

Otherwise you will be in a temporary transition phase where you will see both the old version and the new version. The menus are labeled as such to help you recognize easily the differences. We've also added a banner on soon to be removed menus. In this mode you will have the full capabilities on the new notifications but you will no longer be able to create any old notifications. These menus will be read only with the only ability being to delete.

 

We have also already created the 3 below default agents, that will act as the old Alerts:

• Messages waiting for download
• Certificates expiration
• Gateway polling failure

During this phase it is important that you replace old notifications with agents or extra processings (see below). Please delete the old notifications as you go about this process to ensure a clean status when moving exclusively to the new service.

To do this please follow the below steps:

• Create or update an existing agent
• Remove the Old Notification from the channel
• Deploy the channel
• Delete the notification from the old notifications menu under components

We will continue to scan non migrated environments and make the full switch as soon as we no longer see any old notifications anymore.

Please note, we would like to target October to remove the old service, so don't hesitate to let us know how we can help you in this process.

Extra processings

The old notification service was used to notify users, in the sense of drawing their attention to something that happened in the application. For all these use cases, it is very easy to create agents that do similar notifications (even much better).

But the old notification service was also used for cases that have nothing to do with notifications, but was in fact part of the business processing of the individual message. For example : 

• Dispatch the message to the next channel of the processing flow, using the ability of notification V1 to dispatch differently based on the success or not of the message.
• Send an individual email fully related to the processed message. Again, notification V1 was often used in that scenario (instead of for example an Email gateway out) due to its ability to send only after the end of the processing of the message, or when success/error status is known.

For these previous use cases, you will not be able to create agents that have the same behavior as before. Instead, we have created extra-processings that have the exact same behavior of the previous agents. 

You will find the following extra-processings at various steps (gateway in, message definition in, message definition out).

In the gateway out you will also find the following 2 for messages available for download

Any of these 6 will then act exactly like the old notification and have the same parameters (send to internal gateways, customized body with metadata, dynamic receiver using metadata,…). They will cover the cases mentioned above as reasons for using extra processing.

We can also note that registering one of these extra-processings at one step of the message processing (ex: gateway IN) is enough. This will register that this additional task must be done at the end of the message processing, whatever at which step the message would fall in error.