Open APIs

Hi,

We have below requirement from our client

• To receive a notification for a planned change  (Client need to receive notification from us(service provider))
• To receive a notification for a rescheduled change
• To receive a notification for a completed change
• The notifications shall contain:

• The start date/time of the change
• The end date/time of the change OR the duration of the change
• The impacted Colt circuit ID
• Details of the change

Note: Notification will be in the form of emails

I believe  Communication API to be used for this purpose with below options.
POST /communicationMessage and POST /communicationMessage/{id}/send
or
POST /communicationMessage/send

Please let me know whether this is correct or Change Management API to be used?

Best Regards,
Kalpana

------------------------------
Kalpana HV
Colt Technology Services
------------------------------

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services
------------------------------

Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------

Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services
------------------------------


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services
------------------------------

Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Hi, the state of the message determines when it will be sent (or more accurately ready for sending). 

POST with state==inProgress if the message is ready to be sent  or POST with state==initial if sending is deferred (triggered by an update to the state property).



------------------------------
Knut Johannessen
Telenor ASA
------------------------------

Original Message:
Sent: Sep 09, 2020 09:51
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services
------------------------------


Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Thank you @Knut Johannessen for the response. So,
1. Whether communicationMessage should be stored in a database?
2. Whether another program should send the communication message to recipient?​
Alternatively,
3. Is it OK to implement "send communication message" which will send communicationMessage to recipient without storing?

Best Regards

------------------------------
Kalpana HV
Colt Technology Services
------------------------------

Original Message:
Sent: Sep 09, 2020 10:54
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the state of the message determines when it will be sent (or more accurately ready for sending).

POST with state==inProgress if the message is ready to be sent  or POST with state==initial if sending is deferred (triggered by an update to the state property).



------------------------------
Knut Johannessen
Telenor ASA
------------------------------


Original Message:
Sent: Sep 09, 2020 09:51
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

@Knut Johannessen ,  @Jonathan Goldberg ,  @Rabinder Devnani,
Could you please let me know your thoughts.

Best Regards,​

------------------------------
Kalpana HV
Colt Technology Services
------------------------------

Original Message:
Sent: Sep 10, 2020 02:35
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen for the response. So,
1. Whether communicationMessage should be stored in a database?
2. Whether another program should send the communication message to recipient?​
Alternatively,
3. Is it OK to implement "send communication message" which will send communicationMessage to recipient without storing?

Best Regards

------------------------------
Kalpana HV
Colt Technology Services
------------------------------


Original Message:
Sent: Sep 09, 2020 10:54
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the state of the message determines when it will be sent (or more accurately ready for sending).

POST with state==inProgress if the message is ready to be sent  or POST with state==initial if sending is deferred (triggered by an update to the state property).



------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 09, 2020 09:51
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Hi, the conformance specification (to be published real soon) will indicate that the GET operation is mandatory for the Communication Message resource.

A reasonable expectation by a client would be that a recently posted Communication Message can be queried by a following GET. 

Regarding implementation, the provider of TMF681 takes on the responsibility of ensuring that the messages is delivered to the recipients.
Multiple scenarios are possible for how this can be achieved. 

From a practical perspective, the message will always have to be stored "somewhere" behind the API. That "somewhere" can either be in the control of the party implementing the API or offered by some backend service leveraged by the API.

Would recommend that any implementation of TMF681 properly supports the GET - ref. the conformance specification soon to be published.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA
------------------------------

Original Message:
Sent: Sep 14, 2020 02:42
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen ,  @Jonathan Goldberg ,  @Rabinder Devnani,
Could you please let me know your thoughts.

Best Regards,​

------------------------------
Kalpana HV
Colt Technology Services
------------------------------


Original Message:
Sent: Sep 10, 2020 02:35
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen for the response. So,
1. Whether communicationMessage should be stored in a database?
2. Whether another program should send the communication message to recipient?​
Alternatively,
3. Is it OK to implement "send communication message" which will send communicationMessage to recipient without storing?

Best Regards

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 09, 2020 10:54
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the state of the message determines when it will be sent (or more accurately ready for sending).

POST with state==inProgress if the message is ready to be sent  or POST with state==initial if sending is deferred (triggered by an update to the state property).



------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 09, 2020 09:51
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Thank you @Knut Johannessen. After storing the communication message, is it OK to implement "POST /communicationMessage/{ID}/send" to  send  the communicationMessage​?

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services
------------------------------

Original Message:
Sent: Sep 14, 2020 03:27
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the conformance specification (to be published real soon) will indicate that the GET operation is mandatory for the Communication Message resource.

A reasonable expectation by a client would be that a recently posted Communication Message can be queried by a following GET.

