Notification for Logistics Event creation

[aloccid-iata]

Problem Statement

Today, when a new Logistics Event has been created, a subscriber receives a notification where hasEventType is equal to _LOGISTICS_EVENTRECEIVED (see example below).

POST /notifications HTTP/1.1
Content-Type: application/ld+json; version=2.0.0-dev
Accept: application/ld+json; version=2.0.0-dev

{
    "@context": {        
        "api": "https://onerecord.iata.org/ns/api#"
    },
    "@type": "api:Notification",
    "api:hasEventType": {
        "@id": "api:LOGISTICS_EVENT_RECEIVED"
    },
    "api:hasLogisticsObject": {
        "@id": "https://1r.example.com/logistics-objects/1a8ded38-1804-467c-a369-81a411416b3c"
    },
    "api:hasLogisticsObjectType": {
        "@type": "http://www.w3.org/2001/XMLSchema#anyURI",
        "@value": "https://onerecord.iata.org/ns/cargo#Shipment"
    } 
}

However, the notification does not contains any direct link to the logistics event.

Proposal

Shall we add a optional api:hasLogisticsEvent in the notification object and populate it only in case hasEventType is equal to _LOGISTICS_EVENTRECEIVED?

[nscheiber-champ]

I think this addition makes sense. I assume most parties receiving an LogisticsEvent notification would want to read it immediately. This enables a precise request of what was just recorded.

Additionally, akin to sendLogisticsObjectBody, subscriptions may also want to deliver the LogisticsEvent body by default. Hence, if this is touched, it might make sense to add a sendLogisticsEventBody flag to subscriptions as well. To save another request.

[astein-iamovers]

This makes a lot of sense for the moving industry's use case. Subscribers need to access the Logistics Event and the id is missing in the notification object. It would also be useful to include the body on the Notification object by default.

[aloccid-iata]

Hi all, I see a lot of discussion about this topic. My suggestion is to add a new api:hasLogisticsEvent and populate it with the full Logistics event URI. On the contrary, I am against send either the logistics object and the logistics event body mainly to :

• Avoid any data leak
• Prevent the usage of notification as messaging system
• Keep the notification as small as possible

I am going to check what was the driving idea behind sendLogisticsObjectBody and add more information to the jira issue. Ultimately, when you receive a notification you have the details to get the correct object (and with this change the correct logistics event). The additional GET call shouldn't impact the system performances.

Best, Davide

[nscheiber-champ]

Hello all, I am fine with either approach as long as we are consistent. Either all bodies, or no bodies.

If this is touched , it might make sense to send a form of change/event summary to subscribers to determine whether it is worth to update internal databases.

For event notifications, it could include the cargo:eventCode and cargo:eventName. For LO Patch, it could include arrays of the api:p for api:ADD and api:DELETE.

Especially for events, this would reduce server load.

Let me know what you think?

Cheers Niclas