Regarding implementation, the provider of TMF681 takes on the responsibility of ensuring that the messages is delivered to the recipients.
Multiple scenarios are possible for how this can be achieved.

From a practical perspective, the message will always have to be stored "somewhere" behind the API. That "somewhere" can either be in the control of the party implementing the API or offered by some backend service leveraged by the API.

Would recommend that any implementation of TMF681 properly supports the GET - ref. the conformance specification soon to be published.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA
------------------------------


Original Message:
Sent: Sep 14, 2020 02:42
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen ,  @Jonathan Goldberg ,  @Rabinder Devnani,
Could you please let me know your thoughts.

Best Regards,​

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 10, 2020 02:35
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen for the response. So,
1. Whether communicationMessage should be stored in a database?
2. Whether another program should send the communication message to recipient?​
Alternatively,
3. Is it OK to implement "send communication message" which will send communicationMessage to recipient without storing?

Best Regards

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 09, 2020 10:54
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the state of the message determines when it will be sent (or more accurately ready for sending).

POST with state==inProgress if the message is ready to be sent  or POST with state==initial if sending is deferred (triggered by an update to the state property).



------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 09, 2020 09:51
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Hi, as there is no operation like


Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA
------------------------------

Original Message:
Sent: Sep 14, 2020 07:45
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen. After storing the communication message, is it OK to implement "POST /communicationMessage/{ID}/send" to  send  the communicationMessage​?

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services
------------------------------


Original Message:
Sent: Sep 14, 2020 03:27
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the conformance specification (to be published real soon) will indicate that the GET operation is mandatory for the Communication Message resource.

A reasonable expectation by a client would be that a recently posted Communication Message can be queried by a following GET.

Regarding implementation, the provider of TMF681 takes on the responsibility of ensuring that the messages is delivered to the recipients.
Multiple scenarios are possible for how this can be achieved.

From a practical perspective, the message will always have to be stored "somewhere" behind the API. That "somewhere" can either be in the control of the party implementing the API or offered by some backend service leveraged by the API.

Would recommend that any implementation of TMF681 properly supports the GET - ref. the conformance specification soon to be published.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 14, 2020 02:42
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen ,  @Jonathan Goldberg ,  @Rabinder Devnani,
Could you please let me know your thoughts.

Best Regards,​

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 10, 2020 02:35
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen for the response. So,
1. Whether communicationMessage should be stored in a database?
2. Whether another program should send the communication message to recipient?​
Alternatively,
3. Is it OK to implement "send communication message" which will send communicationMessage to recipient without storing?

Best Regards

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 09, 2020 10:54
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the state of the message determines when it will be sent (or more accurately ready for sending).

POST with state==inProgress if the message is ready to be sent  or POST with state==initial if sending is deferred (triggered by an update to the state property).



------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 09, 2020 09:51
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Thank you @Knut Johannessen.  Should we have a scheduler like program to send stored communicationMessage to client?

Best Regards.

------------------------------
Kalpana HV
Colt Technology Services
------------------------------

Original Message:
Sent: Sep 14, 2020 08:32
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, as there is no operation like

POST /communicationMessge/{ID}/send 

in the latest TMF681 API specification, that would at least not be a conformant implementation.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA
------------------------------


Original Message:
Sent: Sep 14, 2020 07:45
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen. After storing the communication message, is it OK to implement "POST /communicationMessage/{ID}/send" to  send  the communicationMessage​?

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 14, 2020 03:27
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the conformance specification (to be published real soon) will indicate that the GET operation is mandatory for the Communication Message resource.

A reasonable expectation by a client would be that a recently posted Communication Message can be queried by a following GET.

Regarding implementation, the provider of TMF681 takes on the responsibility of ensuring that the messages is delivered to the recipients.
Multiple scenarios are possible for how this can be achieved.

From a practical perspective, the message will always have to be stored "somewhere" behind the API. That "somewhere" can either be in the control of the party implementing the API or offered by some backend service leveraged by the API.

Would recommend that any implementation of TMF681 properly supports the GET - ref. the conformance specification soon to be published.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 14, 2020 02:42
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen ,  @Jonathan Goldberg ,  @Rabinder Devnani,
Could you please let me know your thoughts.

Best Regards,​

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 10, 2020 02:35
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen for the response. So,
1. Whether communicationMessage should be stored in a database?
2. Whether another program should send the communication message to recipient?​
Alternatively,
3. Is it OK to implement "send communication message" which will send communicationMessage to recipient without storing?

Best Regards

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 09, 2020 10:54
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the state of the message determines when it will be sent (or more accurately ready for sending).

POST with state==inProgress if the message is ready to be sent  or POST with state==initial if sending is deferred (triggered by an update to the state property).



------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 09, 2020 09:51
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

@Knut Johannessen, @Jonathan Goldberg, @Rabinder Devnani, Could you please let me know your thoughts.​​​

Best Regards

------------------------------
Kalpana HV
Colt Technology Services
------------------------------

Original Message:
Sent: Sep 14, 2020 10:21
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen.  Should we have a scheduler like program to send stored communicationMessage to client?

Best Regards.

------------------------------
Kalpana HV
Colt Technology Services
------------------------------


Original Message:
Sent: Sep 14, 2020 08:32
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, as there is no operation like

POST /communicationMessge/{ID}/send 

in the latest TMF681 API specification, that would at least not be a conformant implementation.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 14, 2020 07:45
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen. After storing the communication message, is it OK to implement "POST /communicationMessage/{ID}/send" to  send  the communicationMessage​?

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 14, 2020 03:27
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the conformance specification (to be published real soon) will indicate that the GET operation is mandatory for the Communication Message resource.

A reasonable expectation by a client would be that a recently posted Communication Message can be queried by a following GET.

Regarding implementation, the provider of TMF681 takes on the responsibility of ensuring that the messages is delivered to the recipients.
Multiple scenarios are possible for how this can be achieved.

From a practical perspective, the message will always have to be stored "somewhere" behind the API. That "somewhere" can either be in the control of the party implementing the API or offered by some backend service leveraged by the API.

Would recommend that any implementation of TMF681 properly supports the GET - ref. the conformance specification soon to be published.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 14, 2020 02:42
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen ,  @Jonathan Goldberg ,  @Rabinder Devnani,
Could you please let me know your thoughts.

Best Regards,​

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 10, 2020 02:35
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen for the response. So,
1. Whether communicationMessage should be stored in a database?
2. Whether another program should send the communication message to recipient?​
Alternatively,
3. Is it OK to implement "send communication message" which will send communicationMessage to recipient without storing?

Best Regards

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 09, 2020 10:54
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the state of the message determines when it will be sent (or more accurately ready for sending).

POST with state==inProgress if the message is ready to be sent  or POST with state==initial if sending is deferred (triggered by an update to the state property).



------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 09, 2020 09:51
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Hi, there are two requirements that you should consider: 
- the Communication API allows the sending of the message to be scheduled
- there is likely a need to handle errors when a downstream system is unsuccessful in sending (forwarding) the message and respond with an error to the provider of the Communication API

The implementor of the provider of the Communication API could choose to handle both of these requirements with some scheduling capability. 

Br, Knut


------------------------------
Knut Johannessen
Telenor ASA
------------------------------

Original Message:
Sent: Sep 15, 2020 02:00
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen, @Jonathan Goldberg, @Rabinder Devnani, Could you please let me know your thoughts.​​​

Best Regards

------------------------------
Kalpana HV
Colt Technology Services
------------------------------


Original Message:
Sent: Sep 14, 2020 10:21
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen.  Should we have a scheduler like program to send stored communicationMessage to client?

Best Regards.

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 14, 2020 08:32
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, as there is no operation like

POST /communicationMessge/{ID}/send 

in the latest TMF681 API specification, that would at least not be a conformant implementation.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 14, 2020 07:45
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen. After storing the communication message, is it OK to implement "POST /communicationMessage/{ID}/send" to  send  the communicationMessage​?

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 14, 2020 03:27
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the conformance specification (to be published real soon) will indicate that the GET operation is mandatory for the Communication Message resource.

A reasonable expectation by a client would be that a recently posted Communication Message can be queried by a following GET.

Regarding implementation, the provider of TMF681 takes on the responsibility of ensuring that the messages is delivered to the recipients.
Multiple scenarios are possible for how this can be achieved.

From a practical perspective, the message will always have to be stored "somewhere" behind the API. That "somewhere" can either be in the control of the party implementing the API or offered by some backend service leveraged by the API.

Would recommend that any implementation of TMF681 properly supports the GET - ref. the conformance specification soon to be published.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 14, 2020 02:42
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen ,  @Jonathan Goldberg ,  @Rabinder Devnani,
Could you please let me know your thoughts.

Best Regards,​

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 10, 2020 02:35
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen for the response. So,
1. Whether communicationMessage should be stored in a database?
2. Whether another program should send the communication message to recipient?​
Alternatively,
3. Is it OK to implement "send communication message" which will send communicationMessage to recipient without storing?

Best Regards

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 09, 2020 10:54
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the state of the message determines when it will be sent (or more accurately ready for sending).

POST with state==inProgress if the message is ready to be sent  or POST with state==initial if sending is deferred (triggered by an update to the state property).



------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 09, 2020 09:51
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Thank you very much @Knut Johannessen.​

------------------------------
Kalpana HV
Colt Technology Services
------------------------------

Original Message:
Sent: Sep 15, 2020 04:40
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, there are two requirements that you should consider:
- the Communication API allows the sending of the message to be scheduled
- there is likely a need to handle errors when a downstream system is unsuccessful in sending (forwarding) the message and respond with an error to the provider of the Communication API

The implementor of the provider of the Communication API could choose to handle both of these requirements with some scheduling capability.

Br, Knut


------------------------------
Knut Johannessen
Telenor ASA
------------------------------


Original Message:
Sent: Sep 15, 2020 02:00
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen, @Jonathan Goldberg, @Rabinder Devnani, Could you please let me know your thoughts.​​​

Best Regards

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 14, 2020 10:21
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen.  Should we have a scheduler like program to send stored communicationMessage to client?

Best Regards.

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 14, 2020 08:32
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, as there is no operation like

POST /communicationMessge/{ID}/send 

in the latest TMF681 API specification, that would at least not be a conformant implementation.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 14, 2020 07:45
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen. After storing the communication message, is it OK to implement "POST /communicationMessage/{ID}/send" to  send  the communicationMessage​?

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 14, 2020 03:27
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the conformance specification (to be published real soon) will indicate that the GET operation is mandatory for the Communication Message resource.

A reasonable expectation by a client would be that a recently posted Communication Message can be queried by a following GET.

Regarding implementation, the provider of TMF681 takes on the responsibility of ensuring that the messages is delivered to the recipients.
Multiple scenarios are possible for how this can be achieved.

From a practical perspective, the message will always have to be stored "somewhere" behind the API. That "somewhere" can either be in the control of the party implementing the API or offered by some backend service leveraged by the API.

Would recommend that any implementation of TMF681 properly supports the GET - ref. the conformance specification soon to be published.

Br,
Knut

------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 14, 2020 02:42
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen ,  @Jonathan Goldberg ,  @Rabinder Devnani,
Could you please let me know your thoughts.

Best Regards,​

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 10, 2020 02:35
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Knut Johannessen for the response. So,
1. Whether communicationMessage should be stored in a database?
2. Whether another program should send the communication message to recipient?​
Alternatively,
3. Is it OK to implement "send communication message" which will send communicationMessage to recipient without storing?

Best Regards

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Sep 09, 2020 10:54
From: Knut Johannessen
Subject: TMF681 Communication API Usecase

Hi, the state of the message determines when it will be sent (or more accurately ready for sending).

POST with state==inProgress if the message is ready to be sent  or POST with state==initial if sending is deferred (triggered by an update to the state property).



------------------------------
Knut Johannessen
Telenor ASA


Original Message:
Sent: Sep 09, 2020 09:51
From: Kalpana HV
Subject: TMF681 Communication API Usecase

@Knut Johannessen & @Jonathan Goldberg in  the latest specification, "send communication message" operations are not available. Could you please let me know when could the message be actually sent and how to send the message to recipient? Could the "Create communication message" ​operation can be used for sending the message to actual recipient. ​

Best Regards,

------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 23, 2020 06:37
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

I'm not an expert on the Communication API. My simple understanding is that from the point of view of the consumer (the software that wants to send a message), the Communication API abstracts the mode of communication. The implementation of the API would be expected to honor communication preferences of the recipient, and that might be the subject of a separate Preferences API (which I believe is in planning).

Regarding the sending of a calendar, it would have to be done as an attachment, since the communication message itself does not have mime type on the message content. And that means that your implementation of the API would need to honor the attachment (and of course send it only on supporting communication mode, e.g. by SMS you might insert an accessible link to the calendar, perhaps).

But adding @Knut Johannessen to this thread, since he is the lead for the API. ​

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.


Original Message:
Sent: Jul 21, 2020 09:19
From: Kalpana HV
Subject: TMF681 Communication API Usecase

Thank you @Jonathan Goldberg. It helped.
Another question, I believe Communication API is NOT particular on the ​communication mode with clients. It could be email/SMS/etc and hence, sending the notification through email and attachment as iCalender (MIME content Type: text/calendar) is also allowed. Is this correct?

Best Regards,
Kalpana


------------------------------
Kalpana HV
Colt Technology Services


Original Message:
Sent: Jul 21, 2020 08:30
From: Jonathan Goldberg
Subject: TMF681 Communication API Usecase

Hi Kalpana
I'm not an expert in the area of Change Management.
But it seems to me that the Change Management API is responsible for managing the whole process of a change, including approvals, mods, rejections, etc.
The actual communication of such to the end customer would seem to need to go through Communication API, since this abstracts the way we communicate with a customer (preferred means of communication, times of day and days of week for communication, etc.)
So I think I agree with you that you should use the Communication API.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.